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 > Strange Pixel Glitching

#45894 - AkumaATR - Thu Jun 16, 2005 4:11 am

-- Immese appreciation to anyone who helps me det. what is causing this issue --

I have uploaded the Visual HAM project folder I am discussing to:

http://home.insightbb.com/~cecil.jason/files/wtf.zip

I have NO clue what's going on with this strange glitch. My program simply displays an image (bitmap mode, software) and scrolls some pixels over it (typical scrolling star program).

The weird thing is that there is a strange pixel glitch on the screen. I edited the source image I use as my background, adding a square so that the glitch would stand out more.

Weird things about this glitch:

If you swap line x and y (commented as such), the glitch goes away. the reason i don't want to keep it this way is that i would rather load the image from some ram that's faster than game rom (i was also using DMA earlier (why i need the image in something other than game rom)), but stripped down my code to try and pinpoint the cause of this glitch).

Basically, I have an array that I fill to mirror the image from game rom (i believe these structures are mirrored properly in memory as the code that fills them up is quite basic).

If I display from the array in faster memory, the glitch occurs. If I display from game rom, it doesn't. I suspect the glitch *may* have something to do with double buffering. Another strange thing is that if I change the number of stars, the location of the glitch onscreen moves. Total strangeness.

Also, sorry for posting so much the last few days. I am working on this stuff pretty much 10 hours a day as of a few weeks ago, so I have plenty of time to run into problems. Hopefully I'll be over the learning curve soon.

Jason

#45900 - Cearn - Thu Jun 16, 2005 9:27 am

I'm not exactly sure, but this may be it. Whenever you create a static array of global function, it goes into IWRAM. And you're trying to put a 38400 byte array (the image buffer) into 32kb or IWRAM. I'm a little surprised that you get anything at all. If you must have a second buffer in RAM, put it in EWRAM instead. There should be defines like IN_EWRAM or something to do that (I think it's MEM_IN_EWRAM in HAM)

Also if you need speed, it is advised that you compile in THUMB mode, not ARM, and if you must copy large arrays don't do it in 16bit chunks as that's about as slow as you can get. Casting to u32 and looping over that is about twice as fast, and using DMA about 7x (at least in THUMB, in ARM code it's about 15x). Oh, and don't include data files; data/code should be compiled separately and then linked, not included.

Most of these things are covered in the FAQ. If you haven't read it yet, now might be a good time.

#45916 - AkumaATR - Thu Jun 16, 2005 5:53 pm

Yes, I was blowing the IWRAM space. Thanks for pointing that out... I made the silly mistake of thinking 19200 < 32768 (my array was actually 38400 bytes long, however).

Making the image array global, and declaring it with:

__attribute__((section (".ewram"))) ushort16 image[19200];

fixed the problem. However, I also read in these forums that this should work:

__attribute__((section (".sbss"))) ushort16 image[19200];

as well as result in a smaller ROM size (since the array will be zero-filled before main() is called, rather than initialized in the ROM space). I also read that .sbss resides in EWRAM, so I would think the above would be functionally the same in a program?

Using ".sbss" results in this:

http://home.insightbb.com/~cecil.jason/files/ryu.jpg

The stars (which are supposed to scroll over the image) also are cmpletely non-functional as a result. Any ideas as to why ".sbss" causes this issue? I am using the build tools that come with Visual HAM 2.4.2.

Just for kicks I tried declaring the array as

__attribute__((aligned(4))) __attribute__((section (".sbss"))) ushort16 image[19200];

but it still experienced the same issue.

Thanks,
Jason

#45932 - AkumaATR - Thu Jun 16, 2005 9:28 pm

Apparently the linker isn't aware of ".sbss" in the toolchain that comes with the latest Visual HAM (theory).

The compiler doesn't complain, for ex., if I enter

__attribute__((section (".meh"))) ushort16 image[19200];

However whatever I put there (other than ".ewram", which works), including ".iwram", behaves the same (displays corrupted image/pixels). So my theory is that if section isn't known by the linker, it defaults to IWRAM. Anyone else have any other information on this, or ideas on how I could fix it without changing environments?

#45946 - tepples - Fri Jun 17, 2005 12:49 am

AkumaATR wrote:
Apparently the linker isn't aware of ".sbss" in the toolchain that comes with the latest Visual HAM (theory).

A section needs support in the link script and the startup code. Only recent devkitARM comes with a link script and startup code that knows of .sbss. I seem to remember that you can change some setting in Visual HAM and it'll use your installation of devkitARM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#47542 - Peter - Sun Jul 10, 2005 6:34 pm

Hi,

tepples wrote:
I seem to remember that you can change some setting in Visual HAM and it'll use your installation of devkitARM.


not sure if it really helps, but here is a document which describes how to setup VisualHAM with DevKitAdv.