# graphical interface when using assembly language

I want to learn a framework to use in assembly. I know that's not possible without learning the framework in C first. So I'm thinking of learning SDL in C and then teach myself how to interpret the program and run it as assembly language code. Then I will have a window and some graphics routines to display the game while using assembly to code everything in. I need to spend some time learning SDL and then some more time learning how to code all those statements using assembly while calling C functions and knowing what registers returned calls use and what they leave etc.

My question is, is this a good way to go or is there something better to get a graphical window display using assembly language?

• You seriously want to use Assembly? It would be far easier to use... anything else. If this is for learning assembly, don't make a game. – doppelgreener Sep 14 '12 at 7:02
• Im already good with assembly, i just want to use a graphics window of some sort to show the output. I forgot to say i use linux so gui frameworks are probably all ive got to play with. – Hellbent Sep 14 '12 at 7:23
• Well if you're determined to use assembly... good luck! – doppelgreener Sep 14 '12 at 7:42
• What makes you think assembly language will help you in making a great game? Would you go about building a skyscraper with your bare hands? This isn't a real question as it stands, voting to close. – Laurent Couvidou Sep 14 '12 at 9:16
• @lorancou Whether or not using assembly to make a game is advisable, "How should I make a GUI in Assembly for a game?" is still a real and answerable question. – doppelgreener Sep 14 '12 at 9:55

## 4 Answers

I would recommend starting by looking at X11, since SDL runs on top of it for Linux. My guess is that SDL will call straight to X11 for window creation and management. It's the protocol you'll be implementing in any case.

If you get a window going in assembly, your graphics routines could look like anything, so SDL would merely be inspiration at that point.

Keep in mind that my answer is more theory than experience, since I think the idea is a bit insane (I wouldn't reimplement either SDL or X11). Also I wouldn't expect any portability, but if you know assembly you probably know about that.

Godspeed, sir.

• Good Thinking, although reinventing the wheel is probably not good practice. – Hellbent Sep 15 '12 at 8:46
• A bit confusing... Was the question "Are there any SDL-alike libraries in assembly language?" If such a library doesn't exist, you wouldn't be reinventing a wheel, but you would be reimplementing it in the language you chose. Furthermore, C is a framework that abstracts away assembly, so unless you have a hard requirement that prohibits its use, then wouldn't using assembly be reinventing the wheel almost by definition? – tugs Sep 16 '12 at 18:34

When building a GUI with assembly, you'll be working directly with the windowing system of the operating system you are compiling for. For Windows, that the Windows API. For Linux, X Window System (X11) is probably the most popular, though there are others.

My question is, is this a good way to go...

Learning SDL won't teach you anything about those APIs, since SDL essentially does all the window creation for you already (and then some). If your goal is a GUI in assembly, then you need to learn those APIs.

...or is there something better to get a graphical window display using assembly language?

If you want to go about this a bit more creatively (and depending on what your goals are), you could create your GUI with C and SDL. Then you could code all your logic in assembly and compile that to a handful of libraries (.dlls). At that point, you would be able to reference those libraries from your application and have the best of both worlds. This gets you a GUI rather quickly, which you can use as your output for your assembly libraries.

• Probably the best solution. A pity there isnt an assembly based library for linux. I know there is an assembly based OS that would be good. I might think about switching to that in the future as it has all the stuff for hard core assembly dudes and dudettes. – Hellbent Sep 15 '12 at 8:51
• @Hellbent, are you talking about MenuetOS? – Cypher Sep 15 '12 at 15:31

The only fun way I can think of getting display in assembly is by using the 13h mode.

• Thats from the good old days of DOS. I remember well the mode. The book that popularised that is called "Black Art of 3D Game Programming. by Andre LaMothe" If anyone wants to write their own 3D polygon video games in C then that is the book to get inspiration from. Although dos is gone you can use the theory relating to actual 3D from it. There is lots that can still be used for modern programming that can run seriously fast as well. – Hellbent Sep 15 '12 at 8:49

A good match for graphical output using assembly would be the linux framebuffer.

I would write some C code to do the opening of /dev/fb0 and set up the memory map. But once you have done that, you can pass the memory address of your framebuffer to your assembly code.

The linux framebuffer is just a big array of pixels, and you write to them directly. Maybe skip fonts for now, and use assembly to draw some geometric shapes, maybe some graphs.

There is this short guide.

But if you google, you can probably find more complete guides to the linux framebuffer.

I think you need to run a lfb app when X11 is not active. So just quit your display manager. Typically with /etc/init.d/lightdm stop or /etc/init.d/gmd3 stop

You may need some extra privileges to open /dev/fb0 though. Run as root, or give your user account access to the 'video' group.

Lastly, I want to note that there is something else than assembly and C, which sets somewhere between them, and is called intrinsics.

The nice thing about intrinsics is that you can program at a level, almost as low as assembly, but you don't have to think about registers at all. You can just use C variables, and have the compiler do the job of mapping them to registers.

Intrinsics, unlike C, will give you direct access to the CPU's SIMD operations, which means that you can process 4 (SSE), 8 (AVX) or 16 (AVX512) integer/float values in a single operation. They are the most powerful instructions on your CPU.