FF Type-0 Article – Snatching Defeat from the Jaws of Victory

I wrote a pretty in-depth port analysis of FF Type-0, for PC Gamer as usual. The game is intriguing: it’s clearly a far more technically competent port (it even uses some compute shaders!), with none of the random performance drops, but held back by a baffling regression in output resolution choice.

It also got a very bad rep initially on Steam because the options perhaps aren’t labeled expressively enough – the “high” and “highest” AA options perform 2.25x and 4x downsampling, basically, so they have a very significant performance impact. Many expected to just “max everything” in this port, so that came as a surprise.

What I didn’t expect is that the game actually has some decent improvements over the console version beyond just rendering resolution, including a high-end shadow option, a very fully-featured screenshot mode, and a speedup toggle.

1.5 Weeks of Windows 10, and Photoviewer executable release

I’ve been using Windows 10 for about 1.5 Weeks now, and I thought it would be time to write about the experience, explain a few workarounds, and post one tiny tool I made to make it more palatable.

So, what has gone wrong in Windows 10?

Booting & drivers

First of all, initially it wouldn’t even boot on my X99 system. It got stuck in an infinite loop on the initial boot screen. By looking through the boot log from my old WIndows 7 installation, I eventually figured out that the fault lies with the “Intel Management Engine” driver – a component I don’t need at all. Disabling it fixed that issue.

However, I still got a black screen on boot. Turns out that Windows 10 thought it was a good idea to show the initial login screen on my projector (turned off projector, I might add) rather than the  monitor.

Talking about boot issues, the idea of removing the option to get to the advanced boot loader with a key press is really fucking annoying. Being really annoying to power users for no good reason seems to be a theme in Windows 10, as I’ve found.

The new start menu

In short: it sucks. I tried living with it for a few hours, but its refusal to reliably index manually created desktop application shortcuts in its search makes it completely unusable to me. Good thing I bought two StartIsBack licenses back then, and great on the author for having a perfectly up-to-date and fully compatible version out with the Windows 10 release.

Look, it’s a beautiful start menu with actually working indexing for desktop applications and lots of neat functionality!

Program incompatibilities

Let’s start with an amusing one: Skype would crash every time I logged out of Windows 10. The amusing part here is that Skype is now owned by MS, so’ you’d assume that they’d get compatibility right. After a lot of googling, it’s apparently an issue where the sound driver gets unloaded before skype does, and it crashes when trying to play the logout sound. Go figure. The fix is to disable that sound.

There are also various incompatibilities with DirectX pre-9 games and fullscreen mode, resulting in flickering. In most cases I’ve encountered, forcing borderless windowed mode seems to work around those.

What’s nice is that it seems GeDoSaTo is compatible with Windows 10 out of the box, and so is PtBi.

Strange stuff happening to CPU usage

This has been a sporadic issue that seems to have stopped completely now, but for a while I was getting completely nonsensical CPU usage reports in task manager.

Apparently, my CPU was giving its all at 124%.

In complete idle state, my CPU was apparently running at ~30%. At least according to the new “Processes” view in task manager. “Details” was showing 97%-99% idle, and Process Explorer, which I trust more than both of them, agreed.

The “Appification” of general tools & Photoviewer

In the process of converting general windows default utilities to “apps”, it seems that almost invariably functionality is lost — often important functionality. The new “Photos” app apparently can’t even show images at 100% zoom with a simple click, and mouse wheel zoom is completely broken. I find that unacceptable.

Luckily, Windows 10 still ships with the old Photo Viewer. Because it’s MS though, that Photo Viewer is not an executable but rather a dll which needs to be hosted and invoked somewhere, so it’s hard to associate with images in Windows 10. To work around this I’ve created PhotoviewerWow.exe. It merely invokes the existing .dll, and should work on Windows 10 64 bit installations. Just put it somewhere permanent and you can easily associate it directly with image files. (The name is a homage to the insane hoops MS jumps through to run Windows32 on Windows64, since I also had to jump through hoops to run a standard Windows feature on the new Windows)

Another thing about appification that might be even more worrying is that apparently you aren’t even trusted – as an administrator no less – to look at your own apps’ files (hidden away in “Program Files/WindowsApps”). That’s just ridiculous. And worrying.

Improvements?

Well, I guess the new built-in virtual desktop support is neat, and they chose exactly the keyboard shortcuts for it that I would have chosen intuitively (Win+Ctrl+D, Win+Ctrl+Left/Right). So good job on that. And I also like the improvements to the “move window left and right” workflow, where it now shows you a selection of the remaining windows to move to the other half of the screen after you used Win+Left/Right to move one window. It’s also not quite as fugly as Windows 8, and it makes it rather easy to mostly ignore the entire app crap after installing StartIsBack.

