So, I'll need a few beta-testers for the game since I want it to be the best possible, and I want to know the minimum system specs, and I can't do that on 2 or 3 PCs, so I'll post the progress-so-far here and I want you to tell me the FPS:

- without shadows at all (the INSERT key toggles shadows)
- with shadows
- with the flashlight on (F key)

You move with WASD, aim with the mouse, and shoot with the left mouse button (you've got 12 bullets, but there's no ammo display yet).

I'll also need to know your system specs. I want to have a general idea on which computers will it work fine, and on which it won't work at all. Especially since some GFX cards can be picky about OpenGL.

http://cursedtyrant.freshsite.pl/tests/shooter[ol].rar It's Windows only for now.

Just keep in mind that I started the game not long ago, so it's in the earliest stages of its development.

Hey cool shadows! I wanted to do shadows like that. Is it very hard? I haven't done much with OpenGL yet. I'm assuming since you are planning on selling that game you won't be releasing the source...

I have an ATI Mobility Radeon X1600, 1GB of RAM, and a 2GHz Intel Core Duo. I think it's safe to say your game will run fine no matter what. Though I can try it out on my crappy computer if you'd like.

150 With shadows
360 without
120-140 with flashlight

WinXp Pro Sp 2
ATI Mobility Radeon 9700
Pentium M 1.7Ghz, 512MB RAM

You should add rest() somewhere; as it is, it will use all possible CPU time, overheating it after a bit (in 1-2 minutes the temp was of 70°C and i had to shut it down)

I'm more interested in FPS and specs, because I need to know how much FPS you can get with full effects on each computer.

As I said in the other thread, I will release it as opensource (meaning game+source) after half a year or so, but I can isolate the shadow drawing function if you want. It's not pretty, and there're probably dozens of other (possibly better) ways to do shadows like that, but it works fine, and it's fast (as long as you operate on rectangles as objects/walls).

EDIT: That's strange. It doesn't overheat my CPU.

I've got a Sempron 1,4GHz 2500+ 64 bit (OCed to 1,58GHz), a Radeon 9550 and 512MB of RAM and I get ~80-100 FPS with full effects. No overheating, altough I think it's OpenGL's fault that the game uses 100% CPU power.

Oh yeah. I got carried away showing off the specs to my new computer...
180 FPS with shadows but no flashlight. Drops down to 150 when I turn the flash light on.
450 around with no shadows at all.

I'm sure I could find something on the net, but I'd like to see how it's actually implemented into the game. That's the hardest thing for me to do. I was making a similar type of game using only Allegro, except the whole screen would rotate instead of only your character. I'm switching to OpenGL because 1) low resolution + rotated tile map hurts the eyes and 2) there's no way I could make pretty looking shadows + other nice effects with software drawing alone.

Shadow code attached. One thing I love about Programmer's Notepad 2 is the HTML export function. Saves all the colors and styles.

My CPU is on a laptop, they are more prone to overheating. You should check if you showed enough fps, in that case rest

Not sure how tough. I never really needed that sort of control over FPS.

Mostly because I never knew it overheats on laptops.

1300 w/o shadows
500 /w shadows
400 /w flashlight

win xp sp2
2.6ghz p4 ht
1536mb ram
ati radeon x800pro modded to xt pe

Are you sure it was overheating? My CPU in my laptop regularly runs in the 70-80C range when I run it under heavy load for a while and it works fine. They are made to withstand higher temperatures.

Must have had vsync on or something...
60fps
60fps
and .... 60fps

Athlon 64 3200+
Nvidia 7900GT

One thing about the controls though.... shouldnt the guy move in the direction you have him pointed? If you hit W he always goes up no matter which direction he is facing... this is confusing. Also I think this is an openlayer bug but when I have shadows or the flashlight on I get polygon edges showing.

Might be, a screenshot would be helpful.

In the final release you'll be able to choose between absolute and relative character movement. I already have the code for that, just no switch yet. I might as well add it in the next update.

Screenshot:
http://www.allegro.cc/files/attachment/589786[/img

This doesn't happen if you hit insert (shadows off).

Nope, it's an OpenLayer bug. Doesn't happen on my PC, or anyone else's that I know of (except yours).

BTW, does this happen when the flashlight is off too?

Games generally use 100% cpu, because they run in a tight loop and aren't meant to be used alongside other programs anyway. You shouldn't worry about overheating the CPU -- a computer shouldn't overheat just by being used fully. That's a broken computer, not your fault.

It happens with the flashlight off as well.

That's an opinion and should only be considered as such. A lot of users are having programs running in the background like a BitTorrent client or something else. If the game doesn't need to use 100% of the CPU it's common curtesy not to use it all up, and could well be a selling point for his game.

Well, I can't fix it (I don't even have an NVidia card), but you could report that bug so someone who can does

