Hacker News Reader

Comment by markus_zhang | Hacker News Reader

I'm wondering if anyone develops a spinoff exactly as back in 1992.

You know, it would be interesting to follow the Carmack's route: start from Apple ][ programming for a couple of Ultima and Wizardry spinoffs, port them to PC. Then move to 80286 to make a scrolling engine for a double trilogy, and move up to 80386 to make a Wolfie clone, and continue from there. The point is to use real world machines or emulated env for development. One can probably learn a LOT programming by that way, although much if it is irrelevant in modern gamedev...

View on HN

Bonus points for using the same tooling and languages from then too. 6502 assembly, then a bit of 16 bit x86 assembly, and finally some C with Borland's 1992 tooling.

Yeah definitely! Is there any modern tools that can 1) run on native platform and 2) significantly improve dev experience? I guess the guys who developed Nox Archaist used some modern tools, and on DOS we might have something new because of a large retro community.

The more I think about it, the more I believe if someone can pull this off, although many skills learnt are useless in modern programming (like 6502 asm or 80286 asm or whatever tricks to get the games run smoothly on retro platforms), but the amount of effort definitely would pay off.

I don't think one needs to walk the full Carmack road. I think whoever goes from Shadowforge to Quake is impressive enough. Plus one does not need to implement all these games, many of them share similar engines.

(Bad formatting...)

June 22, 1996 Quake id Software GT Interactive Programming

May 31, 1996 Final Doom id Software GT Interactive Programming

October 30, 1995 Hexen: Beyond Heretic Raven Software id Software 3D engine

December 23, 1994 Heretic Raven Software id Software Engine programmer

September 30, 1994 Doom II: Hell on Earth id Software GT Interactive Programming

December 10, 1993 Doom id Software id Software Programming

1993 Shadowcaster Raven Software Origin Systems 3D engine

September 18, 1992 Spear of Destiny id Software FormGen Software engineer

May 5, 1992 Wolfenstein 3D id Software Apogee Software Programming

1991 Catacomb 3-D id Software Softdisk Programming

1991 Commander Keen in Aliens Ate My Babysitter! id Software FormGen Programming

December 15, 1991 Commander Keen in Goodbye, Galaxy! id Software Apogee Software Programming

1991 Commander Keen in Keen Dreams id Software Softdisk Programming

1991 Shadow Knights id Software Softdisk Design/programming

1991 Rescue Rover 2 id Software Softdisk Programmer

1991 Rescue Rover id Software Softdisk Programmer

1991 Hovertank 3D id Software Softdisk Programming

1991 Dangerous Dave in the Haunted Mansion id Software Softdisk Programming

1991 Dark Designs III: Retribution Softdisk Softdisk Programmer/designer

December 14, 1990 Commander Keen in Invasion of the Vorticons id Software Apogee Software Programming

1990 Slordax: The Unknown Enemy Softdisk Softdisk Programming

1990 Catacomb II Softdisk Softdisk Developer

1990 Catacomb Softdisk Softdisk Programmer

1990 Dark Designs II: Closing the Gate Softdisk Softdisk Programmer/designer

1990 Dark Designs: Grelminar's Staff John Carmack Softdisk Developer

1990 Tennis John Carmack Softdisk Developer

1990 Wraith: The Devil's Demise John Carmack Nite Owl Productions Developer

1989 Shadowforge John Carmack Nite Owl Productions Developer

thanks for reminding us: Carmack was a MACHINE in those years. and churning out one impressive/hit game after another

Yes, he's definitely one of those programmers that just blows my mind with how inventive and productive that they are.

Yeah man, definitely.

But from what I know, once you grind out a good enough game engine, essentially you can reuse the same code base again and again. The same with tools. For example Romero's Tiled served all Softdisk games plus Wolfenstein. The only new code is some new functionalities and a lot of new game logic code. Nowadays, you need 6 months just for the concept...

I bet nowadays if a two-programmer team (one for engine and one for tool, both do some designs) with some C++ and game dev experience goes into jam mode, with proper asset support (say he/she downloaded/contracted the assets beforehand), he can pop out games similar to the Softdisk ones in even shorter timespan. After all nowadays computers are much faster and we don't need assembly any more.

The tricky part is to stay on jam mode, and I believe the Softdisk team did wonder back then. Everyone was highly motivated and worked probably 80+ hours per week. They believed they could change the world and they did.

Second thought, if one wants to develop DOOM as Carmack did, he would need a NeXT workstation, might not be easy to come by TBH, but maybe there is am emulator good enough.

