Timing executable inside

Hi!

Kindly please test the following in full screen and windowed mode. I am looking for your feedback on if it is smooth and has expected behaviour for you.

Many thanks in advance!


EDITED: NEW version! :) Please test with a variety of modes, flips and fullscreen or windowed, thank you!



http://www.redflame.net/files/timing2.zip




Please post if you are using an amd or intel processor and basic specs of your pc thanks!

runs smooth across the board here... (2.5 Ghz GFfx5200 , 1.8 gHz Nvidia 6100, down to radeon 733mHz 9200)...

--Mike

Smooth as the hairs on a frog's ass. Runs 100% perfect in windowed or fullscreen, on all three of my Windows systems.

GeForce FX 5200 Intel
GeForce4 MX 4000 AMD
GeForce2 MX 400 Intel

All systems with DX 9.0c & XP

My brother reports:


He can also slow it down horribly just by recieving an msn message, or invoking the yellow rollover help text on the task bar for instance.

I have personally noticed blitzmax executables stutter like mad in situations without timing, where blitz3d ones did not previously. Is this because it has a low base priority or something? I would like to increase the base priority.

Fresh in
Some testers have reported it stuttering when small background tasks happen - things that never slowed down Blitz3D or any 3D app and these are some of the theories:

* The windows procedure is causing stutter

* Bmax is getting messages sent to it and for some reason its doing more work at that time

* paint message may be the cause from other apps


We need to be able to control how friendly the app is? What suggestions do the more techincal savvy among you have?

Smooth AMD 64 3200 (2.2Ghz)

@One Eyed Jack: I had the same stuttering problem.

To fix it temporarily: Run the program, open task manager and go to processes, right click 'main.exe' and change the priority to above normal.

This removes the stutter on my setup. Unfortunately the rest of the sytem becomes a bit unresponsive.

This whole timing/stutter crap is getting on my nerves. I wish BRL would fix it. It can't be about background tasks causing stutter. I can simultaneously play Doom 3, burn a dvd, have NortonAV running and pack a few gb sized winrar archives with no stuttering going on in the game. It can't be about timing routines or graphics cards or any hardware because changing the priority would not fix it.

What gives with a simple ball demo stuttering?

maybe that's it... is there a function in BMax to stop the app from listening to windows messages when it has the focus...

--Mike

IIRC, you can change the priority of your app via an API call, when you start your exe.

I don't think changing the priority is the solution. I think it is windows messaging/paint/process or something.

Guess what? try this OpenGL version and report back with stutter bugs... for my brother, the stuttering went away with the opengl version - even when he got tooltips (it became unbearable on dx).


If you had stutter before, PLEASE download this opengl version and and try again!


edited: http://www.redflame.net/files/timing2.zip

The OGL one stutters here, worst than the DX version.

OpenGL version runs fine on my 3 systems, too.

both are smoother than a really smooth thing from smoothsville slipping down a smooth slope smothered in soft warm butter.


mmmm... butter....

It could be windows messages / paint / something else. Need skidracer to confirm...

both versions smooth in full and windowed on mine. I have virtually nothing loaded though. Nothing in the system ray except Avast, I've even reduced my services that are running.

1) What timing method are you using?

2) Can you make a version where it moves faster, stuttering is much easier to see if it was moving say 5 times faster? Or do like I did and have several at different heights. Also it's too slow to spot any vertical tearing. Mind you did you implement Skidracer's vertical tearing in windowed mode fix?

3) Do you have the anti-lag fix enabled too?

Btw, I really think you are on the right track with windows messages or background tasks etc interfering with Max. I came to this conclusion myself and posted about it recently. It's why I've been asking about doing event-based programming instead of just a loop. It seems that some systems do background crap and then a frame or two aren't rendered, then the logic catches up in the next frame and moves it twice as far (as it should) this is the stuttering *some* people are seeing. Combine that with the fact that some video cards exhibit vertical tearing even in full-screen mode and we are fighting a difficult battle. Even though I don't seem to be able to get *some* people to understand this ... I maintain the problems are either a) hardware/driver based (i.e. cards not being able to update regularly in a windows environment. Also the full-screen tearing is clearly an issue with DirectX not getting correct info from the card driver about Vsync) or b) windows just plain interfering and Max not being able to ignore it, or c) combo effect. Oh and stick TFTs in the hardware problems category too as stuff is rough on my laptop.

