[richardjdare]

Back then assembly language was much more ergonomic than it is now, and the machines were simpler. Many of my favourite games in the 80s were made by teenagers programming in their bedrooms. Check out this 68000 assembly tutorial video from Scoopex, the Amiga demo scene group: https://youtu.be/bqT1jsPyUGw

He gets a simple graphical effect going on the Amiga in only a few lines of assembly. Doing the same thing using DirectX in c++ would take you all day!

[pjc50]

> much more ergonomic than it is now,

This is an interesting line of argument - in what way, and what could be done to improve the ergonomics?

> He gets a simple graphical effect going on the Amiga in only a few lines of assembly. Doing the same thing using DirectX in c++ would take you all day!

This is absolutely true, but in something like ShaderToy you can go back to producing complex pixel-bashing effects with a huge amount of processing power.

It's just the external Tower of Babel from boot to usability has got a lot larger.

[richardjdare]

My notion of ergonomic mostly comes from programming the Amiga in 68000 and then moving to the PC and being horrified by x86!

In 68k you had 8 32-bit data registers, (d0-d7) and 8 address registers (a0-a7)

If you wanted to access bytes or 16 or 32 bits you could do so like this:

  move.w #123,d0 ; move 16bit number into d0
  move.b #123,d1 ; move byte into d1

  move.l #SOME_ADDRESS,a0; set address reg a0 to point to a memory location.
  move.b d1,(a0) ; move contents of d1 to memory location a0 is pointing to.

Nice and easy to work with and remember.

On x86, thanks to its long and convoluted history you have all kinds of doubled up registers which you have to refer to by different names depending on what you are doing, and tons of historical cruft.

On top of the CPU, the old home computers had no historical cruft and it was very easy to talk to the hardware or system firmware; usually you'd just be getting and setting data at fixed memory locations. I can read an Amiga mouse click in one line of 68k. I've no idea how you'd do it on a modern PC or even Java! Modern systems just aren't as integrated, for better and worse.

Assembly language was also part of mainstream programming back then. You'd learn Basic then go straight to assembly if you wanted to do anything serious. So there were computer magazine articles on assembly, childrens books[1]. My first assembler, Devpac, came from a magazine coverdisk with a tutorial from Bullfrog, Peter Molyneaux's old game company[2].

So there were a whole range of cultural and technical reasons for assembly language being much more of a human-useable technology back in the day.

>It's just the external Tower of Babel from boot to usability has got a lot larger.

Yes I agree, I kinda miss being able to see the ground, which is probably why I find retro programming so appealing.

[1]https://archive.org/details/machine-code-for-beginners [2]https://archive.org/details/amigaformat39/page/n61

[MrRadar]

> This is an interesting line of argument - in what way, and what could be done to improve the ergonomics?

Due to the enormous complexity of modern CPUs I'm not sure there's anything that could be done. With the 486 and contemporary (and earlier) uarches you could largely expect the CPU to execute exactly what you wrote so understanding the performance impact of any given bit of assembly was pretty straightforward. Then CPUs started adding features like superscalar, speculative, and out-of-order execution, branch prediction, deep pipelines, register renaming, and multi-level caching that massively complicate modeling the performance of any given code.

For example you may need to explicitly clear an architectural register before reusing it for a new calculation to avoid creating a false dependency in the uarch which would prevent the CPU from executing the calculations in parallel. Knowing when this is necessary can be hard and the rules are usually different between different uarches, even within the same uarch family.

Good assembly programmers who are aware of all this complexity can still beat compilers but they certainly can't do that for the scale of code that compilers routinely generate. Thankfully compilers are generally "good enough" these days and assembly only needs to be hand-written for very hot inner loops for performance-critical code or for cryptographic code where the exact performance characteristics of the code could potentially leak information if they're not handled correctly.

[vardump]

> Back then assembly language was much more ergonomic than it is now, and the machines were simpler.

In a way that's true. I also enjoyed writing assembler back then, especially on 68k.

However, to really extract the last cycle you often ended up generating a block of code at runtime (kind of very basic JIT).

Sometimes self-modifying code provided the final oomph to get something running fast enough. The reasons varied: sometimes it was because of running out of registers, sometimes dynamically changing the performed operation without branch.

Too bad for the later CPUs with instruction prefetching and caching...

[slezyr]

You should use SDL for this and not DirectX. You don't need complex API for GPU to paint line if you concerned about complexity.

[zrobotics]

Have you looked through the SDL source, though? Sure, I can get a window open and paint lines very easily, I only have to write ~50-150 LOC. However, I've silently added thousands of lines (and at least one dll) to my project. The library only hides some of the complexity (which I love about it), but the complexity still exists.

[slezyr]

https://stackoverflow.com/a/35989490

[AnIdiotOnTheNet]

That's just piling on even more abstraction! You may as well use a hex editor and create a single line BMP, then "run" it with any image viewer.

[slezyr]

"more abstraction"? It's just one to be cross platform, you can't use OpenGL without it.

No need to go full shit ape and creation of 3D images in bmp is excellent exercise you should try.

https://github.com/ssloy/tinyrenderer

[AnIdiotOnTheNet]

My point is, if you're allowing arbitrarily deep abstraction you can make almost any task trivial by just using something that basically already does what you're trying to do. The point the parent was making was how, with almost no abstraction at all, you could do graphics on an Amiga in a few lines, but to do the equivalent on a modern system at the lowest reasonable level of abstraction takes a lot more effort. Comparing that to a giant abstraction layer is missing the point.

> you can't use OpenGL without it.

Yes you can. You can't even pretend that coding once against SDL will absolve you of having to deal with platform issues, it just helps a lot.

> and creation of 3D images in bmp is excellent exercise you should try.

I'm a hobbiest game dev who almost exclusively uses software rendering (albeit to a framebuffer that gets pasted onto the screen with OpenGL as the path of least resistance). I've also written image libraries. None of this has anything to do with the parent comment.