is there a NPM package for assembly? I need to keep access to right pad my strings package.
Dude got millions for it. Well deserved imho.
Since it wasn’t mentioned yet: https://openrct2.io/
Best way to play till this day
And most startlingly: no git
Edit: y’all’re right, version control is for wimps. What’s life without some adrenaline?
Who needs git when you have a B: drive and a Save As command for tycoon43.asm
Version control? You mean this?
./src ./src_1998_11_05_added_people_swimming ./src_1998_11_06_added_death_mechanics ./src_1998_11_06_0_removed_swimming_lol
Did the developer use any version control though? SCCS has been around since the early 70s, RCS and CVS since the 80s. The tools definitely existed.
Also, it was a single dev, which makes SCM significantly simpler!
In my experience (some games in z80 and 68000 in the early 90s), version control wasn’t considered until mid-90s sometime, and at first wasn’t trusted. There were network backups, but I don’t know if they had revisions.
Merging seemed like it couldn’t possibly work well, so we would try to have separate ownership of different files. Although there would be only a handful of programmers on a team, so that was easy.
Prior to that, backup and versioning was manually handing a floppy or two to someone each week.
This looks like a screenshot in the background of the C++ OpenRCT version because the resolution is too high and not supported by the original assembly release.
The original goes to 1024 x 786 and has different zoom levels. I’ve played most of the original parks this year and that does not see to be too high res to me. Give me a sec I’ll take a screenshot of mine in a minute.
Edit here it is. It’s the GOG version, which launches fullscreen, so the 1024 x 768 are stretched onto the center of my 1920 x 1080 screen.
Have you seen the insane complexity of modern CPUs? Ain’t no one hand coding that like a 6502 in 1985.
I wonder if there’s anyone alive right now who would be capable of such a task.
If the hardware was fixed, I don’t see why not.
Might not be as fast as the optimisations compilers do these days though.
If you have to support thousands of types of GPU and CPU and everything else, then fuck no.
Even if one did, say using x86, it would still just be interpreted by the CPU into the CPU’s native opcodes, as the legacy instruction sets are interpreted/translated.
as the legacy instruction sets are interpreted/translated.
Wth? That’s it, I’m sticking to the AVR then
Hello everyone and welcome to another video.
The YouTube algorithm works in mysterious ways.
Because I’m nice, to anyone who doesn’t get the reference: https://www.youtube.com/@MarcelVos
Epic Pinball was another game that I recall was written in assembly. When your old 286 struggled to run games at a decent framerate, Epic Pinball would run in a smooth 75fps or whatever you set your CRT monitor to.
Epic Pinball, if I recall correctly, also used some ModeX trickery, meaning it had most of the pinball table in VRAM, and then modified the VGA framebuffer pointer for scrolling, then only moving as much data as it was needed (ball, flippers, etc)
“Try writing it it in assembly”
I want to get off Mr. Bones’ Wild Ride.
Chris Sawyer is an absolute legend
Can you imagine making this game in assembly for MacOS over the last 20 years?
Yes
Also know as “how to keep a coder busy”
This but unironically
I’ve never written a single line of code in assembly, and I’m now curious
Get an 8-bit computer emulator, and learn 6502 or Z-80 assembly.
Usborne machine-code-for-beginners or any book by Rodnay Zaks.
It gets deeper from there, and modern CPUs are kind of awful to hand-hack assembly on, but you’ll at least learn how the computer really works!
I learned z80 assembly back when the cutting edge of technology was a ZX Spectrum, and 68k assembly when I upgraded to an Amiga. That knowledge served me quite well for my early career in industrial automation - it was hard real-time coding on eZ80’s and 65c02 processors, but the knowledge transfers.
Back in the day, when input got mapped straight into a memory location and the display output was another memory location, then assembly seems like magic. Read the byte they corresponds to the right-hand middle row of the keyboard, check if a certain bit is set in that byte, therefore a key is held down. Call your subroutine that copies a sequence of bytes into a known location. Boom, pressing a key updates the screen. Awesome.
Modern assembly (x64 and the like) has masses of rules about pointer alignment for the stacks, which you do so often you might as well write a macro for it. Since the OS doesn’t let you write system memory any more (a good thing) then you need to make system calls and call library functions to do the same thing. You do that so often that you might as well write a macro for that as well. Boom, now your assembly looks almost exactly like C. Might as well learn that instead.
In fact, that’s almost the purpose of C - a more readable, somewhat portable assembly language. Experienced C developers will know which sequence of opcodes they’d expect from any language construction. It’s quite a simple mapping in that regard.
It’s handy to know a little assembly occasionally, but unless you’re writing eg. crypto implementations, which must take the exact same time and power to execute regardless of the input, then it’s impractical for almost any purpose nowadays.
Very interesting. Thank you. I may start looking into C instead. I’ll still watch a couple of videos on assembly, just for the hell of it.
TTD and RCT are still amazing.