Both versions are smooth here, in windowed and fullscreen. I wish I could get my B3D apps to be this smooth - I always get jerking/tearing because of background tasks. :/

Big10p: Hmm, that's what we think people are getting in BMax! I must admit tha BPlus did seem pretty reliable in this department.

Before I installed wireless internet access (and consequently, a firewall and anti-virus), this machine used to do super-smooth updates with 'VWait : Flip False'. Not anymore, though; so I guess it must be the extra background processes that are screwing things up. :/

Just played Luxor: Amon Rising. The rolling balls on the title page are super smooth in full-screen but not in windowed mode. Also played Heacy Weapon, the game is super smooth in full-screen but in windowed mode the planes occasionally jerk as a frame is dropped. So it's not just BlitzMax then, in fact mine and robs frameworks actually seem smoother that these top selling pro games, however, perhaps we are doing less on screen or using less CPU? Heavy Weapon is only 640x480 though.

Also played Bricks of Atlantis. The scrolling on the options page isn't that smooth in full-screen mode, but it shows signs of random vertical tearing in windowed mode + is still not smooth. I think the loack of smoothness is just that it's updating at 30 FPS or something. So another PRO game, not perfect ...

Both versions completely smooth on my system, both windowed and full-screen. (They better be at 100% CPU usage just to move a single object :) ).

AMD Athlon XP 3000+ with 1 gig RAM, 128 meg ATI Radeon 9600 Pro, XP Pro SP2, DX 9.0c

New version with flip 0 and multiple objects.

I have played plenty of super smooth windowed games such as ut2004.

As requested, here is a new zip. It has two executables, which do far more. Also I use flip 0 in these new exes (two exes inside, one for ogl) - just to see if there's any variation in flip. I am using fixed rate logic like you are grey. Anti lag fix is enabled but not anti tear as thats not important to my game at the moment (my game isn't fast paced).

Please try in addition to the above ones everyone... I'd prefer if you tested all 3 because of the flip stuff.

http://www.redflame.net/files/timing2.zip

OEJ: I'll try it now. Flip 0 should give tearing (oh I see you mentioned that) Thing is with tearing, I think some people are mistaking it for jerking as it can give that impression.

Re: UT2004, sure it's smooth but do you think 3D games just have a different feel anyway. Most have vertical tearing unless you put VSync on, but sometimes actually stuff like Doom3 etc does miss a few frames but when it catches it it's not so bad in 3D ...

Between us, we've got to crack this nut!

I am pinpointing the problem with kenshin and my brother's help. It seems to be windows messaging based and task based, and not dx or ogl specific.

He says silly little things like moving windows just over the main dx window speeds it up dramatically, from 116fps to 400(!) fps and so forth, and generally doing tiny things in the os will cause wide fluctuations in framerate. And he dare not run an instant messenger like msn in tandem with it.

Smacks of some lower level problem with bmax's talking with windows?

I get a slight jerking with the new version. It's the same in both DX/OGL and windowed/fullscreen.

OK, both are TOTALLY smooth on my PC Even with 1000. btw, make +/- go in 10 increments as 1 takes too long to get high. With 2000, in windowed mode, I can see it's not rendereding every frame on the fast objects but that's to be expected, it's still "smooth" but moving in bigger chunks. Some may call that "jerky" but it's consistent due to being half the framerate.

1) I can't see *any* vertical tearing in either mode, thus I'm suspicious it's truely Flip 0.

2) Did you make Skidracer's Vwait fix to the Dx module? You may have left it on and it affects flip 0 too.

3) How about a key to change flip modes (F or something).

4) Is the antilag fix Indiepaths latest one?

5) I see that it's not using Set Blend AlphaBlend...also are you using automidhandle, this antialiases stuff too.

[edit] Sorry my specs are P4 3.2GHz Hyperthreading, 1GB RAM, XP SP2, Radeon 9800XT 256Mb (was good once)

It is truely Flip 0.

I have never applied skidracers fix.

Good idea!

As far as I know.

I forgot to use setblend alphablend :) Will fix this stuff now.

well I believe you of course I just wonder why there is no tearing, it doens't make sense ... What Hz is the window set too?

