She canna take any more, captain!

FORWARD: The forum system shrinks images. Click them for the full-size versions.
__________

It’s baffling, really. Perplexing. Curious, by anyone’s reckoning. I’m still not sure what all is going on, but I know that it’s in the way. That awesome project I’ve been working on? Virtual Boy can’t handle it. It’s too much for it to take!

You’ll remember my September progress report thread, wherein I mention a game yet don’t disclose its identity. The game was F-Zero Maximum Velocity, the first GBA game, and I aimed to remake it on Virtual Boy, because how cool would that be?

As mentioned, the project started out with a couple weeks of reverse-engineering. I hacked the GBA game to get its graphics and level data, which I then began implementing on Virtual Boy.

It was going quite well. A little scrolling here, a little affine there, a little optimizing over there… It all looked prettey good. Everything was taken from the GBA game, and care was taken to remain true to the original:

* All of the graphics came from the GBA game and were modified to work on Virtual Boy
* Palette animations on GBA weren’t possible, so an equivalent solution on VB was used
* The GBA game used two affine layers, but I used one on the VB project and got it working pretty well, even so far as to have the same scrolling graphics the game had beneath the track
* All graphical animations from the tracks were implemented, including all course features and the stuff off to the sides.
* As it’s on Virtual Boy, parallax was added for a depth effect, as seen in the screenshots.

As mentioned, the GBA game uses two affine layers, and I managed to get away with just one. The “floor”, as I call it, is the same size pixel-for-pixel as the track layer, but it scrolls at a slower rate and therefore extends off to the sides of the track quite a ways. In order to achieve that effect, I had to modify the floor maps to fit on a bigger canvas.

I spent a good week making a program to help me do just that, and it worked great. The plan was to make an all-in-one utility which would be released alongside the game (source code for both) so people would get a taste of game development even without being a developer themselves. I specifically wrote it in Java so people would be able to play with the code. (-:

The utility was useful because it did three things:

* Loaded the GBA ROM for extracting and saving data
* Modified floor maps
* Processed image files to convert them to the VB character format

I painstakingly went through the course floors, increasing their size, and driving around the track in-game to make sure the floor features appeared in the correct spots relative to the edges of the track, so that it would still “feel” the same as in the GBA game. More time was spent on the floors than any other part of the project.

In the GBA game, the tracks and floors are both compressed. I mean, they represent 4096×4096-pixel images, so they can’t just be stored in ROM as-is. I had a grand plan for this utility. See, I would implement the same compression algorithm used in the GBA game (compressors are harder to write than decompressors), then implement a level editor. The data produced by the utility would be in the same format as, and therefore compatible with, the GBA game. Buuuut, that’ll have to wait for another time.

When I finished my compressor, I verified it was working correctly by running it on the track and floor data from the GBA ROM. It worked correctly, and quite well: my data was 10%-15% smaller than the source data I pulled right out of Nintendo’s game!

I implemented the horizon layers, and those worked just fine. It was surprising, ’cause I wasn’t sure if the VB could handle that much graphics stuff going on. Then I implemented the minimap, and that’s when it hit the fan.

That little guy in the bottom-left corner. It’s a 64×64-pixel BG map with a single OBJ sprite over the top of it to indicate your position. With that in there, the VIP entered overtime and the framerate dropped to 25 fps. “No problem,” I thought, “I must have been at the edge of its processing power with those horizon layers. I’ll just disable one of those and see what I can do later on to reduce the total number of pixels drawn.”

It didn’t work. Removing both horizon layers didn’t work. And this isn’t one of those “turn off the left/right display flags” kinds of dealies, I outright refrained from configuring windows for the horizon layers and it still didn’t work. There’s something about the fact that the minimap overlaps the affine window that just hits the VIP too hard.

I modified the program so I could resize the affine window, and… well, in order to get it to run full-speed again, the window had to be prohibitively small. It was simply an un-salvageable situation. I discussed matters with dasi, and now I’m posting this thread.

Consulting Mario’s Tennis for some insight, I found that the game was taking up a mere half of the available screen real estate. Well no wonder it could run at 50fps!

I still have two months to put together a Virtual Fall submission and sample project for devkitV810, so I’m not out of the race. I just have to start over. Again. (-:
__________

Attached to this post is a zip file the last build of this F-Zero project. Controls are as follows:

Left D-Pad Left/Right: “Steer”
A Button: Move forward
L Button/R Button: Change current course
Select Button: Toggle 3D/2D mode
Start Button: Toggle minimap
Right D-Pad: Adjust affine window size (left/up make it smaller)

It runs just fine in Mednafen, but on the hardware it’ll be at 25fps unless you disable the minimap.

This is not a Virtual Fall submission. This is just letting you guys know what I was working on since I’m changing projects now.