Final Game Framework Test! (?)

OK, here it is, my final Blitz Max Game Framework test (maybe).

www.greyaliengames.com/aotmg/aotmg5.zip (4.06Mb)



This one is the best one yet! It uses Flip 0 and Fixed Rate Logic so that it should run on a wide range on PCs without too much tearing and jerking. By all means try pressing V to turn VSync on, this *may* give better results on some PCs and worse on other PCs.

Note: If your PC is performing any background tasks you may experience erratic movement from time to time, this is normal and unavoidable.

Some keys to try:

Arrow keys move and Z shoots.
Press <Esc> to quit the game.
Press <F> to toggle full screen/windowed mode.
Press <V> to toggle VSync on/off.
Press <D> to bring up the debug display (let me know your FPS!)
Press <P> to pause the game.

Checkout the readme.txt for more keys, and frameworkreadme.txt to find out what the framework does in detail.

Any problems let me know (along with system specs). Also any positive feedback, please tell me! :-D Thanks

P.S. If you have Win98 or WinME please test firing with Z and let me know if you detect a delay between the key press and the sound effect (latency), many thanks.

Hi,

On the 400mhz pc with Tnt, your framework inits a display of 60hz when the desktop is 85. For me, this is undesirable.

works well for me, tho I have a pretty up to date machine. Didn't mind things running in the background.

I know there will be more than ships flying left and right, but even at just this amount, there were places where it was impossible to kill all the ships in time.

perhaps bombs or such to hit a screen full of guys would be a good addition, if a little cliche.

the game might get old fast, since the only challenge thus far is getting things before they leave the screen, they don't fight back, tho I expect they will. Even then, it is still very cliche. I'd like to see something new here... if you can get a puzzle aspect into this, I will be very happy.

It sounds pretty good Mr Grey, but I'm on a Mac so I can't test it. The fixed rate logic is an intersting idea.

Are you supporting 24-bit modes (no alpha?)

Lag Fix Off
Flip 1
Vsync 1

Runs 100% perfectly full screen or windowed on all systems, even with Opera & internet connection running and firewall & antivirus running. Good job, Jake.

(AFAIK, the sound is still messed up for some 98 users in 1.20 (what I have heard from my beta testers). It appears merely a half-assed fix was implemented that causes latency problems. No biggie as I wrote my own OGG streaming DLL.)

Looks great in all modes -- I don't see any stuttering, freezes, or tearing in full screen or windowed mode.

(ATI Radeon 9600Pro, TFT @75Hz, AMD Athlon 2800+)

If running at full speed, things do look a little smoother with lag-fix enabled, but that's mostly because things appear to move a little slower that way and are easier to follow with your eyes

Works well here but I wonder whats going on in the background since it's hogging resource (50% due to dual core) and it makes no difference if I have any of the options toggled on or off???

A little lag on my system (two programs running in the back) but nothing major...

OEJ: I might change this later.

DampeS8N: Glad works OK. I's not supposed to be a game, just a framework demo.

AngelDaniel: Sorry you can't test. It's either 32-bit with alpha channel or 16bit with an alpha channel (if 32bit can't be initialised) so that png's can be transparent. I don't actually know how the alpha channel works in 16-bit, but it just does...

Kuron: glad it's fine on all your systems now. Was it OK when it booted up with the default settings e.g. Lag Fix=1, VSync = 0? I hope so. I ask this because you have listed non-standard settings i.e. after you've been playing with them. If it worked with those settings, then great too! Although I'm going to leave lag fix on, it won't be a user option, nor will Flips etc, only VSync will be a user option.

Xlsior: Great glad it's fine. However, you shouldn't see any speed change wil lag fix on/off, this is odd. Are you sure?

Indiepath: Pretty much all my apps Hog resources as they are loop-based not event driven.

Wedoe: hmm, lag (slow controls) or stuttering of movement? Glad you think it's not major, but it ought to run OK on your PC.

I thought that would make your day ;c)

Some intermittent stutters. But no tearing or jerking.

The settings I posted above, it ran perfect.

OK thanks for the clarification. It'll probably ship with the default settings though.

Jake,

This works better than anything previously, I can see NO stutter, tearing, jerkiness at all.

The features you have added in are tremendous, I love the fact that when you click on some other window on the desktop (in windowed mode) the framework stops the game in it's tracks, music and all and waits for the gaming window to be given focus again, where it picks up seamlessly (music and all).

EXCELLENT work and well worth the time invested.

IPete2.

The stutters were intermittent and extremely small and would not in any way affect gameplay. I think you are good to go with the default ;c)

Thanks IPEte2 for your support. Yeah it now shows "Paused" in big letters when you click out of the window.

