What games actually push the GBA?

With 4 256 color BGs, 128 256 color sprites (with 32 of them partaking in affine transformations) and 5x overdraw, (with a 16.8 32bit processor behind it all) I sure don't see that many ambitious GBA titles. In fact, most GBA games look like they could be easily made on the SNES. One thing I noticed is that a lot of GBA games actually do use 3 or 4 BGs, but one of them is usually used for something that could have easily have been made with sprites, like a status bar that uses 16 8x8 tiles or a vertical pole that is 16 pixels wide. (I don't think I've ever seen a GBA game even use more than 80 sprites, leaving plenty for a status bar.)

I guess mostly the 3D titles that used software rendering on ARM7, which would have needed Super FX if made on Super NES and probably still wouldn't have as much frame rate/detail. Like Payback (licensed by Nintendo).

But how many sprites are in Vulkanon (homebrew)?

Official GBA games. I remember talking about how sprite multiplexing on the GBA was possible on the HDMA Sprite Demo Not Working thread. I don't know all the GBA games out there of course, but I'd say the only GBA game I've seen that does a moderately well job technically is Gunstar Super Heroes. I would have loved to see something like Gunforce 2 on that system, (off course I would ) as I doubt the GBA can't handle something like that. I thing I always find funny is how people say that the GBA hardware is comparable to the SNES, if not, slightly better when its really a substantial leap. (Almost about as big as Master System to Genesis?)

If you were referring specifically to the use of OAM multiplexing in licensed games, Capcom's Super Puzzle Fighter II uses multiplexing. It has slowdown that the PS1 version lacks (hence no "Turbo").

Super Monkey Ball looked pretty good on the GBA.

