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.

C/C++ > Setting pixels vs. Using sprites

#152675 - HubbubJub - Wed Mar 19, 2008 10:40 am

Hello, I'm a new DS programmer, and have been working on a game for a few days. However, I'm running into a problem very quickly:

I'm rendering graphics by setting the VRAM indexes manually. However, I'm running into a problem when I try to refresh the screen every frame; it seems as if it can't clear fast enough to keep up with how fast the game is moving, so a section about as big as a single screen starting from 1/5th from the top of the bottom window to 4/5ths up the top window is just solid black. I'm using memset, which to my knowledge is the fastest C function that can reset VRAM to 0 before drawing again. Should I just give up on setting pixels and use sprites instead?

I was thinking of just clearing an "approximate" section of RAM (i.e. only clear things that are moving), but I feel like the approximation involved would take longer than the already fast memset.

EDIT: Another solution might be to lower the framerate, which would be acceptable to me since the thing one is controlling is already zipping very fast. However, I'm not sure how to do that.

#152677 - keldon - Wed Mar 19, 2008 11:23 am

Are you calling a wait_for_vbl type function? How many objects are you trying to update?

#152679 - Master S - Wed Mar 19, 2008 11:56 am

This should be posible, it is even on the gba ;-) You should use some kind of doublebuffer eg. draw in a none visible buffer and copy (or HW flip) that buffer into vram during the vblank.

#152681 - silent_code - Wed Mar 19, 2008 12:08 pm

if you're not moving the whole scene, but only parts of it (e.g. sprites), then there's a way to reduce the amount you have to draw each frame, without db (which in general, seems to be the best approach anyway... but it depends in your game's needs):

first copy the section of the screen, that the sprite will be drawn to into a small backup buffer (simply allocate twice the memory your sprite needs for its graphics) of the sprite's size. then draw that sprite into the screen buffer. next time the sprite moves, you just need to copy the backup back to to the screenbuffer at the old position and then start again from the begining for the new position.

though, there are some issues with this: you need to properly order all moving parts of the scene. if you have lots of moving parts, use db, because the amount of backup memory could potentially grow bigger than another screen buffer could be.

that's it. happy coding!

ps: i also had that problem, but in the end i decided to go with the hw sprites - way faster! though it's a good learning experience. :^)

#152959 - mattlacey - Sun Mar 23, 2008 11:52 am

You can blit an entire screen and maintain 60fps on the DS.

As suggested above, I'd do all my drawing to a buffer then copy that to vram after waiting for the v-blank, should sort you out!