Basically, a Mac :)

You have a point!

and hard-to-press keys. uppercase letters only. and you are ONLY allowed to backup manually, and to 1.4Mb (or worse) floppies

This is The Way

kids: off my lawn

This would be a feat.

But many more people look for the fun. The good bits without the pains of ancient tooling, lacking debuggers and graphics tools, etc.

Agreed. Not sure what did the programming environment look like on Apple 2 back then. Probably not great. I don't even know whether there were debuggers. Need some Googling.

I only tried Basic on Apple ][. While it was a fascinating machine, I later greatly preferred the pampered experience of Basic, and then assembly, on MSX2.

A simple raytracer is also a good step in that list.

Which in 1992 would mean getting acquainted with either MASM or TASM.

I did it in '86 using a DSP32 :)

Patience... A couple of hours to render a simple scene at 800x600, and displayed using dithering due to a lack of colors in the palette. But it worked.

Uau, that is when I started in computing with a Timex 2068, naturally ray tracing was not even on my radar at the time.

Did it also do the classical line based rendering?

It was the most stupid and naive implementation possible, classic reverse raytracing starting from a distance from the center of the virtual camera plane and branching a few times to get the basics of reflection and a light model to work, then adding other features bit by bit. I don't really remember all the details, but I do remember that it was agonizingly slow on the CPU, the DSP made all the difference and allowed me to add a couple of features. The main loop was on every pixel of the virtual camera plane. I no longer have that code (or the DSP, for that matter) but it was a fun exercise and it taught me a lot of matrix/vector math.

The dithering code was also interesting, because my graphics card could not do true color I put 3x64 RGB shades in the palette and then cranked up the brightness for tetris like sets of pixels to simulate a true color display. Worked pretty well.

This was the DSP board:

https://www.signalogic.com/images/Ariel_DSP32-PC.jpg

I managed to gently overclock it to 24 MHz without problems, it did get a bit warmer but nothing too bad.

Very interesting, thanks for sharing.

I'm thinking, a lot of people, even developers are scary of assembly, right? Or a more irrefutable one: it doesn't have much use. Definitely it is true in the sense that indeed even system programmers don't write full assembly programs.

But then I thought about the kids in 80s, the Romeros and Carmacks, and a little before that the Garriots and Gates, those kids started with BASIC but immediately picked up assembly given the chance, because that was how high performance code could be written and they just learned it on the way. No Internet, very few books even for rich kids (usually a [Machine] programming guide is good enough). Now that I think about it, some of them were barely teenages.

I bet the real difference is 1) Much simpler machine arch and 2) They had to learn it for writing games and other high performance software.

Assembly was pretty much the only way to break the speed barrier that BASIC imposed. It started out as 'the' language, then after a while you'd realize there was the computer underneath BASIC that could do more and was faster, but also a bit scary. Then, after you mastered peek and poke and bit by bit learned more about what made the computer tick one day you'd wake up and realize that all you still used BASIC for was to load machine language programs.

That gradual ramp made it work.

Yep. Plus nowadays people have so many selections and it doesn't really make sense to use assembly for production unless in rare cases.

I am also from that generation.

I really don't get how people are scared of low level programming, computer languages don't bite, don't attack on dark street corners, don't whatever.

Yes bad programs might corrupt some data, just like removing the plug with computer on might do the same and no one thinks twice about it.

Back in the day we didn't had tooling like Compiler Explorer to understand how BASIC would map to Assembly, only trial and error, alongside pen and paper.

Anyone that wants to learn Assembly nowadays can jump there, click on the high level constructs and see how they map to Assembly instructions for their favourite CPU.

If anything virtual machines have made this so much easier than before, it's like having a $100K CPU emulator on every desktop. You can look straight into the CPU, see all of the registers change in lockstep and the result on memory. I'd have happily killed for that in the 80's.

On the other hand, architecture back then was pretty simple though. Plus there is a big OS in middle of everything, you cannot really talk to the hardware directly nowadays. Back in the Apple ][ and DOS days it was mandatory.

That's why I have always been thinking that people actually should still start from an Apple ][/C64/80286/NES/SNES/GB these days, or maybe just embedded system for cheaper introductory tuition/quicker employment. You ignore all bells and whistles of hardware accumulated through the last 30 or so years and start from bare metal, real mode and gradually crawl from there. But without ignoring the bells and whistles of software tools people built for these platforms. I bet nowadays we have better tools for developing on these platforms. As some other commenter said, we can spin up a VM or emulator and directly look at memory and registers.

Reply on news.ycombinator.com