Motion blur

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

Yay, it's so much faster! I can run at 800x600x3 now, as long as the physics can maintain 180 fps.

Edit: I prefer playing with motion blur. :)
ˌɑrməˈɡɛˌtrɑn
User avatar
Z-Man
God & Project Admin
Posts: 11717
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

I'm disappointed :( I had planned to post something along the lines of "Bow to my superior gaming hardware", but look what I actually got (I fell into the attachment reversal trap again) :( My CPU sucks, I guess. I'll have to revise my "AA is fillrate limited on all of my boxes" statement.

While we're talking about fillrate: the accumulation buffer, due to the copying around of memory, eats away a lot of fillrate. Directly rendering to a texture (via pbuffers) sounds like the better option even if the accumulation buffer is supported.

I like how the blurring makes the swoops of the custom camera when you turn easier to follow.
I don't like the blurring generally, however.
Attachments
What I like about it is how it reduces your ping (but I still suck). This are four subframes per frame.
What I like about it is how it reduces your ping (but I still suck). This are four subframes per frame.
But I did get the AIs some time :) (Same settings)
But I did get the AIs some time :) (Same settings)
Live action shot from the net. These are six subframes per frame.
Live action shot from the net. These are six subframes per frame.
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

z-man wrote:While we're talking about fillrate: the accumulation buffer, due to the copying around of memory, eats away a lot of fillrate. Directly rendering to a texture (via pbuffers) sounds like the better option even if the accumulation buffer is supported.
I basically emulated the accumulation buffer. When the video is set up I create some additional pbuffer-related stuff, then leave the pbuffer context the current context. Then every subframe, switch to the framebuffer and draw the texture with 1.0 / ++count alpha. If it is the last subframe, swap. Finally, switch back to the pbuffer.

Do you have a better idea?
ˌɑrməˈɡɛˌtrɑn
User avatar
Tank Program
Forum & Project Admin, PhD
Posts: 6712
Joined: Thu Dec 18, 2003 7:03 pm

Post by Tank Program »

How come when you guys take screenshots you get the blurring but when I do I don't?
Image
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

Using in-game screenshots doesn't work. Experiment a bit with the code near the SDL_GL_SwapBuffers and make_screenshot calls.
ˌɑrməˈɡɛˌtrɑn
User avatar
Z-Man
God & Project Admin
Posts: 11717
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Jonathan wrote:Do you have a better idea?
Not for the basic operation. Maybe, if texture memory is plenty, it may be better to render each subframe into a separate buffer and blend them together with multitexturing.

What I'd experiment with: render four subframes s1..s4 in reduced resolution. Render the last frame at full resolution, too, call it s4'. Blend them together using .25 * ( s1 + s2 + s3 - 3 * s4 ) + s4'. The lowered resolution rendering will not cause any blurring when there is no movement. There will be artifacts, however.
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

z-man wrote:Maybe, if texture memory is plenty, it may be better to render each subframe into a separate buffer and blend them together with multitexturing.
I thought about that too, but decided not to do it because I'd need to manage more stuff, and didn't have anything working yet. I have something working now, and I have 64 MB VRAM, not the latest and greatest, but plenty, so I can give it a try. I'm not sure exactly how it works internally, but it may also improve parallelism. :)
ˌɑrməˈɡɛˌtrɑn
Lyx
On Lightcycle Grid
Posts: 49
Joined: Sat Aug 20, 2005 7:36 pm

Post by Lyx »

Just throwing in my 2 cents:
I like the motion-blurr idea and have a feeling that it would look great combined with a moviepack and other minor graphical tweaks to the game. IMHO its the last missing piece of the puzzle of which we didn't talk yet.

Of course, it would only rock if it can be done at acceptable FPS (like, at least 40fps@800x600 on a midrange-machine)
User avatar
iceman
Reverse Adjust Outside Corner Grinder
Posts: 2448
Joined: Fri Jan 09, 2004 9:54 am
Location: Yorkshire, England. Quote: Its the fumes, they make one want to play
Contact:

Post by iceman »

Tank Program wrote:Haha, it hates me, look @ this:
wahooo I have a new desktop background :lol:

