Ludum Dare 35
Coming April 15th-18th Weekend

Ludum Dare 34 Results

About GreaseMonkey


GreaseMonkey's Trophies

The "Knows his tech" Award
Awarded by sythra4
on November 22, 2012
Selected Hard mode
Awarded by Jwatt
on August 21, 2012
The Autotracker Award
Awarded by asiekierka
on December 15, 2010

GreaseMonkey's Archive

Code base forked!

Posted by
Sunday, September 20th, 2015 5:56 pm


I’ll need to make some decent meshes.

Anyway, codebase is here:

If you actually want to build that, you may wish to point the s3m data to the s3m file in the dat directory – I’m just casually listening to other things in my collection while I nut things out. (Yes, it’s a rather dodgy conversion of a modified version of the .it file.)

Base code declaration

Posted by
Thursday, August 20th, 2015 11:28 pm

This is the current state of my base code:

It works in Mednafen and PCSX-Reloaded. You may need to tweak the paths (and potentially the linker script) to suit your own cross-compiler – I’m using binutils 2.22, gcc 4.7.0, and newlib 2.2.0-1.

Music playback and text printing works, and I have a working libc.

Well, that’s that crap out of the way.

Which platform do I taaaaaaeeeeeek?

Posted by
Wednesday, August 19th, 2015 10:36 pm

I’m probably in.

Toolkit will be VIM, GIMP and/or pixra, SchismTracker, f3m, and either gcc-arm or clang.

Target platform will be one of these:

  • GBA: I’m comfortable with this.
  • DS: I have a toolchain, but it’s incomplete and I’m not sure how VRAM behaves on this. But my toolchain is complete enough to draw a spinning cube.
  • PSX: I have a rather fragile toolchain which uses clang + binutils-mips + some glue scripts written in Python, and it requires me to mess with the -O flag until the damn thing behaves. I’m mostly keen on giving this a crack, though, even though it’s harder to do 3D on it than the DS (there’s no Z buffer).

DS and PSX both have hardware sound mixing (16 and 24 channels respectively), so ideally I’d have to modify f3m to take advantage of this – while I could do the mixing on the CPU, it would be a bit silly. However, while the DS can accept raw 8-bit sound data, for the PSX there’s a snag: Samples are compressed using some form of ADPCM not too dissimilar to BRR but rather dissimilar to IMA ADPCM.

This form of ADPCM requires that loops align to a 28-sample boundary. Dammit. I’d probably have to apply some resampling to ensure that this is the case. Not sure whether I should bastardise the s3m format or implement the compressor in the game code itself – as I like the music to be easily rippable I’d probably go for the latter… and probably just not use loops.

Or I could just softmix it and bang it into the streaming audio buffers. Not sure how to do that though.

As for “filesystem” access, I don’t quite have sufficient tools for generating a bin/toc pair (ultimately I’d need to generate the P/Q subchannels properly), and even if I did have suitable tools I don’t have code for accessing the filesystem, so I’d be stuck with a PS-X EXE file. This will limit me to the 2MB of RAM available. Seeing as I’ve managed to do entries for 32KB ROM cartridges on a system with 8KB of RAM, this shouldn’t be an issue.

I’d also have to deal with inputs. The DS shouldn’t be an issue, as long as I just simply don’t bother with the touchscreen. The PSX handles its controllers via some serial protocol which I will need to mess around with. Shouldn’t be too hard though.

Finally, I need to get vblank timing working. As I don’t have working interrupt code yet, this will be a tad problematic.

Ultimately though, even with just video and input I should be all good.

cuckvid released!

Posted by
Friday, April 17th, 2015 3:44 am

Because other codecs take too many clocks.

But they also tend to look better


Source code is here:

Could be useful for people making games for weird platforms. It should have enough grunt to run nicely on a Raspberry Pi for 640×480 @ 30fps – who knows. (But then you’d ultimately want to use OpenMAX and the H.264 decoder.)

