Hello,
my Wizard of Wor came into a state where things really started to work and now I'm experiencing a typical problem I don't know how to solve within Razor!.
Ive just implemented some collision detecion between the sprites I'm using so today is the first time they actually disappear from the screen and the problem occurs.
Its simple: the speed of the engine heavily depends on the number of the sprites. My problem is not that it's slow... the problem is that it's changing with time. The speed I've tested with so far was my warrior going against 7-8 monsters and some shots on the screen, and the speed was fine... but as soon as I start killing off the beasts, sprites disappear and everything gets faster and faster..
I am doing my steps in nextPeriod and drawing in drawAction. I've tried to change presAdvanceTimeInterval in Customization.h but it made absolutely no difference at all (even at a level of 20).
Is there some way to
1) either limit the timeslice (I don't need 50; 30 would be enough)
2) have the timeslices running on a constant speed with drawaction frame skips if needed.
I'd prefer the first solution. Teacy?
Regards: Marcell
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-09-04
Changing presAdvanceTimeInterval is the correct way to go.
If this is not working, then there might be a bug in Razor! and I will have to look.
BTW, Razor! can sometimes be a lot slower than it looks, especially if you use GCC instead of Code Warrior, for which the assembly routines have not been ported yet.
What compiler are you using, and what kind of device, at which color-depth? Are you using POSE or a real device? I have offered to inspect other people's source code in the past, to work out problems. Just send it privately to tilo.christ@online.de
Cheers,
Tilo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-09-05
Using CodeWarrior8, PalmOS SDK4. Testing on a PalmOS4 running on a real m505, 8 bit color depth.
I'll check the razor! timestepping code again because I've seen something odd there (in Presentation::nextPeriod() why do you calculate the next time step at the end of the function instead of the beginning? If the nextPeriod of the Screen takes too long it could screw up the timing a bit... This was an answer to my question about the different time slices but it still does not explain why chainging presAdvanceTimeInterval would'nt change anything.
I'll send you the sources. Test it yourself.
Thanks in advance:
Marcell
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-09-05
I just committed a version of Presentation.cpp to the CVS repository, which has moved the calculation to the top of the method.
I tried your example with this modification, and at least on my Vx it runs at constant speed at all times now.
Thanks for pointing this out :-)
Tilo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
my Wizard of Wor came into a state where things really started to work and now I'm experiencing a typical problem I don't know how to solve within Razor!.
Ive just implemented some collision detecion between the sprites I'm using so today is the first time they actually disappear from the screen and the problem occurs.
Its simple: the speed of the engine heavily depends on the number of the sprites. My problem is not that it's slow... the problem is that it's changing with time. The speed I've tested with so far was my warrior going against 7-8 monsters and some shots on the screen, and the speed was fine... but as soon as I start killing off the beasts, sprites disappear and everything gets faster and faster..
I am doing my steps in nextPeriod and drawing in drawAction. I've tried to change presAdvanceTimeInterval in Customization.h but it made absolutely no difference at all (even at a level of 20).
Is there some way to
1) either limit the timeslice (I don't need 50; 30 would be enough)
2) have the timeslices running on a constant speed with drawaction frame skips if needed.
I'd prefer the first solution. Teacy?
Regards: Marcell
Changing presAdvanceTimeInterval is the correct way to go.
If this is not working, then there might be a bug in Razor! and I will have to look.
BTW, Razor! can sometimes be a lot slower than it looks, especially if you use GCC instead of Code Warrior, for which the assembly routines have not been ported yet.
What compiler are you using, and what kind of device, at which color-depth? Are you using POSE or a real device? I have offered to inspect other people's source code in the past, to work out problems. Just send it privately to tilo.christ@online.de
Cheers,
Tilo
Using CodeWarrior8, PalmOS SDK4. Testing on a PalmOS4 running on a real m505, 8 bit color depth.
I'll check the razor! timestepping code again because I've seen something odd there (in Presentation::nextPeriod() why do you calculate the next time step at the end of the function instead of the beginning? If the nextPeriod of the Screen takes too long it could screw up the timing a bit... This was an answer to my question about the different time slices but it still does not explain why chainging presAdvanceTimeInterval would'nt change anything.
I'll send you the sources. Test it yourself.
Thanks in advance:
Marcell
I just committed a version of Presentation.cpp to the CVS repository, which has moved the calculation to the top of the method.
I tried your example with this modification, and at least on my Vx it runs at constant speed at all times now.
Thanks for pointing this out :-)
Tilo