@One Eyed Jack: Was crashed out. Woke up just in time I see. Both new tests are perfect. No tearing or jerking or anything in either fullscreen or windowed mode. Even when over 1000 balls or just 1 like before. What's the secret?

OEJ: hmm this is weird, I just change my flip to flip 0, and I'm not getting tearing in my game in full-screen or windowed mode, this doesn't make sense as a few days ago it DID tear...

Rob, both of the new ones work perfectly on my 3 systems (specs in previous post).

Hi,

New Deluxe Version!
~~~~~~~~~~~~~~~~~

http://www.redflame.net/files/timing2.zip

This one has been updated yet again - you can choose flip mode, and it has many other little fixes... lets hope some meaningful results arise from it. It also is compiled with Blitzmax 1.20.

First finding: notice how with flip 1 or flip -1, things seriously slow down in the pc (everything slows down) WHEN you drag another window in front.
With flip 0, it does not seriously slow down the pc when you drag another window in front! Weird...

@kenshin: well it's just flip 0! weird huh..?

OEJ: OK I boosted up the shapes to > 2000 and it starts to slow down and jerk a bit. This is simply because it can't render everything so frames are skipped and the logic catches up in a jump. I DO notice tearing with Flip 0 after all in yours (when I boost the shapes right up to say 5000 it's easier to see on faster objects) and mine (when I added more UFOs), but it goes away with the other Flip flags in full-screen BUT NOT in Windowed mode (this was the original vertical tearing bug I posted that Skidracer made a fix for that I put in my latest UFO test) i.e. all flags show tearing.

Kuron and others must be seeing tearing too in windowed mode if they boost the shape count up as there is nothing in BlitzMax to stop it.

it doesn't jerk on mine at all regardless of objects. they begin to have a higher step rate but they do not jerk. I have noticed many little discrepancies about how blitzmax starts to slow down. I think I've taken this test as far as I can and I have no choice but to go with Flip 0 in my game as it is the only one that remains smooth on every pc tested in this thread (kenshin otherwise stalled badly).

These new versions are perfect. I can't make it jerk or tear regardless of what I do. Two possibilities:

- Fixed in BMax v1.20
- The flipmode that you're starting in (-1) is doing something which makes the subsequent flipmodes work correctly.

Is it possible for you to upload source so I can tweak to find out exactly what's causing it on my box? Just a thought, it may save you some time. I'm still on v1.18 so I can eliminate the first possibility immediately. The other one may take a 'lil longer.

I bet that certain geforce cards are build around updating via Flip 0 (i.e. as fast as possible) and thus when we force them into Flip 1 or -1, everything slows down a lot and also jerks start appearing due to missing frames.

OEJ: You do get tearing though with Flip 0. Put enough objects on screen and you'll see it with Flip 0 in fullscreen, it's quite subtle as your shapes aren't moving quite fast enough. This is on the new 1.20 BMax version btw.

@Grey Alien: I see what you mean. Barely noticable horizontal lines through the fast moving balls in fullscreen with over 1000 balls. This doesn't happen in mode 1 or -1.

My brother gets slight jitter on his 9600XT and major slowdowns when moving another window over the bmax window.

I personally get major slowdowns as in crippled pc, when I move any os window or program over the bmax window using flip -1 or 1.

This is on a dual core pc with x1900XT card....... makes you wonder what the hell max is doing?

Higher step rate is a good-ish term, but I think you really mean higher step value (not rate) when it slows down. As actually you get a higher step "rate" with LESS objects and the "rate" drops with more obects as the value/gap increases. Comprende?

Anyway, the jerks seem to happen for 0.5 seconds after going from full-screen to windowed mode or if I do something else one the syste. Actually I just tried running my UFO demo at the same time and it jerks AND so does your one (DX and GL). Clearly other running processes can mess up Max and it drops frames...

btw, any chance of posting/emailing your mutex code that prevents too instances running at one, it's neat. I did it for a commercial app. in Delphi once but wouldn't mind seeing a BMax version :-)

Kenshin: Yeah that's it, you should get those lines no matter what the flag in windowed mode...

OEJ: moving another window over the demo doesn't affect it on my PC. If I boost the shapes up to 3000 ish then the window moving around is a bit slow.

I guess we are just going to have to bite the bullet and choose a method so that we can get on with a game. My demo has music and sounds too and a background, and fonts, and animimages, so this might all be making performance worse on some PCs.

[edit] In fact in my demo I have an FPS counter which counts the number of flips per second. Now this is normally rock stead and the same as my desktop Hz (in windowed mode) but If I stress the app, the FPS can drop, this is the jerks people are seeing as the logic catches up. You could add an FPS counter to yours, stick it in FLip -1 mode, and find the borderline between full FPS (i.e. desktop Hz) and half that (i.e. draw taking too long) On this borderline, sometimes it will render full FPS and other times not. This will result in jerks, unless Flip 0 is on. It's the same thing in FPS games of course. PLus it'll be more obvious on even faster moving shapes.

Const ERROR_ALREADY_EXISTS:Int = 183

Extern "win32"
	
	Function CreateMutex:Int(lpMutexAttributes :Byte Ptr, bInitialOwner:Int, lpName : Byte Ptr) = "CreateMutexA@12" 
	Function GetLastError:Int() = "GetLastError@0"
		
End Extern

Local ret:Int = CreateMutex(Null,Null ,"ProgName".ToCstring())

;Put a window saying about 2 instances or whatever inside this test, then end.
If getlasterror () = ERROR_ALREADY_EXISTS

	End

EndIf

Thats pretty much my mutex code also :)

Grey, biting the bullet isn't something I want to do. I don't think you know just how bad it is on some pcs in windowed mode... it gets horrifically slow (as in the whole pc slows down not just the app)

When another window is dragged over the current bmax app. This is highly unusual behaviour... Can't think of any prog that does this off the top of my head, and it only happens with -1 or 1 flip.

Kenshin: thanks, snaffled that. Pretty much the same as my Delpi code!


OEJ: No nor do I, I've just been battling with this for weeks now full-time and and it's doing my head in. (Plus I'm tired now, gotta hit the sack, kids to take to school in morning etc.) I'm way behind now on my schedule, plus I have people slagging off my timing routines when clearly something is up with Max/Hardware/Drivers/Windows ... whatever.

Re: the slowdown, yeah it's like Max is hogging everything and not letting windows get an CPU power. I think then when windows does get some it hogs it too and this can result in jerks on some PCs as well.

btw, the new BMax 1.20 has no video fixes of any kind. (I read the docs and checked the D3D7Graphics,bmx file)

It does seem that IF I'm willing to put up with tearing, using Flip 0 gives a more consistent (less jerky) fell.

@Grey Alien: I agree. I think BMax is not playing friendly with the rest of the system. You shouldn't need to spend weeks on something so straightforward as timing. It should just work.

yeah. I've just figured out some important info about why people are getting different results when running my demo. It's partly to do with this border line between full/half speed FPS and also the fact that the VWait code just doesn't work on some PCs. I'll post tomorrow about it... snore ...

Tried the latest (DX) version and it's silky smooth at over 2000 shapes - but not when using flip 0. At 3000 not quite so smooth - but not jerky like flip 0 at the much lower number of shapes.

Just tested on my laptop Lots of vertical tearing in both modes. The step rate increases fairly soon on the underpowered beat. I was able to find a borderline between two step rates in full-screen mode, and thus see a bit of jerking.

Personally I want to use default Flip -1, however this causes a couple of test pcs - kenshin and to a lesser extent, my brother's pc to stall horribly in both OpenGL and DX. What on earth is going on here?

One has ati, the other has nvidia!

I am very sorry, that was not my intent. Please, don't take it personal. I didn't mean to slag them off, I merely intended to state the fact that they don't work on my systems. My displeasure is not with you or your code, its with the situation itself. Rob's timing examples work perfectly and all BMax made games have worked perfectly (so far). Rob's work perfect for me, but not for you or for some others. There is some nutty stuff going on with Bmax and it really doesn't make a lot of sense.

Perhaps you can see why I am still working with B+. Bmax still has some major compatibility issues that need ironing out. Really ticks me off though, as I love OOP. It also gets me that it has been around 18 months since the Windows version of BMax went public and we are still dealing with issues like this.


The only thing I can add to these timing quirks is that although all of my systems run XP, I do not have a "default" install. I tweak the heck out of XP and have all kinds of superfluous services disabled and various optimizations for what isn't disabled.

Jake: Since your framework demo doesn't work too well on my systems right now, instead of buying it, I bought Easter Bonus and Christmas Bonus (order was in my wife's name). FWIW, they both run SMOOTH ;c)

