miniLD #45 – Low-level jam!

Posted by (twitter: @Sosowski)
September 12th, 2013 8:36 am

I would like this miniLD to have an educational value, because fun is overrated! Actually, that’s not true! I do want you to have fun, so if any of the rules mentioned below should cause problems and make this glorious event no-fun for you, feel free to screw rules and do whatever the hell you want!


I’m proud to introduce the Low-Level Jam!

[ View | Submit ]

Many developers are using flash and Unity and Love and Python and Java and Ruby and Twine and Game Maker. The point of this jam is to increase understanding of how computers work while executing your game code and have fun and learn in the process. I would like you to create a game using a programming language or tool that does compile into a machine language, meaning that stuff that you write and create is not being interpreted by a third-party script interpreter (like it happens in Java, Flash, Unity, etc) but translates directly into instructions that the CPU will execute in order you have written them.

Native games are significantly trickier to create, thus I would like to ask you not to aim to high! You can make Pong or Space Invaders or Tetris and still be able to reiterate on that adding something innovative. It is possible to make a platformer in Flash in 48h and it is possible to make an FPS in Unity in 48h, but that is certainly not the case for native programming, so keep that in mind!

tl;dr and more

– Make a game in a native environment that compiles into machine code, use C, C++ or assembly language (you can use fortran or cobol or pascal too, but please do not do that)
Do not use: C#, Mono, Python, Java, JS, HTML5, Unity, Love, Game Maker, Haxe, Ruby, Kink’n’Play, MMF, Flex, Basic, llvm, Lua etc.
Fail, but learn
– You can make your game for a retro computer/console if that’s what you prefer, and in fact, it will be much easier to achieve this and take out knowledge on how computers work out of that
– The point of the game is to learn how the computer works down there inside, beyond what you can see and to have fun.
– If you don’t like that, just make a game, I don’t care
– If you need more time, use more time

