Topic: Need some help with my libretro port

[barbudreadmon]

no

[barbudreadmon]

Some update on this issue : it is arm specific, games run well on both x86_64 and x86_32.

[barbudreadmon]

I was wrong, M92/M107 runs fine on x86_32/x86_64, M72 runs with wrong colors (see the attachment).

[barbudreadmon]

I also noticed something else while trying to debug : DrvInit seems to run with video_type equal to 0 while running rtype.zip (that's what my printf returned), while

Code: [Select]

switch (video_type)
{
case 0: // m72
video_offsets[0] = video_offsets[1] = 0;
break;

case 1: // rtype
seems to say it should have been equal to 1.

[dink]

Could the palette be in a different format than what your system is expecting?
It almost looks similar to those issues Gamez Fan was having with his xbox port, but my memory is a little fuzzy.  any ideas iq_132?

[Arcadez]

Yeah i had the same issues with the Gradius 3 on the xbox game was displaying all in green till IQ_132 reworked the pallete handling
in the Driver As i recall the issue was caused by the xbox not liking certain 32bit defines for the pallette code

i guess it might be a similar problem which is causing the m72 games to be ignoring the greens and reds and just displaying
Blues on certain platforms

[barbudreadmon]

It's kinda strange you speak about gradius3, i wanted to talk about it after resolving the irem issue (which is the most annoying issue on the libretro port), but i actually have most (all?) konami games, including gradius3, displaying blue/yellow only graphics, on all arch. When was the change on gradius3 graphics ? I would like to try the older version.

By the way, treble winner mentioned something about *2s being bad for compatibility, what does he mean ? Lines like those :

Code: [Select]

UINT16 *p = (UINT16*)DrvPalRAM;?

[Romhack]

It seems to be problem with color conversion from BGR to RGB.

[iq_132]

iirc most of these games have 2 byte (15/16 bit palette colors). This is likely an endian-ness issue with calculating them.
usually the pens (individual colors) are stored in xRRRRRGGGGGBBBBB or xxxxRRRRGGGGBBBB format. if they're byteswapped due to endian-ness, you end up with GGGGBBBBBxRRRRRG or GGGGBBBBxxxxRRRR.  If it's a 32-bit color, you may also be having a problem with (r << 16) | ( g << 8 ) | (b << 0) as far as building a 32 (24) bit color pen.

[barbudreadmon]

So, on gradius3, how should i change the code to test/correct this issue about endian-ness byteswapping ?

Code: [Select]

static inline void DrvRecalcPalette()
{
UINT8 r,g,b;
UINT16 *p = (UINT16*)DrvPalRAM;
for (INT32 i = 0; i < 0x1000 / 2; i++) {
r = (BURN_ENDIAN_SWAP_INT16(p[i]) >> 10) & 0x1f;
g = (BURN_ENDIAN_SWAP_INT16(p[i]) >>  5) & 0x1f;
b = (BURN_ENDIAN_SWAP_INT16(p[i]) >>  0) & 0x1f;

r = (r << 3) | (r >> 2);
g = (g << 3) | (g >> 2);
b = (b << 3) | (b >> 2);

DrvPalette[i] = (r<<16)+(g<<8)+b;
}
}

[barbudreadmon]

From your explanation, i thought adding

Code: [Select]

#ifdef LSB_FIRST
p[i] = (p[i] << 8) | (p[i] >> 8);
#endif
in the loop could be the answer, but colors are still a mess and the game is blinking :/

[iq_132]

Hmmm... I'm really not sure then. Endian-ness issues aren't really things I've dealt with much.

[barbudreadmon]

I noticed the lowest part of konami logo on my screen is white while it should be red... It makes no sense if the issue is only a biteswapped color palette. How could 255,0,0 go 255,255,255 ?

[barbudreadmon]

I gave it a try again today, since people on github tends to report a lot about this. I noticed something interesting : there was no issue with colors on konami games with fba-libretro 0.2.97.31, this issue only appeared on next releases (0.2.97.34/35/36, there was no fba-libretro 0.2.97.32/33). Does it ring any bell ? Was there any major change in that timeframe that could explain those issues ?

[Barry Harris]

I gave it a try again today, since people on github tends to report a lot about this. I noticed something interesting : there was no issue with colors on konami games with fba-libretro 0.2.97.31, this issue only appeared on next releases (0.2.97.34/35/36, there was no fba-libretro 0.2.97.32/33). Does it ring any bell ? Was there any major change in that timeframe that could explain those issues ?

The most likely thing I can see is this (attached).