Anyway, now that I’ve declared this code I might end up using it. Or maybe not. Do I really need video? I have a program loader and hardware sprite transforms at my disposal. Who knows.

Live Free Or I’m In

Posted by
Wednesday, April 15th, 2015 4:44 am



I’m in.

I’ll be making a game for the Game Boy Advance.

It’s a piece of hardware that’s capable of doing stuff like THIS:

WIP shot of an Armagetron Advance demakeLD32 Warmup Indev shotMiniLD #58 entry

I also proved it was possible to poorly encode the entirety of Too Many Cooks @ the full 24fps in under 32MB. (It can only decode 40% of a frame every vblank.)

Oh, and the usual list:

  • Languages: C, Python (for table generation and format wrangling and crap like that)
  • Libraries: f3m, libgcc for embedded ARM (if I need a libc function I’ll roll it myself)
  • Music: SchismTracker, Scream Tracker 3, possibly SunVox
  • Samples: Audacity, SunVox
  • Graphics: pixra, GIMP

There’s a chance I’ll be using my ADPCM decoder, which is here:

I doubt I’ll use the mode7 engine in there, though.

But anyway, as they say, it’s on like Sonic the Hedgehog.


Mini LD #58 Theme Interpretation

Posted by
Friday, March 20th, 2015 2:19 pm


I cannot be shafted writing an AI, and I really don’t feel like redoing Breakout.

What Pinball has:

  • Balls! Yes, that’s right, you can have several at once because just about everything that Williams did has some form of multiball! [citation needed]
  • Bats! Except they’re nailed to the board and can only rotate into one of two configurations.
  • Ability to lose!
  • Score!

What Pinball doesn’t have:

  • Ability to win!

What my platform has:

  • Sprite rotation!
  • “Playfield” rotation!
  • Scanline DMA to hardware registers!

Main thing about this is unlike making Pong (which I pulled off on the Atari 2600 once… only to have someone tell me that the picture rolls on real hardware), this will be an artistic challenge.

But enough procrastination, time to get some *.tga making and loading action happening!

(What? I have 16MB of ROM space to kill…)

Oh, and of course I had to make some music first.

I’m in with a vengeance

Posted by
Wednesday, March 18th, 2015 11:08 pm

(Nobody used that title? SHAME ON YOU.)

No, this is not my third LD, it’s probably about my 6th although that’s mostly an estimate.

I’ll be warming up and refining my tools during MiniLD #58, so I can then get ready to beat everyone’s arses to a pulp in LD #32. Namely, I have a nice S3M player which needs work in a few places.

Speaking of MiniLD, sorry for missing MiniLD #57, I was working on another game at the time.

So here’s my setup:

  • Languages: C, dash of ARM assembly (for bootstrapping), Python (for conversion scripts and whatnot)
  • Libraries: f3m (will be updating this as I go)
  • Editor: VIM
  • Graphics: pixra, GIMP
  • Music: Schism Tracker, Scream Tracker 3
  • Sound: Audacity

And that pretty much concludes my setup, other than the fact that I haven’t mentioned what my target platform is, so I’ll leave that up to you to guess, although if you’ve been paying attention in #ludumdare you’ll know already.

Might be in?

Posted by
Tuesday, December 2nd, 2014 1:56 am

If I’m doing this there’s a chance I’ll be teaming up with someone. And to be blunt I’m not sure what we’ll be using.

Here’s my bag of tricks anyway. It might be something completely different, but there’s a fair chance just about everything I use will be here…

  • Languages: C, Python, Lua, C++, JavaScript, Ruby, whatever MegaZeux uses, maybe even GML (Game Maker 4.2a)
  • Libraries: Allegro 4 & 5, SDL 1.2 & 2, OpenGL + GLEW, libsackit, ezjack
  • Music: SunVox, SchismTracker, various converters, custom playroutines
  • Sound: Audacity, SunVox
  • Graphics: pixra, GIMP, Blender, code-generated stuff, converters I pull out of my arse
  • Level editor: Probably just VIM
  • Networking: ENet

