DSFix 2.4

This might in act 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!

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

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.

Urlaubtris

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.

Eball3D

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.

UBC

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.

GeDoSaTo 0.16 Christmas Release

As a holiday special so to speak, today I’m releasing GeDoSaTo 0.16.

The TL;DR version of the updates is this:

  • Fixed a number of memory leaks which caused instability in pretty much all games. In some (most?) it was unnoticeable, but in Final Fantasy 13 and 13-2 crashes could occur as early as after 15 minutes of playtime.
    All of that should be fixed now.
  • As a result of that fix, if you are looking to find a PSHash or VSHash for a game (and only then!) you should enable the new trackShaders option.
  • I’ve also improved keybinding modifier support and borderless fullscreen support.

You can get the latest version with the installer provided here. And, as always, you can donate to support GeDoSaTo development here.

Happy holidays everyone!

 

The long version for those who are interested:

I’ve been chasing the sporadic crashing issues on and off since the release of FF13. For the longest while, I assumed that they had to be related to screenshot taking, as that was when they first and most often occured. I tried many things related to that (pre-allocating buffers, using the library in a way that causes no additional memory allocations, …) but it turns out that this was, more or less, useless, as I was looking in the entirely wrong place.

When I finally realized that, despite the issue only appearing in the FFs, it had to be a general memory leak in all of GeDoSaTo, I manually checked every single instance of new in the code for the corresponding delete . This was less work than it sounds since I try to write modern C++ where you very rarely call those directly. Over the course of this, I found a few issues, specifically  operator delete  being called instead of operator delete [] . However, since those were arrays of POD types, while bad practice and undefined behavior it wasn’t the issue I was looking for either.

Afterwards, I made a few abortive attempts to use existing leak checking tools, but like many tools designed to make programmer’s lives easier they are really hard or impossible to apply in the — very unusual, admittedly — interception use case of GeDoSaTo. It would certainly be a good idea to implement a stand-alone executable testbench at some point, but these things, they take time.

Yesterday, I finally made the breakthrough. My new approach was to fill the memory almost completely at start-up so as to more quickly reproduce the issue. Then, I got a repeated crash during loading in FF13-2. This reminded me of earlier studies of FF log files, and that it loads far more separate shaders than any other engine I’ve looked at, and some of them 3 times each. And it continues to do so heavily throughout the game, which is somewhat unusual. This lead me to looking at the shader management code, and there I finally found the culprit.

And, as is almost always the case, looking back after finding the bug it seems painfully obvious: to enable things like PSHash HuD rendering identification or injection of postprocessing or AO in the case of specific plugins, I keep a map of all shader pointers and their names (which are derived from their code so as to be reproducible across runs). However, I never remove entries from that map. As it is impossible to know when an entry is save to remove without fully instrumenting shaders (which seems like overkill for this purpose) I’ve solved the issue by adding the new  trackShaders  option. If it is not set (the default), shaders will still be identified if they were set as PSHashes or VSHashes, but only those will be tracked. The only reason to enable the flag is to look for a new hash in a new game.

DSFix 2.3 DMCA takedown

So, Bandai Namco filed a DMCA complaint against DSfix 2.3 and got my Dropbox account blocked from public sharing.

You can all let them know what you think about that.

In the meantime, here is a link to “DSfix 2.3.1″.

If you want to donate to my apparent future need for legal counsel, you can do so here. (That’s a joke by the way, at least I hope it is)

 

UPDATE

Apparently, this was done in error, in a wide-reaching attempt to purge the leaked debug executable from the internet. While it’s still a problem that the DMCA simply allows companies to take down arbitrary non-infringing files, at least there shouldn’t be any further issues with DSFix.

DSfix 2.3 – Steamworks works

So, much earlier than I expected to, I’m able to present what everyone was waiting for: DSfix 2.3 supporting the Steamworks version of the game!

There is only one change, and that is updating the address offsets for the FPS fix to work with the new version. All other features still work as expected, at least according to my testing.

That this is possible so quickly is thanks to the contributions of boowoo90 on this very blog. Is he an undercover From Software operative? Just a talented reverse engineering guru? Who knows, but he supplied the required addresses in no time at all.

Get the latest version of DSfix here.

As all but the packaging of this update is the work of someone else, don’t donate just for that! However, if you are just now getting into Dark Souls after it is freed from the scourge of GFWL and find DSfix helpful you can donate here.

