Well, considering that there's no bug tracking system ala bugzilla

Considering that the bug tracking system of sourceforge is tracking bugs, i'd call it a bug tracking system.

Of course just havint a bug in a bug tracking system doesn't fix the bug, but anything you can
contribute to help fixing it is appreciated (though mac-specific things are usually tricky due to
testing "barriers"). If you can for example put together a small test program that behaves
like GTA regarding the fullscreen bug, that'd already help a lot.

I'm just not sure where the best place is to perform the conversion - line drawing functions or somewhere in the renderer?

Since there's a difference between windowed and fullscreen the expected fix is as late
as possible, not? Like *not* somewhere around the graphics write or readout functions.

Why could it be fixed during line drawing? If it's easier and faster to do it there, may be fine too.

Well my experience with the renderer is rather low so I can't tell.

The thread title and reported facts seem a bit contradictory, I'm reading that the issue (maybe separate issues) affects both windowed and fullscreen in 0.74. That screenshot is Trucks in windowed mode.

@orka: the OP reports this for version 0.74, since you are also useing 0.74, it is really to be expected that you STILL suffer the same bug...

And @wd, hal, ripsaw, the bug really is not only fullscreen but also windowed mode. I can try stuff out again if you want though. Easiest way to reproduce it is running Tomb Raider intro, running Windows 3.11 in high colours. If you want I can run more tests.
And as I wrote the screenshot function actually gives the correct colors even though dosbox displays the wrong ones 😉

Maybe try whatvga or vbetest instead of games. There you can select the color depth.

I'll see if I have them around and will report back

@wd: Sorry, never really noticed that dosbox has an account on Sourceforge.

By the way, I owe everybody a clarification, of course: the problem and the weird artifacts I've shown are from the game Trucks, which I was testing due to a different bug exposed on another thread. The game shows such problem after giving a message on using a VESA driver from Scitech (see the first screenshot), but the weird graphics glitches are visible even in other games.
Another game showing this problems is Earth 2140.

I'm not a coder (at least, I doubt that Max/Msp would be anyway useful in this case) but I could try doing some regression testing if it could be useful.

ok, don't have whatvga at hand but vbetest and that one gives the wrong image starting from 15bits, see this screenshot:
left is the image CAPTURED by Dosbox (and which I presume is the correct one), right the image DISPLAYED by Dosbox

Output=opengl (though output doesn't matter, I tried them all with the same result)
machine=svga_s3, vesa_nolfb, vesa_oldvbe (svga_et3000, svga_et4000, svga_paradise did not work with vbetest directly and with univbe loaded only 4&8bit were useable)
machine=vgaonly doesn't work correctly to begin with (somewhere documented in the forum)

Going to test svn now but I doubt it makes a difference - Edit: made no difference on quick test with svga_s3 and vgaonly

Edit: There is a difference between fullscreen and windowed mode, in fullscreen the colors appear to be correct 😀

machine=vgaonly
again, left the captured image and right the displayed one.

In fullscreen there is another colorswitch

the white seems a bit blue in the fullscreen shot.
I think it would be interesting what the colour information from SDL is at each of those points.

I must say that the yellow startup message looks actually pretty nice 😀

Yeah dunno why they are complaining either, they even have SWITCHABLE FUNNY PALETTE OUTPUT!!!

Anything else I can do to help?

As Qbix said the color format might be interesting (since the fullscreen thing hints
at a problem with a special color format, for example 5:5:5 or other 16bit specialities
on your OS), maybe somebody can directly tell you what to modify.

Quick rundown that may help:
put some logging into GFX_SetSize to see which paths are taken when something
is working fine, and which ones are taken for a screwed up output. Try posting some
short summary if there's anything interesting or unusual looking. Then put some
additional logging to the SDL_SetVideoMode codes that are used, especially what
goes in (bpp for example) and the details of the returned SDL surface, especially
the stuff in the pixel format like sdl.surface->format->whatever

I'm sorry, I know we've did stuff like that before but I'm daft at this programming stuff and forget it a week later. Can you give me detailed instructions of where to put which logging instructions?
And then I'll do the logging ASAP (my hard drive acted up yesterday and I need to restore my system and hope the hard drive is not busted).

Oh better care about your HD first 😉

For the first part, browse the code in GFX_SetSize a bit, in the first code blocks
put some LOG_MSG("here 1"); things so you see which of the if() cases are used
to determine the relevant SDL_SetVideoMode calls.

I assume you're using output=surface and windowed mode for testing, so take
the vbetest example you've posted a screenshot recently.

Logging like this:

line 454 in sdlmain.cpp:

1			LOG_MSG("windowed SDL_SetVideoMode bpp==%x, flags==%x",bpp,flags);
2			sdl.surface=SDL_SetVideoMode(width,height,bpp,(flags & GFX_CAN_RANDOM) ? SDL_SWSURFACE : SDL_HWSURFACE);
3			LOG_MSG("-> flags==%x, bpp==[%d;%d], r==%x:%d:%d, g==%x:%d:%d, b==%x:%d:%d, a==%x:%d:%d",sdl.surface->flags,
4				sdl.surface->format->BytesPerPixel,sdl.surface->format->BitsPerPixel,
5				sdl.surface->format->Rmask,sdl.surface->format->Rshift,sdl.surface->format->Rloss,
6				sdl.surface->format->Gmask,sdl.surface->format->Gshift,sdl.surface->format->Gloss,
7				sdl.surface->format->Bmask,sdl.surface->format->Bshift,sdl.surface->format->Bloss,
8				sdl.surface->format->Amask,sdl.surface->format->Ashift,sdl.surface->format->Aloss);

Is this sole instance enough?
For this I get
windowed SDL_SetVideoMode bpp==20, flags==128
-> flags==4, bpp==[4;32], r==ff00:8:0, g==ff0000:16:0, b==ff000000:24:0, a==0:0:8

Test case to compare your output: vbetest -> [0] - Interactive Mode -> [2] - 15 bits per pixel mode -> [1] 640x480x15, 3 Page... -> [0] Banked Framebuffer Mode

(I had some time to do this while I make a long backup of my data - fortunately nothing got lost and while I have a fairly recent backup I want to make sure I have everything - then I'l need to redo my mac it seems 🙁 )