Alignment woes?

[starman2049]

For quite a while now I have been battling what I beleive to be alignment woes. everything would be running just fine and then I would add a few lines of code and then I would get mostly black screen with just the first few pixel lines of display showing through.

I tried to track this down and thought that maybe I had an alignment issue so I put in a

Code: Select all

sprintf(xdebug_string, "%0X", (unsigned int)(&acme8pt_start) );
(this is outside the main loop and only gets called once at startup)

on my init code to see if maybe some of my common objects data was getting loaded to a address that was not a multiple of 16 bytes. Funny thing was that the sprintf cleaned up the flashing black screen.

Then I would add more code and it would come back. For the past couple of weeks I have been in the habbit adding/removing lines of sprintf so that everything runs ok like this

Code: Select all

sprintf(xdebug_string, "%0X", (unsigned int)(&acme8pt_start) );
sprintf(xdebug_string, "%0X", (unsigned int)(&acme8pt_start) );
sprintf(xdebug_string, "%0X", (unsigned int)(&acme8pt_start) );
//sprintf(xdebug_string, "%0X", (unsigned int)(&acme8pt_start) );

I do this until the flashing black screen goes away. I have used this for at least a couple of weeks and it may take a couple of tries to get the right number of sprintf's in there but it always works.

For the past two days I have been trimming my vertex format down to optimize my game, but have now run into a situation where no amount of sprintf's make the flashing black screen go away.

Has anyone experienced anything like this? It seems like an alignment issue to me but I have spent the past two days making sure everything I can is aligned and I just can't get this to go away this time.

I realize it's a long shot but I am getting desperate...

[weak]

first of all, use memalign to get correct alignment.

and maybe you have some caching issues too. take a look at the howto

[ipsp]

From experience, this type of behaviour is generally caused by memory overrun, and less commonly memory leak.

Generally speaking if you have a piece of code writing into memory that it was not asigned then you may experience bad results but not always. For me this is generally a String related problem but often occurs when you are memcpy() structures of different sizes.

In 'C' a simple solution to memory alignment problem is to NOT let 'C' automatically added fillers to structures, as all integers are boundary bound i.e. if an integer does not sit on a boundary 'C' automatically inserts a filler until the integer does sit on a boundary.

The reason the 'printf()' might work is they might force memory to be alocated differently internally and hence no bad results will be seen. But I agree with the first person that responded use 'memalign()', but note this may still not fix your problem.

[starman2049]

I double checked all my memory allocation is using memalign(128, xxx) to be safe and make sure that xxx is a mulitple of 64 as well so as to avoid cache writeback issues.

Still haven't found the problem, it can be fixed by adding junk padding code (such as sprintf's above).

Visually, the top 20-30 pixel lines get drawn and then black for the rest of the screen (actually BGCOLOR, not black)

[weak]

texture and clut data has to be 16 byte aligned

[starman2049]

Double-checked that and they are all ok.

It looks like the draw buffer is getting cleared around 15 pixel lines into the draw. From what little I can see the scene appears to have rendered ok though.

If I remove the sceDisplayWaitVblankStart() then the 15 pixel band moves scrolls down the screen.

As luck would have it I can always get it to go away by adding 0-4 lines of those sprintfs, it just really slows me down and I wish I could get it to go away.

[chp]

How do you make sure you do not start rendering on the displaybuffer? It sure sounds like the next displaylist has started executing while the buffer is still displaying. Remember that when you use GU_DIRECT mode in sceGuStart(), the list will start executing right away as you fill it. I remember in another post we talked about double-buffering the displaylists, which adds complexity to which list is running and which screen is being displayed. What happens if you sleep until the list has finished executing?

If this is your problem, you could use a signal-interrupt (sceGuSignal()) to make sure you don't start rendering too early. Also, rolling your own sceGuSwapBuffers() that waits for the vertical blank before swapping the buffer (look at the parameters for the sceDisplaySetFrameBuf()-call) could also help. You still need to synchronize your rendering, just not synchronize your CPU to the currently executing list.

[starman2049]

Still trying to figure this out, and trying to think of how I can put your suggestions to good use. I don't see how adding some junk lines of code would make this go away if the problem is as deep as you suggest.

It sure feels like an alignment issue. I tried to generate a map file using:

Code: Select all

-Map,main.map

but that did not work for me. Is there a way to generate a map file with the psp toolchain?