I am just testing something new. Grey, did you get around to vwait stuff?

Apology accepted. I'm sorry I asked if you were Bipolar too...I was cross (but that's no excuse) Checkout my essay in the other thread, it may explain more why I'm blaming hardware/drivers/windows and not my timing routintes. Wow, many thanks for buying the games! :-D, I really hope you enjoy them, I worked very hard on them to make them good fun and well made. You are correct that they do run smooth, everything is CPU/DirectX 1-based of course, no 3D card involvement at all. They use the same timing routine as in BlitzMax except that I've made the BlitzMax one a bit smoother based upon that Physics Timestepping article that's floating around http://www.gaffer.org/articles/Timestep.html. I really don't believe the small tweak I've made to it has caused all these problems because the first version of AOTMG didn't have the tweak in, and people still got jerking. Clearly 3D card rendering has a much wider range of results on PCs than my BlitzPlus CPU/DirectX 1 rendering.

OEJ: Check out the essay, that's everything I know about it so far in a (big) nutshell.

@ KENSHIN:

Could you please confirm if the new one at flip -1 runs okay on your rig and does not slow right down?

If it does slowdown, please let me know what apps are running and anything I can do to reproduce it :)

pray tell ...

Done.

Basically I hooked up my favorite test machine. I had to hunt for wires and so forth but here goes... it's a P2-400mhz machine running windows 2000 and a TNT1. Yep, the old crummy first TNT card.

With my timing code, it is smooth as silk, truely smooth on all flip modes with 100 objects regardless of settings.

I tried the Torque 2D shooter demo and it slowed down to the point of locking up, so that proves what a lame platform that is.

In my timing demo, I noticed something though. It looked vaguely *still playable* at 1000 objects, but a little over, say 1,200 objects, it began going slow-large steps-slow, and so on.

I narrowed this down pretty quickly to the timing of Millisecs(). You see, I have a portion of code that detects discrepencies in millisecs.

If your time difference between the last call to millisecs and this call is over 200ms (about 5fps), it resets my timing routine. This works a treat for dragging the window, or any misc delays.

However, my finding is, for a puzzle game, 5fps is still acceptable! This is because the mouse isn't delayed and you can still interact just fine with it. What are your thoughts on resetting time if the difference in millisecs is large?

The original retro 64 timing loop reset numticks (logic loop iterations) if >500 in case of alt+tab or whatever, this was too long so for Easter Bonus changed it to 50 numticks, this meant that, yes the game would run slower than it should, but was actually playable, albeit at 3-5FPS, on really slow PCs.

Now I've changed it a bit so that if app is suspended OR titlebar is dragged, it doesn't "catch up" it resets the timing routing. And I've left the 50 loop iterations in now for slower machines. This may even be too high. My debug stats output the number of ticks and for a normal 60Hz display with a 200Hz logic, the number of ticks is around 3, so 50 could be pretty slow and to be honest, if it's that slow I think the PC isn't suitable anyway, so I might drop it to 20 or so. I'll do some testing on crap machines when my final game is ready. I'm not sure you can set a value that's fine for all PCs, it depends on the game imho.

May I ask how you do your titlebar dragging?

Also this is a bug I think:

BUG:

Under DX on a slow machine, slowing right down causes even the os pointer to slow right down, making a mess of everything, where under OpenGL, the os pointer was always silky smooth, and only the game suffered.

Please report if this is the same for you. I suspect we're on the same mission to perfect our frameworks.

I let max drag the titlebar after enabling mouse just on the title bar. Max auto pauses the game code. Then I call this before the timing code loop starts:

?win32
Extern "win32"
    Function GetWindowRect%(hWnd%, lpRect: Byte Ptr)
End Extern
?

Type TRect
	Field L%, T%, R%, B%
End Type

			'Quickly check to see if the window has moved.
			'If it has, this is because the user has dragged it and so we should
			'reset the timing variables.
			Local Rect:TRect = ccWindowPositionHandle(Game.WindowHandle)
			If Game.WindowX <> Rect.L Or Game.WindowY <> Rect.T Then
				Init() 'timing vars
				Game.SetWindowCoords()
				Game.SetClientCoords()
			EndIf

