During my semester break, I worked on VBA2.

I now understand the ARM core reasonably and I started rewriting the complete graphical subsystem.

I can already process VRAM data and the video registers to produce bitmaps of (character mode) BG layers. (See screenshot)

Instead of rendering only a single line, I process the whole BGs at once, so that should give some nice speed boosts.


I plan to let this new C++ class for managing the GBA's graphical subsystem produce 128x128 ... 1024x1024 bitmap planes, which a hardware accelerated OpenGL renderer will further process with special effects like scaling, rendering, color manipulation and of course combining, clipping & rendering it all to the screen. Maybe this will also look better in higher resolutions. With a few hacking it might even be possible to get real widescreen support on some games.
Sprites are also perfect work for OpenGL instead of a software renderer.

If you want to help me and have a good knowledge of OpenGL, don't hesitate to contact me. I will do the preprocess work and you do the rendering.


You can always find the latest source code at http://code.google.com/p/gbxemu/

Mudlord will want to use Direct3D xD

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

Since only OpenGL is platform-independent, and is supported by Qt, I'd go with that.

OpenGL isn't thread safe.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

What choice do we have?

Fuck it. Count me IN!

we could tell linux users to go and sodomise themselves elsewhere?

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

That will annoy Nach D: We don't want that D:

but mudlord, remember we are developers,.. we don't have to develop with usability in mind. *sarcasm*.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

Today I made a lot of cleanups to my own code (I'm learning the GBA graphic system while developing, that's why).

Mode 0 now supports processing all 4 BGs with up to 4 256x256 macroblocks per BG. 256 colors x 1 palette and 16 colors x 16 palettes work now flawless, including tile mirroring.

Repetive tasks are unified with arrays as much as possible. Memory of picture data is managed by a small CPicture class (my own code).
All colors are converted to ARGB format as soon as possible in order to make processing easier (no bit masks or bit shifts necessary all the time).
I will later use the alpha channel to let OpenGL handle transparency so I don't have to.
We could even transport the alpha channel to the user so he can export PNGs with a perfectly fine alpha channel if he wants to rip sprites or BG layers. I'm so excited ^^

Next on the list are the sprites and window features.

Have you thought of rendering modes like Mode7?

GBA has no mode 7 (only 5 modes)

as far is I know now, it supports rotation & scaling, but only in 2D

EDIT: hm, looking at F-zero (uses mode 2), I wonder how they did that effect of the layer being laid out to the back
And where does the sky come from???

I just uploaded the code for creating the picture of a mode1 rotation/scaling BG

Edit:
Creating pictures out of every mode is now supported. The bitmap modes were extremely easy, just some lines of code.
What's missing now are the window features and sprites.

mode 7 is simulated using 2 layers of mode 2.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

Here's a screenshot from the current version. I added a window that can display each BG seperately and even export it to PNG. Qt is amazing by allowing to do that in just 5 lines of code. (Qt even exports the alpha channel)

The left (main) window uses the old VBA's graphics emulation code with an OpenGL accelerated QPainter-drawn Widget.

The right (debug) window uses my new GBA graphics emulation class.

Both windows are fed using my display driver architecture.

Very nicely done. We need to get in touch. There needs to be a way to scale that LLE output.

That HLE output is quite good. You just need to work on layering the other BG's as textures it seems.

I will need some weeks to finish off the preprocessing, that debug window helps me in verifying my code.

(01-04-2010 12:40 AM)spacy51 Wrote:  EDIT: hm, looking at F-zero (uses mode 2), I wonder how they did that effect of the layer being laid out to the back
And where does the sky come from???

The projection effect is accomplished by changing the affine transformation step values throughout the frame, up to every scanline. This is usually done with HDMA but you can do it with HIRQs.

I don't know specifically about the sky in F-Zero X right now, but the part above the horizon line is often accomplished by changing the screen mode in the middle of the screen and using a normal text BG for it - that's how Mario Kart does it. It can also be done with sprites, or by changing the affine parameters to point to it (but this is a lot trickier to manage). In mode 1 you can use one of the text BGs on top of the affine one.

