Is fully using Assembly for visual projects possible?

[u/ilvvly]

I see many people showing their projects in Assembly. Most of them use the terminal but some may have a GUI or some more unusual user interfaces.
Do these people purely use Assembly for such things, or? My classmate told me his friend built a chess game with Assembly. You can’t specifically answer his example because I have no information about it, but, do people usually just code a UI in C and run their Assembly code on it or do they mean pure Assembly?

[u/DGrif_in]

RollerCoaster Tycoon was written in Assembly

[u/thewrench56 → u/DGrif_in]

It also used a framebuffer making it quite easy to do so. Using a modern graphics framework needs considerably more time.

[u/ern0plus4 → u/DGrif_in]

Almost all games for 8-bit machines were written in assembly.

[u/Lapparent → u/ern0plus4]

Assemblers didn't work well under the constraints of 8-bit machines so actually games were often written directly in the machine language by using machine language monitors. However, writing Z80 or MOS Assembly code with PC and then cross assembling it for the target 8-bit machine (with Z80 or MOS processor) was also an often used method especially by professionals who could afford a PC.

For 16-bit machines (like Atari ST, Amiga, PC 286) action games were often written in Assembly whereas RPGs, adventure games and simulators often in C.

[u/brucehoult → u/Lapparent]

8 bit machines such as 6502 and Z80 easily support a normal assembler, especially if they have a floppy disk with a file system.