156 Responses to “miniLD #45 – Low-level jam!”

  1. Sillyapple says:

    Batch is the only Low-level coding language i know so… batch it is. 😐

  2. Sillyapple says:

    What time is this starting?

  3. JNyknn says:

    Well, maybe I could make a little game using C++, because I’m already using that language (I made my LD 27 entry with C++). If I find enough time, of course.

  4. Optimus6128 says:

    I think I will do something simple on a 486 DOS machine here with OpenWatcom installed, C++ VGA software rendering. Though, I am a little bit pressed with other retro deadlines, should normally be working on a delayed CPC demo preview in two weeks, yet all I think is about this compo which is more fun. Maybe I’ll plan a little bit by tomorrow and prepare the framework but mostly work on the weekend with this.

    • rxi says:

      I spent some time this weekend getting used to C development in DOS and writing what I suppose I will use as base code. I’ll be aiming for much the same target platform as you — The 486 / Pentium 1 sort of region — though I don’t have the real hardware to test on and have to use emulation instead. I’m using TurboC 2.0 which is comically old (1988).

      I look forward to seeing what you end up with!

      • Optimus6128 says:

        Well, great! I am curious to see your too. And most of the entries in this minicompo, especially if they are not like over 1000 :)

        I just started yesterday porting my triangle rasterizer. Still I am going for 2d gameplay, but using simple flat 3d polygon objects for sprites and maybe a fast background with a trick. I’ll see how it goes. And I want to try to keep full frame rate on this 486dx33 laptop with not very fast graphics card. Is it a hard task? We will see. If everything fails, I will still plan to release what I have done so far somewhere..

        • rxi says:

          Oh wow. Now I’m really excited to see the end result — I wrote some simple blitting code and I haven’t even bothered with implementing scaling / rotation, so triangle rasterisation sounds a lot cooler in comparison.

          I wrote a little test game on Sunday and have been adding little bits to it over the week, would you be able to give it a run on your 486 and let me know how smooth it plays (or if it plays at all)? I’ve just been using emulation, but it’d be great to see how it runs on real hardware, if you don’t mind:

          • Optimus6128 says:

            I just tried it, first in dosbox. Runs quite well even with just 10000 cycles. Quite nice graphics. I like the starfield and menu.

            In my 486. First I got a stack overflow message. I rebooted and with F8 I try to get more convetional memory (622kb). It finally started. It’s slower than expected (based on the cycles on dosbox) but if I remove the starfield it’s better. A more important problem I noticed, after a while I get beeps and things slow down when I press keys. Well, after 3 seconds or so of holding a button. Actually, the keyboard buffer fills very fast and is never cleared if I release the keys. I think this wasn’t the case in dosbox, don’t know if it has something to do with my laptop. I don’t know if I will encounter it too in my game and since I never coded keyboard control in dos (because I was always more into demo coding). Might try later on a Pentium 1 DOS laptop I have.

            • rxi says:

              Oh aces. Thanks a bunch for trying it out! I’ve been using dosbox to develop it, but I was aware that the cycles couldn’t be equated to real hardware specs.

              I’m completely ignoring the keyboard buffer and instead handling the keyboard interrupt and calling the original ISR from my ISR. I assumed the buffer would just loop round and overwrite itself without any issue, so i didn’t bother to clear it until the program exits. I’ve added some code to change that now, so the keyboard buffer shouldn’t get filled.

              I’m also curious to whether the fact that I’ve set the PIT to 1000hz might be the reason for some slowness? It’s a higher frequency than I needed, but I figured it was fine if it wasn’t doing any harm and if it produced more precise timing.

              I’ve uploaded 2 versions, both of them should fix the keyboard buffer issue, and one of them has the PIT set to a lower frequency (TSLOWPIT.EXE). I also set a flag on the compiler to use hardware floats :


              Let me know if you try them out, you can hold F12 during gameplay to get a FPS read out. Thanks.

              • Optimus6128 says:

                This new version just goes into black screen and stays there. Don’t know why (booted with himem.sys, dos=high, as in the first try, 622kb conventional)

                I am late with my entry, writing parts of the 3d engine instead of coding the actual game (but at least this is a good boost, this engine was collecting dust for a long). I think I will move the code to my Pentium DOS laptop, to improve compiling times (another reason I was delayed) and try to make something from what I have. I see 4 entries only atm and would like to support this with something more.

    • BleuLlama says:

      That’s the direction I’m going in as well. Reviving those neurons, trying to remember how to do it all. I’ve started poking at some code, and have it switching to mode 13h (no Mode X for me… I’m not that advanced), displaying some stuff, drawing some lines (all written by me). I’m a bit stuck on BIOS keyboard calls though… I don’t want to use conio’s getch(),kbhit() routines.

      For what it’s worth, I’m doing mine in a Dosbox (windows and mac via Boxer), using DJGPP for the compiler. :)

  5. This is awesome! im in! but i dont know when to start .-. …. i guess i cant start now? and also im going to upload a youtube timelapse of me building this game in C++, is going to be a console game…. but the only problem is that i have a lot of school work.. :S but ill try (:

  6. This is awesome. A few weeks ago I was learning a little bit about assembly programming for the Commodore 64 (the first computer we owned back when I was a kid.) I know quite a bit about how the hardware works (it’s features, limitations, and, most importantly, what memory addresses do what.) Assembly didn’t seem too difficult to learn, but the CPU has some limitations that I think might make programming a game a little tricky … which makes it all the more fun!

    For anyone doing 6502 programming, here’s a neat little tick you should look up. Instead of just using RTS for returning from subroutines, use them to make jumps! Look it up. Since you cannot easily do something like function pointers, you can have a table of addresses. You push the address of where you want to go (minus 1) onto the stack and then call RTS. RTS pops that address from the stack and jumps to it. Normally this would be where the program should return from a subroutine, but in this case, it is a location you want the program to jump to instead.

  7. danpm says:

    I am in, already working on my entry. :)
    Is this all that I need to do to participate?

    gl; hf;

  8. nitrocrime says:

    Would C++ with SDL/OpenGL be allowed?

  9. SusanTheCat says:

    Can I make a server based game that players have to telnet into? I am thinking simple MUD like game.


  10. Diogo Muller says:

    Hmmm, I may try something simple. I’ll be a bit busy those days, but maybe I can squeeze something in my free time. Something with a text-based interface, maybe.

  11. Zelen3d says:

    I guess most people here will use C or C++? Maybe I’m wrong.

  12. ahm99 says:

    Sos, I am pretty sure most of us are wondering whether or not we can use things like SDL/OpenGL/etc. Could you make some edits to this post?

  13. ahm99 says:

    Oh, and I am not sure if I am participating, but I do have an idea if anyone would like to use it. Try to see if you can make a very very very very very very basic interpreter for your own language! You would probably need to take some more time, but the point is to learn how computers work, right?

  14. g_o says:

    Very nice idea!
    I used C++ in my 48 compo and everyone used unity and shit like that so I was like T_T no fair!

  15. supersammy7000 says:

    what time exactly does Submits end

  16. mildmojo says:

    The Go language ( would probably be grouped with Pascal, Fortran, COBOL, etc., huh? It’s a systems language that compiles to native binaries, but is influenced by modern languages and has a garbage collector.

  17. RobKat says:

    Whats the rule on third party libraries, can I use DirectX or OpenGL for graphics or do we need to write our own?

  18. bvanschooten says:

    Hmmm… Back in the day I’ve written 10s of thousands of lines of 68k, x86, Arm, 6502, Z80, and PIC machine code. I even wrote a 6502 Jit compiler in Arm machine code, and yes, it supported self-modifying code. I also stuck with C for quite awhile before moving to Java and other high level languages.

    But that doesn’t mean I can learn something from this miniLD :-) Recently I’ve been dabbling in OpenGL ES 2.0 shaders, and I’m lovin’ it. So maybe I should write a game in C and OpenGL 3+, travelling back to the heart of the machine to find what raw power lies there.

    It’s probably going to be a very simple game. I’m not going to burn a lot of midnight oil on this occasion. Maybe something with voxels or particles, and probably with only procedural shaders and no bitmaps.

  19. icefox says:

    LLVM is disallowed? But LLVM is just a compiler technology. Most widely applied to compiling… C and C++, which are pretty low-level languages. Heck, “Low Level” is in the name.

    • Stingray Polymathic says:

      In fact writing in straight LLVM IR would be pretty amusing to see, if not terribly practical. Similar to assembly, but not as CPU-dependent. Some arguments could be made that the LLVM type constraints are too “high-level” but they’re mostly a little lower than actual standardized C (as opposed to the somewhat grungy C that is often used). It feels like the OP just thought “this stuff is ‘low-level’, so we’ll fling everything else into the ‘not’ pool”, which is a bit unfortunate.

      On a more positive note, I think a machine-compiling Forth would be a great candidate for a combination of sharp edges, hardware-y access, and education, while also having a fairly high abstraction ceiling, though the time-to-first-window-open could be a problem unless one ran it emulated (a Forth for DOS accessing a VESA framebuffer, say). A threaded Forth would be “more traditional” in some ways despite clobbering the “compiles to machine code” constraint which I think is really supposed to be a proxy for “sharp edges, direct access to things, and very little direct runtime support”… does a tiny Forth kernel with a very high power-to-weight ratio count as too much runtime? It’s an interesting edge case.

  20. GarrickWinter says:

    Oh wow, I’d love to do this. Gotta think of something quick to whip up though, homework is piling up too.

  21. JAH2488 says:

    Is D lang or Obj-C or Rust low level enough? They’re not C, but they aren’t Java either.

  22. timtipgames says:

    I did just configure visual studio for horde3d and polycode (not sure which to use yet). I will probably take this as an excuse to sink some time into some 3D programming (usually only doing 2D). Like the theme :)

  23. Nosgoroth says:

    C++ without an engine is how I roll anyway. OpenGL those textures into the screen, man.

  24. mackthehobbit says:

    Very tempted to make something for this, maybe even making something for the GBA 😀

  25. Got a puppy last weekend which is whittling away at my sanity too much to asm, but I think I can manage ‘just make a game’. 😉

  26. Uhh, so I seem to be trying to design an imaginary console. Write an emulator for it. Write an assembler so that I can write code for it. Write some games for it. All in straight C (obviously). I think I might be crazy.

  27. tomhunt says:

    J’accepte votre défi!

    I shall write a video game in C this weekend.

    an old friend of mine called Allegro.lib will be lending me a hand.

    the game will probably be really really simple and minimalist-like.

    it will be interesting to see what comes of this :)

  28. nuclear says:

    Awesome! I think I’ll give it a go and spend one or two days trying to hack something together. My idea, which seems to be popular enough looking at the comments here, is to fire up my DOS machine (p200mmx) and write a minmal 3D game for that. Good opportunity to optimize my rasterizer which has been gathering dust neglected in a corner of my filesystem.

  29. Gord10 says:

    Can we submit more than one game?

  30. Optimus6128 says:

    What time/GMT is the deadline tonight?

    I spent some time improving my engine instead of writing the actual game. Got into a lot of stupid bugs and didn’t work the whole day. But since I see there are only 4 entries so far and I love this compo, I’ll try to do my best for submitting something. I just hope to not miss the deadline :)

  31. plop says:

    Hmm, maybe it’s time to write some z80 assembly for my TI calc! Not sure if a lot are going to be able to play it though but .. oh well.

  32. plop says:

    I need to know when the submission closes because I didn’t see this before now!

  33. rollman says:

    I really like this low level idea for a compo. Unfortunately I’m stuck in learning SDL, so I won’t make any game on time. Can we post our games later, or we shouldn’t after 22nd? I never started in such an event.

  34. nuclear says:

    I just submitted my entry. I can’t see it in the browse entries list though. So was there a deadline after all?

  35. superfrog says:

    the dead line was 22 of sectember ?

  36. GarrickWinter says:

    Hey! Just curious, when will submissions be closing? Is the deadline officially past yet?

  37. S0lll0s says:

    And I just had to miss it -.-

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]