Graphic glitches and wrong colors.

[GoogleCodeExporter]

I'm working to fix these problems and I need a feedback.

Please report only if something worked fine with X-revision, but Y-revision 
broke that.
It would be bad if I'll "fix" one game that I have and broke all another.

First rev. to test is r91, second r105.

Original issue reported on code.google.com by AndreyLegchilin on 6 Apr 2010 at 5:26

[GoogleCodeExporter]

I noticed that as of r97, fading graphical effects have been broken. For 
example, in
any of the phoenix wright games or in Super Mario 64 DS the company logos 
should fade
in and out. Instead, they just appear and disappear. I am working to resolve 
this but
though I would let you know.

Original comment by castleva...@yahoo.com on 6 Apr 2010 at 8:15

[GoogleCodeExporter]

For me everything on the main screen now looks good.  But on the sub screen the
colors look wrong.  I'll test against the two revs and let you know more.

Original comment by iamsca...@gmail.com on 6 Apr 2010 at 9:04

[GoogleCodeExporter]

Some notes to not forget =)

Super Mario 64 DS graphic is in BG0.
FFXII FMV is BG2 and OBJ. One of them buggy.

Original comment by AndreyLegchilin on 7 Apr 2010 at 8:11

[GoogleCodeExporter]

Take a peek at Tetris DS which seems to have problems rendering some 2D.

Original comment by castleva...@yahoo.com on 7 Apr 2010 at 11:19

[GoogleCodeExporter]

firnis,

I've been looking at this also.  Trying to explain why some BG layers are scaled
incorrectly and some are not displayed at all.  Everything seems to point back 
to the
BGxPARMS in gpu.h.  After looking over the technical specs I think we may need a
little shift magic for big endian.  see -
http://nocash.emubase.de/gbatek.htm#lcdiobgrotationscaling

This would explain missing layers on some games and also if the scale params are
messed up why some homebrew is screwed.  I'd appreciate another set of eyes on 
this
as I've been going round in circles for two days.

Original comment by iamsca...@gmail.com on 8 Apr 2010 at 6:53

[GoogleCodeExporter]

Endian issue may occur only then you read/write to the memory.
BGxPARMS never reads or writes to memory directly.

Original comment by AndreyLegchilin on 8 Apr 2010 at 11:31

[GoogleCodeExporter]

So nothing is reading and writing to the LCD I/O BG Rotation/Scaling registers?

Original comment by iamsca...@gmail.com on 8 Apr 2010 at 5:36

[GoogleCodeExporter]

I'm talking about the BGxPARMS sctuct. It's not reading or writing directly.
Parameters of that struct are set separately. So there cannot be any endian 
issues with that struct.

Endian issue may be if you have something like this:
union {
  struct{
    u8 first;
    u8 second;
  } values;
  u16 value;
} something_t;

something_t.value = *((u16 *)&mem);
or
memcpy(&something_t, (something_t *)mem, sizeof(something_t));

But we have 

struct {
    s16 BGxPA;
    s16 BGxPB;
    s16 BGxPC;
    s16 BGxPD;
    s32 BGxX;
    s32 BGxY;
} BGxPARMS;

BGxPARMS.BGxPA = x;
BGxPARMS.BGxPB = y;
e.t.c.

Every variable of that struct is set and reads separately.

Original comment by AndreyLegchilin on 8 Apr 2010 at 5:51

[GoogleCodeExporter]

Yes I understand how this works.  My point really is I can't find any place 
where
BGxPA, BGxPB, BGxPC, BGxPD are being set.  Thus was thinking they are mapping 
to the
DS's memory.

Original comment by iamsca...@gmail.com on 8 Apr 2010 at 6:04

[GoogleCodeExporter]

Ow... Here you're right. =)
BGxPARMS is a part of REG_DISPx, that is a pointer to the mem. 

Original comment by AndreyLegchilin on 8 Apr 2010 at 6:28

[GoogleCodeExporter]

I was sure that variables are set in rotBG2, extRotBG2, via pointers on them 
and not 
even check that...

Original comment by AndreyLegchilin on 8 Apr 2010 at 6:34

[GoogleCodeExporter]

Tried to convert the endian, but nothing at all has changed... Maybe commit it 
for 
tests?

Original comment by AndreyLegchilin on 8 Apr 2010 at 7:02

[GoogleCodeExporter]

I've not done it :P 

Just wanted to make sure I was not going insane and get your opinion that these
registers lacked big endian.

I'll take a look later tonight if you don't do it before that.  I'm at work 
right now.

Original comment by iamsca...@gmail.com on 8 Apr 2010 at 7:15

[GoogleCodeExporter]

firnis, did you create a bitmask for this.  I'm interested to see what you did. 
 If
you want to commit it I'll test it with the games I know the BG's are messed up 
on.

Original comment by iamsca...@gmail.com on 9 Apr 2010 at 3:38

[GoogleCodeExporter]

