My engine: Woo, progress!

[sniperwolf]

Okay... first off, I took the advice given in the last thread, and looked into bulletML. The demo on their site is AWESOME. Thus, I have started work on a bulletML document parser class, and it's coming along fine. Considering I've never touched an XML document in my lifetime, I'm surprised...

The timing code has been totally rewritten to lock the [max] framerate at 60fps. I did this, because running the sample game on my laptop [2.2ghz Athlon XP w/512 megs of DDR [shared, 128 for AGP, 384 for system, and an ATI Radeon IGP320 chipset] vs. my desktop [1.8ghz Athlon with 1 gig of DDR and an ATI Radeon 9600] yielded WAAAAY different play speeds. So now, I base everything off of a forced 60 frames per second. This seemed like a fair setting.

Sound clip playing via DirectSound is now working, though heck, I'm already using FMOD for the mod loading, I might consider switching to FMOD for sound clips. As for right now, though, DS is doing a fine job for bullet firing noises.

I'm also moving the entire thing, slowly but surely, over to a state-based system of handling events. I'm having excellent results so far, too. Enemies will behave via what state they're in [firing, idle, etc], the player's ship will move/fire according to it's state, even the engine will maintain state data [such as having a state for loading intro screens, menu, level loading screens, etc]... much better than maintaining huge amounts of boolean flags.

After the bulletML stuff's done, I'll be moving all my input routines to DirectInput. Darn it, I want to start using my Playstation pad to control this thing!

I'm also going to try to make it so that the engine can, probably at the toggle of a boolean flag, switch between top down and side view playing. I don't <b>think</b> it'd be that hard, I'd have to mess with my movement functions to accomodate side-to-side instead of up and down motion, and as far as Direct3D goes it's just moving the camera to a different location... but I think it'd be a neat effect to have handy, even if the engine's designed for side-scrollers.

As a side note, to anyone who claims they don't have enough time to code a game - get a middle management job, and have your boss go on vacation. Voila... lots of time.

[sniperwolf]

I should've also mentioned, the engine is now officially titled "XType", after having to come up with a name for the new project [the old one was just "shipmodeltest", named after me trying to figure out DirectX mesh loading. ]

[mice]

lock the [max] framerate at 60fps

What happens if the framerate drops under this? Does the game run slower then?
Or do you have float-point operations making the game the same speed but with bigger "moving-steps" between frames?

Cheers!
((mice

[Blue]

Another (imperfect) alternative to locking the framerate:
It sounds like you're storing your movement speeds as distance/frame? When the framerate goes over 60, reduce the distance everything moves proportionally.

60/(current framerate) will give you the amount to reduce speeds by.
At 120 fps, 60/120 = .5
At 93 fps, 60/93 = .645...

This will work for speeds below 60 fps as well.
60/35 = 1.71...

I hope I'm making some kind of sense. So before you start a frame, check the framerate. Then find your multiplier:
60/current framerate
When you move your objects, use speed * multiplier.

Pros:
Won't cap framerate on high-end systems
Constant game speed across all systems
Works for both extremely slow and extremely fast systems

Cons:
Could produce irregularities in bullet patterns, depending on how bullet firing is handled
More math used for object movement

I hope that was helpful! I'm sure there are many ways to improve on this idea.

[landshark]

One more "con" to that is it'd be very difficult to store replay files since the movement is dependent upon the speed of the system.

[Tychom]

Okay... first off, I took the advice given in the last thread, and looked into bulletML. The demo on their site is AWESOME. Thus, I have started work on a bulletML document parser class, and it's coming along fine. Considering I've never touched an XML document in my lifetime, I'm surprised...

Have you considered looking at libbulletml? it'll save writing all that again. Of course if the idea is to be writing all of your own stuff then continue writing a bulletml parser. If starting from scratch though I'm sure there are more human-readable methods of defining bullet patterns though than in XML documents.

[sniperwolf]

Have you considered looking at libbulletml? it'll save writing all that again. Of course if the idea is to be writing all of your own stuff then continue writing a bulletml parser. If starting from scratch though I'm sure there are more human-readable methods of defining bullet patterns though than in XML documents.

I'll look at that too. And really, the more I look at bulletML the more I realize I could probably just clean up and modify my existing bullet handling function with influence from how bulletML handles motion/attributes, and accomplish the same thing w/out nearly as much trouble...

[sniperwolf]

And as for the framerate control:

Everything moves at a constant scroll rate, except for the static world terrain. This rate is affected by the current frames per second, which is right now extracted out of my timer class. When things drop below 60 frames, the world slows down accordingly; the player, bullets, everything scrolls slower. So yeah, I'm basically scaling the movement according to FPS, I'm just also saying that the max possible fps is 60.

The reason I capped it at 60 is that honestly, there's no reason to let it be faster for higher end PCs in my eyes. If I have it capped at 60, I can base my movement formulas off of it and know that no matter what machine I run it on, it'll always run at a certain speed - I'd hate to see it run unplayably fast. Thankfully, I have yet to see it dip below 60, even on my laptop.

More later - DSL is flaky today.

[ED-057]

one problem with sticking to 60fps on a PC is that things won't be as smooth as they could be when the monitor is not being refreshed at the same rate.

[sniperwolf]

one problem with sticking to 60fps on a PC is that things won't be as smooth as they could be when the monitor is not being refreshed at the same rate.

Good point... I think that might be what's causing my current problem, visual tearing when I render my terrain mesh [before, I was just using a generic 3D starfield mesh]

I'll start a new thread about the timing problem, post up my current code for it, see if I can figure out a way to fix this whole thing..