Yeah, I realized that quickly, but unfortunately I was at work by that time ;)
I tried some other things, such as
class terrain_Body(soya.Body):
def advance_time(self, proportion):
pass
def end_round(self):
soya.Body.advance_time(self, 1)
soya.Body.end_round(self)
and a few other things to that effect, but it doesn't give me any kind
of noticeable optimization, so I'm tempted to assume that this is not
whats hanging things up.
So frustrating!
So, back to square one:
observations thus far:
1) using other opengl programs on this machine, I can judge that there
is more than ample machine power to render this all.
2) frame rate when most objects are visible (average of about 50 body
instances): 0.0fps
3) frame rate when about 1-4 objects visible: about 10fps
4) frame rate when just the character is visible: 20-25fps
5) when the framerate is low, data streaming from the server gets
backed up, and can not be
processed efficiently. The socket is checked in one of the world's
begin_round method. Also, sdl events are checked at this time and
information is sent back to to the server.
As far as I can tell, the difference between observations 2, 3, and 4
is the poly count being rendered, and the number of visible Body
instances.
buuut, observation 1 would suggest that poly count is not the problem.
So, its either something to deal with the number of visible bodies, or
how the code nested into the begin_round method is interacting with
soya.
Problem with the latter assumption is how the server sends the
rendering data... level data is only sent as the character changes
level, and character data is spammed out, saying where everyone is in
the level each frame. All of my testing has been solo, so theres no
scaling or diminishing of players...
*pause of reflection*
I think this makes sence now; if the data from the server piles up,
the frames are still processed sequencialy. as a safeguard, if it
piles too high, it skips all but the latest frames, but this creates
an odd bug in level loading that I havn't mentioned before, but it
works as a great indicator;
In any case, such a pile up could cause the character to appear
unresponsive, and all the processing happening in the begin_round in
the base world object could be whats preventing the animation to go so
smoothly.
But, it still seems like a chicken and egg type thing; this hasn't
been this much of a problem in the past. However, it seems like the
next logical step is to tinker with how it all fits together ^_^;;
Thanks for all your advice so far :)
On 6/20/07, Souvarine <[EMAIL PROTECTED]> wrote:
> What you did won't work. The advance_time of your body is still called
> several times per round by the world it is into, therefore you won't get
> any performance gain.
>
> Anyway I'm not sure that my idea of calling advance_time just once per
> round for non visible objects will really improve performances or not,
> this need more tests ^_^
>
> Souvarine.
>
> Lunpa, The wrote:
> > I was digging through the examples, and I found out how to make a
> > custom soya.Body class that has a proportion of 1 each time
> > advance_time is called:
> >
> > class terrain_Body(soya.Body):
> > def advance_time(self, proportion):
> > soya.Body.advance_time(self, 1)
> >
> > I've modified the game so that terrain objects are loaded into the
> > terrain_Body class instead of a normal Body object. Performance
> > appears to be identical.
> >
> > Also, as a correction to before, there are about 40 body objects
> > (including "terrain_Body") in the attached screen shoot of the game.
> >
>
> _______________________________________________
> Soya-user mailing list
> Soya-user@gna.org
> https://mail.gna.org/listinfo/soya-user
>
--
This email message is public domain. Have a nice day! ^_^
_______________________________________________
Soya-user mailing list
Soya-user@gna.org
https://mail.gna.org/listinfo/soya-user
