Game Tweeners
Remember those Tweeners from those old cartoons? well here is an idea to use them for games.
Basically the idea is like this:
You get your main graphics engine to make maybe 25 frames per second, and give the next frame to the tweener (instead of the screen).
The tweener generates frames *as fast as the moniter can display* so say your graphics engine is producing 25 fps and your moniter can support 100fps, the tweener would produce four frames for each frame it recieves from the engine.
warning, hard to understand ahead! (sorry)
To make the tweened frames,
the tweener would:
store the last frame (the one before the current one, as a template)
store the current frame (last frame produced by the tweener)
store the next frame (frame produced by graphics engine)
find all of the pixels which is the same between the last frame and the current frame, place it in the frame-buffer and mark where they are as rendered.
I am using frame-buffer in a loose sense of the word, which is a vertual screen, which partly chenges as new data is fed to it. (say if it is given information on a group of pixels it would update where they are, but not the rest of the image).
And find out how many groups of pixels move (would probably use an edge-finding algo- which does not include diagonals- to find out things like this)
For every group of pixels that moves,
mark where it is as unrendered
Find out how fast the group must move (how far it has to move / time it has to move there)
Find out where the group of pixels has to be and
mark where the group of pixels are as rendered
place it in the frame-buffer
next group
for every pixel which is unrendered
find the coords of that pixel and store in x and y
find the pixel that occures at those x and y coords on the last frame.
add that pixel to the frame buffer.
next pixel
Thats about it,
Is this already used/do you have any comments/suggestions/?
Please post
Just in case you misse what i said in the threads body.
Tweening in games would allow consistantly heigh fps figures (like 160fps!).
It does this by creating in-between frames, like interpolating in-between two frames made by your graphics engine.
Just an idea
DENC
Tweening in games would allow consistantly heigh fps figures (like 160fps!).
It does this by creating in-between frames, like interpolating in-between two frames made by your graphics engine.
Just an idea
DENC
Quote:Original post by python_regious
Seems a little pointless to me. Might aswell just render at a higher framerate.
Yes, I agree. Can you elaborate Nice Coder?
The problem I see is that there seems to be too much overhead for something that's supposed to help the system. I'm talking about development time and application speed. It's better to devote this time to achieving a normal higher framerate.
It's a cool idea though. I'd like to see a demo to prove me wrong sometime :)
It's a cool idea though. I'd like to see a demo to prove me wrong sometime :)
The reson to use this, rather then rendering at a heigher frame rate is because rendering takes up too much time to be done at very large FPS (100-160). Now the tweening process would be much faster, as there would only be moving of data (pixel data) inside the GPU.
In order to tween effectively, all the tweener would need to is:
Find out what has moved inbetween the last frame and the next frame(hard part, unless the rendering code stores what has moved)
figure out how much it moves per frame (div/bitshift if lucky)
Figure out how much it has to have moves (mult/bitshift if lucky)
place it back in the fast buffer (Most likely a sto on the GPU).
And figure out what hasn't been changed (memory operations,and a conditional jump?- not sure).
All in all there would not be much overhead, because all its doing is pixel moveing rather then making them!
"It's a cool idea though. I'd like to see a demo to prove me wrong sometime :)" (from okonomiyaki).
Me too!
In order to tween effectively, all the tweener would need to is:
Find out what has moved inbetween the last frame and the next frame(hard part, unless the rendering code stores what has moved)
figure out how much it moves per frame (div/bitshift if lucky)
Figure out how much it has to have moves (mult/bitshift if lucky)
place it back in the fast buffer (Most likely a sto on the GPU).
And figure out what hasn't been changed (memory operations,and a conditional jump?- not sure).
All in all there would not be much overhead, because all its doing is pixel moveing rather then making them!
"It's a cool idea though. I'd like to see a demo to prove me wrong sometime :)" (from okonomiyaki).
Me too!
GPU's are not designed for read back and will not likely be designed for read back in the future. Also, due to lighting and perspective, it is not a common situation that "pixel groups" will remain the same color and situated the same, but simply transpose.
The idea is good.
Even if it might be too expensive to really increase the frame rate, it might give a COOL EFFECT. Imagine a game scene where the character has something like a dream flashback or so, you might render only at 2 FPS and interpolate in between.
In order to do the interpolation, you might look at how they do motion prediction for video compression (e.g. MPEG). In order to achieve higher compression rates, they don't compress the difference (current frame - old frame) but the difference (current frame - prediction of current frame based on older frames). If you can predict frames in the future (extrapolation), you might also be able to interpolate between frames with these methods.
Lutz
Even if it might be too expensive to really increase the frame rate, it might give a COOL EFFECT. Imagine a game scene where the character has something like a dream flashback or so, you might render only at 2 FPS and interpolate in between.
In order to do the interpolation, you might look at how they do motion prediction for video compression (e.g. MPEG). In order to achieve higher compression rates, they don't compress the difference (current frame - old frame) but the difference (current frame - prediction of current frame based on older frames). If you can predict frames in the future (extrapolation), you might also be able to interpolate between frames with these methods.
Lutz
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement