VisualBoyAdvance-M

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 [img]<fileStore.core_Emoticons>/emoticons/laugh.png[/img]/emoticons/laugh@2x.png 2x" width="20" height="20" />

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

OpenGL isn't thread safe.

What choice do we have?

 

Fuck it. Count me IN!

we could tell linux users to go and sodomise themselves elsewhere? [img]<fileStore.core_Emoticons>/emoticons/tongue.png[/img]/emoticons/tongue@2x.png 2x" width="20" height="20" />

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.

 

[img]<fileStore.core_Emoticons>/emoticons/tongue.png[/img]/emoticons/tongue@2x.png 2x" width="20" height="20" />

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?