Hyperresolution Neptunia 0.1 alpha release

Today I looked into the rendering resolution issue for Hyperdimension Neptunia Re;Birth 1, which was recently released on Steam.

What’s interesting about this release is that it uses OpenGL, which is really rare in Windows games these days. It’s the first Japanese port I’ve seen which uses it. Therefore I was interested in having a look, as I’d never done any interception work on an OpenGL game before.

The good news is that the free software situation is much better for OpenGL than it is for DirectX (and particularly, than it was for DIrectX before I started DSFix and later GeDoSaTo :P), with multiple options available for handling the mechanics of interception/logging etc. After some googling I chose glintercept to base this work on, and I haven’t regretted this choice at all. The codebase seems a bit heavy at a first glance, but you only really need to deal with the plugin interface, which seems solid from what I’ve tried.

As for the game itself, after acclimating myself to OpenGL it was basically the same process as always: find buffer creation calls, intercept, try, find stuff that breaks, and iterate until done. In this particular case HUD and minmap rendering were the easiest to fix of any game I’ve worked on so far, and it took less than an hour for those after I got basic rendering at higher resolutions working.

Anyway, here is the download.

And if you want to contribute to my continuing struggle for more pixels, you can do so here (this link includes a reference that lets me know you are donating because of Neptunia in particular).



DSFix 2.4

This might in fact be the final version of DSfix. Why? Because Nwks (the original author of the 60 FPS unlocker!) came back and did something which I had considered ideal for a long time now: make it scan for the addresses it needs to patch instead of hard-coding them.

What does this mean for you as a DSfix user? Hopefully, that when/if the game is updated in the future, DSfix, including the FPS unlocking, will still simply work. The only reason this would fail is if the binary code right around the places which need to be patched were to change, which seems unlikely for the smaller patches which can be expected at this point.

Also, since it seems like some hosts are still taking down DSfix for no discernible reason, here are 3 separate links to it:

Have fun!

Just to reiterate: this version will not work with the GFWL version of the game, only with the beta Steamworks version (which will replace it at some point).

Graveyard of Forgotten Projects (Part 1)

I’ve wanted to do this for a very long time, at least since early 2014, and one of my resolutions for 2015 was to finally get started. This series (hopefully) of blog posts will gather and shortly describe some previously unreleased and forgotten projects I’ve worked on over the past decade and a half, starting from 2000. These projects will mostly be games (or game ideas, rather) but also include a few applications. This is by no means a complete listing, I’m still skipping over the vast majority of unfinished ideas and half-baked projects, but I’m trying to include everything which worked to an extent or has some interesting features.

The primary purpose of this is to serve as an archive for myself, because, as you will notice when I go through the list, I’ve already lost a lot of somewhat interesting stuff and would rather not have that happen again.

Perhaps one thing or another might also be useful to someone else, but I obviously won’t troubleshoot code I wrote more than a decade ago and haven’t touched since then! And, just to make that clear, it’s also obviously not indicative of my current skills. That said, let’s start! I’ll try to do this chronologically.


fastimg_mainThis early 2000 (with some 2001 updates) – so, when I was in the middle of high school – project was a Delphi-based GUI tool for quickly generating pure HTML image galleries, automatically resizing images and generating thumbnails. Shout outs to Delphi for being by far the most convenient tool for generating GUI applications back in those days!

Thanks to the wonders of Windows binary compatibility and static linking, the executable I found which was compiled on 2001-11-05 simply launches and works on my current Windows 7 system. Seriously, if nothing else Microsoft deserves major kudos for making that possible, it must be absolutely maddening to work on.

fastimg_prefsYou can see the preferences dialog above. Anyway, the tool has obviously been made completely obsolete by technical progress, but it’s fun to see that it still works. Here’s a zip archive containing the sources (and holy crap, are they ever terrifying!) and binary. I don’t recommend looking at it ;)

Another Delphi application I remember writing around that time which seems to be completely lost now was an advanced Windows Registry search/replace/editing tool (which was also much faster than regedit). A bit like Advanced Regedit, but not as fully featured.

Tetris Attack Puzzle Mode & Hitori Solvers

Around 2001 or 2002 or so I wrote a few Ruby scripts to solve puzzles. The first one solves Tetris Attack puzzle mode levels, outputting the optimal turn sequence. It’s command line only, so no screenshots to show off here.

