Thread: asm game

Originally Posted by Bubba

Which will lead you off on huge excursion into the weeds. You really don't want to try to program your own small OS, boot sector, or file system just to make a game in assembly. Booting into protected mode is not all that simple and requires that you set up the GDT, LDT, and IDT. I think you can forego the LDT but it's been so long I just don't know. Matsp would definitely be your source for this but I really feel that your 'game' idea will soon get swallowed by the enormous task of getting your own type of OS running.

I completely agree, this is not the way to learn game programming assembler. For completeness, here is a brief explanation of what you must do:

You MUST set up a minimal GDT (two entries, one Code Segment and one Data Segment - although if you want to make a "safer" OS, you may want to set up a user-mode variant of both code and data segment as well, and most OS's use some further segments for special purposes).

You also MUST have an IDT. To begin with, you can get away with setting up the first 18 or so entries to point to a "fault handler" that prints a unique error message for each fault code, so that you can figure out what went wrong (and a lot of things can and will go wrong in the startup before you get it right, I promise). Later on, you will need to have interrupt vectors for any of the hardware you are using, and set up the interrupt controller (APIC or 8259) to match your vectors.

You probably will want to set up a periodic timer, so that you can use some form of "delay/sleep" functionality.

Once this is in place, you can get on with your actual code.

--
Mats

Originally Posted by herWter

How about I ran my game on the linux kernel in kernel mode? Would linux then allow me to access the screen directly?

Rather silly idea. First of all, you'd have to make darn sure that you lock everything down so that no other processor possibly accesses the screen memory - that would pretty much make Linux a single-tasking, single-user OS (and would be pretty difficult to ensure) - otherwise, some other process will write to the screen buffer, and all your graphics gets garbled.

And as Bubba said, you give graphics commands to modern graphics processors through a buffer. Exactly how that works depends on the driver, but in general, you pass a list of graphics commands to the processor, and it takes those commands and performs them. There may be a single copy involved since executing graphics commands from the user-mode memory would allow the user-mode program to manipulate the graphics commands after they have been issued, which could lead to interesting race-conditions and possibly also security holes. But copying the commands for some drawing is still a whole lot less than copying each pixel and any other work involved with getting the pixels onto the screen (e.g. blending background with foreground pixels, etc).

If you insist, you can still write nearly all of it in assembler - but it's hard work, and for most parts of the code, you will not see any difference in performance or code-size, since the compiler will do an adequate job.

--
Mats

As long as you know HOW, assembler can call any other language's libraries. How else would a compiled C program work? The compiler generates machine code, which is the ultimate result of assembler too, so you should be able to push the right arguments on the stack in the right order, and perform a call. Depending on the calling convention for that particular library/language, you may need to clean up the stack after the call - or the calling function does it for you.

--
Mats