Kuron: Well that's reassuring, thanks. Ideally I want a 100% perfect display, which I can get on my PC, but as this is not possible on all PCs, I have to go with something that is pretty good on most PCs.

Jake,

Put a Delay(1) somewhere in the loop, perhaps just after calling Flip to free up some resource.

Noooo, I hate Delay(1) it's so lame ;-) After all this is a *game* not a windows app, so I say resource hogging doesn't matter (as much) ... certainly not in full-screen. Perhaps I could put the delay in windowed mode only ...

Lame? it's standard practice. It's a shame that the App does not sleep while it's waiting for vSync at that's a real resource hogger. Putting it in widowed mode would be a good idea.

Is it? Well I *might* add it to windowed mode. It's just that say your desktop Hz is 85 this only gives you 11.7ms to do stuff in to maintain a smooth display. Stick in a delay (1) and that's 10.7ms. On slower systems, where the logic and drawing takes a while, this 1ms could push it over the boundary into dropping frames. It's a bit sad to add in a delay after you totally optimise the rest of your code. But I'm just a pureist speed freak, that's all :-D

Works here, win 98SE/2K/XPSP2 tested.

Works like a charm now. Thanks for all the hard work. No problems at all.

Jason.

With all background tasks off, it's very smooth.

With background tasks going, I get frequent, small jerks. Nothing too bad, though. It's exactly the same in windowed and fullscreen mode. Toggling the flip mode doesn't seem to make much difference.

FPS changes constantly but averages at ~250(?).

I do get a small latency with sounds. I didn't notice this before.

thanks everyone for the continued testing.

Yoxola: Did you get any minor sound delays when pressing fire in Win98? Thanks.

Big10p, thanks for the background info. Well if you can get 250FPS on your 1GHz with Geforce2(?) then thats OK. Also thanks for confirming the latency issue. Nothing has changed in that sound code, it would have been there before, but I've drawn your attention to it, is all.

Is there a mac version of the demo?! ;O)

Latency bug then?

GreyAlien: ... You don't need any kind of alpha buffer in order to be able to DRAW with alphablending. Your PNG's will render find regardless of whether you have an alphabuffer.

Having an alpha buffer means that the screen/backbuffer ITSELF has an alpha channel. It doesn't refer to the alpha channel present in your sprites. You don't need an alpha channel in the backbuffer in order to render alpha blending because alphablending does not take into the account the backbuffer's alpha channel - it only uses alpha from the source sprite to determine the ratio of color blending.

Your 32-bit mode almost definitely will have an alpha channel in the backbuffer. Your 16-bit mode probably does not, or if it does it probably isn't 8-bit (ie 15-bit might have a 1-bit alpha), and on most systems it might only be 1-bit or 0-bit. It's very uncertain whether you will get alpha in a 16-bit mode. But that doesn't seem to matter for your system because you don't use the backbuffer's alpha buffer anyway.

You could support 24-bit modes, where the display/backbuffer does not support an alpha channel. Not having an alpha in these modes doesn't mean that your sprites wont have transparency. Alphablending still works regardless of having an alpha buffer in the display. Some people will have 24-bit screen modes but not 32-bit. On my ibook for example the desktop is 24-bit, no alpha, so if you opened a window it might not get an alpha channel.

It's up to you, of course.

In my system I'm supporting 32-bit, 24-bit, 16-bit and 15-bit mode, or windowed.

taumel: No ... Cheeky ;-)
OEJ: sounds like it (scuse the pun)
AngelDaniel: Thanks for the alpha buffer info. I considered doing a 24 bit mode, but didn't bother in the end. I could add it pretty easily though ...

- Added 24 bit support.
- Also added Delay(1) to windowed mode. This reduces the FPS of course but the CPU usage drops by loads. *Hopefully* this won't have a negative effect on the visuals that I've worked so hard to get right.

Grey

You should make the delay an option not a fixed item, as long as the code is commented heavily suggesting how to use it correctly, should be fine.

IPete2.

Yeah, I've commented it in the code so it's obvious so developers can remove it if they want. I'm leaving it in for the default framework, but people can comment it out if they want to see full framerate.

OPS, sorry it was "Process tamer" who strangled your program, all fine now :o)

"Process tamer", HOW DARE YOU! ;-)

He he *blush*

This one:
http://www.donationcoder.com/Software/Mouser/proctamer/index.html

HORRIBLE! lol. well since the new version has Delay(1) in the main loop in windowed mode, I daresay it would now work OK *even* with that program running :-)

I've just added a cool fade routine that fades without using GrabImage which is SLOW at grabbing whole screens. Also you can fade as animation continues on screen but with input blocked!