This is something I threw together using my GDI library I am working on, if anyone cares to join in helping with this game, library, or both, leave me a message on this board.

The keys are:

Up/Down/Left/Right arrows for movement of the little guy
Spacebar to pass the time
A - attack, just displays 'Attack' in the text window

A timepiece is in the upper right corner of the window.

To exit, either click the mouse while it is over the window - which will be invisible, or hit the 'Escape' key.

Comments on this game or direction of it are also welcome.  It does have a couple of minor bugs, but it shouldn't crash a win95/98 box  :)
Posted on 2005-05-05 12:02:39 by drarem
I pressed space bar and "a" key everywhere, but nothing happened.
What's the idea of the game?
Posted on 2005-05-05 17:27:20 by Kecol
That's odd, what version of windows are you running? You need to be in a resolution of at least 1024x768.

The arrow keys should move the small character around the screen, the timepiece needle should slowly rotate, and when  you hit the arrow keys,A, or space, the bottom of the screen should display your movement.

That is all it does for now, objective is a hack and slash on the lines of the old ultima games with the usual str/dex/int/wis stat increases.
Posted on 2005-05-05 18:54:24 by drarem
The program does what you said it will. It's just I expected to destroy something in the game when pressing 'A'.
Posted on 2005-05-05 21:39:01 by Kecol
Here is update:

the download file size grew to 515 Kb due to the test bitmap files within.

Main game screen -
? Create New Character - maximum initial stat points 50, variable within the dialog
? Load Character - TODO list
? Journey Forth...? - starts the game

The stat bars are drawn on the left below the timepiece, the blue rectangle within the green panel indicates experience.
You can move around, that's about it for now.
Posted on 2005-05-10 10:24:30 by drarem
Ah, pretty interesting, I hope that when you're done the game doesn't die when the user clicks the window.... accidents do happen.
I feel like my CPU is being hammered a bit here, more so than in the previous version. My CPU says 50%, but of corse that'd be because I have HT enabled and it limits each thread to 50%
I'm currently on a P4-3.4, I almost feel like trying it out on my P3-450 just to see how lag-lust it is.

But anyway, onto my point. THis is like a text adventure game with a map.... right? If so, then perhapse you could re-considder your drawing events. They seem to be happening all the time, regardless of weather anything is pressed or not, IMO this is not necessary, unless you plan on having some real-time events you could reduce the CPU-hammerage a LOT by calling your drawing code from WM_PAINT, and calling the drawing routines whenever a key is pressed. So long as the code to set the players new location etc occurs before the drawing code it should work out just fine that way.
As for the TimePeice, perhapse you could make it so eachtime you move it incriments. I'm not sure what your game is trying to be, it has the hints of a textadventure from the output at the bottom, and hints of being realtime experience from the likes of the timepeice..... and per-cycle re-drawing.

Of corse, this is just an idea, but personally I'm on a laptop right now, and I don't like playing games that result in the insineration of my lap.... Well, perhapse only on Sundays.

But yes, good luck with this.

I'm working on a short side-scrolling shooter myself right now, It's mostly a learning experience . It makes use of the standard gdi32.dll, and runs at 30FPS, I just hope my CPU-hammerage doesn't go insane. To try and reduce it I made the game window pretty small -- no more than 400*300. That way I'm hoping I can get away with what-could-be very time consuming code, such as by-pixel collision detection and some nice background/explosion effects . Although I'll probably only get around to doing 1/4 of the things I plan, 'tis pretty fun. ^_^

PS: if you do plan on adding some events that will require realtime drawing and such, feel free to ignore this entire post.
Posted on 2005-07-25 21:35:07 by //clone
Definitely, there's something wrong with the GDI usage. On my PC it takes 100%, too.
Because you use UpdateWindow, I suppose.
My first commercial project does 50fps 800x768, while taking 0.5% cpu.

Create a 30fps timer. In WM_PAINT do only "ValidateRect". In WM_TIMER, do the sequence:
- draw your stuff to hdcBackBuffer
- GetDC -> into hdcOutputBuffer
- BitBlt  hdcOutputBuffer <- hdcBackBuffer
- ReleaseDC, hdcOutputBuffer

