gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Compiler Optimizations Screwing Up Blending!

#39067 - MrD - Mon Apr 04, 2005 3:14 am

Hi!
I'm trying to use BG0, REG_BLDMOD and REG_COLEY to fade a picture onto the screen. I've got the picture to display perfectly (spent hecka long time weeding out dupe tegels and such ._.) and such...

The problem comes when I try to change REG_COLEY over time for my splash screen:
What it's meant to do is fade the screen to white.
In semi-psuedocode, what I've got looks like this:
Code:

// Up here, BG0 is enabled in REG_DISPCNT, and palette, tiles and tegels are set-up. And the VBlank interrupt is set up. And the interrupt is set to respond by setting REG_IFBIOS.

vu16 no_vblanks_occurred = 0;     // No effect switching volatile on or not.

REG_BLDMOD = bit0 | bit1 | bit2 | bit3 | bit4 | bit5 | bit 7; // All A-Targets and 'whiteblend'
REG_COLEY = 0;

while (no_vblanks_occurred < 64) {
   asm volatile("swi 0x05");
   REG_COLEY = (no_vblanks_occurred >> 2);
   no_vblanks_occurred++;
}

// Down here I set REG_DISPCNT to a forced whiteout and set up another splash screen or something.


It's worked before because i've been using BLDMOD and COLEY for fades all over my game, it just doesn't want to play ball with the title splash... :s
I'm using DevKitARM with a modified AAS C++ Makefile.
My theory is that -funroll-loops or -O3 in my gcc flags is screwing up my compiling... but when I disable them... ODD THINGS happen. Which is no good.

All I get is either a complete lock up in VBA and hardware, or no fade and just a solid normal coloured screen...
Any thoughts?

#39068 - tepples - Mon Apr 04, 2005 3:49 am

Have you tried moving the asm instruction out to a separate function?
Code:
void wait4vbl(void)
{
  asm volatile("swi 0x05");
}

And have you made sure that your register defines are correctly marked as volatile?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#39093 - Lord Graga - Mon Apr 04, 2005 1:53 pm

I think that you are calling THUMB calls in ARM. You should call SWI 0x050000 instead of SWI 0x05.

Code:
#if   defined   ( __thumb__ )
#define   SystemCall(Number)    asm ("SWI     "#Number"\n" :::  "r0", "r1", "r2", "r3")
#else
#define   SystemCall(Number)    asm ("SWI     "#Number"   << 16\n" :::"r0", "r1", "r2", "r3")
#endif


Use this code for systemcalls in C, with DevkitARM. If you are compiling the code as THUMB, it will do THUMB system calls - if ARM, then it will do ARM calls.

#39095 - MrD - Mon Apr 04, 2005 2:13 pm

What'd be nice would be some kinda pair of braces which tells the compiler to get it's evil compilery mitts off-of that piece of code.

I'm gonna try what you both said, although I'm not sure that calling something that should be called as often as VBlank should be called by a function. ._. But then again, there's no arguments for it... argh! Dilemma! (I've got it as a define atm.)

I'm going to check mah headers for volatiles.
_________________
Not active on this forum. For Lemmings DS help see its website.

#39101 - MrD - Mon Apr 04, 2005 3:34 pm

Wahey, everything is working! Kudos for yous guys!

Actually, I don't know what fixed it... I didn't change anything...
I checked my headers, and everything seemed fine and dandy, and then I checked a whole bunch of stuff and tried anything that I could think of... Making everything volatile, making nothing volatile, fiddling with the makefile, fiddling with my path, everything!

Turns out I'd missed one line out of my code:
Code:
REG_BLDMOD = bit0 | bit1 | bit2 | bit3 | bit4 | bit5 | bit7;


I feel like a complete goof. I'm sure that line was there when it wasn't working, but when I added it again, the fade worked like a charm.

Edit: I think this might've done something, I dunno. Sometimes when variables get compiled away, I do this to 'em.
Code:
(*(u32 *)(somewhere out of the way)) = (u32)&variable;

Sometimes works as a last resort making sure the compiler realises that that variable is there for a reason.

Thanks for the help though! :)
_________________
Not active on this forum. For Lemmings DS help see its website.

#39139 - tepples - Tue Apr 05, 2005 2:51 am

MrD wrote:
I'm not sure that calling something that should be called as often as VBlank should be called by a function.

Compared to some other functions, waiting for vblank isn't called "often" at all. It's called only about 60 times a second.

Later you mention that sometimes you copy variables to "nowhere" in memory when you disagree with the optimizer. That can lead to bad karma, especially when No$gba starts complaining about "errors".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.