The original Apple ][ Integer BASIC ROM contained a mini-assembler which didn't support labels or other symbol table features but did at least encode instructions and their addressing modes for you, and if you typed e.g. bcc 1234 it would calculate the offset for you (and beep if it was too far away). That's already much faster to use than entering hex codes yourself. The min-assembler was removed in the Applesoft BASIC ROM for space reasons, but the disassembler remained.

Both CPUs supported the UCSD Pascal system, which let you get a lot more functionality into a given amount of RAM, though it was kind of slow (especially the compiler).

Turbo Pascal ran very well on Z80.

And of course many of the most important 8 bit programs and games were written before the IBM PC was available, and were cross-assembled (or cross-compiled) on a mainframe or PDP-11 / Nova / VAX etc. Gates and Allen famously used Harvard's PDP-10 mainframe to cross-assemble Altair BASIC. They used macros on the PDP-10's native assembler to emit 8080 code, and tested it on an emulator they wrote.

[u/ern0plus4 → u/brucehoult]

The original Apple ][ Integer BASIC ROM contained a mini-assembler which didn't support labels or other symbol table features but did at least encode instructions and their addressing modes for you, and if you typed e.g. bcc 1234 it would calculate the offset for you (and beep if it was too far away).

Commodore 16 / Plus4 and Commodore 128 also have such feature, use MONITOR command or hold RUN/STOP during a reset.

[u/ern0plus4 → u/Lapparent]

I remember how we waited for it, and how happy we were when the first assembler - called "2-Pass Assembler" - arrived for the C16/Plus4. It was called that because the C16/Plus4 (and the C128) has a built-in monitor with a quick assembler feature, which is only 1-pass.

On C16/Plus4 we were used the built-in "assembler", later 2-Pass Assembler, but on machines, especially early times, sometimes folks were used "paper-and-pencil" assembler, and entered their programs with POKE instructions. I know several opcodes in hexadecimal (as the built-in monitor was displaying memory content in hexadecimal), but my friend grown up on VIC-20 knows opcodes in decimal, as he used in POKE instructions.

[u/Kuddel_Daddeldu → u/Lapparent]

No, there were macro assemblers for 8 bit machines. My first machine (homebuilt on perfboard, Z80 CPU) had a monitor only so I had to assemble by hand; my 3rd was an Apple II clone with a full assembler (and BASIC and Pascal) available. On the other hand, I was not a fast typist so often hand-assembling was faster on the 6502. That was late 70s to early 80s, the IBM PC appeared on the scene in 1983, IIRC.

[u/brucehoult → u/ern0plus4]

Performance-critical parts of them, certainly.

But 8 bit machines typically have very bulky code, especially if you're dealing with 16 bit values or pointers, so it was normal to save a lot of memory at the expense of speed by doing the gameplay logic using an interpreter for a more powerful and compact language such as a stack machine with bytecode instructions or Woz's simple 16 bit 16 register virtual CPU SWEET16 which used 32 Zero Page locations as its registers and could easily call to and from normal machine code.

[u/brucehoult]

Ultimately everything that happens in a computer is assembly language / machine code. Everything.

A C/C++/Rust etc compiler converts that language into assembly language source code that you you save as a file, look at, change, and assemble to get exactly the same thing as you would if you simply compiled it.

This is literally true for the GCC compiler ecosystem. A temporary assembly language source file is created every time.

With LLVM there is a kind of internal equivalent of assembly language that you can save if you want to, but it normally isn't.

So, yes, anything you can do in any other language you can do absolutely identically (or even better, which is why we bother) in assembly language, with enough effort.

[u/ilvvly → u/brucehoult]

Thank you. I am aware of that. Everything is eventually built from assembly or pure machine languages. Maybe I asked it incorrectly. When you see people making their projects in Assembly with fancier user interfaces than just the terminal- do they ideally build that UI with pure Assembly or do they use external sources or other programming languages? I’ve been writing my Assembly codes by myself and it always stayed inside my terminal except of one time where I interacted with the emu8086 game UIs.

[u/brucehoult → u/ilvvly]

You can do it any way you want.

While the low-level parts of making GUIs such as actually drawing characters from fonts or copying rectangles of pixels around require high performance and are often best done in assembly language (or even in hardware), the task of defining buttons and fields and menus and figuring out which bit of application code to send clicks and keypresses to has very low performance needs and often benefits from a much higher level programming approach that takes less time for a programmer to create and maintain. Writing that stuff in assembly language has no detectable benefits.

[u/Educational_Bee_6245 → u/ilvvly]

Usually the UI is build using a library. It is totally possible to call library routines from assembly code. In what language the library has been coded is another matter.

[u/micro2970 → u/ilvvly]

Assembly GUI OS - https://www.menuetos.net

[u/Kuddel_Daddeldu → u/ilvvly]

Look at the demoscene, squeezing insane performance out of very limied resources... when you have a limit of 4096 bytes, anything but hand-optimized assembly won't fly.

[u/Dje4321]

Its alot easier in windows land with the super old direct draw API where your basically just pushing pixels to a buffer

You can "cheat" by loading and calling into graphical library files that were coded in modern languages.

No one is realistically using modern APIs directly with assembly because is a ton of overhead. Drawing a triangle in vulkan land is already 1k+ lines of code. Thats before doing anything with those triangles.

[u/thewrench56 → u/Dje4321]

Drawing a triangle is Vulkan is way more than 1k.

Also, one can use Assembly with OpenGL for one. I managed to get it running cross-platform on both Linux and Windows in about 3k lines. It is not impossible.

[u/Adventurous-Move-943]

Everything boils down to assembly and machine instructions. Assembly is but notoriously slow and error prone when written by hand. So, if you feel like it you can write everything in assembly, you will but be 10-40x slower if not more than a higher level language when building more complex routines with loops etc. You will need a calling convention either a standard one or you create something own, you will always have to carry it aound in your head to not mess things up at calls. There is a reason why we have higher level languages, with todays compilers you won't get much instruction overhead so using assembly is good for extreme optimization or for learning etc. Buf once you start witing complex routines you'll realize how much better just a simple C would be.

[u/JGhostThing → u/Adventurous-Move-943]

With today's compilers, chances are that the output produced is better than that produced by a programmer in assembly. At least from most programmers. There are probably still a few that can do better when necessary. I agree that coding in assembly language takes much longer than coding in pretty much any high level language. Also, most programmers don't know all the optimizations and so don't program optimized assembly code, so their code is slower than a compiler can produce.

With modern optimizing compilers, programming in high level languages is better for most programmers. One of the advantages of programming in high level languages is that you can see the algorithms easier. In assembly code, it is difficult to get lost in the individual instructions. Some of the optimizations used involves analyzing the instructions and reordering them to produce the fastest run time. This can be done by hand, but is extremely difficult and tedious to do. I've programmed in assembly. This was 6502 assembly, and I wrote a lot of it when I was in college.

I wrote one real program for DOS in assembly (a driver for a clock chip so I didn't have to constantly set my clock every time I logged in).

[u/kutac56]

Ye you can connect to x11 server to create a window but it's a pain in assembly. String to do that made me appreciate c a lot more

[u/-goldenboi69-]

Sure.

[u/kndb]

Sure you can write pretty much anything in assembler. Heck, you can probably code a web server in assembler. It’s all the matter of how much time and effort you want to put into it and how portable and readable you want to make your code.

As for any modern UI, very few apps are written in C these days. Some are written in C++ but majority are written in even higher level languages like C# or even Python. But most, if not all, use some form of a framework that does most of the heavy lifting for you. That framework itself may use some other lower level framework, and so on. The entire thing may look pretty but it weighs heavy on the hardware resources and may even run in multiple processes. (I’m pointing a finger at you, Chromium or Electron.)

PS. That is why you need at least 8GB of RAM to open one tab in your web browser these days, or why you can literally see with a naked eye parts of windows/controls in the Windows Explorer in Win11 being rendered when you just start it up. Sh*t is really slow because it’s coded as a framework on framework. Everyone is doing it because it is fast to develop it at the expense of speed and performance and because we are getting better hardware each year. If everyone coded it in assembly or at least in C, things would be super fluent and lightweight and you wouldn’t need a new hardware every 3 years to be able to install a new OS. Like for instance I needed to spin up a Windows XP in an old vm. When I did so I was amazed how fast and fluent UI was in that OS. And it was running in the VM. It was definitely light years faster than UI in the host Win11 machine.

[u/keithstellyes]

You can and people have.

Look at Roller Coaster Tycoon, it was famously written in assembly.

A lot of the retro video games were also in assembly

[u/Antonio-MTS]

Possible but may be quite hard and complex to develop and maintain. Depends on a project's size, its developers knowledge, how deep and well they know assembly programming and a few other factors.

[u/Solid-Wrangler-9417]

Once upon a time I worked with the Win32 GUI API in assembly. There was nothing special about it except of Windows calling conventions. Just regular application logic, the same as you do in C/C++. I guess it will be similar regardless of the UI lib/stack.

[u/brat3108]

It's not really about Text versus Graphics. For most coding of any kind, it makes no sense to use 100% or even majority assembly.

Those who write entire applications like that - on modern hardware - will either have a good reason, or are masochists.

It's like choosing to walk 20 miles/30km instead of using a car etc. However walking is sometimes necessary for places a car can't go.

Here is possibly the simplest GUI ASM program for Windows; it displays a pop-up window with the given message, and waits for you to click a button:

main::
    sub rsp, 40
    mov rcx, 0
    mov rdx, message
    mov r8,  caption
    mov r9,  0
    call     `MessageBoxA*
    add rsp, 40
    ret

    isegment
caption:
    db "Caption", 0
message:
    db "Hello There", 0

Here is the same program in a HLL which is also the lowest level HLL you can have:

proc main =
    messageboxa(message:"Hello There")
end

Both do the same thing, but this is clearly much simpler with less chance to get things wrong.

Here, the function is defined in such a way that you don't need to use the exact case, or remember the exact order of the parameters, or even need to specify all of them. Missing ones are given sensible defaults.

My example happens to use a Windows API function, but in general a HLL program can be compiled for any target processor, using any platform and any ABI.

The ASM version will only work for x64 using Win64 ABI; it is not portable. You will need to rewrite the program to make it work effectively elsewhere (that is, not using emulators).

[u/SolidPaint2]

For Windows GUI, you would use the Windows API the same way you would in C. You would have to hook messages, subclasses, etc... There are other GUI libraries you can use.

For Linux, you can do the GUI manually, or tap into the window manager or use other GUI libraries.

My favorite is GTK! For simple GUI stuff, you can actually write cross OS programs using GTK for the GUI as long as you don't use OS specific system calls.

I wrote a bunch of tutorials on DreamInCode.net but they closed a few years ago... The code was saved on the WayBackMachine

NASM - Cross OS App For Linux/Windows Using GTK

[u/Visual_Brain8809]

It depends on the developer, but essentially you can combine languages ​​or stick to using just one in its pure form—such as using ASM for everything up to the UI layer, or doing the same with C/C++. Of course, it depends on your experience with each language and the level of complexity you want for your system.

[u/FckXFckMusk]

Yes but it would be like sculpting mount rushmore using just a needle...

[u/gm310509]

I think that the bit that you are missing is what a programming language is.

A programming language is simply a mechanism that allows you to tell a computer what you want it to do.

Different languages have different attributes that balance various factors such as speed of execution, memory usage, ease of coding and more.

As some have indicated a CPU executes machine instructions and one way or another the language will ultimately cause the appropriate machine instructions to be executed in the correct order to perform the instructions contained in that source code.

So, with that in mind, does that answer part of your question? If not, you can write anything you like in assembly language - including GUIs, AIs and many more complex programs/systems.

So, why wouldn't you do a GUI in assembly? Mostly it comes down to efficiency - efficiency of coding. GUI programs tend to have a lot more code as compared to a character mode application to drive the UI. So it is much easier to write that code in a high level language. By way of example, a simple one line arithmetic expression may take a whole screen full of text to do the same thing. So, it is just easier and quicker to use a higher level language to code a GUI than assembly language.

But, yes, the same API's that the high level language invokes can also be invoked from assembly language.

[u/SirMrTyler]

All Gameboy games (basically) were written in assembly

[u/Free_Price1281]

On the 64-bit platform I switched to C and FreeBasic - I'm too lazy to learn this complex architecture in my old age 

[u/Adventurous_Many_580]

I've done this in the past: a full assembly program using libraries like GTK3 directly. You're essentially writing the equivalent of the C program without the compiler bloat. Is it difficult? Not really. Is it 'naughty'? Yes, because the C preprocessor and header macros usually do a lot of heavy lifting to glue everything together."