Saucer Attack w.i.p. test

I am writing a small game in Blitz Max to test a few things to be used in a larger game.

saucerattack_wip.zip (527 KB)

Edit: The above link is now to a version that simply selects the desktop mode.

Would a few people be so kind as to test this game? It's not finished yet but I'd like to know whether some things work even before I add sound and a few more gameplay elements. The things I would like to test are:

1 - Automatic selection of a display mode; do the numbers mentioned on the title screen make sense?
2 - Switching between "bars" and "stretch" modes to fit game on screen; does it work as expected when you press Enter on the title screen?

(It seems to work on my 4:3 CRT and I would like to know if it also works on other types of screens and wide-screens.)

The game uses a 16:10 wide-screen resolution (1280x800) internally, and by default displays the game using the "bars" method. This means if you are running it from a 4:3 desktop you should be greeted by bars at the top and bottom of the screen.

There is some explanation text on the title screen. I hope the text itself actually stays on the screen. This is how it should appear on a 4:3 resolution:



A few more details are also in my worklog.

I will make the source code available to everybody if it is useful. (And even if it isn't. :))

The game itself is about shooting down evil flying saucers. These guys can shoot back but only when they turn red out of anger first. Use the arrow keys to steer and go forward/backward and hold down the spacebar (or Z) to shoot. Thanks!

Pretty fun game.

1) My laptop's native resolution is 1280x800, but the game selected 1280x600.
2) Pressing enter to enter stretch mode looked fine.

Thanks for testing, is your laptop's desktop resolution also set to 1280x800? (I guess so?)

I just remembered something... In my code I compute aspect ratios by doing division, resulting in a float. Sometimes even though aspect ratios were similar, the system would think they were different because of floating point rounding "errors". I solved this for my own computer by using doubles instead of floats. But maybe this is still a problem in some cases, leading to the wrong default resolution being selected...

I too thought the display looked just fine stretched. The only noticeable streching that occurs is during the title screen. Once the game begins, it is not even noticeable.

It crashes my monitor. I guess it detects that my graphics card support certain graphics mode but sence my monitor does not when it sets the mode, it shuts my monitor down. says "unsupported mode" and turns off.

that's weird.... this is the first bmax game that caused "your video driver stopped responding". that happened on the first play while the second try was ok. the game selected 1280x800 the second time, I don't know what it tried the first.

Thanks for testing all and I am sorry about the problems... I assumed I could pick any resolution from the list returned by GraphicsModes(), and didn't realize the monitor could still have problems with that.

Perhaps picking the actual desktop resolution is the safe way to go then. (Except for possible video memory problems as mentioned elsewhere.)

But with this in mind, even setting up a list of resolutions for the user to choose from would be problematic? (As the list would include modes the monitor is not happy with.)

Or another option would be to hard-code a list of well-known resolutions and use only those resolutions from GraphicsModes() that also occur in the well-known list.

I like the idea of letting the user choose the resolution and waiting about 10 seconds before switching back to their desktop resolution if "is this a valid resolution?" question is not answered.

Just freezes up on here, but I could end the task through tm. (win xp64, gfx Gforce at 1680x1050, 60hz)

Runs fine on Wine (on Ubuntu 8.10), display switching works and makes sense to me. (although it could be made a little more visible in the text, maybe with different colour).

Thanks for testing.

Yes that would be a good idea.

However seeing all the problems this program gives, I am thinking about switching to the method that just picks the desktop resolution.

Cases where the current method selects an unlikely resolution are probably related to my way of comparing aspect ratios (floating point errors) but even then it shouldn't result in crashes and lock-ups; this seems to be caused by the selected resolution not being supported after all.

Adding a list of well-known resolutions could partly solve this (and the floating point problem) but I would never be 100% sure of it functioning correctly on all machines, unlike picking the desktop resolution which is known to be supported by the monitor. (I am just thinking aloud a bit. ;))

I have changed it to using the desktop mode, it would be great if some of you could try it again and see if it works now.

saucerattack_wip.zip

that one just ends for me but that is to be expected since I'm running 2560x1600 and bmax apparently can't open a screen that big...

works fine now... curious little game.

"that one just ends for me but that is to be expected since I'm running 2560x1600 and bmax apparently can't open a screen that big... "

That's the bug in the graphics pipeline I reported a while back. This is going to nip alot of devs in the a$$ when everyone starts launching games at desktop res.

Picked my desktop resolution (1280x800), worked fine.

Works here with a 1024x768 desktop. Game has potential but the controls are horrible (like reversed). Hope you can keep on improving it :-) My son said it needed mouse controls and maybe an aiming cursor...or at least Geometry war style controls.

If it's working correctly then the left and right arrow keys make you steer left and right, and up and down make you go faster or slower. It's like an FPS but top-down. ;) And yes some more work is planned on the gameplay such as first aid kits and power-ups.

Apart from the gameplay I am really starting to wonder how other people setup a system that picks a useful resolution on any given computer and monitor, seeing that

1) GraphicsModes() returns modes that result in crashes
2) Setting the desktop mode results in crashes