thanks tank
Image He who laughs last, probably has a back-up
Image
Image
sorry about the large animated gif
User avatar
iceman
Reverse Adjust Outside Corner Grinder
Posts: 2448
Joined: Fri Jan 09, 2004 9:54 am
Location: Yorkshire, England. Quote: Its the fumes, they make one want to play
Contact:

Post by iceman »

oh yeah I forget to say that frame rendering should be limited to a multiple/sub multiple of the monitor frame rate for jump free refresh

is this possible to do ?
___________________________________________________________

example: just try watching a 60hz ntsc movie converted to 50hz pal (or vise versa) to see the bad frame jumping effect that we currently get in armagetron
Image He who laughs last, probably has a back-up
Image
Image
sorry about the large animated gif
User avatar
Z-Man
God & Project Admin
Posts: 11717
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

iceman wrote:is this possible to do ?
Yes and no. Yes in the sense that you just have to activate VSYNC in your video driver and let it take care of the syncing of full frames.

However, in the hackery framework presented here, the time of the subframes is taken more or less directly from the system timer instead of taking the time taken for the whole frame and equally dividing it into small pieces. So the subframes are not divided equally over the whole interval.

A full implementation would address this issue, and others too: text and the HUD should only be rendered once per whole frame. It costs needless performance and does not look good.

We have bad frame jumping? If so, I think we can blame it on the inaccurate timer we use in Windows :) (Code submissions to fix it welcome)
Or on the general fact that in order to determine the game time the next fame should be rendered for, you would theoretically need the time it will take to render it, but you only have data about past frames.

Lyx: this effect is more or less orthogonal to all other effects; the simple proof-of-concept implementation here shows that it can be combined with everything else easily. I'm pretty sure someone will find the time to build a full implementation for Bacchus.
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

I didn't do much with the multiple texture idea. Reason: Multitexturing is so awkward. I'm tempted to use a fragment program to replace the compositing. Multitexture compositing is virtually unusable when you need to do anything more complicated than previous + current or previous * current. I tried GL_MODULATE_ADD_ATI (arg0 * arg2 + arg1, or current * 0.25 + previous), but it didn't multiply (yes, I have ATI_texture_env_combine3), and it was hardly any faster.
z-man wrote:We have bad frame jumping? If so, I think we can blame it on the inaccurate timer we use in Windows :)
You know what's fun? When programs smooth the time when accurate microsecond times are available on another OS.
ˌɑrməˈɡɛˌtrɑn
User avatar
hang3r
Core Dumper
Posts: 188
Joined: Fri Sep 16, 2005 9:05 pm
Location: Australia

Post by hang3r »

ok so i set out to make timing more accurate for windows, what i got is this:

Code: Select all

#ifdef WIN32
#include <windows.h>
#include <sys/timeb.h> 
#ifndef DEDICATED
#include "rSDL.h"
#endif

void GetTime( tTime & time )
{

    struct _timeb tstruct;
    LARGE_INTEGER mtime,frq;

    // Check if high-resolution performance counter is supported
    if (!QueryPerformanceFrequency(&frq))
    {
        // Nope, not supported, do it the old way.
        _ftime( &tstruct );
        time.microseconds = tstruct.millitm*1000;
        time.seconds = tstruct.time;
    }
    else
    {
        QueryPerformanceCounter(&mtime);
        time.microseconds  = (mtime.QuadPart/(frq.QuadPart/1000000)) %1000000;
        time.seconds = mtime.QuadPart/frq.QuadPart ;
    }


    time.Normalize();

}
I tryed to add microseconds for windows, it seems really really wrong however, im not sure what i done wrong, anyone got any ideas?????

EDIT: By Really Really wrong i mean everything is jumping around all over the place.
EDIT2: fixed something, still doesnt work....
Last edited by hang3r on Tue Oct 25, 2005 7:15 pm, edited 1 time in total.
User avatar
Tank Program
Forum & Project Admin, PhD
Posts: 6712
Joined: Thu Dec 18, 2003 7:03 pm

Post by Tank Program »

We should check what PearPC uses for their timer on windows, because I know they got something that's pretty much 100% spot on.
Image
User avatar
hang3r
Core Dumper
Posts: 188
Joined: Fri Sep 16, 2005 9:05 pm
Location: Australia

Post by hang3r »

This would be 100% spot on, if i could get it to work.

EDIT: they would do it this way
Post Reply