That has sprite multiplexing? when the blocks hit the floor, are they not turned into part of the tilemap like Tetris? Also how does a puzzle game have slowdown? (If they found a way in Sonic the Hedgehog, they'll find a way...)


Oh, yeah how could I forget Super Monkey Ball Junior? I actually found that game surprisingly well made, and I'll take the golfing minigame "Party Game" over the one on the Gamecube anyday. What I probably been more specific about is how many 2d games (modes 1-3 I think?) actually are as good as the specs would suggest. Although SMB on the GBA was good and there'd be no way to have that game being 2d, I think that the 2d titles on the GBA look much better than the 3d ones, because 1. from what I understand, 2d is in general much less processor intensive than 3d and 2. The GBA did not have any hardware support for 3d unlike the DS, making it one of the most powerful solely 2d systems I've seen.

So, are we talking "pushed" as in dropping frames or taking crazy shortcuts to achieve what they did, or "pushed" as in they broke boundaries that few other games managed to achieve? Or both?

I can't say I recall any GBA games of mine where I noticed frame dropping, but my eyes are terrible judges of frame per second to begin with. I will say that when V Rally 3 came out, I knew it was king. That game not only handled non-bland environments, it even added elevation to its courses. Most racers I'd seen up until that point where flat, level tracks, and jumping only possible via F-Zero / Super Mario Kart like physics (if you could jump at all). They even added a 1st-person driver's view. I don't think any other GBA racer had that before them (or after, I dunno).

I played the Ecks vs. Sever games. They're pretty fun as far as simple FPS games go, and had a lot of levels with multiple routes and various guns. The environments and enemies were somewhat bland, but the whole experience was smooth on the GBA.

As for what games actually are doing a lot under the hood, you'd probably have to pop open an emulator with a debugger and look at how many DMAs are going on, how many CPUSets and CPUFastSets it's called, and track CPU usage (no$gba is perfect for all of the above). But generally, with the GBA, developers were pretty spoiled. Coming from the GBC, I sometimes still have a hard time imagining myself running out of cycles unless I try to do something ridiculous. If you catch a game using Halts or VBlankIntrWait BIOS calls though, it's usually just sitting on its hands in that case, meaning its not doing anything particularly important at that moment, so not a good candidate for a game "pushing" the limits.

If I had to guess, I'd definitely put some of shitfaced clown's GBA demos up there as well for pushing the GBA.

Tetris Worlds has a 10x20-cell playfield with 8x8-pixel cells, which match closely with the tile grid. SPF2 has a 6x13-cell playfield with 11x11-pixel cells drawn as sprites. That surprised me when I was tracing through it, as I had expected it to use the Puyo Pop technique (which my Luminesweeper homebrew game also uses) to draw 12-pixel-wide cells as a pair of ordinary backgrounds.


It happens when the game is throwing up big particle systems during explosions of joined gem blocks.


Then why limit it to licensed games? Homebrew games are just as valid cases for pushing the hardware.

I was just wondering if there were any developers back when the GBA was made who actually tried. you can definitely tell they went from GBC to GBA, because a lot of GBA games aren't very ambitious. (When I first saw the GBA specs, I thought they were over exaggerated or just plain made up.) I guess it doesn't matter If there licensed or not though. I think it would be cool to see metasprites this big on the GBA (even though this would take up the entire screen. )


The only reasonable thing I think they could have done to improve the GBA is to have all the sprites participate in rotation and scaling or at least scaling. I guess you could just use the first 32 sprites and use sprite multiplexing down the screen, but this seems really hard to pull off.

Well, it depends on which games you're talking about. I remember seeing quite a lot of GBA games that fit your description, way back in my old Nintendo Power issues. I think they were being cautious or didn't know what they could do. You see that a lot with games early on in system's lifetime. There were a number of games on the GBA that made me feel like I was playing a portable SNES, however. I remember Rayman Advance for being one of the earlier titles to exploit the GBA's massive color palettes, and F-Zero: Maximum Velocity showed the system was capable of emulating Mode 7-like graphics. Then there was Golden Sun, which speaks for itself.



That's already the case; every sprite you can display can be scaled or rotated since each of the 128 OAM entries has flags to enable it. The only thing is that there are only 32 distinct "groups" of scaling parameters that apply to the sprites. So I guess you meant to say that every of the 128 OAM entries should have its own scaling/rotation parameter instead of sharing it with the other sprites in its "group". As far as I know, the DS has the same scaling/rotation limitation for its 2D engines.

As for pushing, you're pretty much stuck with the 3D games (which are mostly CPU grunt). There isn't that much you can do with mode 7-like effects (especially when you only get two simultaneously) and while rotating/scaling sprites helps, there's a limit to that too, and if you push clever techniques in the video hardware you usually aren't pushing the CPU then ;P

Anyway, for a good example of a 3D game:
https://www.youtube.com/watch?feature=p ... Ia0oE#t=32

As for cleverness: Sonic Battle's battle stages do a rather unorthodox use of the layers, with the two floors (bottom and top) being two rotating scaled background layers, and the walls being skewed sprites (everything else is just sprites as normal).
https://www.youtube.com/watch?feature=p ... IQp9M#t=25

Also Golden Sun likes to do particle effects in battle a lot.
https://www.youtube.com/watch?v=rn34B4XhJ4I (spoiler: boss battle)

I just find it a bit disappointing how toned down the shooters and run and guns were on that system, especially when there was no need for it to happen given the hardware. Looking at you, Metal Slug Advance! (Seriously though, why is the animation in that game so choppy? Does they game even update vram or are all the tiles for all the animations stored even when there not needed?)

I don't know which games pushed the GBA, but I certainly known some that could never have similar graphics on the Super NES (without an extention chip). The SNES has only 1x overdraw, and some games such as Secret of Mana and Seiken Densetsu 3 often have sprites that disappears as they break the limit. I bet many GBA games would have this problem if ported on the SNES.

The SNES can only have 2 16 colour BG and 1 4 colour BG at best. I know a lot of GBA games that relies on 3 or more 4 colour BG. But however, the GBA BGs lacks the priority bit of the SNES, which also makes them less powerful.

Really? So if you had a two 64x64 sprites next to each other to form a 128x64 sprite then you would only use one of the scaling/rotating perimeters? Then in that case, why did afterburner look so terrible on the GBA? The ground is so empty compared to the arcade version, but if you can use the same scaling and rotating parameters, then you could make one long horizontal strip of the ground that would cover the width of the screen, but Afterburner on the GBA appears to have everything on a separate plane from each other.


Meaning that, for example, the poles on the mill levels on DKC3 have to be their own BG layer?

GBA backgrounds sacrifice the priority bit to have one more bit of palette select. GBA backgrounds also lack offset-per-tile and subtractive blending.

Hmm, time to do a little investigation. I loaded up the ol' Sega Arcade Classics ROM in an emulator...

Aha

Well, there you go.

Emulator closed; no need to look further.

Look, these "why did so-and-so developer do a shitty optimization job on such-and-such hardware" threads often comically miss the point. In the above case, a 3rd-party developer, a continent and a human generation removed from the original game and its developers, is never going to make something that stands up to the original. They have neither the same emotional investment to do a good job, nor the reputation of doing a good job.

Even reputable companies will sometimes fumble with their first set of releases for new hardware. (Secret: they often outsource anyway...) The important thing for the company is to have something recognizable sent out the door on schedule, not to have all routines optimized via tree searches.

When something is lacklustre on good enough hardware, it's a human failing on the software side. Thus systems cannot be compared to each other on mere technical terms by comparing software / game examples.

In my opinion, it makes complex layering easier on the GBA. Assuming Mode 0 on the GBA, imagine having a cave level with stalagmites and stalactites composed of two foregrounds (one to cover the main sprites, one to go behind them) a standard background for the level itself, and a parallaxing far background just for kicks. Instead of having one BG map (for the stalagmites and stalactites) where I need to know which bits to flip in VRAM before writing tile data, I can just make two separate layers in VRAM and be done with it. That's the trade off I see. Instead of doing priority on a per-tile basis, the GBA just gives you more BGs to work with.



You could, but it wouldn't work out the way you wanted. If you had something like this and you tried to have them use the same scaling/rotation parameters, you'd end up with something like this result if you tried to simply rotate them by 45 degrees. You wouldn't end up with the result you intended you get. To get the intended result, you could scale them by 45 degrees each, then manually calculate the X-Y position that the red one should be. Obviously though, that cuts into CPU cycles, but depending on what you're doing, going manual may not be bad.

Sounds like typical Capcom.

I figured they got rid of offset per tile functionality because the floor on Yoshi's island on some of the levels doesn't warp like it used to. Why did they get rid of subtractive blending though? I guess you could pull off about the same effect by averaging really dark colors. Also, I had no idea that Sega themselves didn't make Sega Arcade Gallery. I'm sure it would have been made much better if they did. (Who is Bits Btudios?)


I understand the hardware can do it, it just puzzles me how no one really took advantage of the hardware. I've seen much more sporadic games on Neo Geo class hardware than the GBA, which from what I gather, is ultimately more powerful.


I had understood that when I posted that. The GBA probably has enough power to make it happen. (Mathematically, how would you calculate the position? I imagine you would find a center point between the two objects and work from there.)

Edit: I found a tutorial for moving to rotating sprites together, but I haven't looked at it yet. (It's using C though. ) http://www.coranac.com/tonc/text/affobj.htm

