I wish I had kept some of my game development experiments because then I could show you what actual bad art looks like!
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.
Need this tattooed in my ADHD brain. Assets are such a rabbithole
Galaxial developer fall into that hole too. Too bad, because alphas looks absolutly super great.
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:
> 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.
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.
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.
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.
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.
The best games are developed as a technical-artistic partnership, with both sides pushing and enabling the other.
So many human years have been wasted trying to avoid this simple solution.
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.
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).
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.
It's GTA1/2 clone with an overhead view of a full 3D world.