Inner Space might be generally CVS related. The game does have some graphics artifacts from time to time, but I do remember this from ages ago on my Matrox Mystique as well, so that is most likely a game bug.
Do you have the Norton Benchmark (it came with Norton Desktop 3.0 - at least with my version)?

Same thing happens in System Info that came with NDW 2.0. There is also something wrong with NDW icons -- they appear grey and distorted in all modes but 8-bit. I've managed to get the same installation to Virtual PC (which conveniently emulates the same card). Cannot tell anything about 15-bit mode, that one is not supported in VPC at all. Pattern distortion happens in DOSBox in all modes except 8-bit -- does not happen in VPC. Greyscale distorted icons happen in VPC in 8-bit (!) and 16-bit modes but not 24-bit -- go figure. I tend to think that it may be some NDW problem.
There are three more interesting glitches in Win3 under DOSBox, not related to my patch (screenshots are from unpatched version). One of them is occasional font corruption when characters appear squished vertically, most pronounced in clock app. The second one is that icon shadow on the Program Manager background is white (this actually does not happen in non-8-bit modes, or it is not noticable for some reason). The last glitch I've noticed is that checkmarks in menu have black vertical bar next to them. The last two issues may be related.

Maybe try with the dynamic core. Could be some flags stuff.

Nope. It's not core-dependent. All these issues may to be results of a single bug either in XGA_DrawWait or in xga.waitcmd setup but I don't see anything wrong there. Need to do more debugging there.

There is also something wrong with NDW icons -- they appear grey and distorted in all modes but 8-bit.

I had this happen to me as well, and remembered this from way back. With NDW 3 there is a file called Icocache.dat, you need to delete it after switching from high color modes to lower ones, and sometimes to higher ones.

Fonts have been bad for some time, I always thought this is a driver issue, but yeah it kind of is everywhere,

Have a question for Vasyl, if you have the time. Looking at the latest DIFF for your S3 support - I wondered how difficult would it be for me to add the VESA v1.2 video mode 0x107 (1280x1024x8bpp) to your S3 code?

I noted the parameter table: VideoModeBlock ModeList_VGA_S3VESA but I am sure that even if the Mode list table had an additional entry that there would be more modifications necessary... 😳

If you have any general hints (and any time) it would be most welcome. It would give me a starting point to implement such a change. I would use such a VESA mode 0x107 for debugging only - no performance necessary. DOSBOX heavy-debug and mode 0x107 would help me finish my code investigation.

Thank you again,

dvwjr

It's actually a simple change. If you do it in DOSBox with my patch the change to that table should just work (I did not test it but there are no reasons it should not). If you want to do it in CVS you need to modify ModeList_VGA in int10_modes.cpp and adjust SCALER_MAXWIDTH in render_scalers.h (with patch it is already at 1280). You can go even higher than that resolution, just make sure you have enough emulated video memory for that -- CVS is fixed at 2M, with patch you can select 4M. I don't know if there is any practical value in running DOSBox at 1600x1200x64K but it is doable.

Vasyl,

Thank you very much for your reply. I'll play around with integrating the DIFF and table changes and get back with the results...

Thanks again,

dvwjr

vasyl, would you test with this program that I attached? It runs with et3000/et4000/et4000new.
When I try it on my old 0.63 build that can be downloaded from my page, it worked. On the other hand, it does not work in dosbox 0.65 clean cvs + svga. Screen gets distored.

vdkb24.exe is an executable to run on dos prompt.

Odd, it does not work for me regardless of the build. I tried current patched one, stock 0.63 and 20060130 version of 0.63 -- same result. There is some difference if I run it with Tseng emulation with no VESA driver loaded -- it seems to use VESA. From the way it looks, the program starts, changes video mode, and then crashes or otherwise exits. Does not seem to depend on core type or clock speed. What's in your dosbox.conf for the working version?

Sorry, I forgot to mention : Before running vdkb24.exe, run setvga.exe.
Choose ACER 7015 then hit enter twice.
Then you are on prompt. Now, run vdkb24.exe
(I removed my configfile, then did "config -wc dosbox.conf" to create a default configfile. After that, I set svgachipset to et4000.)

I see. There is definitely a difference between the last patched 0.63 and current build. The current build does not seem to load charset properly. Can't tell if is because of some change in the patch as the program does not run on S3 at all. I will investigate.

EDIT: All right, this is a bad one. It appears that this program never worked in Visual Studio builds (checked for a few months back). Something might have changed in your build setup just recently -- some library change, option, or just combination of internal factors. Cannot tell more without deeper debugging. I've wasted some time following false lead (one of the recent CVS changes was quite a good suspect) before realizing that it is not a recent problem. It can be a bug in DOSBox or in the program itself (dependency on some in-memory setup), hard to tell.

First idea would be to test it with msdos+dosbox (maybe even loadfix
in dosbox alone).
Charset loading..... are they using int10 calls?

However, when you run any utlity which uses text modes, it works fine on clean 0.65 cvs + svga.

Uploaded screenshots.

My Oct/08/2006 build does not have such a problem.
I am sorry to bother you. That is because of dbcs console patch.
I probably got rid of it in latest build.

I still don't like the fact that it does not work on Visual Studio builds at all. That patch could've triggered it but there is something else going on. Probably, uninitialized variable somewhere. I'll take a closer look when I get some time.

Patch causes dosbox to crash when machine=pcjr

1Program received signal SIGSEGV, Segmentation fault.
20x0052761b in mouse_reset() () at mouse.cpp:601
3601             if (CurMode->type!=M_TEXT) RestoreCursorBackground();
4Current language:  auto; currently c++
5(gdb) p CurMode
6$1 = (VideoModeBlock *) 0x0

Tested with clean cvs + svga patch only.

Yep, looks like it's been broken for quite a while. More than a year, actually. I will fix it as soon as I have a couple hours. Thanks for letting me know. I wonder how that happened that nobody else saw it...

EDIT: Found the culprit. In int10_modes.cpp function VGA_SetupVideoModes is missing clause for MCH_PCJR. I am not that familiar with PCJR, does it have exactly the same video modes as Tandy? In that case it is as simple as inserting one extra line in that function. If the mode list is different than I would rather create separate mode list table.
The crash was introduced by revision 1.24 of dosbox.h -- silent merge conflict 😢 One year and nobody noticed...

Weird, I test at least one or two booter games every month using various builds of DosBox....

Didn't look too close as what your ModeLists are, but the mode
definitions are the same. The video memory access is different
though, but that shouldn't matter.
You can use case TANDY_ARCH_CASE instead of case MCH_TANDY
for that purpose.