News and updates

Warning: May contain traces of cynicism

18th of March 2016 - the meaning of success

If I call a function with a set of parameters, and that function returns success, am I wrong to assume that it did what I asked? Here's another couple of slides comparing softdx to hardware. (Click to switch)

ddraw1 slides

Pretty good, aside from two cases; an alpha blended blt, and a blt of an 8 bit paletted texture to a 32 bit surface. I'm fairly sure that alpha blended blts have never worked in directdraw, so that's actually softdx's bug for supporting it, but even so, why does it do a non-alpha blended blt and then return success at me? Why doesn't it return DDERR_UNSUPPORTED? The same thing applies to the 8 bit blt, although I'm not actually sure whether that's supposed to work or not. If you create a software only device, it blocks you from creating surfaces with an alpha channel. If you create a hardware only device (at least on win 7, probably not on win 9x,) it blocks you creating an 8 bit surface. Maybe it's a case of the HAL and HEL both assuming that the other one will fill in their blanks.

2nd of March 2016 - text rendering

As evident in the screenshots in my last post, I've already added some basic text rendering support to softdx. It uses freetype, because no point rolling my own, but is otherwise a quick job just to let me get some text into my unit tests. It didn't match the reference output, but I didn't particularly care because I wasn't trying for accuracy at that point. Turns out that GDI font renderering changed in win 7; my text output actually matches the win xp output exactly, aside from the font colour. That was a bit of a fluke... Looks like the font colour difference is coming in because I was rendering with 8 bit font bitmaps, whereas win xp GDI apparently defaults to monochrome. Easy enough to switch over, and now I'm pixel perfect on fonts, as long as I compare myself to windows xp.

Doesn't fix the rasterizer though; the reference device is even harder to figure out than the HAL device was.

28th of Feb 2016, addendum

And it turns out that the reference device gives different results to both the RGB and hardware devices. Le sigh.

28th of Feb 2016 - rasterizing

One of the basic requirements of a 3d renderer is a rasterizer: Given a bunch of vertices, which pixels need to be filled in? The rasterization rules define which pixels are included in a given primitive, and it's important to get rasterization correct, or you can end up with single pixel seams between triangles and other such nasties. Given that, the logical thing to do is to generate a test sheet with lots of different primitives, render it with real directx, and then compare myself to it and make sure I match.

Except... real directx doesn't seem to agree with real directx. :( Results from an RGB device differ from a hardware device. It doesn't seem possible to create a dx7 reference device on windows 7, so I'll have to fish out my win xp VM and see how it compares. The problem seems to be that subpixel handling is left undefined*, at least in any documentation I've seen. Given that my hardware device is doing such insane things as varying the x position of a horizontal straight line based on its y position, (actually, scratch that, it was just that my test slide was hitting the limited precision of floats,) I think I'll be following what the software device does. In any case, my current code is not matching either, so I still have some tweaking to do. (left/right click to cycle through the images)

rasterizer slides

*e.g. The rasterization rules for lines state: "Non-antialiased line rendering rules are exactly the same as those for GDI lines." The GDI line drawing functions take integers as positional arguments. DirectX takes floats. I don't think 'exactly' means what they think it means...

25th of Feb 2016

I was quite excited when I heard that tales of symphonia and disgaea were coming to PC. They were two of my favourite games from that generation. Then tales of symphonia came out and the porting job was a steaming pile of turd, so I let myself have a moment of sadness, then got my gamecube back out for a bit and carried on with life. Now disgaea is out, and it turns out that it's rather broken too.

Is it really so hard to port things from consoles to PC? I guess ps2/ps3 is harder than ps 4/any xbox, but really, there's no excuse for the state of these games. There is no way in heck they've run them through test and been given the all clear; These ports are knowingly being released in their broken state. Ah well, at least a ps2 emulator lets you change game speed, which is a rather vital feature for disgaea. I would have had to make a game speed mod if I'd bought the PC version, so the poor port has saved me a bit of time. :p

To people rereleasing old nostalalgic games: I want to give you my money!!! Stop making it so bloody hard!

23rd of Feb 2016 - Introducing softdx

What's this? A blog post? After 3 years?! Well who knew, looks like I'm still alive after all. :)

I've still got my day job, but now I've been promoted to the point where I spend more time reading/writing emails and sitting through meetings* than I do actual programming. While that's kinda sucky from an enjoying-your-work point of view, it does mean that I'm no longer completely programmed out when I get home, so coding has a chance to be my hobby instead of my day job again for a bit. All of my old projects have new homes though**, so time to start a new one.

Something I've looked at a few times in the past is methods of creating a universal directx wrapper, that fixes up all of the usual glitches like palette problems, missing dithering and so on. It was actually one of the things GOG was interested in back when I was doing contract work for them. It never works too well, because trying to shoehorn all of the various old interfaces in together, along with GDI, doesn't map well onto the modern APIs. In my last attempt I ended up with 4 copies of each surface, and ended up spending 90% of the time blitting between them... But even if it had worked, we'd still be at the mercy of windows and graphics drivers changes, and there's no telling how long it would last till something broke again. So this time I'm going to try a new twist; write a software directx 7 implementation, that doesn't touch the graphics card aside from pushing finished frames to the screen. Surely a modern CPU can manage the same throughput as a 17 year old graphics card?

As far as I can tell, there doesn't seem to be an existing fully featured software directx 7 implementation, aside from the reference rasterizer, which is too slow for usefulness on any hardware. There's software renderers that advertise 'directx 7 class features' but have their own proprietary api, and there's software renderers that implement higher directx versions. This is slightly surprising, so possibly I've missed something there... In any case, unless you want to go the WINE route there's nothing that ties in GDI too, so time for some experiments to see whether a software directx 7+gdi stack can be accurate enough and fast enough to be a viable option to solve compatibility woes once and for all.

And with that grandiose plan in place, time to sit down, start coding, and given my track record, immediately get distracted and end up signing off for another 3 years.

*Arggg meetings. For example, I currently have a daily status meeting for a code drop where my section is a) complete and b) has no open defects. I'm not entirely sure what it is that I'm supposed to report. This wouldn't be too bad, except that it's timed right on top of my lunch break!

**Thanks to phobos2077 and NovaRain (among others) for looking after sfall. I think that was the last one I was still active on at the time of my last post.

6th of May 2013

My job hunting went better than expected, and I'm now happily working in my first permanent job. Alas the best offer I had required me to move house, with all the faff that goes along with that, and having my computer packed into boxes and no internet connection or phone line for weeks did rather horrible things to my programming time, not to mention my discworld addict-o-meter rating. I also find that now that I spend all day coding, I'm not so geared up to work on my own projects when I get back home, so even now that I'm settled in again I'm not really doing much. I do have a few project ideas kicking around in my head that I really want to try out one day, so hopefully the lull won't last forever.

I've removed the ddfix downloads from this site, because with the existence of newdark there's no reason at all for anyone to be using it. sfall has also had an update to 3.0, the major version bump being due to some little used features that I decided to remove, in order to simplify the dx9 graphics mode a bit and improve things when used together with the high res patch at high resolution.