VOGONS


First post, by kas1e

User metadata
Rank Newbie
Rank
Newbie

Lately found that on 2 different BIG ENDIAN PPC OS such as AmigaOS4 and MorphOS some games and apps give us broken colors (while everything shows correctly in the same apps/games, on the same DOSBox svn build, with the same config, but on X86 or X84). It doesn't matter if you use "normal" or "dynamic" core, as well as doesn't matter if you use SDL1 which is currently official in DOSBox, or SDL2 build, issue with colors always there. I also tested it not only on machine:svga_s3, but also on vesa_nolfb and vesa_oldvbe: the same result (at least only those 3 seems to give the ability to use more than 256 colors).

Firstly I found that issue only in old diskmag "HUGI", which issues prior 20 or so was done for DOS. That how it looks like:
http://kas1e.mikendezign.com/aos4/dosbox/dosb … colors_hugi.jpg

Then, while testing more games, found the same issue in those ones as:

"The 11th-hour" game:
http://kas1e.mikendezign.com/aos4/dosbox/dosb … lors_11hour.jpg

Intro in animation scenes in "TombRaider":
http://kas1e.mikendezign.com/aos4/dosbox/dosb … _tombraider.jpg

And the last one in "Screamer2":
http://kas1e.mikendezign.com/aos4/dosbox/dosb … s_screamer2.jpg
http://kas1e.mikendezign.com/aos4/dosbox/dosb … er2_in_game.jpg

Now, Dominus in "PowerPC Dynamic Compiler thread" says that with SDL1.2x there is a color bug that shows on OS X and higher colors. But as I say at the beginning I have those color bugs and with SDL1 and with SDL2.

But what is more important, with the Screamer2 game it was easy to reproduce that issue INDEED because of more colors. Screamer2 game has 4 different exes to run :

start65h: to run in hi-res mode with 65k colors
start65l: to run in low-res mode, but still with 65k colors
starth: to run in hi-res mode with 256 colors
startl: to run in low-res mode with 256 colors

And, if we run binaries which will use 256 colors, all looks and renders correct and fine. But if we use 2 binaries which want 65k colors, then the issue is there!

So it looks like it DOSBox's big-endian issues when it comes to handling 65k (and more?) colors.

Does anyone have any idea where to even look in DOSBox's code? Logically it's probably something in vga.cpp & vga.h, as well as vga_s3.cpp too.

Probably some easy test-case can be done/written/found, but for time being if anyone willing to test this issue, the smallest test case is HUGI diskmag: https://files.scene.org/get:nl-ftp/mags/hugi/hugi17.zip , just 3mb, nothing to install, only unpack and run "hugi17d.exe" to see an issue.

And if anyone even in interest to take a look at and trying to fix it, I will happily donate at least 50$ for. Sure nothing, but to just motivate even a little bit 😀

Thanks in advance!

Last edited by kas1e on 2020-01-26, 08:01. Edited 2 times in total.

Reply 1 of 39, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Quick test results:

I don't have the issue with the last release of SDL2. And I don't have it with SVN builds against SDL1.2 since 2018 or so. I still have it with my snapshots of sometime 2017.
What changed: I am using the latest source of SDL1.2 which I really recommend. AND/OR at some point I did change a simple thing in the SDL1.2 source but... hm... I need to find it again 😀 (and see if my source is actually using that)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 2 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

I don't have the issue with the last release of SDL2. And I don't have it with SVN builds against SDL1.2 since 2018 or so. I still have it with my snapshots of sometime 2017.

Hm... I also use the latest SDL1 sources as well as the latest SDL2 sources...

AND/OR at some point, I did change a simple thing in the SDL1.2 source but... hm... I need to find it again 😀 (and see if my source is actually using that)

Probably that 😀

Are you check it on MacOS PPC?

It anyway feels strange, maybe your issue was totally different in end? Or with your snapshot of 2017, you have exactly the same visual color swaps? For me I have those issues if I use:

few years old SDL1 and 10 years old DOSBox
very latest SDL1 and today's DOSBox code
very latest SDL2 and today's DOSBox code + SDL2 patch

How you check DOSBox with SDL2 btw? What patch? Or only DOSBox with SDL1 was checked? If so, maybe you indeed fix it inside of your SDL1 which you use, just this change not in SDL1 main repo.

Reply 3 of 39, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I followed this bug report and eventually the bug/patch against the SDL tracker https://sourceforge.net/p/dosbox/bugs/347/ but I checked and the latest build I'm using to make the snapshots did not have the SDL change (nor the Dosbox one).
The SDL2 patch for DOSBox is the one by Ny00123.

BUT yes, it's a different bug. My bug was that the color blue was "missing" from the mix, but you have much more distortions.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 4 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

Oh, your bug indeed looks a bit different. For you, only a few colors were swapped, but on my screenshots, all looks like some palette issues. Something now usual "wrong colors swap" but heavier. So I seem again left with our SDL 😀 Is in terms of SDL in DOSBox 256k and 65000 modes handled differently? I was under impression that all done inside of DOSBox's core, and SDL only flips ready frames.

Reply 6 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

And another info to add by one of MorphOS developers who do the port for that os:

It should be some easy bug to fix (maybe MacosX PPC / LinuxPPC uses RGB16 and we on AmigaOS4 and MorphOS mostly use RGB16PC).

And I managed to run Hugi with normal colors:
- set desktop to 16bit (instead of 32 or 24)
- run DOSBox, run HUGI -> wrong colors
- alt+enter -> go to fullscreen -> wrong colors
- alt+enter -> go to window mode -> good colors 😀
- alt+enter -> go to fullscreen -> again wrong colors

