Grind – A first person shooter for Amiga 500
indieretronews.com
indieretronews.com
On top of that the Amiga500 graphics chip placed all graphics in bitplanes, that was a great move for just copying 2d graphics in the mid 80s with the help of simple hardware acceleration, but it really became a pain for anyone wanting to do 3d graphics.
To call it a reskin is quite a disparagement of the amount of work they've probably had to put in to get in running decently (unless they figured out a very clever way to make the hardware do a fair chunk of the work for them, kudos either way).
And as others have pointed out, it's that they've chosen a more "amiga-y" artstyle.
https://github.com/Krzysiek-K/Dread-source-drop/blob/master/...
https://github.com/Krzysiek-K/Dread-source-drop/blob/master/... (This feels reminiscent of the "generate-y-fillers" that ID did for Wolf3d)
https://github.com/Krzysiek-K/Dread-source-drop/blob/master/... (Browsing this reminds me of Fabien Sanglard's Doom/Duke3d walkthroughs)
No it isn't!
You just outlined all the reasons that a Doom reskin on the Anus is impressive!
> And as others have pointed out, it's that they've chosen a more "amiga-y" artstyle.
That's great! I wasn't replying to that.
In this case I doubt there is any shared code at all other than conceptual ideas.
If you are willing to go around proclaiming that Rust is just a reskin of Java then sure, I'll give that you're willing to equate wildly different things. (I didn't use C# and Java because those are probably closer in lineage due to J++ than this game and Doom)
That is why is this is impressive.
The number of gamers who switched to PC's just because of Doom was huge. After Doom everything was measured against it for a long time. Even many diehard Amiga fans suddenly decided the game was up and switched.
That your reaction is that it is "barely more than a Doom reskin" demonstrates why it is incredible.
To the extent that if a "barely more than a Doom reskin" had been achieved near the time Doom came out, computing history might have looked quite different (though Commodore was so badly mismanaged at this point that they'd probably still have managed to mess things up even if they'd been handed this kind of reprieve on a silver platter, but one can dream)
So it is nice to see this :-)
[0] Both demo scene coders [1] Funnily I was a Sega Saturn zealot around the time too, which was also 100% 2D focused and Sega didn't see 3D coming (Though I loved Panzer Dragoon, a 3D game squeezed out of 2D hardware, and Daytona was great too). And yes there was Starglider2 for the Amiga (Loved the space whales, was recently reminded of them when watching Ahsoka).
The first 3D I remember having played was Major Havoc or I robot - so yes there were "real" 3D games in the market, but 3D completly took over the home market, except handheld like the Gameboy/Advanced/DS/... (I think the 2D revival came with the indy developer movement, but I'm not sure).
Also see e.G. the transition from Bards Tale 3D (small window) to Dungeon Master 3D (main window, 3D interaction) and then Ultima Underworld 3D (all in, tilt, up/down) as an example of 3Dification of games and genres.
Sega released Saturn as a full fledged, 3D focused hardware. A year before the PlayStation 1 was out.
Some chronological refresher:
Sega had already been successful in making arcade 3D games and were the first to effectively transition true 3D to the home markets with multiple early flagship releases such as Virtual Fighter, beautifully ported to the home console.
The reason not many decent 3D games were shipped on Saturn was not down to the hardware capabilities or goal from sega to embrace expected 3D market demands. It was rather due to the horrific developer experience. It was so terribly difficult to program it, only those at sega were comfortable with it, if that.
Saturn's hardware architecture complexity, having multiple CPUs, and other design aspects prove bad choice as it jeopardised 3rd party game developers productivity. Words were that most games shipped leveraging a single CPU given how obscure dual cpu programming was.
Ironically Sega designed a more powerful machine than the PS1 and got it out a whole year earlier, yet games on PS1 were significantly superior. All down to ease of development.
Wipeout was an early game on PS1 and indeed among many other popular games sealed the fact home gaming would be 3D. But sega had already produced a full fledged 3D capable Saturn, they didn't wait to see wipeout in 1995/1996, or Mario 64 another 2 years later. Saturn was capable of running wipeout 2097, metal gear solid, grand tourismo, and other late PS1 games that pushed the ps1 to its limits. But it missed the momentum and studios were not anymore invested in the saturn. Its marketshare kept shrinking.
what the Dreamcast got added was primarily developer friendly features, the rest was simply leaps forward in compute power, especially on the GPU. Bump mapping if I'm not mistaken was supported by the Dreamcast first among home consoles. It was not "added" 3D, for sega that was its 2nd generation of 3D focused hardware, also their 2nd attempt, both ultimately failed for different reasons.
If you'd implemented a z-Buffer in software you could sort these sprites to draw them in the right sequence to use the distorted sprites as 4-corner polygons to render 3d models.
The Dreamcast added a 3D GPU with the PowerVR2.
[0] https://www.copetti.org/writings/consoles/sega-saturn/#graph...
VDP1 draws distorted textured quads (it's misleading to call them sprites). The playstation's GPU displays distorted textured triangles.
The playstation GPU also knows nothing about 3D, it doesn't have a depth buffer. Like the Saturn, you have to implement depth sorting on the CPU and link all those distorted triangles up in the right sequence of 3-corner polygons to render a 3D model.
Yet nobody ever claims the playstation isn't a 3D console.
"Sega calls them ‘distorted sprites’" [0]
[0] https://www.copetti.org/writings/consoles/sega-saturn/#graph...
And if you are in a discussion about if VDP1 is 3D capable or just advanced 2D hardware that clever programmers tricked into doing 3D, then it doesn't really matter what terminology Sega used.
It's misleading terminology because if the person you are talking to doesn't understand the functional equivalence between distorted sprites and texture-mapped quads, as the "sprite" terminology might lead them to assume it's 2D-only hardware.
This was not the discussion. The discussion was if Sega missed the total shift of gaming to 3D games that was brought on by 3D graphics cards and that propelled PCs into the mass gaming market (before 3D it mostly excelled at thing consoles couldn't do, like text adventures and point&click). And that it didn't need 2D hardware (at least for the international market, JP had e.G. more Shmups and it seems less interest in 3D shooters) but dedicated 3D hardware like the PowerVR2 they did put in the Dreamcast (too late, and I wrote Dreamcast software and loved the machine, so I'm not against Sega hardware in any way). And if they had anticipated the move of games (the vast majority of todays AAA titles are 3D games, for the better or worse, and in the Top 10 of most sold games, 8 are 3D and 2 are 2D or 2.5D) in it's majority to 3D, they at least had a chance to overtake the Playstation and survive as a game hardware vendor. The Saturn was only on par with the Playstation (e.G. at the time I owned Tomb Raider on both), which wasn't enough.
If you take a look at the most sold PS1 games, it's mostly 3D games:
https://en.wikipedia.org/wiki/List_of_best-selling_PlayStati...
The Wikipedia page says this about 3D of the Saturn:
"[..] which resulted in the creation of the "SuperH RISC Engine" (or SH-2) later that year [..] According to Kazuhiro Hamada, [..] we realized that a single CPU would not be enough to calculate a 3D world." Although the Saturn's design was largely finished before the end of 1993, reports in early 1994 of the technical capabilities of Sony's upcoming PlayStation console prompted Sega to include another video display processor (VDP) to improve 2D performance and 3D texture mapping"
Sega build the Saturn without a focus on 3D. Because they saw 3D coming too late, late in and after development had mainly finished, they added a 2nd CPU and added a VDP for 3D texture mapping to compensate for the lack of 3D capabilities.
The Saturn only beat the playstation to the Japanese market by 11 days.
The gap was more like 3 months in other markets, but only because Sega bought the launch date forwards (with disastrous results. In North America it was scheduled to launch one week before the Playstation, but Sega said "Surprise, it's launching today". Many retailers in North America went on to boycott Sega, because they weren't informed about the surprise launch, and didn't have any stock).
Sega's problem wasn't that it didn't see 3D coming. They did, despite the common claims on the internet, the Saturn was designed to be a 3D capable console, with dedicated 3D hardware.
Sega's problem is that they bet on the wrong 3D technology. Like Sega's arcade systems. the Saturn was designed for quads, and could only do forwards texture mapping (which doesn't allow for UV coordinates).
While the playstation went for triangles and inverse texture mapping. It turns out that was the correct direction, and the whole industry settled on that as a standard. All game engines and tooling would assume triangles.
To make things worse, the Sega's hardware 3D implementation wasn't that good even at the techniques it was trying to implement.
"You are forgetting [...] Daytona USA"
Part of the reason why the Saturn port of Dayton USA was so good, is because the game was designed for the Model 2 hardware, and the Saturn's 3D capabilities were cost-optimised versions of the Model 2 3D capabilities.
VDP1 was designed to do 3D. It's not just a 2D sprite engine that developers later tricked into doing 3D, it was absolutely intentional that it would be used for 3D from the very start. the fact the 3D quads could also be used to show thousands of 2D sprites with full scaling/rotation/distorting was more of a intentional bonus of the design.
Yes, Sega did miss a trick by also dedicated a bunch of the silicon budget to 2D-only capabilities. VDP2's four layers of scrolling backgrounds plus two layers of mode-7 style "3D planes" are pretty useless for 3D work. They should have dropped VDP2 entirely and and focused on making VDP1 more powerful.
When games were actually designed around the Saturn's 3D capabilities, the results were pretty good. Daytona is great, Tomb Raider is another great.
Some games went further, going out of their way to adjust their game design so they could take advantage of VDP2's 3D planes. That's the major reason why Panzer Dragoon looks so good, the water is a 3D VDP2 layer. The skybox too, but that's reasonably common technique in Saturn games.
If you haven't seen any recent Amiga demoscene entries, you're in for a treat. I'm tempted to share a whole list of demos, but here is a particularly amazing one released earlier this year that runs on a stock A500: https://www.youtube.com/watch?v=2jciCr8zEhw
This demo didn't impress me that much, I was actually hoping for more. Maybe I've just forgotten how underpowered the Amiga OCS was for things like this? Second Reality by Future Crew on the PC is still my #1.
So yeah you forgot how underpowered OCS Amigas are :)
However, the cross-platform build stack has gotten comprehensive, and straight modern hardware has become the method of choice for a lot of devs (including myself). There is an "Amiga Assembly" extension for VS Code which does a ton of heavy lifting for you, including setting up the build tools, and even grabbing a fork of the emulator that has DAP support so you can use VS Code's built-in debugger.
I personally use Neovim and a couple plugins for syntax highlighting and DAP support. As part of my build process, I run Python scripts which convert images and SFX to Amiga-friendly formats and assemble them into a custom binary file. I can't imagine how long that would have taken me to set up in an Amiga-only environment—Python is just too convenient.
I think a lot of what you see possible on Amiga today is thanks to modern tools allowing for very rapid iteration as well as some crazy preprocessing for effects that depend on lookup tables, etc.
To be clear, this is a trailer/demo and not an actual game you can play?
When designing a game, you probably have to code a game engine that has certain capabilities and certain restrictions that persist through the entire game. But for these demos, you can write an entire isolated program that runs one 15-second visual effect before flushing it out and loading something totally different for the next effect. The effects are also usually designed with a lot of tricks that make them inflexible (like preprocessed data tables) and usually also take up every CPU cycle available, leaving none for stuff like game logic.
I was fascinated by the Amiga when I was young, but they weren't widely available in my country.
Lately I've had an itch to do some retro programming work and was looking at the Amiga specifically. I tried Aztec C natively in UAE and VBCC as a cross-compiler, and got some command-line and hello world Intuition programs working.
But going beyond that has proven somewhat difficult. Documentation seems to be scattered all over the internet. I found a bunch of books on archive.org, but they mostly seem to focus on Intuition applications or beginner programmers.
https://www.youtube.com/@WeijuWu
Wei-ju Wu lays out how to code directly on the hardware in an accessible manner and, importantly, from C, instead of 68K, with lots of examples. Then, if (or rather: when) you have to, you can always step down a level into 68K assembly to get better performance.
https://www.youtube.com/watch?v=iD9xk3SDSYc
https://www.youtube.com/watch?v=_wpXOsEm7M0
If you are considering doing the same, I recommend going to YouTube and look up two keywords: PiStorm and FS-UAE. These two allow me to prepp a hard-disk image in emulation on my PC, transfer the image to a rPi inside the Amiga and mount it. My Amiga 500 now boots a workbench with all the things I was looking for.
I also bought a new case and keys, because the Amiga was very yellowed. And a new power supply because the old one looks like it wanna burn my house down
The last time I wrote a 2.5D engine was over 25 years ago so please be gentle
And that's for monochrome. (Pure black and pure white.)
To have more colors, you add more of these "bit planes" on top of each other.
So if you have say, 32 colors and want to update a single pixel, you have to write four bytes, changing only the one bit in every one of these four bytes.
This is not very nice when you try to sweep textures on a 3D-ish mesh.
(But very good for 2D graphics with large chunks bobbing up and down.)
The Amiga (except some early 1000s) also had a Extra Half Brite mode that has 6 bitplanes, 64 colours with the second 32 being half the brightness of the others.
https://en.wikipedia.org/wiki/Amiga_Halfbrite_mode
The extra data fetching does slow things down.
https://eab.abime.net/showthread.php?t=102990#:~:text=And%20....
The panel at the bottom looks like it uses the copper to have a different palette to the rest of the screen. That is a very common effect.
https://codetapper.com/amiga/sprite-tricks/shadow-of-the-bea...
And of course 4096 in HAM mode, but the mode has severe limitations and is completely impractical for textured 3D-games.
https://www.youtube.com/watch?v=wbWGAFIkA5E&list=PLRdmatuCYA...
A small correction, you have to write 5 bytes (or 16-bit words, same performance).
4 bytes changed gets you only 16 colors.
1. simulates texture filtering and dithering hiding low resolution and low number of colors in textures, and
2. renders two or four columns at once.
Amiga had planar graphics, which did not support setting individual pixels. To set a pixel you'd have to set appropriate bit in up to 6 bytes (64 colors max) scattered around in memory. Writing one byte modified one bit of 8 adjacent pixels, which was terrible for textured 3D graphics.
I think it's a similar technique to Sonic 3D's Intro FMV on the Genesis/Megadrive (https://www.youtube.com/watch?v=VTawyLNoRhU).
The original image is squashed vertically, so that you only compute half the pixels and then you stretch it back up. When you do this, you can't have the usual dither patters, so you end with something like this (unless you cheat shift every other line, like in Sonic 3D, but then you have dither patterns everywhere).
https://youtube.com/playlist?list=PL-3inz2kpSUPGYZwBUAbJjaj-...
Are they still making those new Amiga systems implemented on an FPGA?
A1200 bare system £276 https://archive.org/details/cuamiga-magazine-050/page/n28/mo...
4-8MB fast ram £200-400 https://archive.org/details/cuamiga-magazine-050/page/n49/mo...
340MB £380 pounds https://archive.org/details/cuamiga-magazine-050/page/n28/mo...
14 multisync monitor ~£320 https://archive.org/details/cuamiga-magazine-050/page/n52/mo...
~£1200-1400. 1994 £/$ exchange rate 1.55 = $1860-2170. To quote a classic I feel like Im taking crazy pills.
https://www.reddit.com/r/pcmasterrace/comments/7235w0/the_sp...
486dx2-66mhz, 256KB cache, 8MB, 1.44MB fdd, 350MB HDD, SVGA monitor/card, keyboard/mouse. $1840
Early 1990s me would have been more than happy with that.
I was happy with 5 fps or less on the gameboy with Faceball 2000.
Has never been common on Amiga 500.
Perhaps you mean 512k SLOW RAM Extension.
Or CHIP RAM (after a motherboard solder-jumper adjustment) with the ECS Agnus common in late A500 models.
It feels like I've heard so many Amiga users say that they finally broke down and jumped ship when Doom and the DX2/66 dropped. It really was a gamechanger. Before then it was possible to argue that a '040 Amiga 4000 still held its own against a DX/33 or maybe even a DX/50, but not this.
There were a lot of things that came together to kill the Amiga, mostly Commodore's mismanagement, mismarketing and complacency, but as the final blow to it being a viable computer with a future in the eyes of consumers, I feel like the DX2/66 was it. It would have killed the Mac too if Apple hadn't woken up to smell the coffee a few years prior and had Power Macs ready to go.
I kind of wish they port it to PC !
They were mismanaged enough that they might well have failed to leverage that and just failed a year or two later as you said, and it might very well be that even the best case of completing AAA[1] would just have bought them another extra couple of years.
But Commodore had faced crunches like that several times and survived and bounced back massively. So who knows what things might look like if AAA had gone to market (with chunky graphics modes, and massively increased memory bandwidth) and bought them enough sales and by extension time to complete the next-iteration - Hombre[2] - as well.
Though Hombre was based on PA RISC, so might well have ended up being the death-knell instead a bit later. Though their "backwards compatibility" story for it was based on options of either a "classic Amiga on a chip" or emulation, so maybe they'd have gotten to a sufficiently CPU agnostic position to be able to make further architecture switches survivable.
It's fun to speculate.
I'm a bit of two minds about it - I'd have loved the Amiga to have survived longer - I still miss it -, but I'm unsure if I'd have liked the direction Commodore would have taken it in with Hombre (which was being designed to also run Windows NT... Shudder). It's easier to have nostalgia when later iterations haven't ruined the original experience...
[1] https://en.wikipedia.org/wiki/Advanced_Amiga_Architecture_ch...
Part of it is surely that I was using hand-me-down PCs and there was probably some time lag on the games that my dad would get through the sneaker-net.
The art style is also really solid and modern which I’m sure helps hide some of the limitations.
For smooth frame synced 2D games (no lag, no jitterynes, no tearing) Amiga was hands down better, but those kinds of games were falling out of style in the early 90s.
It led to the odd situation where you had PC's that had these killer CPU's but everything else about the system was holding them back. The Amiga had an average CPU (8Mhz 68K) but everything else was picking up a lot of slack.
As for this example, this is exceptionally good for the Amiga. I don't recall there being anything even remotely close to this in its time. Hackers are just gonna optimise way beyond reason and I love it.
This engine very likely is written in hand optimized, clock-exact, asm.
Additionally, anybody that grew up coding on the Amiga has had 30, 35 years to think about it since! - and they are probably still young enough (or, more accurately, probably not yet properly old enough...) that time has, for now, added more to their abilities than it has taken away.
And: modern PCs are ridiculously fast! A table or routine that would have taken your Amiga days to produce, even assuming you'd have considered the idea feasible in the first place ("b-but - you'd need a temporary 512 MByte table for that!!") can be generated in 5 minutes with some python code on your 10 year old laptop.
I mean things like Commander Keen were considered really decent for side scrolling graphics on PC but would be seen as trivial on a system like the Amiga and maybe even the NES using early 80's tech. It was a long time until the PC could scroll graphics as smoothly as the NES could with Super Mario in 1985. Custom ASIC designs just had to so leverage back then. It is something we are moving back into nowadays with chiplet designs and SoC's in general. Just look at the processor blow outs on something like the M1/M2 to see this.
This new engine is an absolute masterpiece of Amiga coding. The many mid-90s attempts to do similar things tended to need more powerful Amigas (at least an A1200, preferably with an 030 or better accelerator card and extra RAM) for less impressive results.
As for me, VGA was wonder, I now think from marketing considerations, PCs way was to make Super-EGA, with little colors, but high resolution. But, sometimes wonders happen.
Amigas, or to be more exact, Commodore computers, from beginning made as home computers, with decent integrated graphics and sound.
Unfortunately, Amiga parent company was very aggressive against clones, and from what I hear, was not effectively managed (or may be, just tried to made too complex architecture). So after some time, initial superiority was lost, and PCs not just dominated market, but also, once become better technically (because of constant competition on free market).
Approx after 1987-middle 1990s, Amiga become technically lagged behind forever, then parent company bankrupt and now, each year, Amigas become more history artifacts.
More sequels in the style of the first one would have been amazing.
The visuals here though are lovely. Well done to the team
- Looks like Mona Lisa paint in 8 bit, but it's frame is 16 bit.
Imagine if this game was released back then. It would absolutely blow everyone’s mind.
Now think what’s possible on a PS5, someone 30 years from now will create an awesome retro game for it
Looks nice GG
Here is a 3D FPS on ZX-Spectrum: https://youtu.be/tiV8ZPmmoJI?t=106 or https://youtu.be/3v7cFGneuaw?t=66
This is running on a computer with a 3.5MHz CPU, no hardware multiplication, and only 48K of RAM.
Here is the same thing in turbo mode on an Ultimate 64:
https://youtube.com/shorts/fF2IXTwWDPQ?si=ds5-5Kwm95Zj2vtf
And with no vsync:
When I clicked through and hit play on the first video I braced myself for the worst framerate in human history and/or a tiny viewport, and so my jaw briefly dropped when I was greeted with neither of those. The game is basically fullscreen and runs great: a perfectly respectable (for the time - I know a lot of you will moan about games that don't run at a constant 60fps but, man, maybe you don't know what it was like back then) 25 - 30fps, and a frankly amazing framerate for the Amiga. Plenty of 2D games couldn't have reliably held that and just forget it for any kind of 3D.
Then my rational mind kicked in with, "There's no effin way that's running on an A500 with a stock 68k CPU running at 7.16/7.09MHz."
And, sadly, I'm right: there is no effin way. The footage was recorded from an A1200 with a stock 68020 running at 14MHz. The graphics are OCS compatible, and I've no doubt the engine is caning the OCS blitter to within an inch of its life, so it looks exactly the same as it would on an A500, but you ain't getting that kind of framerate without more horsies than the A500's 68k can supply.
With that being said, the game runs at 10 - 12 fps on a stock A500 with 1MB RAM (512K chip + 512K fast, so you need the 1.3 ROMs and the Fatter Agnus), which is still incredibly impressive. For a lot of solid polygon 3D games back in the day - think F/A-18 Interceptor, F-19 Stealth Fighter, and even games like Starglider 2 - drops to single digit framerates if not exactly the norm, were certainly commonplace (I remember F-19 being particularly bad for this). I seem to remember the Amiga version of Elite held a pretty decent framerate but, to be fair, the polygon count was very low, and it had a pretty small viewport. By comparison with these games, the Grind visuals, at 10 - 12 fps, on a bog standard A500 with an absolutely era appropriate amount of memory are nothing short of extraordinary.
If, in 1990 - 1993, or even after I'd first played DOOM on a mate's dad's 486SX in summer 1994, you'd shown me Grind running on my Amiga 500 at 10 - 12 FPS I would probably have fainted or jizzed myself or something equally ridiculous. It would have literally blown my mind.
Incredible work.
EDIT: Is it me or is the shotgun sound effect a slightly edited version of the DOOM shotgun sound effect? Not complaining, because it's an awesome sound, but just wondering if others are hearing the same thing I am.
Not Fast RAM, but Slow RAM.
Fast RAM is exclusive to the CPU. On A500, it needs to be on the CPU socket, or on the left expansion port.
Trapdoor RAM, as in the common 512K expansion, can only be Slow or Chip.
Slow because the chipset can block access to it, but can't access it itself.
Chip on newer A500 boards with ECS Agnus, after a small motherboard jumper mod.
Could you be specific about the envelope math used to arrive at this conclusion? What are the essential bottlenecks?