With shadows: ~215 fps (+- 5)
Without shadows: ~540 fps
Flashlight: 160 fps - 215 fps (depending on how much of the cone is visible)

Specs:
Windows XP SP2
ATI mobility Radeon x700 (128MB)
1 GiB RAM
Pentium M 1.86 GHz CPU

I unfortunately can't play it, due to the problem I brought up here. I have the same problem with all OL games. The game does work, as I can see things moving around the bitmaps it does create, but they're too small for me to be able to read the FPS counter, or to be able to make out much of the graphics.

Can you name a single comercial "3D" game that use this as a "selling point" ? It's not an opinion, it's a fact, and the curtesy is far from "common" (a game should use all the available power for the best experience).

BT clients and such don't use hardly any CPU. Stuff running in the background shouldn't use much CPU.

Ok, open layer games never work for me, and it makes me mad sometimes. These are my specs:

Intel Pentium 4
Processer 540
3.2 GHz
1 GB DDR
Intel Graphics Media Accelerator 900 (I know, very sad, but I can't afford any better than the built in stuff)

Do OpenGL or AllegroGL games work for you Brian?

To argue that games should always consume 100% of the CPU even though it isn't used isn't very clever. And it's not even something I need to debate further.

Perhaps the user is rendering an animation using 3D Studio Max or something? In any case it's really irrelevant what else the user will need the available CPU-time for. It's the users computer and a game shouldn't use more than it needs, so that the user may decide if he/she wants to do something else at the same time or not.

If they are rendering in the background then the game won't run very well and if they are that concerned about playing games they should either pause the rendering or use a different computer.

No, nearly all commercial games don't use CPU if they don't need it. Just for example i could happily play Ufo: Aftershock (modern 3d tactical game) with max settings, but Civil War Generals 2 (an OLD 2d wargame) uses so much CPU that it overheats in a few minutes... talk of optimizing! Besides using more CPU power than you need is just useless.

I'm saying it overheats because Asus Probe thinks 70°C deserves getting my attention with loud beeps

Change Asus Probe's settings then? I highly doubt you are overheating. It's not 'wasting' CPU time, a waste of CPU time is when the CPU sits idle.

I can see that you didn't read my post very throughly and that you didn't understand the point I was trying to give. Each application/game should only use what it needs. If you use up all CPU-time "for the hell of it" you are practicing bad software engineering.

Why not apply the same philosophy to the required hard disk space? Most games these days take up 600-700 MB, so even if you are not using it you could store some large trash files along with your game, so that you are not wasting less resources than other games.

Give one single reason for why you want to use up all CPU-time even though you don't need to? Except that you as the programmer is lazy and/or use libraries which won't allow you to be nice to the system.

I think they know a bit more than you and me, and since only "broken" aps have this behaviour i don't see why i shouldn't stay on the safe side.

Kent:

There is a problem here in that giving the OS back some time could result in your game missing a frame or more because the OS doesn't return back to your game in time. I think the OS processes in Windows only have something like a 10 ms resolution.

The best bet is to provide options to run with or without resting.

A game can use 100% CPU if it wants, it is doing stuff during the time, which allows for more accurate stuff and such.

FMC: 70C seems like a good number for a desktop, but laptops are designed to run hotter to help preserve power (less fans running = less power consumption).

Yeah this is the only reason. If you have tried this, does the game skip a frame or two once in a while? And does it matter?

Absolutely!

Well that is not always the case. When you reach a certain treshold it makes no sense anymore to break down for example unit movements into smaller movements per logic update and a higher rate of logic updates. There will always be a point when it makes no sense anymore to consume all available CPU-time.

The "new way" of programming is waste resources all you want to, because great hardware is common and relatively cheap these days. I'm not an advocate of this style.

Ok, I've used:

rest(1);
DeltaTime = FpsCounter::NewFrameStarted();
FPS = FpsCounter::GetFps();

The CPU is used at merely 2%, maybe 10% at most, but the FPS drops down (and stays at) 63. With effects, as well as without them. Am I doing it the right way?

It's nice of you to not take up all the system resources! Do you see any difference at all in game quality except for the FPS number? (And if so, you could have it as an option as Richard suggests.)

The resting is supposed to free up system resources while waiting to do the next logic/frame update. That is, if you finish and have lots of time left until the next cycle you wait some more than 1.

Actually, the game runs as smooth as before, only the FPS stays at 63.

I've updated the game, now it includes a plasma rifle (actually, 2). It's a test of the tri-slot weapon base I'm trying to implement (3 customizable slots, you can have 1 pistol and 2 plasma rifles, or the other way around. Once I include more weapons and add all the necessary menus, you'll be able to change which weapons you insert and into which slot).

The link is the same, but I'll post it again, so that lazy people can still try my game: http://cursedtyrant.freshsite.pl/tests/shooter[ol].rar