You need trig to build the matrix. You can use similar trig to calculate where the center points are.

Don't forget that even if they do, they probably don't have the means (read: time and budget) to do it anyway. The Sonic Spinball port was made off the original source code (which they found by pure luck at the house of somebody who worked at STI, since Sega had lost the source code), which was written in C so in theory the gameplay could easily be converted as-is on the GBA (maybe altering some stuff like the size of int - EDIT: actually I think 68000 defaults to 32-bit int...), and it was still a very lackluster port. And most of the time the developers who port the game don't even have the source code in the first place.

Also on a non-GBA example, let's not forget the 3DO port of Doom, which was done in 10 weeks because of incompetent executives...

A Sega Genesis game written in C? (Well I guess Sonic Spinball isn't exactly "processor intensive") Also, I seems like companies totally discarding their source code seems like a major issues with ports. (What is STI? I looked it up Google and got, you know, and I also got a Texas gun manufacturer.) One of the examples of a port made without the source code is R-Type 3 for the GBA, which is an abomination. (VERY sh*ty music and a lot of the sound affects are either changed or flat out removed. The collision detection is atrocious and the force is noticeably dumber too. They also got rid of the awesome opening for some reason.) Just looking at the box art, you can tell you're in for a "ride" (Considering I beat the SNES game on the second loop with all three forces several times, I could probably do a better job replicating it.)


God how ugly... (Games like this are the reason the "Official Nintendo Seal of Quality" was changed to "Nintendo Seal of Quality".)

That would be the Sega Technical Institute, a development team located in the US.

Umm... yeah? Please look up the intertwined histories of the C programming language, UNIX, and the 68000, which was basically modeled after PDP and VAX mainframes, which is why it compiled C programs so well.

Yes, hardcore peeps coded Genesis / Arcade games in 68000 assembly, but a plurality of games were written in C.

If you want to know the whys and wherefores of history, it's better to stop ranting and start reading.

Yeah but C was usually avoided like the plague for games back then because compilers weren't exactly great at optimizing (not to mention C being quite wasteful on a machine with such low resources available, remember there's only 64KB of RAM) and a human programming in assembler still had a much bigger chance to make the code faster and taking up less memory. It was only in the mid-'90s that using C for games became more widespread.

Sonic Spinball was made in C because the game was done in a rush (it was made specifically because they were already aware that Sonic 3 wouldn't make its way to 1993 christmas). If I recall correctly they only had 9 months of which only 6 could be spent developing. The result wasn't bad considering the constraints =P (also probably explains why there are only four levels, and why the music licensing issue was only noticed at last moment)

I know that Ultimate Mortal Kombat 3 was programmed in C, and probably the earlier ones (in fact, I think the code from the ports are actually based on the arcade version, which most of the dumbing down being either hardware limitations or running out of ROM space). I know that the XBand firmware was programmed in C too. I imagine Hard Drivin' as well since the port had the same programmer who was hired for Sonic Spinball (no idea if it uses assembly for the drawing routines, though).

I bet that Capcom didn't develop the GBA version of Puzzle Fighter at all, but just took the decision and outsourced the port from the arcade version. 90% of the time, remakes or ports works like that.