DirectX 12 article on PC Gamer

I wrote an article about DX12 for PC Gamer. It discusses the differences between high-level and low-level graphics APIs and what that means for gaming. It also features some insight gained from talking to Dan Baker at Oxide games about a few related topics, which was a big help.

I went a bit wild in terms of technical detail in the middle section of it, but it could be up your alley if you read my blog (and hopefully also interest some PC Gamer visitors).

Some Audio updates for PtBi

Thanks to a comment on the last post, the audio crash which affected some should now be fixed in version 6.1901.

Also, I investigated the reports of trouble capturing PS3 output, and there was something strange going on. It seems like in some conditions the BMI Pro 4k driver can enter an error state, and nothing will work until the next reboot. Anway, after some debugging I got 1080p5994 capture with full ARGB quality working on PS3:

PtBi updated for RGB pixel formats and Intensity Pro 4k support

I recently got an Intensity Pro 4k to replace my Intensity Pro, which served me well for more than 6 years. It has mixed reviews on the internet, but mostly because of one of two reasons:

  • Noise, which was indeed terrible but is fixed completely by updating the firmware.
  • Software compatibility, which I can’t speak for. I only use one piece of software and I make that one compatible if it isn’t.

BMI Pro 4k to the left, BMI Pro to the right

I have to say that the device has worked pretty flawlessly for me. Nice to finally get full RGB input and 1080p60 capture.

Of course, to actually make use of those features I had to release a new version of PtBi. Since it’s a pretty major upgrade I decided to call it version 6 now. More specifically, the release is 6.1877. In addition to supporting the new pixel formats PtBi should now also produce somewhat more useful messages on errors.

It’s still not quite user-friendly though. You have to select the pixel format and video mode with command line parameters, e.g. PtBi.exe -disable-audio -pf=ARGB -mode=1080p5994. The supported modes are ARGB, BGRA and YUV (which is the default and only option in previous versions). I don’t support 10bit modes since I don’t need it — if anyone really does it shouldn’t be too hard to add.

I also pushed the current source to GitHub, what was there was completely outdated. It’s still terrible though, which is about what you’d expect from a project developed for a few days here and there over 6 years, and built on code even older than that. However, it does it’s job, and it’s the only thing which does that particular job, and I still use it all the time, so perhaps it’s useful to someone.

Dark Dreams Don’t Die (D4) Alternative Launcher

D4 PC released (on Steam and elsewhere) recently. The game uses UE3, so it works well on PC, and the mouse controls are also well done. The only problem is that the built-in launcher presents a fixed list of resolutions rather than all available ones, and also somehow messes up with DPI scaling.

I wrote a new Launcher in C# which doesn’t have this issue. It’s available here.

