I distinctly remember Spider-Man 2 on GBA having a 3D overworld. It was my first introduction to the concept of "low framerate" in a videogame haha. Incredible what people were capable of doing with the hardware back then.
Amazing - a purely software rasterizer on 16MHz, no floating point, 16-bit data bus, at most 512k of RAM? That’s the original 68k! What’s everyone’s excuse for not getting SM64 running on a Macintosh Plus?
I guess you're probably joking, but in case there's any actual confusion:
ARM7 is fully pipelined, and GBA connects it to 32K of on-chip zero-wait-state SRAM, so it's possible for optimized code to approach 16 MIPS with 32-bit operations. The original 68K is a multi-cycle processor and Mac Plus runs it at 8 MHz, which tops out at more like 2 MIPS for 16-bit operations, less for 32-bit operations (the ALUs are only 16-bit).
It's funny to me when people apologize for not being artists when they've produced actually nice looking art. It's like a host saying "excuse the mess" when entering their nearly immaculate home.
I wish I had kept some of my game development experiments because then I could show you what actual bad art looks like!
I should have included a disclaimer -- I agree that textures and sprites are excellent, but they come from asset packs (for this same reason I cannot redistribute them in the source release). Only the crossbow placeholder is self-made.
I don't have any issue with paid asset packs, I would gladly build the entire game with third-party art, but there is only so much of it in the necessary style, resolution and quality.
It might look much better if you picked a palette with a mood (https://lospec.com/palette-list). The resolution mismatch between the foreground crossbow and the sprites and background textures could be made less apparent too by reducing the resolution. For the monster sprites there's always scaling and palette flips. But yeah, with those sprites (and sound) defining the game's identity it's a bottomless pit.
Not sure if you care at this point, given that you stopped working on project, but there's a better way to find the ray direction for each column than using sin/cos for every one, which will also get rid of the slightly warped look:
Calculate the two vectors from the camera at the very left and right of the screen (using your fov angles and sin/cos, that's fine). Then, to find the ray direction vectors for each column, interpolate linearly between your left and right direction vectors, and possibly normalize the resulting vectors if your ray walking algorithm requires it.
This will create a perspective that integrates tightly with sprites that you 3D project the usual way, and lines will stay straight lines.
In my experience there are two mistakes people sometimes make that leads to the fisheye lens look. The first, as parent mentioned, when calculating the ray directions you should linearly sample a line rather than interpolating view angles. Second, when doing per-column perspective division, you should divide by dot product of the forward vector and the difference between the ray intersection and the camera location. Often if someone is making the first mistake they are also making the second.
Following this will give you the normal pinhole camera 3d projection that we all expect to see from a 3D game.
Rule of thumb I found as a beginner in 3D graphics: any time polar coordinates seem like the obvious solution, there's usually a better way.
As someone who has tried and failed at many points throughout the years at building a game I couldn't agree more with "Build a game, not a game engine" it's hard not to get sucked into the game engine black hole though.
Its depends what you like. Usually programmers focus more on game engine part, while designers on the other. And thats why is hard to make game solo :)
Galaxial developer fall into that hole too. Too bad, because alphas looks absolutly super great.
> Content. Brace for an obvious statement: it is one thing to imagine a grand, Daggerfall-scale game in your head, and a completely different thing to actually start building the pieces that make it up.
This is what always kills it for me. It's not so much that there aren't good off-the-shelf content packs, its that unique gameplay ideas with unique visualizations don't have ready made assets. Even for a simple game like pong, if you want to do something graphically unique with it (make the paddle shake, charge up, or have a power bar embedded in it that fills up whatever), then you better be prepared to become an artist or find someone who will be your game's artist.
And also like the article points out, the latter is fine if you're looking to commercialize it, but it doesn't seem like there are many artists offering their skills for free games made casually in a developer's spare time. It seems there's a critical threshold of game development "seriousness" that needs to be committed to by all involved to make it worth the time and effort of others.
Tangentially related, I've been extremely impressed following 3DSage's work. I've only dipped my toe into GBA programming ("hello world"-level stuff), and the fact that they built a real-time 3D level editor is mind-blowing to me.
I'm personally a bit more impressed by the Tomb Raider port mentioned in another thread, the linked game is doom/duke3d-esque and the GBA cpu should be roughly on par with a 486sx both in terms of clock speed and instructions per second (assuming you spend most of your time in code using the fast-ram).
The editor and looking at another video from sage3d also the rendering method, seems extremely reminiscent of duke3d. You can see a review of the duke3d rendering and sector setup on Fabians page.
Why the Tomb Raider port impresses more is because Duke3d-like renderers can work on straight spans and only interpolate textures in on direction and also get "free" hidden-surface culling (ie they never draw more than is seen), Tomb Raider on the other hand seems to have arbitrary texturing probably more overlap as well.
The takeaway that "content" can be the hard part in making a game is why I think its so important to make games with teams. There are some folks out there who will produce art the way an engineer produces code; all they need is to be empowered.
The best games are developed as a technical-artistic partnership, with both sides pushing and enabling the other.
From my perspective, this is a great outcome for a game-making attempt. There's no shortage of fun games coming out lately - far more than I have time to play. But these days they're largely made by amateur non-programmer indie devs tooling around in Unity or similar, and have no technical merit despite being very fun. What I'm lacking these days are fun technical accomplishments to read about in the gaming space, like a GBA raycaster.
No offense meant to the author at all, but I probably wouldn't have played this game even if it were fleshed out and finished. Very glad I got to read about some of the technical decisions that went into making it and poke through the code though.
This reminds me of playing Ecks vs. Sever on the GBA. A raycasted 2.5d doomlike game based on a crappy movie. It was pretty impressive for a GBA game, and it ran well, never stuttering. It had some pretty cool levels, I remember one where you fight through a hotel using IR night vision. It also had a sequel which added a guided missile launcher and some crazy Robocop ED-209 type enemies. As I recall both had multiplayer deathmatch but good luck finding a friend who also had the game and a link cable.
One thing I took full advantage of as a kid was that both games had some cheesy behavior with the sniper rifle scope implementation.
In the first game, while zoomed in with the scope you could use the D-pad to move your view a few clicks left/right/up/down to refine your aim. However, this was not really turning you, it acted more like you were a ghost side-stepping and poking his head up and down. So, you could crouch behind a box, scope in on the box, then D-pad up to look over it and shoot an enemy mob who still couldn't see your character and wouldn't engage you. Or stand just slightly behind a corner, scope in, and D-pad right to shoot around it.
The last level of the first game involves fighting a boss character who has a powerful weapon and a ton of HP, and is surrounded by his infinitely-respawning goons. There's no way kid me would've beaten it without abusing this trick, which reduces the challenge to avoiding his attacks while fighting enough lower-tier enemies to obtain their precious sniper rifle ammo.
In the second game, the D-pad moves a crosshair around a fixed viewport rather than shifting the whole viewport around. So the trick doesn't work exactly the same way. If you zoomed in staring at some obstacle right in front of you, you couldn't move the viewport to see around it like you could before.
However... when you zoomed in, it worked like you were a ghost moving forward in space, instead of narrowing your FOV from your original vantage point. So you'd instead stand about 10 feet back from a corner, zoom in past the edge, and voila: you were able to see more around the corner just as if you'd walked up next to it. Sure enough, you could slide the crosshair over and snipe the enemies now visible in your viewport despite your player character still being safely 10 feet back around the corner.
Good times. They were still great GBA games even with this exploit, it just made the (scarce) sniper rifle ammo even more valuable to the player.
Shockingly enough it is actually possible to do decent ray casting and much more on the GBA despite the incredibly minimal compute budget.
Joshua Barretto has been working on a GBA port of Super Mario 64 with entire 3D levels, characters, and movements. In my opinion just incredible work:
https://youtu.be/9mUsgJ-HiDM
There was actually a fully 3d platformer released for the system during it's production run, Asterix & Obelix XXL: https://www.youtube.com/watch?v=b0pknb4ghUA
There was also a Tomb Raider port (and probably other examples of the genre).
The one that blew my mind as a kid was Need for speed underground:
https://youtu.be/36U2xN-196c?si=T7xSCeKxss_at3S0
The one that blew my mind was Payback: https://www.youtube.com/watch?v=9wApAbxZY9k
It's GTA1/2 clone with an overhead view of a full 3D world.
I distinctly remember Spider-Man 2 on GBA having a 3D overworld. It was my first introduction to the concept of "low framerate" in a videogame haha. Incredible what people were capable of doing with the hardware back then.
I'm more impressed with the song "Get Low" ending up in an E-rated game.
Amazing - a purely software rasterizer on 16MHz, no floating point, 16-bit data bus, at most 512k of RAM? That’s the original 68k! What’s everyone’s excuse for not getting SM64 running on a Macintosh Plus?
I guess you're probably joking, but in case there's any actual confusion:
ARM7 is fully pipelined, and GBA connects it to 32K of on-chip zero-wait-state SRAM, so it's possible for optimized code to approach 16 MIPS with 32-bit operations. The original 68K is a multi-cycle processor and Mac Plus runs it at 8 MHz, which tops out at more like 2 MIPS for 16-bit operations, less for 32-bit operations (the ALUs are only 16-bit).
In my opinion, the most impressive 3D game for the GBA is still the unfinished port of Quake by Randy Linden:
https://youtube.com/watch?v=R43k-p9XdIk
That SM64 port is incredible, thank you for sharing it!
It's funny to me when people apologize for not being artists when they've produced actually nice looking art. It's like a host saying "excuse the mess" when entering their nearly immaculate home.
I wish I had kept some of my game development experiments because then I could show you what actual bad art looks like!
I should have included a disclaimer -- I agree that textures and sprites are excellent, but they come from asset packs (for this same reason I cannot redistribute them in the source release). Only the crossbow placeholder is self-made.
I don't have any issue with paid asset packs, I would gladly build the entire game with third-party art, but there is only so much of it in the necessary style, resolution and quality.
It might look much better if you picked a palette with a mood (https://lospec.com/palette-list). The resolution mismatch between the foreground crossbow and the sprites and background textures could be made less apparent too by reducing the resolution. For the monster sprites there's always scaling and palette flips. But yeah, with those sprites (and sound) defining the game's identity it's a bottomless pit.
I was thinking the same thing and actually thought they should continue building it. It looks like a great game!
It was the censored radio edit version in north america though
Not sure if you care at this point, given that you stopped working on project, but there's a better way to find the ray direction for each column than using sin/cos for every one, which will also get rid of the slightly warped look:
Calculate the two vectors from the camera at the very left and right of the screen (using your fov angles and sin/cos, that's fine). Then, to find the ray direction vectors for each column, interpolate linearly between your left and right direction vectors, and possibly normalize the resulting vectors if your ray walking algorithm requires it.
This will create a perspective that integrates tightly with sprites that you 3D project the usual way, and lines will stay straight lines.
In my experience there are two mistakes people sometimes make that leads to the fisheye lens look. The first, as parent mentioned, when calculating the ray directions you should linearly sample a line rather than interpolating view angles. Second, when doing per-column perspective division, you should divide by dot product of the forward vector and the difference between the ray intersection and the camera location. Often if someone is making the first mistake they are also making the second.
Following this will give you the normal pinhole camera 3d projection that we all expect to see from a 3D game.
Rule of thumb I found as a beginner in 3D graphics: any time polar coordinates seem like the obvious solution, there's usually a better way.
Of course I still care :) Thank you for sharing this technique, I will try it out.
Might be of interest to those of you that ended up here: PS1 Tomb Raider ported to the GBA, Sega 32X and other platform with the OpenLara project
https://www.youtube.com/watch?v=igEUjEci-eg
They even made a web demo. I've been replaying the whole game with my GoG.com Tomb Raider copy.
http://xproger.info/projects/OpenLara/
> Don’t get stuck on assets. Make a quick placeholder when necessary
Need this tattooed in my ADHD brain. Assets are such a rabbithole
As someone who has tried and failed at many points throughout the years at building a game I couldn't agree more with "Build a game, not a game engine" it's hard not to get sucked into the game engine black hole though.
Its depends what you like. Usually programmers focus more on game engine part, while designers on the other. And thats why is hard to make game solo :)
Galaxial developer fall into that hole too. Too bad, because alphas looks absolutly super great.
Perhaps that explains Chris Roberts
> What didn’t work
> Content. Brace for an obvious statement: it is one thing to imagine a grand, Daggerfall-scale game in your head, and a completely different thing to actually start building the pieces that make it up.
This is what always kills it for me. It's not so much that there aren't good off-the-shelf content packs, its that unique gameplay ideas with unique visualizations don't have ready made assets. Even for a simple game like pong, if you want to do something graphically unique with it (make the paddle shake, charge up, or have a power bar embedded in it that fills up whatever), then you better be prepared to become an artist or find someone who will be your game's artist.
And also like the article points out, the latter is fine if you're looking to commercialize it, but it doesn't seem like there are many artists offering their skills for free games made casually in a developer's spare time. It seems there's a critical threshold of game development "seriousness" that needs to be committed to by all involved to make it worth the time and effort of others.
Tangentially related, I've been extremely impressed following 3DSage's work. I've only dipped my toe into GBA programming ("hello world"-level stuff), and the fact that they built a real-time 3D level editor is mind-blowing to me.
https://www.youtube.com/watch?v=msM_oYqUMT0
I'm personally a bit more impressed by the Tomb Raider port mentioned in another thread, the linked game is doom/duke3d-esque and the GBA cpu should be roughly on par with a 486sx both in terms of clock speed and instructions per second (assuming you spend most of your time in code using the fast-ram).
The editor and looking at another video from sage3d also the rendering method, seems extremely reminiscent of duke3d. You can see a review of the duke3d rendering and sector setup on Fabians page.
Why the Tomb Raider port impresses more is because Duke3d-like renderers can work on straight spans and only interpolate textures in on direction and also get "free" hidden-surface culling (ie they never draw more than is seen), Tomb Raider on the other hand seems to have arbitrary texturing probably more overlap as well.
https://fabiensanglard.net/duke3d/
The takeaway that "content" can be the hard part in making a game is why I think its so important to make games with teams. There are some folks out there who will produce art the way an engineer produces code; all they need is to be empowered.
The best games are developed as a technical-artistic partnership, with both sides pushing and enabling the other.
From my perspective, this is a great outcome for a game-making attempt. There's no shortage of fun games coming out lately - far more than I have time to play. But these days they're largely made by amateur non-programmer indie devs tooling around in Unity or similar, and have no technical merit despite being very fun. What I'm lacking these days are fun technical accomplishments to read about in the gaming space, like a GBA raycaster.
No offense meant to the author at all, but I probably wouldn't have played this game even if it were fleshed out and finished. Very glad I got to read about some of the technical decisions that went into making it and poke through the code though.
This reminds me of playing Ecks vs. Sever on the GBA. A raycasted 2.5d doomlike game based on a crappy movie. It was pretty impressive for a GBA game, and it ran well, never stuttering. It had some pretty cool levels, I remember one where you fight through a hotel using IR night vision. It also had a sequel which added a guided missile launcher and some crazy Robocop ED-209 type enemies. As I recall both had multiplayer deathmatch but good luck finding a friend who also had the game and a link cable.
One thing I took full advantage of as a kid was that both games had some cheesy behavior with the sniper rifle scope implementation.
In the first game, while zoomed in with the scope you could use the D-pad to move your view a few clicks left/right/up/down to refine your aim. However, this was not really turning you, it acted more like you were a ghost side-stepping and poking his head up and down. So, you could crouch behind a box, scope in on the box, then D-pad up to look over it and shoot an enemy mob who still couldn't see your character and wouldn't engage you. Or stand just slightly behind a corner, scope in, and D-pad right to shoot around it.
The last level of the first game involves fighting a boss character who has a powerful weapon and a ton of HP, and is surrounded by his infinitely-respawning goons. There's no way kid me would've beaten it without abusing this trick, which reduces the challenge to avoiding his attacks while fighting enough lower-tier enemies to obtain their precious sniper rifle ammo.
In the second game, the D-pad moves a crosshair around a fixed viewport rather than shifting the whole viewport around. So the trick doesn't work exactly the same way. If you zoomed in staring at some obstacle right in front of you, you couldn't move the viewport to see around it like you could before.
However... when you zoomed in, it worked like you were a ghost moving forward in space, instead of narrowing your FOV from your original vantage point. So you'd instead stand about 10 feet back from a corner, zoom in past the edge, and voila: you were able to see more around the corner just as if you'd walked up next to it. Sure enough, you could slide the crosshair over and snipe the enemies now visible in your viewport despite your player character still being safely 10 feet back around the corner.
Good times. They were still great GBA games even with this exploit, it just made the (scarce) sniper rifle ammo even more valuable to the player.
> generate a C++ header with the compiled data
So many human years have been wasted trying to avoid this simple solution.
TONC is amazing. I learned so much from it.
[dead]