No, I’m probably not going to use assembly this time.

I’m considering making a 3D game with red-cyan anaglyph support. This still leaves things pretty open-ended.

It’ll most likely be C++, SDL, OpenGL+GLEW, and the rest is to be decided.

Change of plan.

Posted by
Thursday, August 21st, 2014 6:29 pm

Y’know how I said I was going to be doing the compo using C + Allegro?

Change of plan. I’ll be jamming with someone and using PyGame.

Will probably be laying out the foundations of the engine as well as making seriously smooth sounds and gorgeously grotesque craphics.

…once I’ve got pygame working, which is currently depending on numpy, which seems to be missing a few files.

.i mi gasnu lo nu banli betri

Posted by
Sunday, August 17th, 2014 5:37 pm

(en: “I am causing a great disaster”)

Well, I needed something more interesting than just “I’m in!”, so I thought I’d have a bit of fun with that. I think “.i mi zvati” would be the best translation.

About 4 years ago, LD #18 happened, and I participated in my first Ludum Dare. Somehow I ended up in 1st place for audio. I made the game using Java + Swing… on FreeBSD. No, that’s not the name of a Linux distro. It’s actually a different OS (which ends up sharing about 90% of the average Linux userland anyway).

This time around, I’m using FreeBSD again. But I’ll be using something I used before I ever touched Java. That’s right, Allegro 4. I used that for LD #21 (“Escape”), and it was quite frankly a breeze to work with. That time around I used dumb to play my music. This time I’ll use sackit.

So, here’s the lowdown.

  • IDE: VIM
  • Languages: C, possibly Lua (but probably not)
  • Compilers: Clang (native FreeBSD), MinGW (Windows port), GCC (Linux + Raspi ports)
  • Libraries: Allegro 4, sackit
  • Audio: Audacity, SunVox, SchismTracker

I’ll probably be using Allegro 4 for what it’s good for, rather than writing that hackjob partial Sega Master System emulator I did in LD #18 (Never. Again.), so we’re talking maybe 2D vector graphics and stuff like that.

So yeah, with all that crap said, I’m in!

World editor!

Posted by
Sunday, December 15th, 2013 3:35 pm

Currently there’s only 3 terrain types and they’re graphically boring right now.

You rock

But I can make them look more interesting.

OK, so the collision detection is kinda shit and there’s no enemies yet. I might as well focus on adding them.

World editor now working sort of

Posted by
Saturday, December 14th, 2013 11:47 pm

Let’s just leave a screenshot. (Also, all the screaming about bugs in the OpenGL implementation? They were all my fault. I think.)


I can breathe.

Posted by
Saturday, December 14th, 2013 6:15 pm

…ok, I still don’t have an actual game yet. But the character can breathe.


…I need to sort my priorities out.

Anyway, little tech demo – move the mouse around and the eyes will follow.

Working on some music.

Posted by
Saturday, December 14th, 2013 3:06 pm

Whipped up some samples in SunVox and started work on a simple loop. The samples pack quite well.

It’s just the “chorus” section, so to speak. The bass didn’t come out very bassy though so I’ll need to chuck in some subbass, but it’s an FM bass so it’s still inherently awesome. (~96KB)

And my battery is running low. Should be home soon.

JACK support!

Posted by
Saturday, December 14th, 2013 2:12 pm

I’ve added JACK support to my game, because SDL2 doesn’t have a JACK driver and Fuck You PulseAudio.

It acts as a wrapper around the SDL audio callback I wrote, and calls it whenever it needs a new buffer.

Took under an hour.

I’m in a van.

Text boxes! (6h in)

Posted by
Saturday, December 14th, 2013 1:04 am

They’re even a self-contained “class”. And they’re rounded, too!

Certainly not!

I think I’ll take a break from this now.

[cache: storing page]