I also made the source code available on Github. Not because I’m very proud of it or because it’s particularly interesting (it’s just a simple Winforms C# app written in an hour or so), but because I hope if I put it in the public domain it could help improve this state of affairs in the future.

Well, that’s all.

The Witcher 3 Tech Analysis

witcher3_2015_05_19_19_52_05_657I wrote an article about The Witcher 3 for PC Gamer. I focused primarily on some tips for achieving the smoothest possible gameplay, but what I’m really surprised by is the CPU results I obtained.

I might have chosen a bad location for that benchmark, and perhaps I’ll repeat it somewhere else, but I really expected an open world DX11 RPG to be more CPU-heavy. Certainly not playable with two 2.2 GHz cores at 30 FPS and 4 at 60 FPS. Very well done, and another indicator to me that seems to hint towards the gains with future low-level graphics APIs being less pronounced than some expect, outside of very specific use cases.

Of course, that level of control will at the very least be a huge boon to VR rendering, which inherently requires a high framerate, low-latency and extremely consistent performance.

GeDoSaTo FPS capping, modding controversies

FPS Capping

I recently started implementing FPS capping in GeDoSaTo. For those not familiar with the term, basically you want to achieve a consistent framerate in a given game, and in order to do that you cap the framerate at a given maximum.

In practice, this is usually done by simply inserting waiting periods after you are done with a given frame. E.g. if you want to cap to 30 FPS, you would wait until you reach a frametime of 33.3 ms.

There are multiple external tools which already do this (e.g. NVidia drivers have an option, RTSS can do it, some games have a built-in cap, …) so up to now I wasn’t interested in doing the same in GeDoSaTo — though I was sometimes frustrated by the lack of fine-grained control in external tools. However, I recently had an idea on how to improve upon the commonly employed method for doing this, in order to perhaps slightly improve input lag in a capped scenario.

fps_cappingThe image above shows 3 use cases: uncapped framerate, a traditional 30 FPS limit implementation (“Capped”) and my new method (“Predictive”). As you can see, the traditional method simply inserts a waiting period after each frame. However, this means that you are potentially losing a few milliseconds of input latency for no good reason.

Instead, with predictive FPS capping, GeDoSaTo keeps track of the frame times for previous frames, and takes a set fraction (configurable) of that as a predictive waiting period before each frame. The result (for games which do synchronous input sampling on the rendering thread or at least on another thread synchronized with it) is that the input after waiting is used for the new frame, reducing input lag by some fraction of the frame time.

The only dangerous aspect of this method is if there is a sudden spike in frame rendering times. For example, in F2 in the picture you can see that the frame almost doesn’t get done in time. If it were to cross the threshold, predictive FPS capping would result in a framedrop which would not happen in a traditional FPS limiting scheme. For this reason, the ratio of how much waiting time should be moved to the start of the frame is configurable — you can use a low value like 0.25 for a game with very erratic frametimes and something like 0.9 for one with extremely consistent performance.

Here are the new configuration options (which can be configured as per-game user profiles, like always)

The busy waiting or sleeping option is there for completeness, but outside of running on a laptop battery I don’t really see why you would not use busy waiting. In my tests it’s a lot more exact.

Note that you can use floating point numbers as the frame limit, I find it often useful to go with e.g. 30.5 FPS if I want a solid 30 in order to overcome unmeasured overheads.

Modding Controversies

Since my last blog post there have been two pretty large controversies about modding. The first was regarding paid mods for Skyrim. I was asked to provide a comment for PCGamesN, which was used in this article. My full comment, which is provided on the second page of the article, sums up my feelings on the issue. I have to admit that I was most disappointed by the level of vitriol some (purported) members of the community stooped to.
The other issue was once again the old friction between modding and multiplayer. Both in DS2 and GTAV, people who claimed to be using only mods which do not affect gameplay in an unfair way were relegated to the cheater pool in online multiplayer. This is a very delicate issue. It is extremely hard or even impossible for a game to assess whether a in-memory modification is benevolent or not, so I can certainly understand “no online modding” policies in principle. in the end, that is just another instance which shows why developer-supported modding is the way to go: in such a setup, it’s easy to control which modding functionality is available in what game mode.

GeDoSaTo minor update, Pillars of Eternity, DX11

I just pushed a minor update to GeDoSaTo (which you can download here, as always), mostly to integrate the pull requests and new profiles people have contributed over the past 3 months or so.

With the release of Scholar of the First Sin, I also get a lot of renewed interest and questions about DX11 support in GeDoSaTo. The answer to that is still that I’d love to do it (and I also already laid some of the groundwork for it last year), but I simply don’t have the time right now between some increased load at my “real job” and still trying to get some gaming in. I do of course welcome any contributions, as always.

Speaking of gaming, Pillars of Eternity was released recently, and it’s really really good. You should play it.

 

Graveyard of Forgotten Projects (Part 2)

This is a direct continuation of the first part. Let this partial quote from there serve as an introduction:

This series (hopefully) of blog posts will gather and shortly describe some previously unreleased and/or forgotten projects I’ve worked on over the past decade and a half, starting from 2000. 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.

I stopped the previous post around 2003-2004, a timeframe of abortive attempts at creating a 3D multiplayer physics-driven space ball game.

Rudloid

I wasn’t sure where to slot this in, as I started this project in ~2002, but did a lot of work on it in 2005. I chose to go with something closer to the latter than the former. This is an Arkanoid clone written in Ruby. It used the RUDL SDL wrapper (another amazing example of my naming sense really), and initially did software rendering. Later on I switched to using OpenGL for the rendering for performance reasons, which is why the final 2005 iteration was called RudloidGL.

What is interesting about this project is that it’s actually written rather well, in some ways at least. For example, I implemented features like collision detection, sound effects and sprite animation as Ruby mixins, and they are re-used in every object where it makes sense. So the balls, paddle, blocks etc. use the same basic collision code with distinct response events, and animated blocks, paddles and balls use the exact same sprite animation code just with slightly different parameters.

Of course, there are also some things were I was maybe going a bit too far with trying to be smart. For example, I used the “evil” library (yes, that’s actually its name) to implement different ball/paddle/etc. types and changing between them (when picking up a powerup pill) by actually changing the class type. It works, and in a way it’s elegant, but it’s also a bit wild.

Talking about powerups, that’s actually another thing where the code for this game is a lot better already than most of what I discussed in the first post in this series. For example, I seem to have had attained a decent understanding of the “once and only once” principle at this point, and the value of setting up tools in the code base so that it can be effectively used. For example, this is the actual, entire definition code for all 12 powerup pills in the game:

While eval’ing some random strings would make my hair stand on end now, at least the heart for this code is in the right place, and I still appreciate how concise it is.

The game also features a level editor, which nicely reuses most of the actual game rendering and related code. It also allows for undo/redo and copy/paste operations.

On the whole, this isn’t too bad really. What was bad, no, terrible are the sound effects. I never spent much time on those and it really, really shows. Check it out for yourself in this Shadowplay video I took of the game (after spending literally 2 hours finding all the dependencies in compatible versions and getting them to work together).

I will not upload the .zip for this, since I don’t think I am actually allowed to distribute some of the music and sound effects I used. If anyone cares a lot, post a comment and I’ll try to create a working package without those.

Wasser

The imaginatively-named “Wasser” (German for Water) is a very small program I hacked up in early 2005 in order to generate daily data fitting a decent-looking curve from monthly data about the electricity production from hydroelectric power plants. Until I made this, that was apparently a process carried out manually in Excel (I shit you not).

wasser2There are two interesting things about this one:

  • It uses both Tk for the UI window and SDL (via RUDL) for the visualization window. That’s insane, but I guess I just used what I knew, and it works.
  • I came up with the method of how to distribute data across the days of each month on my own, without really knowing how one would actually solve such a thing correctly. Nonetheless, what I do in the end isn’t too different from what an explicit iterative solver would look like.

You can get it here, though I have no idea why you’d want to.

Ragex

Released (actually released!) Christmas 2005, Ragex is a tiny generator for XHTML. I don’t need to write much about it here, because the web page is still online, I’m just including it for completeness’ sake. The best part about this one was when I got an email from someone actually using it, in 2008 or so, when I had almost forgotten creating it.

Crystalise

After my 3D experiments in 2004, and other game projects that never quite reached completion, I really wanted to actually finish a game. That’s why I came up with a very simple action/puzzle principle, and Crystalise was born (also check out the help file for a visual explanation of its gameplay).

Here’s a bullet point summary:

  • It’s made for PSP, the hottest gaming device of 2005 ;)
  • The vast majority of the game is written in Lua, with some of the heavy lifting (rendering, collision detection) in C. Pretty modern in that regard!
  • As far as I can tell, I completely lost the entire C source code for this project, as well as all the original (non-distribution) assets. A valuable lesson about backups, and even more so the value of releasing the source. The lua code at least is included in the distribution.
  • It really is a complete game, including stuff like a main menu, difficulty levels and high score tracking.
  • The levels (including boss and special levels) are procedurally generated, probably one reason why I actually managed to finish this game.
  • If you hit a certain level (which probably no one except me ever did) the game increases the PSP clock speed to 300 MHz in order to keep up solid 60 FPS:
  • I believe I invented the now commonly used paradigm for writing text with a analog gamepad in this game. That is, selecting a direction with the analog stick and then selecting a character from that direction using a button:

This is one of those projects where I’m really sad I lost (part of) the source. At least in this case most of the Lua is still available. And some of it is pretty neat, check e.g. circle.lua which (despite the name) keeps track of and handles updates to the current state of the level.

LuXr

This is a C#-based program launching (and other stuff) tool that I’m still quite proud of. I made and released it in early 2006, and the web page is still online. I just downloaded and ran the 54 kB package, and it still works well on my current Windows 7 installation.The major reason I created this was because I was fed up with the Windows (pre-Vista) way of launching programs. Of course, Microsoft seemingly agreed, and the keyboard / string search driven way of using the start menu in Vista onwards pretty much made LuXr obsolete.

Still, there are a few things to like about this one:

  • The aesthetics for the startup effect were influenced by the OS in Serial Experiments Lain. Which was much more awesome of course.
  • It features a plugin system which dynamically loads plugins written in C#, which can have their own config dialogue pages (they are adressed by adding a prefix to what you type, e.g. “g something” to google “something” with the google plugin, or “e” to use the eval plugin:
  • I still prefer how this resolves substring matches comapred to the Windows Start menu search. For example, if I write “vis 13″ in the start menu on my current PC, it finds no matches. LuXr finds “Visual Studio 2013″.

What’s not to like is that I believe I lost the source for this one as well (except for the plugins, which are part of the distribution package). It seems that with the years progressing I got better about actually releasing stuff from time to time, but worse about keeping backups.

 


That’s it for today, next time around we’ll get to actual 3D graphics programming. WHOOOHOO!