Jitters during camera rotation, help?

Blitz3D Forums/Blitz3D Programming/Jitters during camera rotation, help?

Orgull(Posted 2005) [#1]
Hi there.

This is actually my first BB3D program (I've just come over from DBPro) and I've spent an hour searching the forums but I can't seem to solve this odd little problem.

Here is my code:
**********

timing = 1000/60

upkey = 200
downkey = 208
leftkey = 203
rightkey = 205

Graphics3D 1024,768,32,1 ; 1024x768, 32-bit, 1=fullscreen mode
SetBuffer BackBuffer()
camera1 = CreateCamera()
CameraRange camera1,0.1,1000
;AmbientLight 0,0,0

cube = CreateCube()
PositionEntity cube,0,0,10

light1 = CreateLight()

cubetexture = LoadTexture( "texture1.bmp" )
cubebrush = CreateBrush()
BrushTexture cubebrush,cubetexture
PaintMesh cube,cubebrush
Global camspeed = 1

;*****
While KeyDown(1) = 0

current = MilliSecs()

TurnEntity cube,0,1.0,0

If KeyDown(upkey) = 1 Then MoveEntity camera1,0,0,0.5
If KeyDown(downkey) = 1 Then MoveEntity camera1,0,0,-0.5
If KeyDown(leftkey) = 1 Then TurnEntity camera1,0,3,0
If KeyDown(rightkey) = 1 Then TurnEntity camera1,0,-3,0

Cls
RenderWorld

.time
finish = MilliSecs() - current
If finish >= timing Then Goto skip1 Else Goto time
.skip1

Flip

Wend
;*****

**********
What's happening is this: If I set the number on the first line to 1000/30 or 1000/45 or basically anything significantly different from 60 (desired fps) and if I get the camera close to my cube and then turn left or right, the cube "jitters". Specifically it appears to render twice in two different locations like the camera is rendering twice when I call flip or something.

Anyone have any idea what it is I've missed? I found several other posts with jitter issues but they didn't seem to help. And FYI my monitor's refresh rate is 85hertz not 60 so I don't think it's a refresh rate issue.

Any suggestions? Thanks in advance.


Sledge(Posted 2005) [#2]
If one of your arbitrary timing code rate and screen refresh rate isn't a multiple of the other then of course the display will jitter.

The variable Timing should also be a float.


Orgull(Posted 2005) [#3]
Ok I changed Timing, Current and Finish to floats... no change...

I don't understand your first statement at all... eg. Dungeon Siege runs at about 37-47 fps on my system but it never jitters. Also 85 is not a multiple of 60 so I don't see why only a setting of 60 provides smooth turning...


xmlspy(Posted 2005) [#4]
The way I control FPS is by using the Timer commands
My version of your code, just in case.
Graphics3D 1024, 768, 32, 1
SetBuffer Backbuffer()

Cam = CreateCamera()
Light = CreateLight(Cam)
Cube = CreateCube()
EntityTexture Cube, LoadTexture("Texture1.bmp")
MoveEntity Cube, 0, 0, 10


Timer = CreateTimer(60)

Repeat

	Cls
	TurnEntity Cube, 0, 1, 0
	Camera_Move( Cam )
	WaitTimer( Timer )
	RenderWorld
	Flip(0)
	
Until KeyHit(1)
End

Function Camera_Move( Cam, MSpeed# = 0.5, RSpeed# = 3 )
	If KeyDown(200) Then MoveEntity Cam,0,0,MSpeed#
	If KeyDown(208) Then MoveEntity Cam,0,0,-MSpeed#
	If KeyDown(203) Then TurnEntity Cam,0,RSpeed#,0
	If KeyDown(205) Then TurnEntity Cam,0,-RSpeed#,0
End Function



Sledge(Posted 2005) [#5]

Also 85 is not a multiple of 60 so I don't see why only a setting of 60 provides smooth turning..



Are you certain of your display rate? I also took the CLS line out so you could try that (it's best after Flip I tend to think). Also, you are waiting a certain amount of time before drawing each frame but never bothering to make sure that each frame you send is synced to the vertical retrace - this is why distortion occurs. You can either throttle that procedure by while...wending until the appropriate scanline is reached or simply Flip True instead.


Dungeon Siege runs at about 37-47 fps on my system but it never jitters


Probably it vSyncs, leaving only the remainder of the update rate into the monitor refresh rate to cause visual quirks... it's harder to spot these in a full, textured 3D scene - especially when the camera is in motion, especially when the view is being rotated rather than panned. Were Dungeon Siege a side-scrolling shooter, you would notice the jerking straight away.


Orgull(Posted 2005) [#6]
ARGH! Xmlspy I tried your code... changing to 30 instead of 60 brings the jitters just like my code does. But thanks for the obvious cleaning up of the code, I'll take some notes.

And Sledge, I am set at 85hz in 1024,768 but who knows, maybe DirectX is dropping my refresh to 60hz for some reason in fullscreen mode. Taking out CLS made no difference :(

I remember having problems with DBPro when I first started out, until I got everything under my belt. I'm sure if I fiddle around I'll eventually get it.

Thanks for the help so far though!


Sledge(Posted 2005) [#7]

Taking out CLS made no difference



Thought not, but as it is superfluous it is best to eliminate it from the list of possibilities (because it was in a non-standard place and drivers can be odd).

You really, really need to vsync to get a satisfactory image though. It's no good matching the monitor's refresh rate exactly if you're sending it each frame when it's, say, half way through its scanline cycle. Unless you sync, it's pot-luck as to which scanline you'll catch for the duration of your program.

Welcome to the forums, BTW. The issue of updating the display is a particularly thorny one on a platform like the PC, where the hardware is not fixed. Once you get used to Blitz you will find that there are other avenues to explore, such as so-called "delta timing" (personally I'm not a fan, but others swear by it).


sswift(Posted 2005) [#8]
The effect you are seeing is normal.

The camera is not jumping, and the cube is not in two places at once, it is just a trick of your eyes.

Movies run at 24fps. They look smooth, but they only look smooth because cameras have motion blur and computer graphics do not. Your computer screen updates at a minimum of 60fps. And even this appears to flicker to some people, like myself, so 85hz is becoming the norm.

Your eyes are sensitive to changes in brightness, and they have a long decay time so you see an image for a little while after the image has changed. With an image like this, the color goes instanty from white to black, and your eye takes a moment to adjust. Also your brain processes the information in funny ways. If a green pendulum swings back and forth and changes to red suddenly at the end of a swing, you will see the pendulum fade from green to red, over the course of the swing even though that is physically impossible because the pendulum didn't change color until the end of the swing.

This effect is caused either by your eyes or by your brain interpreting what your eyes see.

Either way, in order to get rid of this effect, you'd either have to have motion blur, which you can forget about if your game can't run at over 30fps to begine with, or you have to run at a higher framerate.

Graphics with lower contrast will reduce the effect. A white cube, or a textured cube, on a black background has high contrast so the effect is very obvious. In a game, things in the environment are roughtly the same color as other stuff around them, so your eye doesn't see the double image. Also, if the player controls the game with the mouse so the rotation speed varies, that appears to help too.

In short, you aren't doing anything wrong. Your eyes are. :-)


RiverRatt(Posted 2005) [#9]
You also do not need the cls in there for 3d.


Orgull(Posted 2005) [#10]
hmm... thanks for all the replies. sswift, I'm honoured to have you post in reply to one of my first questions. I've been lurking here for months and I've read many good things here (especially about your shadow system... nice work there).

Interestingly, my cube is grey against a black background so I see the point about motion blur (which I am familiar with) it just hadn't occurred to me in regard to gaming, but hey, you learn something new every day right?

Going back and looking at other games after having worked with DBPro has been a real eye-opener. I see a lot of tricks and shorcuts that I would never have noticed before.

But as for my framerate issues; right now I'm just practising, but I do have a project I intend to do with BB3D, and I want to use a fixed framerate system. The reasons are too many to explain here, but mostly it's due to the fact that I'll be "cheating" a lot of the animation using some very old 2D tricks and lookup tables etc.

Delta Timing won't work for this project since I have to coreograph every 3D and 2D animation according to a strict number of frames. My concern now is, what framerate should I pick? The lower I pick, the more effects and animations I can cram in, the higher I pick, the smoother it will appear but the less I can do with it.

Thoughts?

The game is an action-rpg (diablo) with slightly slower combat, using a "round"system (NWN) but with robot, so there will be lots of weapon effects and particles (which is why I need to cheat some of the effects by using 2D animation overlays)

What kind of framerates do you guys feel are acceptable for an action-rpg? (I mean WoW sometimes chugs below 20fps on my system and it's still playable, but on the other hand, when I finally got FarCry to hit 50fps with a ton of tweaks, it was sooo nice).

Yes, I am a framerate whore (sigh)


sswift(Posted 2005) [#11]
I think you should use Delta Timing to be perfeclty honest. I don't think there is anyhting you plan to do which would not work with it. Even if your characters are geosprites (a set of fixed 3d meshes each of which represents one frame of animation, as used in Quake 1) there's no reason why you can't move them smoothly through the world while changing the frame of animation being displayed at a fixed rate. Sure, the animation might display a frame a tiny bit learly or a tiny bit late, but only a tiny bit. You wouldn't notice the difference. Of course you WOULD stil notice that the animation is choppy.

As for what framerate to choose if you want to do a fixed framerate system, I can't really offer you a concret choice. It depends on your needs and what you are going to do. What the lowest system you want to support is.

The higher the framerate the more frames you need for 2D animations or geosprite animations. The memory costs for this can quickly grow.

If memory isn't an issue, then what you could do is make your animations run at 60fps, and then on low end computers drop every other frame if the PC can only render at 30fps, or drop every third frame if it can only render at 20, and every fourth if it can only render at 15. With a framerate of 30fps, then you're really limited to only 30fps or 15fps, neither of which are very smooth. And if you use 45 fps, then you're stuck with only 45 fps.

You also need to consider how fast the monitor refreshes though. A monitor might refresh at 60, 65, 70, 72, 75, 80, or 85hz. Those are the most common rates as far as I know. I think the standard right now is 85hz though.

The reason you need to consider this is because if you wait for the vertical refresh when flipping then you have to wait for the monitor. And if the monitor runs at a different refresh rate than your game, then you might end up running at a lower FPS than normal.

For example, if I have a 3D game, and I am using delta time, but also using flip true, then even though my game could in theory run at 60fps, if my monitor updates at 85hz, I might find that my game is only actually running at 42 fps because it keeps having to wait for the monitor and wastes half a frame waiting for it every other frame.

There is no real way to solve that problem that I know of, other than to turn off waiting for the vertical refresh, but that can lead to tearing. On monitors at least. I don't know how LCD screens react to it.

Anyway, as you can see there are a lot of issues to consider. I personally use Delta Time with a max framerate limiter so I can give some CPU time back to windows.




Orgull(Posted 2005) [#12]
again, some very good points. thanks sswift!

I ran some tests using the samples provided, I applied different timing systems on them, tried using flip 0 just to see... I was stunned that on my very crappy system, the birds demo runs at 470fps (fraps) in 1260x1024x32 fullscreen with 4xfsaa and 8xAF... mindblowing!

BB3D is by far faster than DBPro at handling tri's and entities (objects). I think surfaces may be an issue though... but there are ways to keep the number of surfaces down.

If I can get this much speed out of BB3D maybe I'll just go for a fixed framerate of 60fps and assume that my system is the lowest common denominator.

Specs: Amd Duron 1.3ghz / 1gb 333mhx sdram / radeon 9800 pro 128

Again, I'm stunned at the speeds I'm getting out of BB3D on my low-end system!


sswift(Posted 2005) [#13]
A radeon 9800 Pro is nothing to sneeze at. That was top of the line only a year ago. And 1gb of ram is twice as much as I have. 1.3ghz isn't great, but adequate for games that don't require a lot of CPU power. I wonder if Half Life 2 would run at an acceptable rate on such a system. I think it would. It is the 3d card which is the primary bottleneck generally.

The lowest common denominator is lower than a 9800 pro and 1gb of ram. The CPU speed is probably on the low end though.

I personally wouldn't consider 60fps my lowest speed if I was makign a shareware game. I would go for the largest market possible, and not more than a year ago I was still running a Radeon 7200, and that was faster than the onboard 3d my Dad's PC came with. And my 7200 wasn't enough to get 85fps out of my 3D Marble Madness game if I had a skybox in the scene. I got more like 60 I think with the skybox on. So it was just barely enough for a simple 3D game to get 60.

It all depends on what market you weant to target, and how long it will be before you release your game.

As for surfaces, I would try to keep below 200 surfaces. On older cards like I had that was around where I think it would run around 40fps. I dunno what my current card, a Geforce 6800 OC could do.


Orgull(Posted 2005) [#14]
agreed re: surfaces < 200... and an interesting point about how long before release. I expect it will take me bare minimum 500 working days to complete this project, so it won't be ready for release before the end of 2006. I figure my system will be the lowest common denominator by then.

And my target market will be people who value deep gameplay over visual flash. Of course there will be plenty of simple visual flash, but not at the Half-Life 2 or Doom 3 level, just enough to provide clear feedback for each choice of attack.

And my concern won't be finding a huge sales market. My concern is attracting attention to what I think is a more fun approach to game design. I'm hoping for critical success and recognition of some new ideas I have, not commercial success.

P.S. I played Half-Life 2 successfully on my system at about 15-30fps... it was good enough for me to get all the way to the end and enjoy it a lot!


Ross C(Posted 2005) [#15]
That surprises me. I don't think a radeon 9800 pro 128 and a GB of RAM will be low spec by 2006. I'd say a low spec, entry level pc would probably have onboard graphics, 256 - 512 RAM and 1.5 Ghz, slightly forward thinking.


Orgull(Posted 2005) [#16]
Well, Ross C, that's quite possible... but I'll have to set the line somewhere, so I'm aiming for near my specs... memory being the critical part. I can always test my code on my old P2 450mhz w. 256mb ram and a Geforce MX 440. Wonder how well that would work.. heh heh.

And honestly I think My CPU is already low-spec. I would say my ram is low-spec in speed but high-spec in quantity. And the video cards rocks frankly, that I have to admit.


Ross C(Posted 2005) [#17]
That sounds like a good test system for the absolute minimum :o) Deal with your surfaces well, and you'll be surprised the extra fps you can get :o)


sswift(Posted 2005) [#18]
Ross:

This is the second lowest priced PC on Best Buy.com
http://www.bestbuy.com/site/olspage.jsp?skuId=7118558&type=product&productCategoryId=cat01172&id=1109233804582

For $500, you get:
2.9ghz processor speed
512mb of ram
16x DVD Rom
80gb HD.

But you also get:
Integrated Intel® Extreme Graphics with up to 64MB shared video memory.


That last bit will be your bottleneck, but I'm not sure actually how fast that chip is. It probably is pretty crappy. Probably less than a Radeon 7200 in performance, like on my dad's PC.

And I don't know if you can upgrade the video. It may not have an AGP port, or PCI-E ports.


Orgull(Posted 2005) [#19]
interesting link sswift...

I'm counting on gamers having enough self-respect to at least have a reasonable if not decent video card. If I were using an Intel Extreme Integrated I sure wouldn't want to tell anybody, heh heh!

I think my real problem will be surfaces... but I'll experiment for now and hopefully address that in a new thread later :)


Ross C(Posted 2005) [#20]
Dam, that's a good price. But alot of people still have the PC's they bought 2 - 3 years ago. But i agree any person wanting to play games on their computer, with have something in the way of a gfx card.

I think your PC prices are better than UK ones ;o)


sswift(Posted 2005) [#21]
Ross:
I think the price of PC's has recently dropped because of competition from products like the $500 Mac Mini, which has half as much ram, and no upgrade options. :-)

I think another part of the reason is Microsoft is afraid of Linux. Places like Wal Mart want $500 PC's to sell, and Wal Mart gets what they want. Microsoft on the other hand was charging too much for Windows XP, and it was preventing this price point from being reached. So Wal Mart was talking about using Linux instead. Microsoft probably quickly reduced the cost for OEM's to put XP on systems so that they could reach the price point Wal Mart wanted.

Do you have Wal Marts in the UK? Do you have many of them? Maybe that is why your prices havan't dropped as much?


Ross C(Posted 2005) [#22]
We don't have Wal-Mart, but we have ASDA. And i'm sure there part of the Wal-Mart chain :o)