The default "faked" hi-color on mode 13h has no trouble, it's only when you run the demo with a -24 parameter for TrueColor that you get the error message.

It can't find a VESA mode that is 320x200 with 24-bit color. The TrueColor VESA modes in DOSBox report 32 bits per pixel through INT 10h/4F01h, and the demo wants 24 bits per pixel. Perhaps the devs can explain what's going on with 24 vs. 32 bits, because the RBIL says that standard VESA modes are at most "16M" colors which implies 24 bits, and mode 10Fh seems like it should be a fit for what the demo wants. Loading SDD/UNIVBE doesn't help, still says 32 bits. If you try to cheat and make mode 10Fh report 24 bits per color then the display is messed up.

The part of the demo with the wobbly "Kolor" text is somewhat glitched. Tried loadfix, increased memsize, and machine=vgaonly, but the glitches still appear. Not sure what could cause it... maybe segment limits?

I have a small program which can solve this problem ...
Don't ask me why ...
This program is to solve another game's problem and I am not the author.

The part seems to run too fast. If you set the cycles lower you'll see the logo stretching more or less correctly. Maybe the overlay is not synched to vsync?...

For me it crashes both with and w/o the "-24" parameter.

WTF! That worked. Thanks!

Btw. I don't know if the S3 should have the appropriate mode, but VESA should have 320x200*24Bit

Hmm, maybe some timing issue, because the demo runs to completion on my system with default settings in DOSBox 0.74 and SVN (as long as the -24 switch is not used).

This program is to solve another game's problem and I am not the author.

It looks similar to a workaround I made for Sokoban Revenge, and if it's for that game then it's much more aggressive than it needs to be. It blocks INT 15h entirely, and if that is helping with a problem in the demo that some people are experiencing then perhaps try a vanilla SVN build because some fixes were made to INT 15h/86h.

Hmmm. Not sure. In the part that crashes it seems to switch to a 640x480 mode and then use fake highcolor anyways...

The solution works for me so that's ok...

Thanks for the help y'all!!!

I recently posted my Custom S3 Trio patch a few days ago where I patched it to include 24 bit colour - I did it experimentally. Having tested this demo with the -24 parameter, the demo looped successfully and when I disabled 24-bit colour, it crashed out like raer said. I never knew that my patch would come in handy one day!

I guess the crashy part is where there's a pic of Minnie Mouse with the caption "Kolor super demo"? I can't induce a crash there when I don't use the -24 switch, and I've tried all output= options and fixed / limited cycles... it just works every time. I don't view it as a blessing when I can't reproduce problems, though. :/

I will just notice that that mode is not 320x200 but 320x400

Most of the demo is in 320x200, but there is one part in 320x400

raer
coolhaken
can you both enclose your dosbox.conf?

Can you also verify this:
When you start the game it displays some text lines about the testings it did. Depending on whether you use -24 switch or not there is a different message there: it either says it runs in true color or that you can switch to true color with -24 switch. What message have you got if you run the game without -24 switch?

Also does it work for you with machine=vgaonly ?

btw - you can lower cycles and use alt-f12 to get to the crush point quicker.

The mode must be 640x400. That's what DOSBox captures when you create a video of that Minnie Mouse part.
@s3freak: Nice! How does the part look with your patch? Is it still some fake RGB-scanlines or is it just regular 320x200?

EDIT: Attached my dosbox.conf

thanks, what about my two other questions?

Mode 13h is normally 320x200, double width, double height, 70 fps. The "Kolor super demo" uses register-tweaked mode 13h at 320x400, double width, normal height, 70 fps.

The issue might be a misreading of the display timing due to the screen resize delay. If anyone who has the issue would like to test the theory, try running the demo with the experimental build of 0.74 here.

robertmo wrote:

raer
Can you also verify this:
When you start the game it displays some text lines about the testings it did. Depending on whether you use -24 switch or not there is a different message there: it either says it runs in true color or that you can switch to true color with -24 switch. What message have you got if you run the game without -24 switch?

The demo runs WITHOUT the -24 switch. It crashes for me otherwise in the Minnie Mouse part. Haven't tried vgaonly, as I wanted to capture it in the best possible format.

ripsaw8080 wrote:

Mode 13h is normally 320x200, double width, double height, 70 fps. The "Kolor super demo" uses register-tweaked mode 13h at 320x400, double width, normal height, 70 fps.

The issue might be a misreading of the display timing due to the screen resize delay. If anyone who has the issue would like to test the theory, try running the demo with the experimental build of 0.74 here.

I'm just saying that DOSBox gives me 640x400 frames when I capture that part (without the -24 switch).

I tried the experimental build, but saw no difference. It still crashes.

can you try it with machine=vgaonly ?

With vgaonly it runs all the way through, regardless of the "-24" switch (makes sense) and the Minnie Mouse part uses the fake highcolor mode.

ok, we are getting closer. can you now answer that second question of mine?
use alt pause to be able to read the text if it goes too fast. (alt pause again to unpause)

Makes sense only with svga_s3 I guess:
with the -24 switch it says "Using VESA 2.0 Truecolor mode"
w/o it say "You can use the -24 switch" bla...

check if it works with
scaler=normal2x