Language :

Low performance issue solved!

April 6th, 2009

I’m in the early stage of my project. Currently, I have a very basic collision handling mechanism, and I’m blitting a “few” sprites to screen. On the emulator, everything seems to work fine. However, when I transfer the software to an actual device, either the Touch Diamond or the Axim X51v, two devices with good specs, I received the following FPS :

Axim : 11FPS

Touch : 21FPS

These low values are really annoying, especially that I intend to add way more “features” to my game, meaning that these values will go down ! So I had to find out quickly why the performance was so low.

I probably should’ve used a profiler, but somehow, I just commented out of the program some parts of the code. Taking out the collision handling logic did not even give me a single added FPS. So it was definitely with the blitting. Removing most objects ( about 100 of them ), gave me a very decent increase. Now what’s a game if you can’t see what’s going on ? :)

So I tried something else. It seems that it is not the number of pixels written that takes time, but the number of calls to the blit engine. Since most of the time, the objects shown do not change, I blit everything once in an offscreen surface. I draw the modifications on that surface, and I finally blit the whole updated surface on the screen. The same amount of pixels are transfered, but with less than 10 calls to ->blt(), instead of more than a hundred before.

Axim : 40fps ( but very smooth display, due to the usage of hardware page flipping )

Touch : 47fps

Clearly, that did the trick. I guess that we need to think a little when using these devices, which makes developing for them much more fun :)

Backbuffer on the Touch Diamond ???

April 4th, 2009

So I’ve decided to go with DirectDraw as the basis for the graphics in my game. It’s pretty straigthforward to initialize, and there’s quite a few tutorials on it. Well, not that many related to Windows Mobile but still…

I have used a tutorial – Ski Time Mobile – to get myself started. It’s aimed for non-touchscreen devices, with a rather small screen. Anyhow, the initialization routine they use for DirectDraw works fine on the emulator, and on my Axim. But on the Touch Diamond…

The following code is used to determine device capabilities :

    // True if backbuffers and flipping are supported by hardware
    m_bPageFlipping = CheckSurfaceCaps(DDSCAPS_BACKBUFFER | DDSCAPS_FLIP);

I receive true for both the Axim and the Touch, but on this following call :

        ZeroMemory(&ddsdPrim, sizeof(ddsdPrim));
        ddsdPrim.dwSize            = sizeof(ddsdPrim);
        ddsdPrim.dwFlags           = DDSD_CAPS | DDSD_BACKBUFFERCOUNT;
        ddsdPrim.ddsCaps.dwCaps    = DDSCAPS_PRIMARYSURFACE | DDSCAPS_FLIP;
        ddsdPrim.dwBackBufferCount = 1;
        HRESULT lHR;

        // Create Primary Surface
        if (FAILED(lHR = m_pDD->CreateSurface(&ddsdPrim, &m_pDDPrimaryBuffer, 0)))
            m_bPageFlipping = false;

The creation of the Primary Surface fails, only on the Touch. I can’t remember the error, I’d need to check. Anyway, I thought that I would implement some fallback mechanism. If this call fails, we’re back to flipping our buffers manually.

What scares me is… how many of these weird results would I experience if I had more devices ? Welcome to Windows Mobile I guess :)

Windows Mobile – Game Development

April 4th, 2009

I’ve started developing a game for my windows mobile game, quite a while ago – almost one year to be correct. The number of problems I have encountered is huge. I will use this blog to write down my findings.

I own two windows mobile devices. An Axim X51v from Dell (PDA), and a Touch Diamond from HTC (Phone). Both devices have a screen resolution of 640×480, which gives pretty awesome graphics on such small screens.

Hopefully, I can manage to release a full game someday, before the marketplace goes live :)

Hardware overclock of a Q6600 within a Dell XPS 420

November 19th, 2008

With a few friends, we all bought some Dell XPS420 last year. Not being a maniac about overclocking, I did not research the subject much, but I knew that my bios was locked and that it was probably not worth wasting too much time on it.

However, a few days ago while browsing the ‘net, I found out this article :

It’s a nice read with lots of picture, and I will make some reference to it in my (short) post.

So that guy was able to crank-up the speed of it’s 2.4GHz Q6600 to 3.0GHz by shorting two pins of the processor. This has the effect of making the Front Side Bus run at 1333MHz, instead of the stock 1067MHz speed. I did some more research, and this modification is well-known, and called the “BSEL MOD”.
But there is something more. There is no need to go out and buy a defogger kit. You simply need to isolate the bottom pin from the socket, and with little luck, this should have the same effect ( I have not seen a post from someone for whom it did not work ). So read again the tutorial, it explains very well how to open your computer case and reach your CPU.

Here’s a picture of the modified Q6600. Note the tiny amount of tape covering only one pin. I know the picture is blurry, as I had to hold the processor to make sure I would not spread thermal paste all over my desk.

Modded Q6600

( Click on the picture for a better view, the mod is in the bottom-right corner )

I put the CPU back in, boot-up, and launch CPU-Z.

CPU-Z from a modded Q6600

Core Speed : 2.99GHz

FSB : 1330MHz

All seems right and working fine. I was worried in the beginning about the RAM, because it was already running at 333MHz, which is the max of my DDR2 PC-5300. But the ratio changed from 2:3 to 1:1, so my cheap ram that came with the machine still works good at the same speed. With the 1:1 ratio, Vista even gave me a better score !

All in all, it took me about 10 hours of looking around, trying softwares like cpucool, clockgen and such, with no success… and less than 10 minutes to do the hardware modification. It’s been a week now, and the machine still runs with perfect stability.

Note : I’m not responsible if you blow your own CPU/Machine/Cat, use at your own risk :)

Features planned for Warlock DPS Calc 1.06

November 21st, 2007

I’ve just realized yesterday that 2 months had gone by since the last update to the DPS Calculator.  I wanted to improve the Timeline first, but this will take a deep revision of the drag&drop mechanism, which I do not wish to undertake right now.

I have received a suggestion to display some graphs. Indeed, it’s true that more information could easily be displayed about the selected spells and the resulting DPS.

I’ve received one mail about bugs, but after discussing with the person it appeared that it was just misuse of the calculator, or bad comprehension of the results. Also, I’ve read on some forums that this “Calculator was bugged, as all the other ones”. I have invested many hours in testing – probably more than what I used for coding – to make sure that the results were accurate. So I guess that I will have to show the output of the calculator, so people understand what’s going on.

Here’s a summary of what will be included in 1.06 :

  • DPS over time graphics, x-axis based on 60 seconds to let the dots expire.
  • Text output of the spells damage, including base damage and modifiers
  • More statistics, such as Max DPS achieved during sequence

Let’s say that a reasonable target date for this would be december 15th.

Shadow Destruction Spe – Should you cast Immolation ?

November 12th, 2007

My current template is 0/21/40, with points chosen for SB spamming. To keep this test simple, I only took Improved Shadowbolt (5/5), Bane (5/5) and Ruin. Since I have more Shadow damage than Fire damage, I wanted to check if casting Immolation was useful or a waste of time.

Here’s a simulation of a pure shadowbolt spam, with +1000dmg to all, 18% crit and 11%hit.

Shadowbolt Spam

Pretty straightforward, we get 776 DPS. We’ll compare other results against this sequence.

Now, we’ll include an Immolation spell :

Immolation + Shadowbolt Spam

Obviously, the DPS is higher (4.3%)…not bad ! To get the same increase in DPS while keeping the DPS spam, we’d need to increase our shadow damage by 65 !!

Since many warlocks have more shadow spell damage than fire spell damage, I tried to see how low we can go with fire spell damage to make it useless to cast Immolation :

Immolation + Shadowbolt Spam (Different spell DMG)

To get my DPS down to 776, I had to get my Fire spell damage down to 350 ! So unless you have a difference greater than 650 between your shadow and fire damage, you can keep casting Immolation.

Obviously, you’re always better to try all this by yourself on the calculator :

When to cast Curse of Shadow ?

November 11th, 2007

For this small test, I assumed that the warlock has chosen to go deeply in the affliction tree. All spell damage and hit rate have been set to 0, to make it easier to compare.

The first sequence shows what most warlocks, including myself in the past, would do. We start with Curse of Shadow, then we fire the offensive spells :

Timeline - Shadow/Corruption/Affliction

Let’s try a different approach. Since we know that Corruption does not tick until three seconds have elapsed, and that the same mechanism is applied for Unstable Affliction, we’ll apply Curse of Shadow last. Here’s the updated sequence :

Timeline - Corruption/Affliction/Shadow

So what happened ? We lost a bit (12) of total damage, because the first tick of corruption occurred just before Curse of Shadow was applied. However, we reduced the running time of the DOT sequence to 21 seconds instead of 22.5, giving us an increase in DPS (6.4%).

Of course, this example only works for short fights. But it shows that good timing of the spells you cast may increase your DPS. In our case, if we wanted to keep the first sequence and check how much more spell damage we require to achieve 84.2 DPS, we’d see that +59 to spell damage would be needed – quite huge !

You should try this on the calculator to verify it all works with your setup :

Welcome to this blog

November 3rd, 2007

Yet another blog.

I guess I really used to dislike the word “blog”. Not sure why, maybe I felt this term was just hype for naming a personal page or site. But along with it comes the notion of easy publication. Whatever comes to your mind, you can post about it in a matter of seconds. No need to fight with HTML/CSS, there’s a zillion of tools to take care of this for you.

Even if I like to be in control of the code I use on my websites, I can’t deny that using WordPress for my blog has been a huge time server. Skinning the site took about 30 minutes, on top of the 10 minutes required to configure WordPress. I now have a nice wysiwyg HTML editor to post from.

I intend to write about anything that is not long enough to be worth the creation of an article on The layout of the blog is still really simple, I will add categories and the usual stuff once I have a few posts going. In the meantime, it’s not really worth it to spend time on getting the search function working :D