Schedule based on sceneGraphTime

#1 I've been thinking of asking for this for a long time. I think the schedule should be based on the sceneGraph time. For instance:
My bullets are fired based a schedule when ever the player is holding space down. This works exactly like the demo. At extreamly low frame rates the scene time slows down, but bullet creation does not. This makes the bullets closer together. It also (from the scene's point of view) speeds up bullet creation, which means more sprites, which means the game slows more, which means more sprites... You get the point. Soon you're running at 0.1 frames a second. If you let go of the space it recovers. This problem is even worse in the side scrolling demo because the bad guys are also generated by a schedule. So when the boss dies the game slows down for some people, which makes the bad guys and the bullets generate faster. That's why people were getting huge leaps in points when "the boss died and everything got really choppy." Anyway, it really affects my game since if you were fighting a boss and suddenly your bullets were coming faster it would effectively make your gun much stronger. It also gives the player incentive to have a slow machine!

So, I second that motion.

-Peter

#2 I've actually got something similar to this on my NICETO list. It certainly would be nice for the scenegraph to have its own timebase timers both single and periodic. I think I'll bump it to my TODO list!

*sigh* another thing to get done. ;)

- Melv.

#3 @'Poor' ;) Melv: I will prob. have a look at it for my next project anyway, I'll send you the results when I have something. I usually post things here if I think they are a good general idea.. eventhough I might end up writing them myself (such as forceEvent). Could I ask you how you had planned it (calls / methods / naming)?

-Edo.

#4 This is definitely a good idea! It would definitely resolve a couple of problems my games experience under bad (ie, slow FPS) conditions.

Although, instead of a schedule command tied to the scenegraph object, perhaps there should be an alternate schedule() command (%obj.sceneTimeSchedule( %delay, %command, [etc] )) that could still be attached to the object needing the scheduled event. The reason being that any scheduled events for that object will be cancelled automatically if it uses a %obj.schedule() call rather than a global schedule() call.

Just a thought.

#5 Are there any advancements on this topic? If not, I might give it a look and post a solution.

#6 Hmmm... this is sure interesting, because my game is fighting in the border line
of "acceptable frame rate" right now in my target machine (2.2Ghz + 64 MB video)
I have resorted to spaw enemies in zones because lots of entities drop the frame
rate at the point where collision becomes inaccurate and the NPCs fall of the platforms...
well optimizing is something that any game programmer is going to do always I think
but a little help would be appretiated :)

#7 Dammit! It's 4:30 am over here and I'm still sitting in front of my computer. But I've got this working and it's pretty slick. I hope for sure, this feature is not included in the new Alpha3 that just went live...
Also, I have only done the most basic testing, so use with care and report any bugs.

You can download the source file here: SceneTimeScheduler.cc

It's just this one source file. Drop it into your c++ project anywhere and recompile. It compiles fine in Visual Studio Express 2005 with the Alpha2.

Before using any of the new commands, you have to call t2dSceneGraph::initScheduler() in your script.
Then you can use the new commands:
t2dSceneGraph::sceneSchedule() /* works exactly like schedule, I think */
t2dSceneGraph::sceneEventPending(%id)
t2dSceneGraph::sceneForceEvent(%id)
t2dSceneGraph::sceneKillEvent(%id)

(Names are arguable).

An example:

// ************************************************************************
	//
	// Add your custom code here...
	//
	// ************************************************************************
	
	t2dScene.setDebugOn(255); //  we want to see our object...
	t2dScene.initScheduler();

	%x = new t2dSceneObject() { sceneGraph = t2dScene; };

	for(%i=0; %i < 10; %i++)
		t2dScene.sceneSchedule(%i, %x, "setPosition", %x, -50 + %i*10 SPC "0");

As you can see in the source file, I tried to use a FreeListChunker for better memory managment but I always got errors. Maybe I was using it in a wrong way. Also note, that I didn't modify the engine in anyway. However, this has the sideeffect that I had to use a dynamic field to store the SceneTimeScheduler's id - causing some nasty lookups in the Sim-dictionaries that could be avoided by storing a pointer in the t2dSceneGraph class.

t2dSceneObject::sceneSchedule and the like will follow.

I hope you find this useful. I'll be using it and will post any updates here.

-Michael

#8 Ok, I have updated the source file.

From the file:

Changes from v0.1 to v0.2

- added ConsoleMethod t2dSceneObject::sceneSchedule()
- changed set-/getSceneTimeSchedulerIntervall() to set-/getSceneTimeSchedulerInterval()
- added constant sanity checking in SchedulerUpdateEvent::process()
- corrected error messages in the ConsoleMethods
- added sanity checking in ConsoleMethod initScheduler()
- changed default SceneTimeScheduler::UPDATE_INTERVAL to 10 ms

Note that sceneSchedule() does not take milliseconds for the time-offset but seconds (for consistency with scene time that also is given in seconds). So you have to specify an offset of 0.5 where you formerly had 500.

Everything seems to work fine.

-Michael

EDIT:

The new file is tested in ALPHA 3b. For the example in the post above you have to change

t2dScene.setDebugOn( 255 ); //  we want to see our object...

to

t2dScene.setDebugOn( 0, 1 ); //  we want to see our object...

since t2dSceneGraph::setDebugOn() has changed in Alpha 3.

#9 Awesome Michael!
I'll check this after porting my game to alpha3!!

#10 If I'm not mistaken, I think this same functionality is in the alpha3.

#11

Quote:
If I'm not mistaken, I think this same functionality is in the alpha3.

In that case:

Are you sure? I could not find anything. But I already wondered why this didn't get more attention, as it would solve all pausing problems and the like.