Testing & Fixing


Here is a screenshot showing some of the new additions. Notice the massive range of the Lightning spell for testing purposes, and the way that pieces on the board are obscuring the line of sight. The line of sight routine is rather generous, since from my own experience it’s more frustrating not being able to cast a spell that you think you should than the other way around..

I noticed earlier today that for some reason whenever I moved over some spells like Raise Dead and Lightning I got a massive frame drop from 60fps to around 20-38fps. At first I thought this was perhaps an error in the line of sight code or the highlighting code, but that checked out fine. After more testing I found that drawing the spell description was responsible for the slowdown..

Switching to a single line text system removed the frame drop, so I thought that it was my home made word wrap code that was to blame. Well, it wasn’t too efficient, so I rewrote it to work properly and more efficiently, but saw no difference! After more testing I found that the getstringwidth function in PTK was killing the framerate. Well, I remembered reading something about a speedup in the truetype functions in PTK and checked the website. It turned out I didn’t have the latest version of PTK downloaded as I had thought and instead had an older version where the truetype text was about 160 times slower (according to the history). So, one swift update later and now it ran great at 60fps again!

The new version also provided a new multiline function though. It doesn’t let me adjust the vertical spacing to get a nice lineup between the three lines of the description and the info on the lines on the right. That’s the downside, but the good part is that it does let me have extra spacing between words to get perfectly alligned text at each end. This does look better, so I’m using this function instead for now.

I also had another silly bug in there where the highlight square in position 0, 0 of the board was always being removed for some spells. I tracked that one down to a missing alive check when finding if a wizard was in a square. As a result wizards that were not alive had a position of 0, 0 and were triggering the ‘can’t cast on wizards’ code which removed highlights from them (including 0,0!).. Doh! Now, it’s fixed.

So, two little things which took a few hours to trace.. 🙂

12 Responses to “Testing & Fixing”

  1. Ash Says:

    This sounds like it is coming on a treat and it’s very interesting reading up your work log and the problems you’re tackling.

    Really looking forward to the next demo.

  2. happymonster Says:

    Thanks Ash. I always enjoy reading development blogs myself, especially when they go into specifics about finding bugs, design issues and adding new features. 🙂

  3. kreezer Says:

    Any chance that you could explain how you coded the line of sight routine?

  4. happymonster Says:

    Ugh.. I tried twice to explain, but aborted the comment as both entries confused even me! 😦 What method are you using now? Maybe that is easier..

  5. Nick Stevens Says:

    So.. what method are you using now?

  6. kreezer Says:

    I have the game grid which references various creatures and wizards. At the moment a wizard can cast a spell anywhere on the board. I have not coded the line of sight routine yet.

    It would be helpful if you could online the LOS routine where a wizard casts a lightning spell on an enemy creature. For example, how do you check if there is a wall in the way?

  7. happymonster Says:

    Right, I’ll try again to explain it!

    First, assuming you have two points (x1, y1 & x2, y2) find the largest distance from between x1 to x2 & y1 to y2. This gives you the maximum distance (a variable: float distance) in board squares you need to travel.

    Now make 2 new floats dx & dy and do something like:
    dx = (x2 – x1) / distance; // One of both of these will be a maximum of 1.0 or -1.0
    dy = (y2 – y1) / distance;

    Now, have 2 floats x & y:
    x = x1 + 0.5; // The centre of our start square.
    y = y1 + 0.5;

    Start a for next loop from 0 to distance:

    Now add dx to x & dy to y in the loop. This will move along the line and you would then check to see if that square was empty. If not, return false. If you get out of the loop return true.

    That is the basics, it doesn’t cover making the line of sight pass through the edges of squares or ignoring the start and end points of the board. But is this understandable so far..?

  8. kreezer Says:

    Could you please elaborate on how you found the distance variable in the first paragraph. Cheers!

  9. happymonster Says:

    Ok. Say you want to check between positions 1,1 & 4,1 on the board (x1, y1 & x2, y2)

    So first you would work out the difference for the X dimension, and then the Y dimension. If you do x2 – x1 that would give you 3, and y2 – y1 = 0. So in this case the maximum distance is 3 squares.

    If we checked from 1,1 to 4,4 then both distances would be 3,3 and if we checked from 1,1 to 1, 4 then the x distance would be 0, and the y distance would be 3.

    We have to make sure any negative values are treated as positive though (I use the C ABS() function to do this..)

  10. kreezer Says:

    Cheers !

    I think I get the gist of it now.

  11. happymonster Says:

    Good. I take it you are doing your own version of Chaos then?

  12. kreezer Says:

    I’ve started to do a version in Flash but have had to put it off for a while. I find your blog useful because it shows how you have solved a few of the problems that I will probably face later…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: