How hard could it be?

Writing in ASM is not too bad provided that there's no operating system getting in the way. If you're on some old 8-bit microcomputer where you're free to read directly from the input buffers and write directly to the screen framebuffer, or if you're doing embedded where it's all memory-mapped IO anyway, then great. Very easy, makes a lot of sense. For games, that era basically ended with DOS, and VGA-compatible cards that you could just write bits to and have them appear on screen.

Now, you have to display things on the screen by telling the graphics driver to do it, and so a lot of your assembly is just going to be arranging all of your data according to your platform's C calling convention and then making syscalls, plus other tedious-but-essential requirements like making sure the stack is aligned whenever you make a jump. You might as well write macros to do that since you'll be doing it a lot, and if you've written macros to do it then you might as well be using C instead, since most of C's keywords and syntax map very closely to the ASM that would be generated by macros.

A shame - you do learn a lot by having to tell the computer exactly what you want it to do - but I couldn't recommend it for any non-trivial task any more. Maybe a wee bit of assembly here-and-there when you've some very specific data alignment or timing-sensitive requirement.

Pssh, if you haven't coded on punch cards, you aren't a real coder

Further proof C++ is a pita

Is there not a way to take assembly and automatically translate it to some higher level language?

Edit: Post-post thought: I guess that would basically be one step removed from decompilation which, as I understand it, is a tedious and still fairly manual process.

Well worth it. The mobile version is amazing, that is to say, almost exactly the same as the original.

Survivor bias is a thing and part of the reason people are nostalgic for old media.

People only remember the good stuff. They don't usually think about all the software that sucked.

Discord is garbage software lmao. Has been from the beginning. I can't stand using it.

A fucking calculator needs megabytes to run? And I'm not talking about a full fledged graphic scientific calculator. I'm talking about a basic one.

Old=good is a great mentality specifically when standing the test of time is an important factor. For the most part, the old code that's still used today is only still used because it's proven good, whereas it's a grab bag with newer code. And that's the cause of the unwarranted nostalgia thay you're rightfully criticising.

It's like with music. "Oh, the X's were the best decade for music, today's music is garbage". No, 90% of everything is crud but unless you're an enthusiast, once enough time has passed, you'll only ever be exposed to the 10% that isn't. 50 years from now nobody is going to be listening to Cardi B.

If you want to get a glimpse of the hate against Unix in the early 90's, give "Unix hater's handbook" a read. It's a funny piece

Probably not as optimized though.

RCT could run on a toaster from the 90's (ok, maybe early 2000's) and looked amazing for the time.

OpenRCT can run on a toaster from the 2010's and looks great because of the timeless art style of the original.

It's still an incredible feat, though!

The best book I've ever bought on programming, and the second best book I bought for a class in uni, was https://dl.acm.org/doi/book/10.5555/1824214 it may be worth checking out on libgen and buy if it suits your needs.

Whenever I do low-level programming on the AVR architecture, I'll make a memory map. As in I'll map out where I'll put what. It may not be suitable for more complex programs, but it does the job for me. And it has enabled teamwork in assembly in the past.

If you want to work in a language that doesn't offer memory management, but manually mapping memory isn't feasible either, how about building your own memory management? Or perhaps use an RTOS? I've used freeRTOS before on various arm-based micros, and it does take a bit to get started, but after that it's easy sailing.

Sorry for the following tangent, all semi intelligent content in this comment is found above this line.
BTW I tried CoOS once, I wouldn't recommend it... OK it was 12 years ago, I can't remember exactly what was wrong other than the documentation was crap, but I don't need to remember why to hold a grudge.

I might be wrong, but doesn't SSE require you to explicitly use it in C/C++? Laying out your data as arrays and specifically calling the SIMD operations on them?

If you're writing sloppy C code your assembly code probably won't work either

I’m a developer, I don’t just continue doing things for years if it doesn’t make sense.

(If I’m the one making the decisions)

Remember old Apple, had to use them when learning to program, there were 2 types, one with the OS on a diskette, one with a small hard drive, and they randomly showed a large bomb in the middle of the screen and you had to reload the OS. Probably the compuler that broke everything.

I'm on E already

D

Don't give me hope.

I was really into D, but I gave up on it because it seemed kind of dead. It's often not mentioned in long lists of languages (i.e. I think Stack Overflow's report did not mention it), and I think I remember once looking at a list of projects that used D and most of them were dead. I think I also remember once seeing a list of companies that used D, and when I looked up one of them I found out it didn't exist anymore 😐️

What are we doing here? Baking a pie?

Assembly requires a knowledge of the cpu architecture pipeline and memory storage addressing. Those concepts are generally abstracted away in modern languages

Try 6502 assembly. https://skilldrick.github.io/easy6502/

My favorite assembly language by far.

Sounds very similar to my own experience though there was a large amount of Pascal in between BASIC and C.

To further emphasize this, I had an assembly course in university. During my first lab, the instructor told us to add a comment explaining what every line of assembly code did, because if we didn't, we would forget what we wrote.

I listened to his advice, but one day I was in a rush, so I didn't leave comments. I swear, I looked away from the computer for like 2 minutes, looked back, and had no idea what I wrote. I basically had to redo my work.

It is not that much better than reading 1s and 0s. In fact in that course, we spent a lot of time converting 1s and 0s (by hand) to assembly and back. Got pretty good at it, would never even think of writing a game. I would literally rather create my own compiler and programming language than write a game in assembly.

thanks petah

Chris Genius is a madman.

Release the docs!

Inspector Gadget for GBC: https://youtu.be/GSPCBtg0cJ4?si=GHfE4gIJpJA8ITC8

Toonsylvania for GBC: https://youtu.be/IHOwUWpXi2Y?si=GNrc6S08sy3CQMmG

My older games didn't get published, but I had another platformer for Amstrad CPC, as well as several adventure games with syntax analyzers.