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.
I like ASM because it can be delightfully simple, but it’s just not very productive especially in light of today’s tooling. In practice, I use it only when nothing else will do, such as for operating system task schedulers or hardware control. It’s nice to have the opportunity every once in a while to work on an embedded system with no OS but not something I get the chance to do very often.
On one large ASM project I worked (an RTOS) it’s exactly as you described. You end up developing your own version of everything a C compiler could have done for you for free.
bjoern_tantau@swg-empire.de
on 17 Oct 16:53
nextcollapse
I mean, I’m pretty sure it would be a good learning experience so I would really not regret it.
I tried decades ago. Grew up learning BASIC and then C, how hard could it be? For a 12 year old with no formal teacher and only books to go off of, it turns out, very. I’ve learned a lot of coding languages on my own since, but I still can’t make heads or tales of assembly.
Yeah, I skipped Pascal, but it at least makes sense when you look at it. By the time my family finally jumped over to PC, C was more viable. Then in college, when I finally had to opportunity to formally learn, it was just C++ and HTML… We didn’t even get Java!
I had used like four different flavors of BASIC by the time I got a IBM compatible PC, but I ended up getting on the Borland train and ended up with Turbo Pascal, Turbo C, and Turbo ASM (and Turbo C++ that I totally bounced off of). I was in the first class at my school that learned Java in college. It was the brand new version 1.0.6! It was so rough and new, but honestly I liked it. It’s wildly different now.
Dubiousx99@lemmy.world
on 17 Oct 18:06
nextcollapse
Assembly requires a knowledge of the cpu architecture pipeline and memory storage addressing. Those concepts are generally abstracted away in modern languages
You don’t need to know the details of the CPU architecture and pipeline, just the instruction set.
Memory addressing is barely abstracted in C, and indexing in some form of list is common in most programming languages, so I don’t think that’s too hard to learn.
You might need to learn the details of the OS. That would get more complicated.
I said modern programming languages. I do not consider C a modern language. The point still stands about abstraction in modern languages. You don’t need to understand memory allocation to code in modern languages, but the understanding will greatly benefit you.
I still contend that knowledge of the cpu pipeline is important or else your code will wind up with a bunch of code that is constantly resulting in CPU interrupts. I guess you could say you can code in assembly without knowledge of the cpu architecture, but you won’t be making any code that runs better the output code from other languages.
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 😐️
It also makes it really portable which is a big part of why all the ports to modern systems are so close to the original. Obligatory OpenRCT2 shoutout.
fubbernuckin@lemmy.world
on 17 Oct 19:25
nextcollapse
Started playing openrct2 multiplayer with a friend yesterday. Some of the best fun I’ve had.
Imgonnatrythis@sh.itjust.works
on 17 Oct 20:45
nextcollapse
Damn this post. This is really going to f up my weekend plans.
Writing it in assembly would make it pretty much the opposite of portable (not accounting for emulation), since you are directly giving instructions to a specific hardware and OS.
Not necessarily, unless you’re working on something like an OS you’re not usually directly accessing/working on the hardware. As long as you can connect the asm up to your os/driver abstraction layer and the os to hardware apis work the game should be functional. Not to mention RCT targets the x86 assembler architecture which was one of the most popular at the time
celsiustimeline@lemmy.dbzer0.com
on 17 Oct 17:49
nextcollapse
Your game will actually likely be more efficient if written in C. The gcc compiler has become ridiculously optimized and probably knows more tricks than you do.
dejected_warp_core@lemmy.world
on 17 Oct 20:15
nextcollapse
Especially these days. Current-gen x86 architecture has all kinds of insane optimizations and special instruction sets that the Pentium I never had (e.g. SSE). You really do need a higher-level compiler at your back to make the most of it these days. And even then, there are cases where you have to resort to inline ASM or processor-specific intrinsics to optimize to the level that Roller Coaster Tycoon is/was. (original system specs)
Write it in Rust, and it’ll never even leak memory.
DannyBoy@sh.itjust.works
on 17 Oct 18:34
nextcollapse
This game ran so smooth.
bratorange@feddit.org
on 17 Oct 18:51
nextcollapse
Don’t Want to be that Guy but you can actually use libraries in Assembly and probably want to, as otherwise you have no good way of interacting with the os.
kibiz0r@midwest.social
on 17 Oct 19:21
nextcollapse
You can actually pluralize library and probably want to.
you need all of that when writing a game in assembly. wtf do you think assembly is?
MonkeMischief@lemmy.today
on 17 Oct 19:27
nextcollapse
I love Roller Coaster Tycoon.
It’s absolutely crazy how he managed to write a game in a way many wouldn’t even attempt even in those days, but it’s not just a technical feat, it’s a creative masterpiece that’s still an absolute blast to play.
It still blows my mind how smoothly it gives the illusion of 3D and physics, yet it can run on almost anything.
OpenRCT brings a lot of quality of life and is often the recommended way to play today, but the original RCT will always deserve a spot on any “Best Games of All Time” list.
The game Roller Coaster Tycoon was famously hand written in raw CPU instructions (called assembly language). It’s only one step removed from writing literal ones and zeros. Normally computers are programmed using a human-friendly language which is then “compiled” into CPU instructions so that the humans don’t have to deal with the tedium and complication of writing CPU instructions.
IMNOTCRAZYINSTITUTION@lemmy.world
on 17 Oct 22:34
collapse
thanks petah
RavenFellBlade@startrek.website
on 18 Oct 00:44
collapse
threaded - newest
To be fair, assembly lines of code are fairly short.
/ducks
Back in the day we wrote everything in asm
Pssh, if you haven’t coded on punch cards, you aren’t a real coder
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.
I like ASM because it can be delightfully simple, but it’s just not very productive especially in light of today’s tooling. In practice, I use it only when nothing else will do, such as for operating system task schedulers or hardware control. It’s nice to have the opportunity every once in a while to work on an embedded system with no OS but not something I get the chance to do very often.
On one large ASM project I worked (an RTOS) it’s exactly as you described. You end up developing your own version of everything a C compiler could have done for you for free.
I mean, I’m pretty sure it would be a good learning experience so I would really not regret it.
I tried decades ago. Grew up learning BASIC and then C, how hard could it be? For a 12 year old with no formal teacher and only books to go off of, it turns out, very. I’ve learned a lot of coding languages on my own since, but I still can’t make heads or tales of assembly.
Sounds very similar to my own experience though there was a large amount of Pascal in between BASIC and C.
Yeah, I skipped Pascal, but it at least makes sense when you look at it. By the time my family finally jumped over to PC, C was more viable. Then in college, when I finally had to opportunity to formally learn, it was just C++ and HTML… We didn’t even get Java!
I had used like four different flavors of BASIC by the time I got a IBM compatible PC, but I ended up getting on the Borland train and ended up with Turbo Pascal, Turbo C, and Turbo ASM (and Turbo C++ that I totally bounced off of). I was in the first class at my school that learned Java in college. It was the brand new version 1.0.6! It was so rough and new, but honestly I liked it. It’s wildly different now.
Assembly requires a knowledge of the cpu architecture pipeline and memory storage addressing. Those concepts are generally abstracted away in modern languages
You don’t need to know the details of the CPU architecture and pipeline, just the instruction set.
Memory addressing is barely abstracted in C, and indexing in some form of list is common in most programming languages, so I don’t think that’s too hard to learn.
You might need to learn the details of the OS. That would get more complicated.
I said modern programming languages. I do not consider C a modern language. The point still stands about abstraction in modern languages. You don’t need to understand memory allocation to code in modern languages, but the understanding will greatly benefit you.
I still contend that knowledge of the cpu pipeline is important or else your code will wind up with a bunch of code that is constantly resulting in CPU interrupts. I guess you could say you can code in assembly without knowledge of the cpu architecture, but you won’t be making any code that runs better the output code from other languages.
Try 6502 assembly. skilldrick.github.io/easy6502/
My favorite assembly language by far.
this page is great. starting right at “draw some pixels” in such a simple way just instantly makes it feel a bit more approachable!
Step 1: Begin writing in Assembly
Step 2: Write C
Step 3: Use C to write C#
Step 4: Implement Unity
Step 5: Write your game
Step 6: ???
Step 7: Profit
Eww Unity
Step 6 extort developers
Step 0: Invent the universe
What are we doing here? Baking a pie?
Good thing I wrote my own game engine using D, and soon there will be 2 (known) games for it.
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 😐️
I’m on E already
Reminder that ttd was open source even before open ttd :D
I don’t know if everyone gets the reference: RollerCoaster Tycoon is in fact writing mostly in assembly to use the hardware more efficiently
It also makes it really portable which is a big part of why all the ports to modern systems are so close to the original. Obligatory OpenRCT2 shoutout.
Started playing openrct2 multiplayer with a friend yesterday. Some of the best fun I’ve had.
Damn this post. This is really going to f up my weekend plans.
My friend and I created MONORAIL LAND
Does it have a scientist Batman?
Writing it in assembly would make it pretty much the opposite of portable (not accounting for emulation), since you are directly giving instructions to a specific hardware and OS.
Not necessarily, unless you’re working on something like an OS you’re not usually directly accessing/working on the hardware. As long as you can connect the asm up to your os/driver abstraction layer and the os to hardware apis work the game should be functional. Not to mention RCT targets the x86 assembler architecture which was one of the most popular at the time
Is it only 500,000 lines?
Shifts bit to the left
Um what am I doing
Shifts bit to the right
program crashes
Chris Sawyer is a madman.
I believe you meant to write genius.
Chris Genius is a madman.
Who the hell even is Madam Chris Genius?
Your game will actually likely be more efficient if written in C. The gcc compiler has become ridiculously optimized and probably knows more tricks than you do.
Especially these days. Current-gen x86 architecture has all kinds of insane optimizations and special instruction sets that the Pentium I never had (e.g. SSE). You really do need a higher-level compiler at your back to make the most of it these days. And even then, there are cases where you have to resort to inline ASM or processor-specific intrinsics to optimize to the level that Roller Coaster Tycoon is/was. (original system specs)
Yep but not if you write sloppy C code. Gotta keep those nuts and bolts tight!
If you’re writing sloppy C code your assembly code probably won’t work either
Write it in Rust, and it’ll never even leak memory.
This game ran so smooth.
Don’t Want to be that Guy but you can actually use libraries in Assembly and probably want to, as otherwise you have no good way of interacting with the os.
You can actually pluralize library and probably want to.
In fact Chris Sawyer did use C for the purposes of linking the OS libraries necessary for windowing, rendering, sound etc.
They call me the Programmer and I speak to the metal,
Now check out this app, that really shows off my mettle!
where’s your furry cracktro then??
I want to get off Mr. Bones’ Wild Ride
The ride never ends!
I was looking for this comment. Brings back so many good memories of the early internet.
you need all of that when writing a game in assembly. wtf do you think assembly is?
I love Roller Coaster Tycoon. It’s absolutely crazy how he managed to write a game in a way many wouldn’t even attempt even in those days, but it’s not just a technical feat, it’s a creative masterpiece that’s still an absolute blast to play.
It still blows my mind how smoothly it gives the illusion of 3D and physics, yet it can run on almost anything.
OpenRCT brings a lot of quality of life and is often the recommended way to play today, but the original RCT will always deserve a spot on any “Best Games of All Time” list.
It was even ported to the original Xbox. I remember the total games file size being incredibly small - compared to most other titles on that system.
Not Assembly, but HROT was written in Pascal by one person and runs buttery smooth.
Oooh! Know what I’m playing this weeeknd! Thanks!
They have played us for fools
Small error, game crashes and takes whole PC with it burning a hole in the ground.
Back into the fiery pit of hell, where it belongs!
Just don’t make any errors. Not one.
It dis-assembled the computer!
Roller coaster Tycoon is one of a lifetime game.
Now everything is electron or react shit. Gone are the times of downloading fully featured software under 10mb.
But the modern OpenRCT, written in an actual language, is better in every way.
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!
petah please what’s this mean
The game Roller Coaster Tycoon was famously hand written in raw CPU instructions (called assembly language). It’s only one step removed from writing literal ones and zeros. Normally computers are programmed using a human-friendly language which is then “compiled” into CPU instructions so that the humans don’t have to deal with the tedium and complication of writing CPU instructions.
thanks petah
Glory to you… abd your hoooouse!
.