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!

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

This entry was posted
on Thursday, September 12th, 2013 at 8:36 am and is filed under LD #27.
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response. Pinging is currently not allowed.

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.

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).

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..

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:

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.

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 :

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.

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.

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 (:

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.

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?

The Go language (http://golang.org/) 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.

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.

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.

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

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.

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.

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

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.