Sonic 3D Blast has a special place in my heart. one summer in elementary school my buddy and I were in the basement taking turns playing this game, and we'd just got the furthest we'd ever gotten, to some stage we hadn't ever seen before. my younger siblings were running around the basement and my sister tripped on the controller cord, yanking the Genesis forward, causing the game to crash. we were stunned—Sonic 3D Blast is pretty difficult, especially for a couple of kids, and it had taken meticulous effort to get as far as we did. we were about to lambast my sister for her carelessness, causing us to lose hours of progress (the original game has no save system), when suddenly the TV flickered and a blue screen exclaimed:
C O N G R A T U L A T I O N S
YOU HAVE FOUND THE SECRET LEVEL SELECT
SCREEN
there was much rejoicing, and we proceeded to check out all the levels we had never been able to get to, including the final boss. I never knew how it happened until years later I read something about how jiggling the cartridge can cause that to happen, which still seemed like black magic. it wasn't until even later that I found out, from the youtube channel of the guy who worked on the game and later this romhack, it was because the error interrupts (exception handlers) restart the game and jump to this congratulations message and level select screen: https://www.youtube.com/watch?v=i9bkKw32dGw
I think you see cleverness in coding still, certainly in the distributed space I'll find insanely clever stuff on occasion, but I mostly agree that the "optimizing for every single bit of memory and shifting between five different palates to spoof monochrome animation" days are mostly over. I think this is largely a good thing, as it makes programming more accessible to people who don't have the ability to figure out every bit of minutia involved with a CPU (particularly since modern CPUs are ridiculously complicated!), but I will admit that occasionally I do love seeing old-school tricks to stretch out memory and make systems do things that they have no right to be doing.
My favorite "wtf how is this possible" classic game will probably always be the SNES port of DOOM. It's definitely among the worst ways of playing DOOM now, but for a port to the SNES, even with the SuperFX chip assisting it, it really does not feel like that should have been possible.
Second Reality has always been my favourite demo of all time.
I guess the CGA demo is working by very quickly overwriting the display buffer and switching the palette, using Persistence of Vision. I did the same thing on VGA in 640x480x256 color mode to get 24-bit color in the late 80s.
It's wilder than that: it hacks up the CGA text mode so instead of drawing all 8 scanlines of each character, it draws the first scanline twice then moves to the next character. Then, it carefully chooses characters, foreground and background colours that (when combined) generate an NTSC composite signal with the required colours in it:
Mostly, yes indeed. Partial counter-example though, Jon on his Coding Secrets channel demonstrates how to achieve PS5 effects on lesser hardware, so maybe on PS4 for example. This [0] Ratchet and Clank example focussed on debunking marketing hype that certain effects were only possible on PS5 SSD.
An obvious other counter would be 3D engine development (Unity, Unreal) where the developers of those engines will be employing some obscure seeming low level stuff to make this look good.
Not to be unclear though I'm 100% in agreement that for most devs, those days are mostly over.
[0] https://youtu.be/5XOV3pZj8rI
See also the PICO-8[1] or TIC-80[2] fantasy consoles: fake virtual consoles with built in editors and limited on purpose to add more fun and cleverness to development.
I actually have a license to Pico-8, and I absolutely love it (I actually used to volunteer at the library teaching programming, and I taught it to teenagers).
He was not part of Sonic Team. He was part of Traveller's Tales. That was a British studio who was contracted to do some Sonic games. This game and Sonic R.
Childhood me never really knew about them, but it is so cool to see entirely new things added to old games (e.g. Super Mario 64: The Green Stars, or some of the Pokemon Red/Blue hacks). Maybe this is kinda silly, but I feel like hacks like these really extend the magic and mystery of that specific game "world" we grow to know and love inside and out after playing a game for years.
This is awesome. How cool must it be to come back to a beloved project 20 years later and add all the stuff you wish you could have the first time around?
I see the wiki says this was the Mega Drive version but the one I'm familiar with was the Saturn one. Does anyone know if they are different? The screenshots are familiar.
Yep, the Saturn version utilized Sega's 68k assembly to C converter which was common for them to use when porting their Genesis games to platforms such as the Saturn and PC.
I played this on PC as a kid and really did not like it. I have not revisited it since, but what I remember is that it felt awful to control. Like Sonic was underwater, which is not exactly what you want from Sonic. Evidently this adjusts the speed and movement, it will be interesting to see how it changes the game.
Last weekend I was playing this in a VM where it felt very slow and easy. I went looking and found a fan patch (https://forums.sonicretro.org/index.php?threads/sega-pc-relo...) that allows the game to run on modern hardware / Windows and it was faster than I remembered.
I also played it on PC. I don't remember hating it, but I do remember thinking "This doesn't feel like Sonic". The perspective was really tricky, especially with the stupid red birds that jumped around all over the place.
Note this is from 2018, it's not a new release. Still, I didn't know this was a thing, it's very interesting - note how the changes are generally to make the game much more forgiving.
I think he must, because on his YouTube channel he'll show different development iterations and "what if" scenarios throughout the games he has worked on. I suspect that he cannot legally release the code, so he had to do the Director's Cut as a ROMHack where you supply your own copy.
Video game source code is very poorly archived, from experience in the industry. Ask practically anyone who worked on any games pre-2000 and I bet they can't find the source for any of their games.
Everyone does because most games back then were written in assembly so the raw code is there on the ROM.
Games written in C slow in comparison, as seen with Sonic Spinball, so I’d wager Sonic 3D would have had to be assembly too given the technical achievements involved in that game.
There’s some YouTube videos from various developers of that era and you can see them stepping through the assembly of those games too.
A disassembly of the ROM is not the same as the source code because it's missing the human-readable labels for memory addresses. It's more like the source code after using an obfuscator to remove variable and function names.
I was really surprised to discover that quite a few games in the SNES/Genesis era actually weren't written in assembly. They were usually "touched up" in assembly; there would be inlined assembly stuff for a lot of core loops and hardware interaction, but apparently quite a few games actually used "high level languages" for large tracts of the code. I'm merely relating hearsay here, but at least one primary source (Secret of Evermore) suggested this was the case.
The thing is that once it's compiled down to a final rom, all the scaffolding used to build it is gone, so there's so little evidence left that it's pretty plausible for people to think it was just done completely in assembly (particularly since there's significant evidence of hand-crafted assembly routines in such a product, since they did that for parts of it).
I think there's a lot of "transposing of knowledge" there, where people know how 8-bit games got built, and assume it was the same for the 16-bit era, but I suspect the 16-bit era was where the transition away from that started, so there was a bit of both.
As I said, C code did exist but it was slower so it wasn’t the norm. I don’t know of any other languages being used on those systems (I think C++ was supported on the following generation of consoles, albeit SDKs took longer to be released on some consoles than others). If anyone knows of non-C languages being used I’d love to hear about it.
Back then compilers weren’t as good at writing optimised machine code as they are now and the consoles of that era were built with assembly in mind anyway so it was an easier job writing assembly for them than it would be on modern architectures.
That all said, it seems to be a lot more common these days (ie with the homebrew community) to use higher level languages even on easier platforms like the GameBoy.
I had both the official Sega dev kit and the SN Systems one. IIRC they both came with a C compiler. I don't remember any C++ compilers for the 16-bit consoles. C++ was just coming into PC game development at that time. I was in the industry then and I definitely used some C++ code for PC game development.
I once called up SN Systems as their office was down the road and asked if I could visit (this was about 1996) and they were such a nice bunch of people. They had very early prototypes of every console stacked on a back wall. Stuff that would not see the light of day for at least another 20 years. Early PlayStations, 32X, Saturns, Megadrives, Mega CDs. I was looking at a Mega CD dev station and they just handed it to me and said I could have it O_O. I think they gave us a couple of SNES and Megadrive dev kits too. They said they would have given us boxes of the things but they'd just thrown them out yesterday and the rubbish had already been collected.
Yeah C was definitely available for the 16 bit but and think I recall C++ being available for the N64 but that was a later generation (and thus released several years later) than the Mega Drive and SNES era.
By the time the N64 / PlayStation / Saturn generation was released, it was more common to expect SDKs. As you say, an expectation likely driven from PC development. SN Systems, being by that point acquired by Sony, would have been excellently placed for the PlayStation dev kits. Unfortunately from the stories I’ve read, Sega were really late in delivering an SDK for the Saturn instead expecting developers to continue to write code in assembly. Which was one of the many issues developers had with that console.
Unfortunately I wasn’t lucky enough to have access to any dev kits for any generation of consoles prior to the PS2 / Dreamcast era. Instead specialising in PC games (and 8-bit micro computers before IBM-compatibles took over) instead. But I have gone back and written some homebrew stuff for the older consoles since. Nothing good enough to boast about on here though.
> Unfortunately from the stories I’ve read, Sega were really late in delivering an SDK for the Saturn instead expecting developers to continue to write code in assembly. Which was one of the many issues developers had with that console.
The Saturn launch was a serious fuck-up for developers who struggled to get anything working. I don't know if they shipped a dev kit without a C compiler. It would be a total nightmare accessing all the 3D hardware without C. And they'd had the 32X for a good while before that. They'd definitely given the earliest prototypes of the 32X to SN Systems for them to make their own dev kit. I saw two prototypes there, one they said was called The Fridge as it was the size of a small refrigerator, and another they called the Pizza Box which was the size of a rack mount unit.
> I don't know if they shipped a dev kit without a C compiler. It would be a total nightmare accessing all the 3D hardware without C. And they'd had the 32X for a good while before that
Their complaints were exactly that. Plus it didn’t help that Saturn didn’t really do 3D. It was a dual graphics but both chipsets were designed around sprites. So the Saturn emulated 3D by transforming squares into triangles. Imagine trying to do that in assembly. It’s definitely beyond my capabilities that’s for sure.
Slightly envious (if that’s the right word?) that you got
To experience all those dev kits though. The 16 bit era is probably my favourite era in console games (even though the Dreamcast is my favourite console of all time).
> So the Saturn emulated 3D by transforming squares into triangles. Imagine trying to do that in assembly. It’s definitely beyond my capabilities that’s for sure.
All my early 3D engines were in software (x86 assembler), this was in about 1990, before any 3D hardware came along. Doing the 3D texture-mapping is actually really simple, even in assembler, once you know how. Figuring out the algorithm was really hard because it was so hard in those days to find out any information about this stuff.
What I couldn't figure out until several years later was how to fix the issue of perspective warping on the textures. Again, the solution is so simple once you know it, but as a kid it was beyond me, until the Internet came along and opened up a world of coding I'd never seen before.
My point wasn’t that 3D is hard. It was that doing 3D on the Saturn was uniquely much harder because the hardware was designed for 2D sprite manipulation rather than polygons. Thus to create polygons on the Saturn you had to transform 2D square sprites into triangles (in a way that’s not to far from mode 7 on the SNES except you have to do it for every bloody sprite and not just an entire layer) and then place them on a 2D canvas at just the right points to make it looks like a connected three dimensional shape.
It was nothing like software rendering 3D in DOS nor anything like how the N64 and PS handled 3D (and they had their own problems too). I’m fact it was nothing like how anyone did 3D maths apart from Segas own engineers and that’s only because they’d already been using those same graphics chipsets in arcade cabinets. Hence where there are so many ports of Sega arcade games on the Saturn.
Segas approach created all kinds of problems when working in 3D that was technically possible in 2D on the same hardware: like the lack of understanding about depth/z-index (since you’re not actually working with polygons), broken alpha blending (which was supported by the hardware but didn’t work properly with transformed sprites because the act of transforming them meant pixels overlapped and thus the alpha blending became uneven) and so on and so forth.
And this is without even touching the usual problems that developers have with SMP. It wasn’t that uncommon for developers to only utilise one processor, effectively halving the capabilities of the machine, just to do away with the concerns of parallel processing.
Then to top all that off, you had to figure it all out in assembly. You couldn’t abstract some of those problems away in C (at least not initially).
While it’s true a lot of developers were still wrestling with how to do 3D in the mid to late 90s, the Saturn was uniquely awkward for 3D. It was a fantastic 2D system but it sucked for writing any 3D games on it.
The Koei strategy games on NES ran in a bytecode virtual machine. The actual game program would be written in C and compiled to the virtual machine. This allowed them to use the same codebase as the computer versions of their strategy games. As for why they use a VM rather than compiling to 6502, my guess is it saved ROM space (for example a 16 bit memory + memory add would be one instruction instead of 7)
There were a few game engine that adopted this approach (though I can mentally visualise the games, my mind has gone totally blank trying to name said engines). I wouldn’t go so far as to say it was common practice but it certainly was a technique used by a few game developers.
A lot of the time is was as much down to portability as anything else. However I’m not that familiar with Koei (aside having a few titles as a gamer) to comment on their design decisions.
Having the machine code from the ROM isn't the same as having the original assembler files, even if it's close.
I would over-comment my assembler just because it is an order of magnitude harder to scan over than C code. You also lose all the labels on your subroutines and jmps, all your variable names, all your data block labels.
It's provided as a patch - you still need to procure the original ROM yourself (legally or otherwise, but that's on you). Someone more knowledgable in copyright law can discuss the specifics, but AFAIK this is totally legal. It hasn't been any kind of problem for the ROM hacking scene so far, anyway.
It's distributed as a patch file, and also he founded and currently serves as director of the company that originally developed the game. I think he'll be fine.