Function ccWindowPositionHandle:TRect(hWnd%)
	'Pass a handle in
	?Win32
	Local window:TRect= New TRect
	GetWindowRect(hWnd,window)
	Return window	
	?
End Function

re: bug, sorry I'm plain out of motivation right now. We both are on the same mission at the same time, but I'm peed off with the whole thing now.

Thanks Jake :)

BUG CAUSE:

Indiepath anti lag fix.

Proposed solution: only apply fix when framerate is above 30fps.

Oh DEar: This one?

Function ccFixLag()
	'This fixes the annoying DirectX7 rendering lag in BlitzMax
	?Win32
		If TD3D7Max2DDriver(_max2dDriver)
			Local sdesc:DDSurfaceDesc2 = New DDSurfaceDesc2
			sdesc.dwSize = SizeOf(sdesc)
			Local res:Int = PrimaryDevice.backbuffer.Lock(Null,sdesc,DDLOCK_WAIT|DDLOCK_READONLY,Null)
			PrimaryDevice.backbuffer.unlock(Null)
			Return res
		EndIf
	?
End Function

The previous lag fix, the While Wend one cause big jerking on Geforce cards, Indiepath's code really improved this a lot.

SO you are going to monitor the FPS and bring the lag fix in for normal speeds? I'm still going to leave it on.

You do that and you will be slowing pcs down needlessly. Lag only occurs when the pc is capable of rendering faster than logic, surely?

The lag is present on my in-game mouse cursor even with a minimal amount of ufos. The fix sorts it. You could make a demo for a slow PC and try it without the lag fix and see if there is any lag. Then you'll know for sure if you ought to disable it at low speeds. I can't be bothered to monitor FPS switch the fix on/off. I've got to make this next game now (my schedule is shot to pieces), maybe some new stuff will crop up in Max before I release it, maybe not. It's not too much of an issue for puzzle games, but if I want to make action games (scrolling, sprites) etc in the future, I'll look back into it. Sorry dude, but I've done enough now, gonna have to leave it to BRL and anyone else who wants to run with the baton. This has been costing me time, money, sleep, relationship, diet and I can't do it anymore... I'll help out now and then as stuff crops up that needs testing but that's it for now.

so much for 220 hours lol :)

yeah I'm at half that just p*ssing around with the framework. Haven't even made a title page yet!

Sorry to bail out after getting so far but I can't continue, hope I've helped a bit anyway... good luck!

@One Eyed Jack: The new one does not slow down at all in flipmode -1 in ogl/dx win/fullscreen. The only way of getting slower movement is by going to insane number of balls. Even then the pointer and the rest of my system remains ultra responsive.

Thanks pal :)

I've tested your timing2.zip version and it run smooth in these setups

GeForce 7600GT Athlon 64 X2 3800+ LCD Monitor
GeForce 7800GS Athlon 64 3000+ CRT
Radeon 9800Pro Intel 1.7 CRT
GeForce 5700 Intel 1.7 LCD

for both DX and OpenGL

Thank you assari, much appreciated!

And you are still using Flip 0 aren't you? So assari couldn't see and obvious tear on the GeForce 5700 Intel 1.7 LCD whereas my Vsync Test showed this up. Perhaps another argument for just going with Flip 0 after all (did you read my idea about using Flip 0 after all in the other thread?)

Do NOT turn vsync off by default - it causes tearing which is especially noticable on larger screens - make it an option and don't rely on it for timing. Seeing the screen redraw is a bad thing no matter how it ruins your timing method.

I wish people wouldn't do it to get a few extra frames - it's like the bad old days of the ZX Spectum for Gods sake - flickering is bad!

Steve: wonder if I should copy and paste my other reply ;-)

I won't, don't panic Steve, put the gun down.

what if my new Flip 0 demo is less jerky on those machines it failed on before? Will you consider it then?

LOL! But I'm on a mission. It ruined your tank game mate - but with the vsync on lovely and smooth - because you can't see the screen redrawing.

Seriously, this should be the default - which can be changed. But it does seem the sensible thing to do - else why use 2 screen banks at all when using one and the screen re-draw is evident?

very nice and smooth, did upto 5000 objects and it ran fine.