forums.ps2dev.org

[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

[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.
_________________
GE Dominator

[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: