Greetings Everyone =)

So, as some of you know, the Morning's Wrath, Beta 1.1 was released last week to a few choice testers, and already the bugs and comments are pouring in. So as you can imagine I am on bug patrol =D

There are two major things that have stuck out as far as bugs and feature requests, and I knew they would come along sooner or later, and they are:

The Dreaded Time-Based Movement/Animation And The Dasterdly New Font Engine

I knew these guys would rear thier ugly heads again sooner or later, they were shruged off a while back, in favor of 'more important things' such as scripting, graphics and mapping. Well, now the scripting and mapping is all done, so they have come back, only too happy to wreak havok on me.


The Dreaded Time-Based Movement/Animation

This actually isn't as bad as I make it out to be.
currently we use 'frame capping' to ensure that MW will never run _super fast_ on a very high end machine, this does, however, have some draw backs:

Potential loss of high-end machine speed

Unplayably slow on low-end machines

Very noticable shift in frame rate flug

So, I recently did some time based work, at work (for thier game), and after seeing the results I came up with these pros:

Noticable smoothness on high-end machines

choppier on slower machines, instead of slower

allows you to sleep off the rest of your time-slice, (os is happier)

velocities can be expressed in PPS(Pixels Per Second) and animations in FPS(Frames Per Second), much more intuitive

So the only real issues with implementing this system, is the current way we do motion. Currently when moving from one tile center to another, we say:

Interpolate between P1 and P2 over N steps, this works, but it has some problems.

As distance increases Pixels Per Step increases (which happens in iso =/ )

line segment transition P1->P2->P3, does not hold to the step velocity (gives 'pause' effect as slow speeds)

So, instead with time based motion, we will specify velocity as, Pixels Per Second, which will be a floating point value, time will be sampled in miliseconds from the game loop, and stored as a floating point as DeltaSeconds.

It is then as simple as, p+=d*pps*ds;

wherein p is position, d is a unit direction vector, pps is the pixels per second, and ds is the delta seconds.

There is, however, one Small problem =D

And that is, with the current system of interpolation, you are assured to get from Point A to Point B in N steps, however, with time based motion, you can ensure you get to Point B (by doing a check), however, you may have 'overstepped', now, the simple solution is simply:

1. Realize I've overstepped
2. Set me where I should be

However, this is 'technically' wrong. Assume that on your last step, you stepped 10 units, but it only requires 5 to get you to the end, that leaves 5 units that have been discared into the ether, now, if you have exceptionaly long path segments, this isn't a very noticable issue, but if your segments are very short(especially if they are shorter than a given step ammount), then you will not be moving at the speed you should, and you will notice an 'inter-line-segment pause'.

The Solution!

There is a very simple solution to this though. Asuming that our last step puts us over 5 units, we would want to use those 5, twoards our next path segment (if applicable). This is as simple as getting the distance between where you should be, and where you would have put yourself if you had used the entire step. You can then factor in this scalar distance into your next computation.

A little Optimization.

The last example required using the distance forumula, which, is a fairly expensive function in the grand scheme of things. There is a way around this which should yeild faster results.

Before Traversing a line segment, record it's length, then for each amount your position increases along the line, save the velocity used, when you finally come to the end, and realize you have overshot, you can compare, how much distance you have traversed, with the total distance you should have traversed, this will give you what is left of the line segment, and thus, how much you should add to it given your current movement amount, and with that you know how much of that movement amount is left over.

Time Based Frame-By-Frame animation technically suffers from the same problem, however it is ususaly not noticable, and the worst case of it(which is rarely encounterd) is 'strobing', that is, animation frames are being traversed faster than the refresh rate, and you are missing entire frames. This only occurs wil very fast moving animations.

Later, I'll discuss the evil font system =D


-Raymond