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

Here’s my base code. It’s what I ended up with after some Ludum Dare jam entry (yes, that one that had nothing to do with the theme but was supposed to have something to do with bombing buildings), a couple of One Hour Game Jams and a few other experiments. It has a rather hacky OpenGL wrapper, and by hacky I mean I have to fake a depth buffer on a console that does not have a depth buffer. Let that sink in. (Or not, as the solution for that is rather elegant. Texture warping, on the other hand, still requires you to subdivide polygons in a suitable fashion.)

It hasn’t been touched in a while, and since I last touched the code my hard drive started crapping out and bad sectoring so I decided to get a new hard drive and chuck CRUX Linux on (goodbye for now FreeBSD, stay classy, don’t do systemd, and don’t do meth) and then copy all my stuff over. I’ve heard Void Linux is the way to go these days but until this hard drive craps out (It’s a Seagate 1TB SSHD Hybrid) I’ll have to struggle some more. Oh well, at least the graphics drivers no longer get wedged at random points and require a reboot, and no longer do I get garbage spewing everywhere on my screen.

Here’s what happens when I try to compile it with GCC 5.3.0:


(EDIT: what WOULD be pictured if the site wasn’t broken: a demonstration of the text not working properly – turns out it’s using the wrong CLUT, AKA palette. the font is completely fine.)

Mostly working but the text is buggered. No idea why, as the font is in VRAM. Everything else appears to be functional, although I’m not sure if this thing has the SPU RAM loading screen, and it’s kinda hard to test if the controller inputs work when you need to read the font to see what the hell is actually going on.

I blame $gp. That thing always bites you in the arse when you’re trying to just get things working.

Timewise I may be a bit too restricted to actually get something working. We’ll see.

My setup:

  • Editor: VIM
  • Graphics: pixra and/or GIMP
  • Sound: SunVox
  • Music: SchismTracker (yep, I’m still using that s3m player!)
  • Engine: Base code as linked above
  • Libraries: Base code, newlib, f3m (in base code)
  • Physics: None. What, you think I’d bring pre-made physics to a Ludum Dare?

I actually have a game idea too, so I may actually end up with something. We can’t not have a PS1 entry, dammit!

Code base forked!

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


I’ll need to make some decent meshes.

Anyway, codebase is here: https://github.com/fanzyflani/mld62

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: https://github.com/iamgreaser/psx-chain

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: https://github.com/iamgreaser/cuckvid

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: https://gist.github.com/iamgreaser/967070e7f02108b87003

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.

http://segfault.net.nz/~greaser/ld28/ld28-gm-song1.it (~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.

[cache: storing page]