And remember, if you use the FPS unlock, you need to use some other method to achieve Vsync. Options include your graphics card’s control panel, D3DOverrider, or simply running Dark Souls in borderless windowed fullscreen mode using DSfix.

FF13 article

In unrelated news, my latest article on PC Gamer just got published. It discusses the Final Fantasy 13 and 13-2 ports. Busy day today!

GeDoSaTo updates / DSfix in the Dark Souls Steamworks version

GeDoSaTo

I just pushed a new GeDoSaTo update. Among some smaller stuff, it also includes two significant changes:

  1. Fixes to the Borderless Windowed mode forcing behaviour, which should greatly increase compatibility of that setting (and hopefully not break it in anything it already worked with!).
  2. A new “performance tracing” feature which I used in an upcoming article for PC Gamer, and which I’ll describe a bit more below.

Performance tracing allows you to record the performance of a segment of gameplay to a file. There is a keybinding for it ( togglePerfTrace) which you can configure like any other keybinding (now including modifier keys!), and after recording a sequence it will output a file such as this:

The first 3 lines give general information, including the total frames measured, total duration in milliseconds and average FPS over that duration. The following 3 lines give 99, 95 and 75 percentile effective frame times. These give you a quick idea of the overall smoothness of a game.

Finally, the rest of the file is a CSV (comma-separated value) recording of each frame’s times. The individual measurements are (i) CPU time from the start of the frame to the present call, (ii) GPU time according to D3D API measurements, and (iii) effective frame time from one present call to the next. You can use this detailed data to do analysis or generate graphs in your favourite statistics tool, like e.g. this one representing frame time distribution:

I realize that tools doing something very similar already exist, but they may not report all the information, or not be open source, or not be compatible with GeDoSaTo, so I integrated the functionality.

Dark Souls update / DSfix compatibility

The Dark Souls Steamworks migration update is now live. As I expected, most DSfix functionality I implemented (which is based on API call interception) remains operational, but the framerate unlocking (based on binary hooks) does not work with the new version. This part was implemented by Nwks, so we should hope that he is still around and interested in updating it for the latest version. If not, I can try, but it lies outside my expertise and could potentially take a lot of time (which I’d rather spend on other projects). Of course, there’s also the chance for anyone else to step in, as all the code is available on github.

For now, you can use DSfix with the new version as long as you disable the framerate unlocking feature in the .ini file.

Upsampling with GeDoSaTo, other small updates

The past day or two I have been looking into making GeDoSaTo a better tool for upsampling (as opposed to its usual downsampling use case). This might seem meaningless at first, but it’s useful in a few cases.

The most important such case are retro games (or modern retro-inspired indie games) which are stuck at a specific low resolution. In such cases, GeDoSaTo can be used to provide a nearest neighbour (or high-quality bicubic) upsampling, which often looks better than a straight bilinear filter. Now recently, someone integrated Timothy Lottes’ great CRT shader with GeDoSaTo. However, this only works if the shader has a sufficient number of pixels to work with. In order to support this use case, GeDoSaTo can now optionally perform postprocessing after upsampling.

Final Fantasy 6 in BSNES

Final Fantasy 6 in BSNES

The resulting pattern for fixed-resolution games is this: add the fixed resolution as a rendering res in the config file, use nearest neighbour upsampling to your display resolution, and then run the CRT shader. This works well for both emulators and low-native-res 2D titles. Obviously, a lot of tweaking can be done to get the CRT to look just like you want it (sharpness of pixels/scanlines, gamma, bloom etc.). Here’s a gallery with some of my results.

In other news, I also implemented a few small requested features:

  • You can now set the timeout for on-screen messages from GeDoSaTo, or disable them completely.
  • Settings can be reloaded on the fly just like shaders with a keybinding, but note that not all of them take effect immediately. This is mostly useful for trying out pshashes and such.
  • More than one action can now be bound to a key/button at a time.

As always, you can get the full version here or update. By the way, if the update ever fails (i.e. immediately prompts you to update again) delete the .dll and run the installer again. And also as always, if you’d like to you can donate here.

Edit:
Also, buy Valkyria Chronicles.

Forcing Anisotropic Filtering with GeDoSaTo (in FF13 and elsewhere)

I just added a new option to GeDoSaTo, forceAnisoLevel.

You can use this option in any game, but it only makes sense in a select few. If you force anisotropic filtering in the driver, it’s smart about which surfaces and original filtering types it overrides – that’s why it very rarely breaks games, and this makes perfect sense for a driver option.

