OpenArena Message Boards

Due to the fast nature of the game there's always framerates in the hundreds commonly found though most modern flat-panel monitors these days are stuck in the 60hz hell so they miss out on the visuals of the extra frames CRTs enjoyed.  

Would it be possible, in theory, to take all these unseen frames above 60hz and combine them all to a separate framebuffer that gets rendered in the 60hz?  The video card would technically still render the higher frames and the input would also be that responsive, the buffer swap would only happen in 60hz intervals and you'd see these frames.  Vertical sync would make this impossible though

Maybe scaling it down to locking it at 30fps would be useful for things like Youtube for demo capturing...

You should be able to record videos of demos at any framerate lateron, given that your monitor supports it. Currently the engine lacks functionality to do offscreen rendering, unlike q3mme (which also has motion blur iirc).

Not that i have any experience with this, but since motion usually involves an accumulation buffer:
Would it be possible to:
- disable v-sync and render more frames than the monitor will display
- blank this buffer when a frame has been displayed

That way the image you see would be based on all frame rendered in between display refreshes. And i have a strong feeling our brains will be able to use the extra information and make it appear smoother / easier to see where rockets are going.

I personally use a different solution, my middle monitor is still a big old crt. But perhaps a feature like this could persuade me.

You can't see more than your monitor can render as you look at your monitor to see the game. The monitor just works on like 125Hz. It will look like you render a lot more frames when the framerate is 125+, but that is actually just the framerate drops which being whiped out (a bit).

Asuming, 120 frames on a 60Hz screen:

Your monitor can display a picture which is composed of 1 one frame that is between 0 and 8.3ms old superimposed over a frame that is between 8.3 and 16.6ms old.

So in case of a rocket, you will see 2 rockets, the top one beeing a slightly more current version.
Having extra rockets in your display will (i think, and this is pure speculation) help your brain interpolate the motion of the rocket.

Edit: so the gap (visual difference) between frames is smaller than normal

I know there exists 120Hz screens (still missing 30Hz IMO) but you could easily run openarena at 500 - 800 fps. (which would probably be awesome)

Tried the sample-some-5-frames-and-then-mix-them-in-a-fragment-shader method.
(http://leileilol.mancubus.net/crap/mblur9.jpg)


It works okay on a 60hz screen, but varies too much with framerate.  It definitely does feel smoother though, rather than jerky and tearing.

That actually looks awesome!

Could you make a seperate branch on github for this, i would love to check it out.

(Since i've replaced my CRT i have a renewed interest in this area)

The motion blur is actually available in the github master, but the internal fallbackshaders don't work (which currently cause compiling issues - I wlil take this out of the makefile on the next commit BTW).  You'd have to copy the glsl files from code/renderer_oa/glsl to a glsl subfolder in baseoa to get it to work


Also I don't have the reduction implemented properly yet (i.e. showing 4 frames for 240fps, 3 for 180, 2 for 120 and just 1 for 60)


At 240fps it definitely feels more fluid on a 60hz screen, so it does seem effective to me.  There's also other methods for doing this via vertex shaders on models with alternating interpolated values for animation blended (which is what CryEngine3 does IIRC) but that's too complex to do ATM.


I wrote these shaders (leifx, motionblur) because I do miss my CRTs and older video cards :D :(

I've tried it, and i like it a lot! It really feels smoother; i can do my usual fast movement again, without loosing track of where i am!

So i'm actually loving this, please don't take it out ;).

I'm now trying to implement a more oldschoolish way for motion blur in addition - the accumulation buffer


So far it's working though I did have to tear sdl_glimp.c a bit to get it to init with the accumbits neccessary.

It's more fadey and less smooth than my fragment shader method though, and i haven't committed it yet.