Due to my state of newbieness to the matter..

nevermind, i'm also a newbie for this kind of projects, or at least i was before karga :wink:

if I understand correctly, you're basically normalizing game animations and events by checking how fast the application is running?

yes, exactly. the idea is to increment the game state (animation indices, positions of moving objects etc) as much as the time elapsed since last update

say you have an opening door animation which you want to last for 2 seconds, and your fps is 50 (= 1/50 seconds elapsed) you increase animation index of door by 1 / (50 * 2) each frame

r a f t

assuming constant fps it is trivial to decide where that user will be in each frame. with un-constrained fps it's somewhat more complicated

himm, i'm re-thinking now about the subject and, assuming constant fps even in an un-constrained enviroment may be a good assumption. normally fps doesnt change that much if something doesnt change radically (such as world size doubles or user opens another cpu eater application).

so, measuring fps every -say- 5 seconds and assuming it constant may also simplify things. i guess this way fps increases slightly since number of updates decrease. a drawback is, if one moves with key strokes every frame, fps/ups results in a smoother feeling

sorry raven, filling your forum with self thoughts  :oops:

r a f t

hello raven,

So, to sum up, my question basically is: is this the way to go? Or is there some other method that's better when making 3D games? For example, should I be looking into threading each type of manager so it runs independantly?

as a rule of thumb, you should avoid threading whenever you can. it only complicates things and cost some performance (due to syncronization and context switching overhead). use threading where you have to do so (for example when use blocking i/o)

in karga, to simplify things, i targeted a constant fps. even collision detection and other non-render stuff doesnt cost much compared to rendering, so if i cannot reach targeted fps, i simply skip rendering for some frames and update the game state only. this method depends on measuring render time, something like this:


while (running) {
    long startTime = System.nanoTime();
    gameUpdate();
    gameRender();
    long elapsedTime = System.nanoTime() - startTime;

    if (elapsedTime < expectedElapsedTime) {
        // sleep here for some time
    } else {
        // do some gameUpdate without render
    }
}


with this approach, even on a slow machine updates stay closer to high targeted fps (50 for instance) so you can decide animation indexes etc depending on targeted fps

instead of controling animations and other things (movements etc) from a central location i've also defined a FrameListener interface which lots of my 3d objects implement. so they can 'take care of themselves'

public interface FrameListener {
    public void timeForNewFrame(/* pass here whatever you want like frame no, world etc*/);
    public void timeForRender(/* same as above */);
}



so what i do in gameUpdate and gameRender is:

private void gameUpdate() {
    for (FrameListener l : frameListeners) {
        l.timeForNewFrame(/* some parameters */ );
    }
}
private void gameRender() {
    for (FrameListener l : frameListeners) {
        l.timeForRender(/* some parameters */ );
    }
}


hope this helps :wink:

r a f t

Undersampling simply renders at half the resolution and doubles  the rendered pixels in x- and y-direction. Maybe scaling is faster because it can benefit from hardware support, but i somehow doubt it, because it's a non-accelerated BufferedImage.

on my box (both redhat and win xp), scaling runs almost 10% faster then undersampling. swing uses VolatileImage (accelerated) by default for back buffer, but the result doesnt change even if i disable double buffering. strange :?: (btw, i dont if copying from a non-accelerated image to an accelerated one offers any improvement)

anyway, i preferred the undesampling way since it makes things (like 2d blitting) much easier. and 50% undesampling makes almost a 50% speed impovement so i see no point in using other scaling ratios

r a f t

you can't deserialize old stuff with a changed class. So where is the actual difference?

you can, even if you changed the class incompatibly. you can change method names, signatures even add new fields (they are simply set to nulls or zeros during deserialization). i'm not sure what happens if you change field types or remove a field but the others dont break deserialization

r a f t

+1
although not reading all posts, i'm here too :wink:
r a f t

if you say so..  :roll: