[HN Gopher] How I failed to make a game: Raycasting on the GBA
___________________________________________________________________
How I failed to make a game: Raycasting on the GBA
Author : mcejp
Score : 119 points
Date : 2024-10-15 22:53 UTC (3 days ago)
(HTM) web link (mcejp.github.io)
(TXT) w3m dump (mcejp.github.io)
| nsxwolf wrote:
| 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!
| misterflibble wrote:
| I was thinking the same thing and actually thought they should
| continue building it. It looks like a great game!
| mcejp wrote:
| 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.
| qludes wrote:
| 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.
| sublinear wrote:
| It was the censored radio edit version in north america though
| timenotwasted wrote:
| 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.
| Borg3 wrote:
| 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.
| paulryanrogers wrote:
| Perhaps that explains Chris Roberts
| RankingMember wrote:
| > Don't get stuck on assets. Make a quick placeholder when
| necessary
|
| Need this tattooed in my ADHD brain. Assets are such a rabbithole
| Tyr42 wrote:
| TONC is amazing. I learned so much from it.
| eig wrote:
| 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
| chpatrick wrote:
| The one that blew my mind as a kid was Need for speed
| underground:
|
| https://youtu.be/36U2xN-196c?si=T7xSCeKxss_at3S0
| dmonitor wrote:
| 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.
| Dwedit wrote:
| I'm more impressed with the song "Get Low" ending up in an
| E-rated game.
| Newtonip wrote:
| 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.
| p1necone wrote:
| 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
| cubefox wrote:
| 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
| nxobject wrote:
| 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?
| 0xcde4c3db wrote:
| 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).
| sunnybeetroot wrote:
| That SM64 port is incredible, thank you for sharing it!
| Shawnecy wrote:
| > 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.
| favorited wrote:
| 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
| whizzter wrote:
| 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/
| bhaney wrote:
| 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.
| rspeele wrote:
| 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.
| hrydgard wrote:
| 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.
| mcejp wrote:
| Of course I still care :) Thank you for sharing this technique,
| I will try it out.
| empw wrote:
| 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.
| marci wrote:
| 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/
| Kapura wrote:
| 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.
| tightbookkeeper wrote:
| > generate a C++ header with the compiled data
|
| So many human years have been wasted trying to avoid this simple
| solution.
___________________________________________________________________
(page generated 2024-10-18 23:02 UTC)