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
How to use param_named_auto <var> time ?
-
- Halfling
- Posts: 75
- Joined: Thu Apr 28, 2005 9:21 am
-
- Halfling
- Posts: 75
- Joined: Thu Apr 28, 2005 9:21 am
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.
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.
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
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:
Glad you got it sorted.
.. so you really should have known better than to monkey with it.Gets a pointer to the central timer used for all OGRE timings

-
- Halfling
- Posts: 75
- Joined: Thu Apr 28, 2005 9:21 am
-
- Halfling
- Posts: 75
- Joined: Thu Apr 28, 2005 9:21 am
Sorry, forgot to mention:
I wrote in the initial post:
Sorry for being rude, but you can't tell me things like
I wrote in the initial post:
You wrote: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.
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.The key is that it's Root::getTimer and not Root::createTimer.
Sorry for being rude, but you can't tell me things like
if you don't get my question at all.[/quote]so you really should have known better
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
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.
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.

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.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.
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.
-
- Halfling
- Posts: 75
- Joined: Thu Apr 28, 2005 9:21 am
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
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