something is really broken here 😀

And it definitely looks like something about 16 (16PC) vs 32 vs. And maybe issue and SDL and DOSBox?

Reply 7 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

I find out that PCPBench tool has the ability to choose the size and depth of the screen, and so, I can confirm in which modes we have color issues:

8 bpp: no bugs
http://kas1e.mikendezign.com/aos4/dosbox/badc … nbench_8bpp.jpg

15 bpp: have bugs
http://kas1e.mikendezign.com/aos4/dosbox/badc … bench_15bpp.jpg

16 bpp: have bugs
http://kas1e.mikendezign.com/aos4/dosbox/badc … bench_16bpp.jpg

32 bpp: have bugs (much less distortion, just green color swapped)
http://kas1e.mikendezign.com/aos4/dosbox/badc … bench_32bpp.jpg

From screenshots above, probably it means that both 15 and 16bit modes suffer from PC vs no PC modes, while 32-bit mode seems to suffer from some easy wrong byte orders.

How it may works on MacosPCC and LinuxPPC are strange, but maybe they both just use little endian screenmodes ?

Last edited by kas1e on 2020-01-26, 08:03. Edited 1 time in total.

Reply 9 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

DOSBox is the first SDL1/SDL2 program that brings that kind of issue (and we have a gazillion of SDL1/SDL2 apps). It is probably not about SDL implementation, but how screens/etc done on different OS. Or do you mean SDL's code inside of DOSBox? The same issue happens on 2 different PPC OS, with different SDL implementations, just both OS share usage of PC video modes (so byte-swapped)

Imho, inside of DOSBox, there should be byte-swapping done somewhere. If not for all PPC platforms, then at least for AmigaOS4 and MorphOS and any other OS which may use big-endian screen modes.

It will be interesting to test DOSBox on LinuxPPC as well, not only on macOS PPC.

EDIT: also "ctrl+f5" take a screenshot in the wrong colors as well.

Reply 11 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

Is Wii have PC screen modes or non PC ones? What I mean, is that on AmigaOS4 and MorphOS for 15/16 bit we use PC modes, maybe Wii doesn't and so it works.

Last edited by kas1e on 2020-01-26, 09:15. Edited 1 time in total.

Reply 12 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

Though, that didn't explain why for you 32bit modes work fine on Wii. Can you re-test plz PCPBench with "PCBench.exe 115", so to run it in 32bits? If it will have the same "green" issue as I have in 32bit colors, then it means we may have 2 separate issues: one for 32bit mode for all big-endian machines, and another one for 15/16bit ones when "PC" (byte-swapped) screen modes used.

Reply 14 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

Sorry, I am not a programmer, so not understand what the latest phrase means and how it related. If DOSBox didn't something, then bugs should happen the same on all Big-Endian oses, but if it happens on some and on some not... So I tried to understand where is issues are. Are you 100% sure, that for you on Wii, when you run "PCBench.exe 115" all render correctly? And that Wii itself didn't use "PC" screen modes? That at least will give us an idea of where to look at.

And issue happens not only with surface output but with OpenGL as well.

Reply 16 of 39, by rzookol

User metadata
Rank Newbie
Rank
Newbie

So MorphOS also has problems with 32bit and 16bit screens. 32bit is easy as it can be fixed using RGBA mask. 16bit can't be fixed such way. SDL Surfaces have to be in native format (big endian for PPC) and implementation should convert it to GfX card destination format (RGB16 with littleendian). In theory there are two conversions VGA (LE) -> SDL (BE) -> Gfx card (LE)

@jmarsh
Is Wii SDL store surfaces in LE or BE?

Reply 17 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

@rzookol

In theory there are two conversions VGA (LE) -> SDL (BE) -> Gfx card (LE)

That probably will slow things down? But at least if we can choose to do such conversion only for 16-bit modes and keep 8bit ones as it was, then better than nothing.

Reply 18 of 39, by kas1e

User metadata
Rank Newbie
Rank
Newbie

@All
Oh, there is really good news now!

Kcroft does check it on his Linux PPC on PowerMac, and he have exactly the same issues (absolutely the same look as we have), see further here: https://github.com/dreamer/dosbox-staging/iss … mment-578533293

So Jmarsh's Wii there as an exception. Probably in his SDL for Wii he does something for (?)

Reply 19 of 39, by rzookol

User metadata
Rank Newbie
Rank
Newbie
kas1e wrote on 2020-01-26, 19:22:
@All Oh, there is really good news now! […]
Show full quote

@All
Oh, there is really good news now!

Kcroft does check it on his Linux PPC on PowerMac, and he have exactly the same issues (absolutely the same look as we have), see further here: https://github.com/dreamer/dosbox-staging/iss … mment-578533293

So Jmarsh's Wii there as an exception. Probably in his SDL for Wii he does something for (?)

Fixing it is easy in render_templates.h:

#if SBPP == 15
....
#elif DBPP == 16
#define PMAKE(_VAL) (((__builtin_bswap16(_VAL)) & 31) | ((__builtin_bswap16(_VAL)) & ~31) << 1)

#if SBPP == 16
...
#elif DBPP == 16
#define PMAKE(_VAL) __builtin_bswap16(_VAL)

and similar fixes for 32bit

So it seems that VGA emulation gives data in LE format, which is good for graphics card but not for SDL Surface.

Last edited by rzookol on 2020-01-26, 19:57. Edited 1 time in total.