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.

DS development > Opinions needed on rendering graphics on DS

#137863 - thx1138 - Thu Aug 16, 2007 8:32 pm

We're designing a DS application in which we need to overlay a series of images. One of these images is the size of the full screen so it's opaque, while an additional 10-12 smaller images of variable size need to be added one of top of the other to create the final image.

The challenge here is that the shapes are irregular so transparency is required. We'd also like to support alpha-blending so that the best possible quality is maintained. The process doesn't need to be done in real time as we're only concerned with displaying the final image - hopefully with a reasonable delay.

We've had feedback from a couple of DS developers. One says what we need to do shouldn't be an issue (even with software-based alpha blending) as long as we watch out for the 8x overdraw limit. Another developer has basically told us that the DS doesn't have enough power to pull this off.

Anyone have any thoughts or suggestions on this?

#137870 - sajiimori - Thu Aug 16, 2007 9:20 pm

The DS will handle that just fine, using any reasonable combination of the BG, sprite, and 3D hardware.

Using all polys tends to be simpler for artists and programmers, and it also allows more flexible sorting and alpha blending. However, you can only use polys on one screen without fancy capture buffering, and it's possible to run out of fill rate.

I'd use all polys if possible, and if I ran into fill rate issues I'd use a single hardware BG for the opaque layer and use polys over it.

Just to give an idea of how many viable options there are, I know someone who's doing something like this on the DS, all in software using a direct color framebuffer, with scrolling, and it runs quite smoothly. It just needed a few lines of assembler for the low-level blitting.

#137872 - NeX - Thu Aug 16, 2007 10:24 pm

You could just software blend. Probably the easiest way.
_________________
Strummer or Drummer?.
Or maybe you would rather play with sand? Sandscape is for you in that case.

#137896 - jetboy - Fri Aug 17, 2007 6:46 am

NeX wrote:
You could just software blend. Probably the easiest way.


Yeah. Just use 15 bit "true color" mode and do it 100% software.
I would also recomend doing all the calculations in real true color (3xbyte), then rendering finished image to 15 bit at the end. That way you will have easier blending calculations (speed) and a finer final result.
_________________
Colors! gallery -> http://colors.collectingsmiles.com
Any questions? Try http://colors.collectingsmiles.com/faq.php first, or official forums http://forum.brombra.net

#137936 - sajiimori - Fri Aug 17, 2007 7:00 pm

Gyeh, that's what I get for not reading the whole question. Software rendering is definitely easiest if you're not scrolling or otherwise rendering in realtime.

#138033 - thx1138 - Sat Aug 18, 2007 9:03 pm

Sounds like we should be reasonably safe if we go with bitmaps and implement the blending in software.

The original graphics are vector-based so another suggestion was to develop a simple rendering engine for lines and polygons. This would save considerably on space for the data, allow for matrix-based manipulations and the fill colours could be determined on the fly.

However, I'm told that 2D on the DS would likely be too slow when you factor in the point count and ant-aliasing. I'm guessing that the quality may also be a bit iffy with lines unless you oversampled.