Confirm Bloom-Effect bug

by nitrox1 on 09/07/2006 21:08, 16 messages, last message: 09/14/2006 23:45, 1493 views, last view: 03/29/2024 06:34

Hi,

I'm not sure if it is a bug or not in the current release.

Turn gfx-effects OFF:
-Load nmap8_d
-use the jump-pad to get the 200-shield
It's really easy, or ?

Now turn Bloom-effect (120) ON.
-try to get the 200-shield
Now it's harder, because I'm not as fast as without gfx-effects.

Please try several times.
Btw. : I'm using the current Linux-Port

Anybody have the same issue ?

Thx. nitrox

   Board Index   

#1: ..

by makkE on 09/07/2006 21:52

It´s normal. The speed a jumppad pushes you depends on fps. Actually all physics depend on it. It makes it hard for mappers to balance jumppads, since they must work on low fps, and on high fps.
But it has nothing to do with bloom itself.

reply to this message

#2: Re: ..

by nitrox2 on 09/07/2006 22:16, refers to #1

Thanks a lot for the info. Then the nice gfx-effects are not an option for me.

Bye. nitrox

reply to this message

#3: yeah....

by metlslime on 09/07/2006 22:48

i have this problem on metl4 ... becuase of the normalmapping, i can't run at the same resolution that i use when playing non-normalmapped levels.

I think I remember that Cube's physics were changed to be framerate-independent (by having a fixed physics update frequency) but I guess that feature didn't transfer over to Sauerbraten.

Shit, what's 9 times 3....

reply to this message

#4: ..

by chead on 09/07/2006 23:25

I haven't looked, but my guess is that Sauer updates the world after a certain amount of time but doesn't account for time left. Say it updates every 30ms or something, and 40 ms passes since the last frame. It probably doesn't count that remaining 10 ms, meaning the physics aren't quite right.

But, I could be totally wrong.

reply to this message

#5: Re: ..

by pushplay on 09/08/2006 01:39, refers to #4

>> But, I could be totally wrong.

Yeah, no one has does physics that way since the c64.

reply to this message

#6: ..

by chead on 09/08/2006 03:12

How do people do it now?

reply to this message

#7: Re: ..

by ethan592 on 09/08/2006 06:53, refers to #6

calcs based on velocities per second. that way the time since last frame can be used to get the correct amount of movement.


i didnt have that problem, still got the armor. oh wait, im running at 199fps (and its a laptop :))

reply to this message

#8: ..

by nitrox4 on 09/08/2006 11:01

yes, exactly, 199fps and no problem to get the armor. :-)
Until fps goes to ~<90 with bloom. :-/

reply to this message

#9: lol

by ethan592 on 09/09/2006 06:53

i still run 199 with bloom! and the new water, and everything else. gotta love the 7900gs with 2.16ghz core duo and 2gb or ram lol

reply to this message

#10: Re: lol

by Passa on 09/09/2006 07:22, refers to #9

You need to learn not to show off mate :/
Anywho, 7900GS cards are poor value anyway, considering you can get a 2.4GHz Intel Conroe system with a 7900GT for $1500 AUS dollars (btw thats with 400GB of RAID 0 storage ;)

If you want to lower your computer self-esteem (about your specs) go to www.tomshardware.com

They do fucking stupid benchmarks, and test things like quad 7950GTX2 systems :(

reply to this message

#11: The short explanation

by pushplay on 09/09/2006 19:04

The short explanation for why your frame rate makes a difference:

Ogro moves at Am/s. So if it's been 12ms since the last time his position was calculated you take his velocity and multiply by the time and that gives you his new position. That's grade 11 physics. The problem is that all the math has limited precision so there's always going to be a rounding error. At X fps you keep getting rounded up but at Y fps you keep getting rounded down. This is why a lot of games now lock the physics frame rate.

reply to this message

#12: Re: lol

by ethan592 on 09/09/2006 19:58, refers to #10

lol passa. im an engineering student i use desktops that will beat the crap out of anything every day. and that 7900gs was in a laptop and is a better value than the other high end cards once overclocked. i wasnt really trying to brag but sorry.

(finally a math problem that doesnt equal 7 lol)

reply to this message

#13: Re: The short explanation

by metlslime on 09/11/2006 03:07, refers to #11

The formula you mention for position:

position += frametime * velocity

isn't much of a problem. Linear motion isn't affected much by framerate becuase the precision errors only result in a slight change in distance travelled. The real problem is the other formula:

velocity += frametime * gravity

Parabolic motion is much more affected by framerate becuase the path of an ballistic object gets replaced with a series of line segments that deviate more and more from the ideal path depending on framerate, and that dependence is worst when framerate is lowest (becuase you get the coarsest approximation of an arc.)

reply to this message

#14: Re: The short explanation

by pushplay on 09/12/2006 03:56, refers to #13

Good point, I forgot about the other accumulating error.

The final issue of course is that with some collision detection algorithms (like in Cube) a sufficiently low frame rate lets you pass through geometry. Anyone with a program that can hammer the cpu for a short burst could jump through a wall.

reply to this message

#15: Re: The short explanation

by Passa on 09/12/2006 08:22, refers to #14

"Anyone with a program that can hammer the cpu for a short burst could jump through a wall."

Stop giving people ideas! Strange anyway, I havent noticed anything different in the physics running Sauerbraten on my laptop (<6 FPS)..

reply to this message

#16: ..

by CCmachine_firefox2 on 09/14/2006 23:45

hmm if i use /maxfps 5 does that also lower the physics calculation rate?

reply to this message

   Board Index