How to use param_named_auto <var> time ?

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
Tassilo
Halfling
Posts: 75
Joined: Thu Apr 28, 2005 9:21 am

How to use param_named_auto <var> time ?

Post by Tassilo »

Sorry, I have problems using:
param_named_auto <var> time

In the manual, the 'value_code' [b]time[/b] is described as:
[quote]The current time, factored by the optional parameter (or 1.0f if not supplied).[/quote]

Well, I always get 0 in my vertex or pixel shaders.
What is the format of the time returnen by this value code ?
... and why do I get 0 all the time ?

Thanks,
bye
Tassilo
Halfling
Posts: 75
Joined: Thu Apr 28, 2005 9:21 am

Post by Tassilo »

Ok, I fixed it. I'll post the solution for everyone that's interested.

I started out using a timer I got from the Ogre::Root object using the getTimer() method. That gave me a timer I was able to work with, since all the calls to Timer::reset(), Timer::getMicroSeconds(), etc... worked.

But the "time" parameter didn't work, and the things like wave_xform inside the materials didn't work either.

If I create a timer using PlatformManager::getSingleton().createTimer(), it works, though. Seems like Ogre uses the first timer created by the user for a lot of other things inside the engine.

Ok, I'm happy now, but I'm still interested in an explanation about the architecture of Ogre, since this isn't coherent, though.
If the user really has to "start" a timer (perhaps in order to tell Ogre when to start counting), why isn't it possible to spend the Timer class a thing like init() oder run(), etc... or to redesign it (with these things in mind, reset should be replaced by getDelta(), or something like that), in order to really "define the point" the counting starts up ?
This is not meant to offend the authors of Ogre - you're doing a great job. Keep up the good work.

Thanks - I hope this helps other one's with similar problems.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

Well, the Timer you get from Root is clearly the central timer, so changing it's state alters everything, that's kind of the point. You can create extra ones if you want it to be independent, as you've seen. The key is that it's Root::getTimer and not Root::createTimer. And to be fair, the documentation for Root::getTimer does say:
Gets a pointer to the central timer used for all OGRE timings
.. so you really should have known better than to monkey with it. ;) Glad you got it sorted.
Tassilo
Halfling
Posts: 75
Joined: Thu Apr 28, 2005 9:21 am

Post by Tassilo »

Well, ok, it's the central timer....
And why do the animations using wave_xform, and the time parameter for the shaders don't work if I don't call PlatformManager::getSingleton().createTimer() at least once ?

Sorry - I'm not kidding.
Tassilo
Halfling
Posts: 75
Joined: Thu Apr 28, 2005 9:21 am

Post by Tassilo »

Sorry, forgot to mention:

I wrote in the initial post:
I started out using a timer I got from the Ogre::Root object using the getTimer() method. That gave me a timer I was able to work with, since all the calls to Timer::reset(), Timer::getMicroSeconds(), etc... worked.
You wrote:
The key is that it's Root::getTimer and not Root::createTimer.
And now, please compare the quotes. I did it exactly the way you describe it, and the things mentioned don't work that way. I have to call PlatformManager::createTimer() at least once. Perhaps it is not the way it should work, but well, it works that way.

Sorry for being rude, but you can't tell me things like
so you really should have known better
if you don't get my question at all.[/quote]
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

Well, that's what the ;) was for, but I guess you're in no mood for friendly jokes today; I'll just get down to business then.
And now, please compare the quotes. I did it exactly the way you describe it, and the things mentioned don't work that way. I have to call PlatformManager::createTimer() at least once. Perhaps it is not the way it should work, but well, it works that way.
No, you don't have to; none of the examples do and wave_xform and time-based shader paramers et al work just fine (we use them in the demos). What they don't do though is call Root::getTimer and start calling state-modifying functions on it, which was your problem I believe.

Each timer is self-sufficient - Root calls createTimer itself in fact when it starts up. Your posts seemed to indicate that you were calling methods like reset() on the central timer which is a sure-fire way to make it misbehave. You seem to have misunderstood my point about getTimer and createTimer - what I meant was that the naming of getTimer implies that you're getting a timer instance which is potentially used by others, not creating one you are free to modify without repercussions. The API states it too of course. So by calling getTimer and modifying the result, you're interrupting the normal flow of time as OGRE perceives it, which is why wave_xform et al didn't work.
Tassilo
Halfling
Posts: 75
Joined: Thu Apr 28, 2005 9:21 am

Post by Tassilo »

Hello,

sorry for being confused about your post. Thank you for your answer and for shedding some light on the problem. Now I understand the problem. I use a separate timer now for keeping the game at a constant speed, so I can use an own timer not disturbing the general timing no more.

Thanks again
Cheers
Tassilo