Assembly language?

I used 8086 assembly language for years way back when. It used to be that the screen was memory mapped using the same addresses space at as the CPU. Also graphics cards did next to nothing. All they did was read memory and display it on the screen as pixels. In those days you could in fact draw by simply writing to memory. For instance to draw a line you would use Bresenham's algorithm. To draw a polygon you would use the same algorithm on the edges and just scan the middle and write bytes to memory. Now you have graphics cards with separate processors (GPUs) and graphics memory and typically you access the hardware using a library like DirectX or OpenGL.

It's really not worth it to make whole programs in Assembly language any more. Yes you can use it to optimize bits of code, but those bits don't have a lot to do with graphics directly. Of course you can call graphics libraries from Assembly language but it won't get you much and it won't teach you much that you can't learn elsewhere.

I recently had to learn x64 just so I could help a friend do his homework. We wrote a basic big integer library (add, subtract, multiply and divide) and it worked pretty well. (In fact he said it smoked the professors code so he got a 5+ which is like an A+ in the US, and he got to skip the final exam ) In any case, IMO it's probably better to learn ASM doing something like that, where writing it in ASM might actually be of some benefit.

As for resources there are lots of them on the web or you can just grab a decent book on Amazon. ASM really isn't that hard. In fact I would say it's way easier than C++. You typically just end up writing procedures. It's just a bit tedious at times but once you get used to it, it isn't that bad. It's also easy to link into C++ or C so you can write your procedures and use them in C++.

7 minutes ago, Gnollrunner said:

It's really not worth it to make whole programs in Assembly language any more. Yes you can use it to optimize bits of code, but those bits don't have a lot to do with graphics directly. Of course you can call graphics libraries from Assembly language but it won't get you much and it won't teach you much that you can't learn elsewhere.

I know, but I was always fascinated by the .kkrieger guys and wanted to play around with it. I doubt it will be productive in the long run, but I am very much in a "just screw around and ignore the future" mode at the moment, due to the private issues...

I am still using this float to int asm code : http://musicdsp.org/archive.php?classid=5#56

I dont know if its still needed, i use it.

I have assembly code versions of NeHe's OpenGL tuts on a drive somewhere...

I just found this one, looks okay once you get into it:

This is the one I used recently to get back up to speed, I enjoyed it (has multiple videos):

There won't be that much information about this and there certainly won't be many introductory tutorials. You've strayed far, far into DIY territory and something that's not even practical or even in wide use in game development. You will find generic information about assembly language programming, of course, but you won't really find anything about game development.

That said, assembly is a lot of fun. One of my hobbies is 16-bit x86 assembly on DOS, and this is old enough that there is actually information about this available in the form of text files and books (many of which can be had on Ebay for $5 with free shipping). It's also interesting and rewarding having an entire machine to yourself and controlling the video hardware manually. This is as far from modern as you can get, but if you're interested in this I can dig up some info for you.

But in the end this is a real hardcore path that I only recommend if you're extremely persistent. Games are complicated as they are and programming one in assembly when you're just learning assembly is a real tall order. You won't find much or any help, you're going to have to be really self-reliant and know how to solve problems yourself.

4 hours ago, gaxio said:

There won't be that much information about this and there certainly won't be many introductory tutorials.

Actually that is completely untrue. I found about 2 dozen tutorials (mostly introductory tutorials at that) in a couple minutes of googling. I even posted two video tutorial series one of which uses x64 assembly. The Intel books are available via PDF as great references too. I finally got rid of my print ones that they sent out for free just a couple years ago, but they were over 10 years out of date.

11 minutes ago, CrazyCdn said:

Actually that is completely untrue. I found about 2 dozen tutorials (mostly introductory tutorials at that) in a couple minutes of googling. I even posted two video tutorial series one of which uses x64 assembly. The Intel books are available via PDF as great references too. I finally got rid of my print ones that they sent out for free just a couple years ago, but they were over 10 years out of date.

If you would have continued reading just one sentence down the road, it's clear I was talking about assembly in game development, not assembly in general. Of course there are resources about assembly programming.

On 7/10/2018 at 10:00 AM, Embassy of Time said:

poking a stick at assembler / assembly language, whatever you want to call it (I keep seeing people use those two names interchangeably

The difference is that "assembly language" is the language that you write your program in (ie the set of symbolic CPU instructions made available by the CPU manufacturer), while "assembler" is a program to convert your mnemonics text into proper machine language, possibly going through a linking stage.

The distinction is quite small though, as most assembly languages are extended with assembler-specific instructions, eg for specifying start memory addresses, or switching segments, etc. I guess you could name the extended set an assembler language, since often these extensions have specific syntax for one assembler.

15 hours ago, gaxio said:

You've strayed far, far into DIY territory and something that's not even practical or even in wide use in game development.  You will find generic information about assembly language programming, of course, but you won't really find anything about game development.

I have to add some caveats in here. True, nobody builds games in assembly. But there are certainly uses for it. It's still common to write SIMD routines in assembly, especially newer instruction sets where the compiler intrinsic support is either not available or just doesn't work that well. PS3 SPUs were frequently coded in assembly. And debugging often involves going over the assembly code being emitted and run, in order to understand what's going on. Performance optimization also frequently requires analysis of the compiler output to fully achieve the desired results.

We're not writing in assembly or even reading it on a regular basis, but you better believe that it comes up plenty in games.

I also started with assembly in the '80s and agree it can be really good fun, and I'd recommend anyone to have a dabble with learning it, not so much because it is likely to be useful itself these days (except specific areas) but so you can understand how compilers work, how interpreted bytecode works, what is the difference etc. Those youtube tutorials brought back memories of writing sprite drawing routines etc.

As said the reason why it is less relevant now is because in the old days you had direct access to screen memory (and because the compilers now are so damned good!). Now everything is done through APIs, the CPU doesn't have direct access to screen memory (or you shouldn't write as if it does). So writing assembly to call OpenGL for instance is kind of pointless, because it's the same thing as calling OpenGL from e.g. C, you are gaining nothing by doing it in assembly.