I already deleted that code. Because I tested rotBG and they not affect 
anything in 
games that i have.

But it was something like:
union somename16 {
  struct {
#ifdef WORDS_BIGENDIAN
    u8 h, l;
#else
    u8 l, h;
#endif
  } bits;
  u16 val;
}

struct _16_bit {
  somename16 value;
  u16 get_val() { return ((value.bits.h << 8) | value.bits.l); }
}

union somename32 {
  struct {
#ifdef WORDS_BIGENDIAN
    u8 h3, h2, h, l;
#else
    u8 l, h, h2, h3;
#endif
  } bits;
  u16 val;
}

struct _32_bit {
  somename32 value;
  u32 get_val() { return ((value.bits.h3 << 24) | (value.bits.h2 << 16) | 
(value.bits.h << 8) | value.bits.l); }
}

...
parms->BGxX.get_val();
...

parms->BGxX.value.val += parms->BGxPB.value.val;
parms->BGxY.value.val += parms->BGxPD.value.val;

Maybe I miss now something, I'm in hurry, need to out to work already.

Original comment by AndreyLegchilin on 9 Apr 2010 at 3:58

[GoogleCodeExporter]

What's interesting if you look at the other bit masks is that the byte order is 
not
reversed for big endian but the bit order per byte is.

Original comment by iamsca...@gmail.com on 9 Apr 2010 at 4:28

[GoogleCodeExporter]

more info...

Testing with M&L - Partners in Time -

In Windows the first time through the variables are the following.

in - template<bool MOSAIC> void lineExtRot(GPU * gpu)

              parms->BGxX = 0
              parms->BGxY = 0
              parms->BGxPA = 256
              parms->BGxPB = 0
              parms->BGxPC = 0
              parms->BGxPD = 256

debugging on Wii the values are :

              parms->BGxX = 0
              parms->BGxY = 0
              parms->BGxPA = 1
              parms->BGxPB = 0
              parms->BGxPC = 0
              parms->BGxPD = 1

Original comment by iamsca...@gmail.com on 9 Apr 2010 at 5:11

[GoogleCodeExporter]

r141 should now fix the BG mode.  

Original comment by iamsca...@gmail.com on 9 Apr 2010 at 9:51

[GoogleCodeExporter]

BMP sprites has wrong colors in Assasin Creed, but right colors in FFXII. If 
one try 
to swap color in rot_BMP_map or render_sprite_BMP, then all will be opposite.

Original comment by AndreyLegchilin on 26 Apr 2010 at 5:41

[GoogleCodeExporter]

Sure it's not just the alpha mask? if ((color&0x8000)&&(prio<=prioTab[sprX]))

Original comment by iamsca...@gmail.com on 26 Apr 2010 at 6:43

[GoogleCodeExporter]

No. I dumped all colors before this check and compared them with PC version.

Original comment by AndreyLegchilin on 26 Apr 2010 at 6:50

[GoogleCodeExporter]

Humm I just looked at FFX11 and the color on top is messed up.  The bottom 
screen
flips between ok and bad color.

Original comment by iamsca...@gmail.com on 26 Apr 2010 at 9:02

[GoogleCodeExporter]

Are you sure you are trying r172? Because I tested it right now and bottom 
screen is 
ok.

Original comment by AndreyLegchilin on 26 Apr 2010 at 9:19

[GoogleCodeExporter]

Yes 172. The bottom intro screen where the ship flies in seems to alternate 
between a
good image and a bad one.

Original comment by iamsca...@gmail.com on 26 Apr 2010 at 9:30

[GoogleCodeExporter]

I second what scanff is seeing.

Original comment by castleva...@yahoo.com on 26 Apr 2010 at 9:32

[GoogleCodeExporter]

That's really strange...
Then try to swap color in rot_BMP_map...
{{{
u16 color = LE_TO_LOCAL_16(T1ReadWord(adr, 0));
}}}

Original comment by AndreyLegchilin on 26 Apr 2010 at 9:40

[GoogleCodeExporter]

Maybe it depends of region?...

Original comment by AndreyLegchilin on 26 Apr 2010 at 9:45

[GoogleCodeExporter]

Strange.  I just rebuilt and now my bottom screen is fine. Any ideas with the 
top
screen?  

Original comment by iamsca...@gmail.com on 26 Apr 2010 at 10:12

[GoogleCodeExporter]

No...

Original comment by AndreyLegchilin on 26 Apr 2010 at 11:05

[GoogleCodeExporter]

hey pplz keep up the great work. just thought id put in my comment about new 
super mario bros. even in the r199 when playing the minigames, the screens 
constantly flash red and blue... you can see mario and the monsters (just 
barely).and in the pokemon games when selecting your name/walking around parts 
of the image just.... slide across the screen. (best way i can describe it) 
sorry if someones already said this. 

Original comment by matthewb...@gmail.com on 22 Aug 2010 at 10:51