I myself only run Linux at the moment so I can't try it. By the looks of the screenshot earlier in this thread it seems nice. Are you inspired by the Alien Breed games for the Amiga? (If not, check them out using WinUAE - they are great)

Actually, yeah Those were some great games. Not for the Amiga tough, I've played Alien Breed under DOS.

And here's a screenshot for those of us who use Linux:
{"name":"589799","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/6\/56182d9d40b49de1d2953459705974f9.jpg","w":527,"h":470,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/6\/56182d9d40b49de1d2953459705974f9"}
You can see two bullet trails, and one plasma shot here.

A program should use 100% CPU power if it needs it. If it needs 1% and does 99% busy waiting, then that's bad.
Aside from battery life in laptops (which IMHO don't make sense for playing games on anyway), desktop machines drawing as little power as they can is a good thing in a world where people try to safe power.

I think you should do something along the lines:
if( there_are_enough_frames_for_this_second) rest(1);
else just_go_on()

So that you are sure you're resting only when you don't need CPU time

Yeah, but I'm not sure how to do that in OL.

@ FMC

Isn't it just doing VSync ? That's more than enough to spare CPU time if this option is available.
I've already asked Flad for this feature in OL.

@CursedTyrant:

if (FpsCount::GetFps() > 200.0) rest(1);

Where 200.0 is the acceptable FPS limit (assuming it's the same as the logic speedrate)

I will agree that it's friendly to use less than 100% of the CPU when possible, to allow for energy conservation, greater battery life, better multitasking, but calling an app 'broken' because it uses 100% CPU is simply incorrect. If the computer breaks down under these conditions, the hardware configuration is entirely to blame. So, sure, put in two lines of rest-when-idle, put in your other optimizations and your 'low quality graphics' mode, but there will almost certainly still be some PC that will need to use 100% to run your game, and that is not something you should lose sleep over.

One could certainly construct a world with background, physics-driven effects which could be scaled up to take more processor time than any currently-feasible processor could possibly provide. So unless you mean this in a very abstract, 'assuming we had a machine that was ~infinitely fast' sort of way, um, I don't know how you come to this conclusion?

Er. What? There's surely nothing wrong with trading off performance for ease of development, when one has analyzed the significance of the gains and losses involved.

OpenGL games work for me, and I think AllegroGL works as well Richard.

Sure and if it's part of the game then use 100% CPU-time. Just do not use it without spending it on something which adds to the game quality.

Well in some cases it is, and this is one of them. Remember that we are talking about a game using up 100% of the available CPU-time without needing it. I'm not saying that we should all do some kind of pre-mature optimization, just not be lazy in situations like this one. That laziness is what I meant by "new way".

Um, okay ... except that laziness isn't new, and running tight loops of code-which-does-nothing doesn't rely on "great hardware" being "common and relatively cheap", so I still have no idea where your "kids these days"-style commentary comes from.

Anyway, regarding the demo:
The shadow cast by the block in the middle of the map looks jittery when I move my cursor; the shape moves smoothly for a short distance, then jerks back. In still frames it always looks roughly correct so it's hard to give you a visual.
FPS is always 59, cpu usage hovers below 90%
Graphics card is a GeForce Go 6800, CPU is a 2GHz Pentium M.

Not a good idea. It starts jumping periodically on my PC when I turn out shadows (the only way I can get over 200 FPS). I think that rest(1) unconditionally is the best way to go, especially since it doesn't slow the game down at all.

Yeah, I know. It's because I'm calculating each ray of light, and it just works drastically slower if I make it any more smooth.

Nope
I always disable Vsync in modern games, to get a little more fps.

Can you say "bloodshed"?
{"name":"589813","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/e\/2e0382fc122e8e39ad835713d0cee8a7.jpg","w":377,"h":333,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/e\/2e0382fc122e8e39ad835713d0cee8a7"}
No shadows this time so that you can see the whole scene.

EOD. Let's just say that I don't agree with you.

Very nice! Is that skeletons lying in the blood? Perhaps the blood should splatter in the same directions as the bullets? (You blood piles seems to be gravity droppings, if I may speak CSI-eEnglish;) )

No, those are the aliens (at the moment, anyway). The blood does splatter in the same direction as the bullets, tough I'll have to strech it in that direction too I guess.

Oh, no pun intended! I guess it's obvious when you run the game and not just look at a still picture.

Yeah some stretching would make it look even nicer, but it looks nice as it is as well.

Dang you CursedTyrant! I was working on a unified colored light and shadowing through colored glass lib for OpenLayer.
Circular / Elliptical lights should even cast shadows correctly.

Unfortunately, the OL 2.1 pre-compiled update doesn't blend correctly between
non-back_buffer canvas#1 and non-back_buffer canvas#2.

I ran into trouble compiling the latest OL SVN in DevC++.

What version of OL are you using?

One of the snapshots from a week or two ago, but I have no idea which one.

Do those blood stains look better?
{"name":"589814","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/e\/6e93adb42cd81868fad00c39e867f930.jpg","w":427,"h":376,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/e\/6e93adb42cd81868fad00c39e867f930"}

maybe a bit too stretched?

How so?

I'm not sure, maybe in movement it's right, but as a still picture the blood trail seems too long

Hmm, I found the effect pretty jarring. I think it would be worth hacking up a fix.
One way you could try to handle this is to remember the rays you sent last frame, and, if you're sending a ray which is 'close to' a ray from the last frame, adjust the new ray so that it goes through the collision point of the old. You'll end up with slightly more uneven, but more across-frames-consistent, coverage of the same space. (Don't do this kind of adjustment to the outermost rays, though, as you'll want the range covered to be consistent.)

It should be fixed to the point that it's no longer noticeable unless you look for it specifically. The frame rate doesn't go down much, as I narrowed the flashlight's cone, which in turn produced a more realistic version of the flashlight.

The link is the same:
http://cursedtyrant.freshsite.pl/tests/shooter[ol].rar

Cool, looks great. But now the side of the flashlight's light cone 'snaps' to the edges of the tile, so the flashlight width actually changes as you rotate over that space. It's pretty noticeable, at parts. You should try to avoid applying your fix to the rays at the very edge of the flashlight's light-cone.

Also, I noticed I get the 'polygon edges are visible' thing too. I don't get it in the OL demo, so I'm not sure why it's showing up here ...

There's nothing there that would cause it on its own. I only draw the tiles, the objects, blood, and the shadows. Maybe Flad could shed some light on this, wherever he is.

EDIT: The link above is updated. It's about as smooth as I can make it. Besides, it's not as if anyone will notice a little bit of jittering on the edges of the flashlight in a fast paced shooter.

EDIT2: I always loved a good flamethrower.
{"name":"589818","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/f\/4fbc3707d3cadb545c4b3d0d5c6464ec.jpg","w":429,"h":410,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/f\/4fbc3707d3cadb545c4b3d0d5c6464ec"}

The latest flashlight effect is great. Nice job!
Ah, and the flamethrower is pretty awesome too

Regarding the polygon edges, it's almost definitely to do with OpenLayer internals, so, yeah, Flad would be the one to ask. Looks like there's a missing GL_CLAMP_TO_EDGE, except that these are probably drawn as QUADs, so I wouldn't think you'd need to specify anything like that ...

Can't decide which looks better:
{"name":"4fbc3707d3cadb545c4b3d0d5c6464ec.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/f\/4fbc3707d3cadb545c4b3d0d5c6464ec.jpg","w":429,"h":410,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/f\/4fbc3707d3cadb545c4b3d0d5c6464ec"}

{"name":"589822","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/e\/ee0e0be4f3a85fb35e2e92da955ad537.jpg","w":368,"h":340,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/e\/ee0e0be4f3a85fb35e2e92da955ad537"}

Although you said it is only Windows program I tried it in Linux through Wine. Unfortunately screen was mostly filled with black but that is most likely OL/AGL problem. I did saw the framerate, flashlight and a big dot in the lightcone. FPS was way too erradic to get a decent number. With shadows and flashlight it was jumping around 150-450.

From the screenshots it looks quite nice. Reminded me of a game called "Tapan Kaikki" that I once enjoyed quite a bit

http://www.jonneweb.net/pelit/file/1233/tapan-kaikki-4:-bloodshed/
http://www.jonneweb.net/pelit/file/363/ultimate-tapan-kaikki/

If I could get AllegroGL to work in Debian, I could look into making a .deb file, which should work on Ubuntu as well. Or just compile a Debian binary.

I think the top one looks more exaggerated, hence 'cartoony', while the bottom one looks more 'real'. Which is better will probably depend on the rest of the art -- I think 'real' is probably more fitting, for you.
But really, both look good to me.

Wine and Allegro-based programs don't play nice, IIRC.

You could try asking for help in the "Installation, Setup & Configuration" forum -- there's a fair chance Bob or someone else could help you through, or at least figure out why it's broken and start working on a fix.

Most regular Allegro programs work, or at least their graphics is correct. There were some issues with keyboard, though.

It would be next to useless to anyone else though. Just tar gzip the result and then everyone can read it.
Better yet to release sourcecode so people can compile it themselves if your binary doesn't work.

Keyboard and mouse, actually. Can anyone check if this has been fixed in a recent release of Wine?

CursedTyrant, if you could somehow "combine" the two flamethrower effects, I think that would look best. The top one looks more like fire, but it's a bit unrealistic, while the bottom one is realistic, but it looks a bit too much like smoke.

And so I did.

Make the 1st part orange->yellow and the 2nd part grey like smoke. (See the openlayer demo)