And as promit says it is still used in the form of SIMD (mostly via intrinsics), which is really fun. Kind of things I've used SIMD for recently are for CPU graphics techniques, vector math and audio.

If you are determined to make a small game in assembly you might want to look at emulators for simpler (older) computers which do have a 'screen memory'. As a bonus the assembly will be easier I think because of less instructions. It's not that tough, it's the same concepts as writing modern games, just simpler .. game loop, input, displaying stuff etc. Back in the day we wrote all the tools in assembly too, sprite editors, map editors etc.

Just to make it perfectly clear, I am NOT turning my entire game creation hopes over towards assembly! Even I am not that outrageously insane ?

I had hoped to make a small game, just to test myself, in the style of ZX Spectrum or early Atari machines, just moving some dots around (Space Invader comes to mind). But am I correct to understand that assembly language cannot access the screen? I can't write assembly code that puts a series of dots on the screen without using some other, non-assembly language? Because that would defeat the entire idea of making a small game 100% in assembly language

19 minutes ago, Embassy of Time said:

Just to make it perfectly clear, I am NOT turning my entire game creation hopes over towards assembly! Even I am not that outrageously insane ?

I had hoped to make a small game, just to test myself, in the style of ZX Spectrum or early Atari machines, just moving some dots around (Space Invader comes to mind). But am I correct to understand that assembly language cannot access the screen? I can't write assembly code that puts a series of dots on the screen without using some other, non-assembly language? Because that would defeat the entire idea of making a small game 100% in assembly language

You have a few choices, either get a really old computer with a really old graphics card and then you can do what you want, or you can just write to a block of memory and then copy that to the GPU. Come to think of it, you should also be able to just open a buffer on the GPU and write to that directly and display it, and then for the next frame do the same thing using a second buffer. Then you just flip back and forth like the normal swap chain. In any case I think you can do more or less what you want, you just need some minimal Direct X or OpenGL code to handle the setup and swapping of buffers.

I couldn't find my NeHe asm source code. This might get you started though...

https://github.com/duncanspumpkin/NeHeNASM

I have not looked at his code.

ED: Looky what I found

https://github.com/gamedev-net/nehe-opengl/tree/master/masm

Assembly is very much alive in games development, but its in the "retro-revival" scene where you will find it.

Look to the C64 or ZX Spectrum 48K as a starting point, as they are backed up by a wealth of learning material, and their architecture are basic. The community support is good and the emulators and tools are ideal for the beginner.

As a programmer I found Assembly to be essential study, as you get an much better idea on what is happening at the hardware level. As a maker of games( well, demos in all honesty ) I don't see its use beyond the 16-bit era of machines, but lets just say the "language" fits the size of the programs you can expect to make for such classic machines.

Whilst we are on the subject, would it be possible for GameDev to have a sub-forum dedicated to retro development? It gets a little tiresome when met with the usual "why would you want to do that?" when posting on the subject, and it would help to connect those of us who do have such an interest...

For Uncharted 4, they used intrinsics to make the multicore architecture working at max potency for the Ambient Occlusion.
Assembler gives you the deepest control over the hardware.
You can combine the beginner tutorials with the documentation of Intel, which is extremely explicit and available for free online.
You can search for the assembler community in G+. They like to help and I have seen people there making games for assembler, still nowadays, still now.
If you are gonna use ASM, please be aware that in a perfect scenario ASM should be used in conjunction with C/C++.

I find it amusing, how .kkrieger is mentioned as motivation, given that it is written almost entirely in C++:

https://fgiesen.wordpress.com/2012/02/13/debris-opening-the-box/

https://github.com/farbrausch/fr_public

As for the main question - I would like to know the answer myself.

I'm rather sceptical of the video-tutorials (of pretty much any kind) on the subject. What I want is a proper textbook. And there doesn't seem to be many of those around.

I get the impression, that the mindset is like "whoever wanted to learn assembly did it in 90's already, and if you are trying to learn now - sucks to be you", which is unfortunate.

My best suggestion would probably be using books (& environment, e. g. DosBox) from 90's and then slowly assimilating information on more modern assembly, scattered on the net. Which is... suboptimal.

About the best recent textbook on assembly I know of would be "The Art of Assembly Language", which for one thing I would not call exactly 'modern' anymore, and for another has made some questionable choices for my tastes (fascinations with macros is one example: they might be useful to write assembly, but arguably not to learn it).

There is "Intel 64 and IA-32 Architectures Developer's Manual", of course. That is a great reference, but it is frightening trying to imagine someone trying to use that behemoth as a textbook.

I wouldnt waste time learning DOS 16 bit Assembly with its weird segmentation and quirky register use. If you want to learn Assembly, just start with a modern 64 bit form.

18 hours ago, wintertime said:

I wouldnt waste time learning DOS 16 bit Assembly with its weird segmentation and quirky register use. If you want to learn Assembly, just start with a modern 64 bit form.

Ha!

I already skipped DOS 16 bit assembly in the 90s, buying an Archimedes with ARM processor (whopping 8MHz, but out-performing a 386DX 40MHz), and foremost, a nice flat 32 bit address space.