You'll be perfectly fine. Notice that we "lock" the output HDC only after we've done drawing on the backbuffer.

Generally, using GDI for games is not recommended. For a few days' project it's fine, but after a week you'll feel awful about the limits. How about using DDraw, and blitting only in software (with your own code) ? For me it gives perfect power - if I want an effect, I'll have that effect (after a little effort, of course).

There is only one big drawback of DDraw - you have to make your own wrapping-library.

//clone, I'm also working on a shooter (but for mobile PalmOS devices ^^") . Using DDraw for the Win32 port. Needs a 200-300MHz cpu, yet lots of stuff can be drawn. At some time you should consider studying DD too.
With GDI's Set/GetPixel, it won't be long before you run out of cpu, and it'll just make you unhappy in the end
Posted on 2005-07-26 20:10:29 by Ultrano
Thanks, I didn't know my real-time apps were doing that..  why is it bad to hit 50% cpu usage?  Bad for chips or bad to be stingy >)  ?  The system idle process is at 98% all the time, guess that is normal.

I added a sleep 1 right after my main function call, and the % dropped to 0.  If I add a real timer to it, it should replace the sleep function call.

Posted on 2005-07-27 05:48:50 by drarem

Thanks, I didn't know my real-time apps were doing that..  why is it bad to hit 50% cpu usage?  Bad for chips or bad to be stingy >)  ?  The system idle process is at 98% all the time, guess that is normal.

I added a sleep 1 right after my main function call, and the % dropped to 0.  If I add a real timer to it, it should replace the sleep function call.

CPU spikes in general are discouraged. Think of it like an automobile assembly line, if you have a rush and then a deficit, it takes that much longer to get things back into smooth flow. CPU usage should only seriously fluctuate during application loading and other load/purge operations.
Posted on 2005-07-27 16:21:34 by SpooK
drarem, we noted the cpu usage, because even if the app doesn't do anything, it lags the PC (heavily!) .
Mouse movement was pain, and animation of movement was completely rigid. Gives up any gamer immediately.

Using UpdateWindow or InvalidateRect (actually the former calls the latter internally) on regular short intervals leads to such lags, as I've noticed from my own experiments. Just keep the window region valid all the time, and you won't have problems.
Making the cpu work all the time on 98-100% will lead to overheat on imperfectly assembled and maintained PCs. During summer, perfectly-assembled ones are prone to overheat too, when used all the time at 100%. An automatic PC power-down is the least penalty for overheats.
Posted on 2005-07-27 16:53:36 by Ultrano
I think drarem already knows my Ilix library, maybe //clone might find it useful too -
It's good for fullscreen games, completely ready to use. It only lacks my favourite BltAdd proc, but that can be easily changed.
Posted on 2005-07-28 12:15:56 by Ultrano
I'll try your library, it comes up as page cannot be displayed.
Posted on 2005-07-29 15:50:33 by drarem
Also another pitfall I found to be annoying with DirectDraw is the BLT strecth thing. My emu uses DirectDraw and I make use of the strecth feature of the Blt. The weird thing though is that my S3 SuperSavage (in my Thinkpad T23) doesnt support stretching yet it supports OpenGL and D3D H/W acceleration :S, doesnt make any sense. Well anyway BLT (w/ stetch) is super slow on my laptop :(.

Just make certain if using DirectDraw to check if a feature is supported before using it, maybe if it is not you can write optimized routines to emulate the functionality.
Posted on 2005-07-29 17:54:05 by x86asm
x86asm: yes, and on top of that, Blt stretch looks different on different PCs. For these reasons I haven't implemented it in Ilix, and any DD-based code of mine

drarem: my previous domain registrator is bitchy and their hosting server became bitchy about the lost domain.... so now I have to host files from home: Upload speed is only 110kbit/s, and if I play CS:Source, I stop the server ^^
Ilix doesn't have problems in full-screen mode. In window-mode, things are a lot more complicated, thus I had to make a separate lib "iDraw", posted in the game development forum.
Posted on 2005-07-29 19:09:39 by Ultrano