However, specifically in the case of running stuff at resolutions it was not built for and downsampling, it is sometimes beneficial to apply filtering even to surfaces specified to be point filtered, which is something the driver doesn’t do (as it could often break shaders).

The main reason I added this feature is FF13, or more specifically its HUD and menus. These are point filtered by default (since they are rendered 1:1 at 1280×720), which looks terrible at higher resolutions. This setting alleviates the issue, though of course higher-res UI assets would still be preferable. Here’s an example of the difference:

To use it, add a user-level FF13 settings file (if you don’t already have one) and add the line forceAnisoLevel 16 to it. See here for details on settings files – I have seen that this causes quite some confusion and sometimes erroneous bug reports.

As always, you can get the latest version by grabbing the installer here or simply update, and if you want to you can donate here.

How recent Unity games do stuff, and a new GeDoSaTo version

Dreamfall Chapters: Book 1 was just released (go buy it), and it’s another game using the Unity engine. Like with another recent Unity title, Wasteland 2, it refused to work with GeDoSaTo. Now, since I like both of these games a lot I invested some time to find out what’s happening, and hopefully fix it.

Without further ado, here are my findings. This is what recent Unity engine games do on Windows if you select “fullscreen” mode. Note that all of this is based on deduction from the behaviour of Dreamfall and Wasteland 2, someone with access to the Unity source probably has a more exact understanding:

  1. Check the desktop resolution and create a fullscreen window as well as a DirectX device with that size.
  2. Check the native monitor resolution (using GetMonitorInfo), and reset the device/window to that size.
  3. Render at whatever resolution you specify in the game settings, to an off-screen surface.
  4. Stretch that surface to the window.

So, no real fullscreen mode in sight. Why would you do this? Well, it has multiple advantages: you don’t lose your resources switching to another rendering resolution, alt-tab behaviour is much faster and more stable, and you get free, correctly implemented triple buffering if the user is using Aero.

Obviously, this majorly messed up the way GeDoSaTo works — and the same goes for traditional downsampling methods. In the latest version, it’s now possible to downsample Unity games following this scheme, provided you add this magic formula to their configuration file:

It works by “pretending” that both the desktop and monitor are the given renderResolution in size, forcing that to always be reported, and modifying the mouse cursor position used by the game (so that clicks register correctly). GeDoSaTo takes care of actually constraining the fullscreen window to the correct size, and of course performs a high-quality downsampling of the rendering result as always.

Since the resolution you want to downsample from needs to be known before the game requests any, only a single rendering resolution can be provided.

Cursor Sidenote

Already in earlier versions, a problem in games using windowed modes was that custom cursors would be lost outside of the rectangular region corresponding to portion of the screen that would be taken up by a window downscaled by the downsampling factor. I figured out why this happens: To make games work, the cursor positions reported to them need to be adjusted (modifyGetCursorPos). This works for any processing within the game, as it thinks it is operating within a larger rendering area.

However, an issue occurs for cursors: I found out that many/most games use the Windows API WindowFromPoint function to check if the mouse is within their window before setting the cursor, passing the modified coordinates. Now obviously, Windows knows what the real window sizes are, and the modified virtual coordinates fall out of them. So I had to apply the reverse transformation in that function.

Release

Anyway, the new version is called “Tokikagura”. Other than the stuff discussed above it also includes some GeDoSaToTool fixes.

As always, grab the installer here or simply update, and if you want to you can donate here.

By the way, Nvidia’s DSR can’t downsample in these games (for now). Take that big boy corporate version!

FF13 micro-update

Another small update to fix some reported issues:

  • Fixed lack of postprocessing when disabling HuD
  • Fixed crash on alt-tab (again)

The latter took a lot more time to figure out than I expected. It seems that the game is actually leaking a backbuffer reference :/

About texture dumping/replacement: After getting the current GeDoSaTo facilities to work (more or less) on FF13, I figured out that most interesting textures (e.g. the fonts) aren’t actually being loaded using D3DX, so the existing mechanisms don’t help at all. I have a different method in mind (for a long time now actually), but this will take some time to implement.

Talking about time, what I wrote about on the blog a few days ago regarding not really having any time due to “real world” workloads applies now even more than before — after I spent basically the entire weekend on FF13. Therefore, don’t expect updates from me until next weekend.

That said, I’ve seen a lot of new forks at GitHub, so perhaps someone will make some contributions! I’ll try to merge good additions as quickly as possible if there are any.
As always, you can use the installer here to get the latest version (or just press the update button!), and you can donate here.