Dosbox mapper blue not white
After a clean install of Retropie 4.2 on Raspberry pi zero, I installed DOSBOX from source. The Mapper CTRL+F1 looks like this. Connected to HDMI to take picture but I will be using it on 3.5 inch display. The blue text is unreadable. Mouse is above ESC button

I can verify that this also affects Raspberry Pi 3b
You already have a topic open on the forum -I prefer not to have issues opened in multiple places (info when opening a ticket asks to use the forum - it doesn't mean open a topic, then also post here). This is likely a DOSBOX or SDL issue rather than being RetroPie specific.
Is this your ticket also ? https://sourceforge.net/p/dosbox/bugs/452/
Yes. Since i wasnt sure where the problem was from, i opened this issue before diving into the code.
@joolswills Can you try running this program. PasteBin Link
I was able to isolate the problem quite a bit. This program creates a grey scale gradient on my laptop running Fedora 25 with SDL from libsdl website. It creates a series of colors on Raspberry pi 3 running Retropie 4.2. Screenshots below.
Surprisingly the code runs properly on both Fedora and Retropie when LEVELS = 16
SDL_SetPalette(screen, SDL_LOGPAL|SDL_PHYSPAL, colors, 0, LEVELS);
If number of colors is not 16 the colors are not the same. This suggest SDL error on Retropie.
Screenshots with LEVELS = 128


Did you try switching dispmanx sdl2 backend on/off for dosbox to see if that helps?
I doubt any more work will be done on sdl1.x - it's more likely we will move to sdl2 for dosbox anyway.
I don't have any free time to look into this currently.
I have a solution for this. Should I submit a patch?
what solution ? against sdl or dosbox ?
patch for the dosbox source. all you have to do is fill map_pal with blank colors so size goes from 6 to 16 and change corresponding SetPalette ncolors to 16. Diff below
--- sdl_mapper.cpp 2017-04-24 15:34:46.721040544 -0700
+++ sdl_mapper.cpp 2017-04-24 15:40:45.407736264 -0700
@@ -2003,13 +2003,24 @@
bind_but.bind_title->Change("Bind Title");
}
-static SDL_Color map_pal[6]={
+static SDL_Color map_pal[16]={
{0x00,0x00,0x00,0x00}, //0=black
{0x7f,0x7f,0x7f,0x00}, //1=grey
{0xff,0xff,0xff,0x00}, //2=white
{0xff,0x00,0x00,0x00}, //3=red
{0x10,0x30,0xff,0x00}, //4=blue
- {0x00,0xff,0x20,0x00} //5=green
+ {0x00,0xff,0x20,0x00}, //5=green
+ {0x00,0x00,0x00,0x00}, //blank
+ {0x00,0x00,0x00,0x00}, //blank
+ {0x00,0x00,0x00,0x00}, //blank
+ {0x00,0x00,0x00,0x00}, //blank
+ {0x00,0x00,0x00,0x00}, //blank
+ {0x00,0x00,0x00,0x00}, //blank
+ {0x00,0x00,0x00,0x00}, //blank
+ {0x00,0x00,0x00,0x00}, //blank
+ {0x00,0x00,0x00,0x00}, //blank
+ {0x00,0x00,0x00,0x00} //blank
+
};
static void CreateStringBind(char * line) {
@@ -2362,7 +2373,7 @@
if (mapper.surface == NULL) E_Exit("Could not initialize video mode for mapper: %s",SDL_GetError());
/* Set some palette entries */
- SDL_SetPalette(mapper.surface, SDL_LOGPAL|SDL_PHYSPAL, map_pal, 0, 6);
+ SDL_SetPalette(mapper.surface, SDL_LOGPAL|SDL_PHYSPAL, map_pal, 0, 16);
if (last_clicked) {
last_clicked->BindColor();
last_clicked=NULL;
Please can you wrap it in a code block. it's unreadable otherwise.
Attached file instead of code block. The code block was getting broken due to text in diff.
code block should work fine - I put diffs on github all the time. just use three backticks above and three below (can use ```diff for diff colourisation)
you used a single backtick which is why it didn't work btw.
Thanks for the patch. Will look into it when I have time - did you try btw with dispmanx backend on/off without the patch ?
I dont know how to. Can you elaborate more.
RetroPie-Setup -> Configuration / Tools -> Configure emulators to use dispmanx SDL
Change the dosbox setting - restart dosbox from ES (not manually as the dispmanx setting is handled via runcommand).
Enabling dispmanx SDL works too. It is not enabled by default.
Although there is no harm in adding 16 colours to palette instead of 6.
~~Just to note it would probably be worth opening an upstream bug agaist sdl for this - I will look into including the code workaround, but if it's a sdl issue it should be reported upstream. https://bugzilla.libsdl.org/~~
Sorry. I had a brain glitch - this is sdl1 still, so no point reporting upstream. I will look into the sdl1 code and see if I spot anything obvious. Could be a RPI framebuffer issue.
@joolswills which patches are used to patch sdl1 on RPI