Rendering the entire screen at once is going to give you massive compatibility problems. As you can see from from the two examples in this post alone a lot of games change what's on the screen while it's being drawn. Games use it for lots of other things too, like color gradients and wavy scrolling.

That's why emulators of just about every 2D platform use per-line renderers instead of per-frame ones. In fact, in some ways per-frame is slower because you're working with frame sized buffers instead of line sized ones. This applies to priority combining and alpha blending. You'll end up with a lot more L1 misses.

One of the big speed hits from typical line based renderers vs frame based ones is that they will check every sprite every line to see if it should be drawn. You can improve upon this approach by caching which sprites are on which lines are on then only changing this if OAM has been modified before the line. Usually OAM is only modified in vblank so you end up recreating the table once per frame instead of once per line. Even the few games that perform sprite multiplexing only do so a few times per frame.

I've mentioned these things in another thread, but I think that trying to do the layer compositing in OpenGL is just asking for trouble. You're not going to be able to correctly emulate blending so easily (or mosaic, but I think most people don't really care about mosaic anyway). The only way I can think of doing it is with a relatively complex depth peeling approach that would require at least three passes. OBJ windows are also going to be pretty problematic.

Caching the backgrounds into bitmaps (correct me if this is not what you're doing) might also prove a little unpleasant - basically, what is your strategy for dealing with modifications to them? Do you plan to recreate the entire background when any part of the map is modified? Or just a part of it? Unfortunately, in OpenGL modifying textures can be slow, even if it's just a part of it (sometimes especially if it's just a part of it). An even bigger issue is what happens when the tiles themselves are modified, since it can be expensive to track where in a map a tile is being used. You may end up having to re-cache every map any time any tile is modified. Some games modify tiles to animate them, and if you recache the entire maps you'll end up with something that's probably substantially slower than a full software renderer. Oh yeah, forgot about palette modifications, another common per-frame mod. I guess you're basically going to be stuck recaching the whole map a lot no matter what. Layers are at least 256x256, already a decent amount more than the work rendering them to 240x160, but they can be up to 512x512. Affine maps at up to 1024x1024 are quite a bit worse, although there you do save on not having to transform them.

One more comment: if you found the bitmap modes extremely easy then you're probably not emulating them completely. I say this because the bitmaps are affine transformed like the affine layers in modes 1 and 2.

Wow, sounds like I have a problem.

You should have taken the comments on this matter that I posted several months ago more to heart

It's possible to emulate all of GBA video using shaders, but it'd require some damn complex ones with lots of texture lookups and multiple passes. A DS scener by the name of WolfgangSt is currently writing a DS emulator (or at least he was, haven't seen any public updates in a few months) that renders in hardware. But it's still very incomplete, and I told him a lot of the same things I told you. At any rate, he's doing very little caching, meaning that he fetches tile maps and paletted pixels using shader code. This means that rendering a quad with that shader results in it actually rendering those pixels from a layer like a DS would. Raster effects weren't a problem because it could render a line at a time this way. But I still don't know how he intends on handling blending or OBJ windows.

I think that you should step back and determine what your basic high level goals are. If your main goal is something faster than VBA's current renderer then that's very attainable. If you want something cleaner then you're probably going to have to make a compromise somewhere. If you want it on harder so that you can tie in shader effects at an earlier stage of the rendering pipeline then you're probably not going to get it.

I disabled the new graphics code for now and use the old code.

Anyway, I noticed the new Qt 4.6 SDK now offers sound input/output classes (platform independent), so VBA2 now blurts out some noise. It seems kind of right already, but I have to further work on the timing.

EDIT:
I am so happy, sound output is finally not stuttering anymore.
I even read Qt's source code and all, but I think the cause was just that the audio engine calls reset and resume too early at the beginning.
I found out that the windows implementation of the QAudioOutput class uses the WaveOutOpen() function from the Windows API. The is supported since Windows 98.