hitoriThe other one helps solving Hitori puzzles, and even visualizes them, as you can see above. Here’s an archive with both scripts, though note that they require a very outdated Ruby version to get working – and are terrible in terms of code quality of course.


I wrote this Tetris clone around the end of August 2002 while it was raining for a few days when I was on vacation with my family in Italy (“Urlaub” is German for “vacation”, as you can see with e.g. GeDoSaTo my naming skills are still just as amazing as they were back then).

It uses Ruby 1.8 and RUDL (a Ruby SDL layer), and as such is almost impossible to get running on modern systems. I managed to create a packaged binary which should include the right versions of the interpreter and all the libraries, but I’m very unsure that it will actually work anywhere.

There are a few neat things about this one, considering I spent all of 2 or 3 days over 12 years ago writing it:

  • It supports an arbitrary number of cooperative players — or, well, as many as you can manage to find keyboard keys for :P – and arbitrarily sized levels.
  • It saves/loads settings as YAML files. Considering YAML history, that was some pretty damn early adoption of a technology which is still around and which I still like.
  • The code isn’t completely terrible even if I look at it now (which makes sense since it’s very small and written in a very short amount of time, makes it hard to accumulate cruft).
  • It features the Gameboy Tetris theme performed a capella by my sister as background music ;)

Here’s the archive in case you are interested. As I said above, you probably won’t be able to get it to work, and I’m obviously not going to support it.


This was my first 3D game project which got further than just displaying a model on screen. It was also my first larger-scale C++ (as opposed to C) project, and it’s as terrible code-wise as you might expect from that description. I started on it in 2002 and worked on it for a few weeks, and also came back to it for a few days in 2003 — at least that’s what it looks like from the file timestamps.

The game uses the Ogre3D engine, ODE for physics and OPCODE for collision detection. All in some very specific and utterly outdated version, and in a Visual Studio .NET (that is, 7) project and as such, I didn’t even try to compile it. I also made some “art” for it, using Wings3D (still a very neat, free polygon/subdivision modelling tool IMHO) and Rhinoceros, which was available at the university I had just started at.

The idea was to create a game which plays a bit like Uniball, but completely in 3D. That is, there are two teams of players, a ball, and two goals, and they can shoot the ball either to pass them between each other or at the goal, while being affected by recoil and slowdown while carrying it. I was going to go for an “energy” ball in this version, as it would have made a bit more sense in 3D when quickly “picking it up” or taking it off another player.

As I said earlier, it’s nearly impossible to get to compile (never mind running!) on modern systems, and I don’t have any screenshots anymore, so sadly some model shots must suffice:

To the left you see a ship: the semi-round thing in the front carried the energy ball if it had one, and I was going to change the blue colored stripes on the back depending on team assignments – of course I now realize that this wouldn’t have been nearly visible enough. And that the model is utter crap ;). To the right is a level. The game would take place inside the ellipsoid, with the ball bouncing off both its outer walls and the obstacles within, allowing for some skillful ricochet play. Note that a ship was small enough for two of them to easily fit through each of the holes in the central obstacle.

I got as far as loading everything, getting physics/collision for the level, ball and ships working, as well as making a single craft playable and capable of picking up and shooting the ball, before losing interest. I remember that when I wanted to get back into the project later on (in early 2003 I think) I tried upgrading it to newer versions of all the libraries used, hit some roadblocks and dropped it again.


I picked up the Eball3D idea once more in late 2003 and 2004, but realized that full 3D gameplay would simply be too complex to be fun (or even playable really). Especially since much of the enjoyment in Uniball came from pulling off precise team moves and passes.

As such, the new plan was to go with an essentially 2D level structure, but with some elevation, jumps and perhaps multiple stacked planes. However, I got distracted with developing more and more intricate revisions of the level editor with C# and never even got to a state where you could do anything in-game (unlike Eball3D).

On the left you can see a screenshot of the second unfinished revision of the UBC level editor, and on the right the initial model for the player crafts. The energy ball would have floated in the central space if carried — as you can see, the shape is much simpler (and probably more elegant) than in Eball3D, built for “2.5D” gameplay,  and would also have allowed for much faster and more exact collision detection. So I guess I learned something at least.


That’s it for today, as I already spent around 5 hours crawling through backups and backups of backups as well as trying to get completely outdated software working to an extent that will allow me to at least take screenshots. Next time I’ll have some more modern projects to show, which might be interesting from more than just a historical perspective.