Game Design, Programming and running a one-man games business…

Insane days work just to swap screen res :D

Today, I was awake at 6am as it was holiday morning. Not for me, I’m staying here, but it means I was awake at 6am, and naturally, ended up programming by 7.30am.

Sooo… I thought I’d get the screen res code done today, and here it is at 11.55PM and it’s still not 100% what it should be. I’ve stopped for food twice, and didn’t linger over it. Bah.

Now granted, I spent maybe two hours dealing with the upcoming German translation of Democracy 2, but the rest of the time I’ve had my head buried in the directx documentation trying to find out just how the hell it’s supposed to handle a screen res change under directx9. I finally got there, and I’m still ironing out the bugs in certain circumstances, but my main objective now at least looks doable, which was to retain the feature all my games have of ‘in-game’ resolution toggling.

I HATE it when games ship with a separate ‘launcher’ app that you use to set the screen res. It’s just so fiddly. I much prefer being able to fiddle with such things, especially windowed / fullscreen toggling ‘on the fly’. I doubt it will be possible mid-battle, but at least it will be a part of the main app itself. Plus it makes it trivial for me to test that the GUI works in all resolutions. 768 really pushes it height wise, but I’ll sort it.

Today was not fun, it took longer than it should had, and it was seriously frustrating and involved. The idiot who knocked on my door to try and doorstep-sell me energy supplies got told where he could shove his special offer :D

5 thoughts on Insane days work just to swap screen res :D

  1. The trouble with the screen res thing is that it may or may not nuke any graphical resources you already have loaded. The way I used to handle that, when I was writing my own engines, was to make the switch, kill all resources, load up a loading screen animation, display that, and then reload the whole show. It was dirty and probably overkill, but it kept the code readable without a whole other section just devoted to detecting/reloading bad textures and so on.

    It’s surprising that you can still get newish games that don’t handle these things well. Honestly, DX (and others) should just have a FixIt function to check through and reload things for you. Every program has to do it…why not put it in the API?

  2. Isn’t there libraries out there that help with that sort of thing?

    I haven’t looked at many, and it’s been a while since I worked with SDL, but it feels to me like someone else has already gone through your pain and wrapped it all up nice in a library you can use.
    Turning that day long death march into 1 quick hour of happy bliss.


  3. SDL is a generic engine though. I needed something heavily optimised to draw things exactly the way I need them drawn :D

  4. @cliffski:

    I wasn’t suggesting using a library for all of your stuff, but it seems like you could maybe find one just for the screen resolution changing or one that you could just use that part of it. Screen resolution/resizing in DX seems like something fairly generic that could be shared easily.

    Ahh well, doesn’t much matter anymore. You’ve figured it out and you’ve learned it in the process. So :)

Comments are currently closed.