PyWeek - RICHARD: unmarked ?

I uploaded from the web page, using Opera browser. I doble checked that the 'final submision' was checked, but... The file shows in the entries list but its the only that not have the 'not rated' in the titlebar.
And there is not the phrase ..'final entry...'
Can you help ?

— claxo on 2008/09/14 09:51 of mutant lightning dog

Comments: (log in to comment)

By richard on 2008/09/14 21:53:

There are two final submissions uploaded against your entry.

By claxo on 2008/09/14 22:50:

Thanks, Richard.
Oh, sorry, probably I misunderstod the ausence of 'not rated' as a 'not an entry with final submision'.
Thanks again, Richard.

By riq on 2008/09/16 18:14:

I'm running your game in a MacBook OS/X 10.5.4 intel. python 2.5.2, pygame 1.8.1. It runs pretty slow.
it this the expected behavior ?

By claxo on 2008/09/16 18:39:

( the game is kiko )
Well, in the first level probably you can't go too fast or you lose equilibrium and fall. In the second and third, I would say that appears slow in comparation with other games, but just a tad.
Just to confirm if we are looking the same, I timed the time it takes kiko to go from the left time to the right side of the 3rd level, about 10 seconds. You see the same ?.
If you see similar, then you can blame me for the constants selected ( no time to adjust )
If more than this, then there is another problem.
In my plataform, win xp, I tested with pygame 1.7.1 and 1.8.1, no diferences.

On another thing: shame on me! The screen telling what key to use mention 'z' and 'x' for equilibrium, when in reality is 'z' and 'c'. ( sorry )

By riq on 2008/09/16 20:47:

ok, something is wrong with my configuration + your game.
For example, the falling (when there is no balance) takes 10 seconds.
It takes me more than 1 minute to pass level 1 :-(

By bencoder on 2008/09/16 21:23:

riq: I had the same problem on ubuntu, it was really slow, i've just tried it on windows and it goes at a normal, decent speed.. it's a lot harder! how strange though :S

By claxo on 2008/09/16 22:21:

Thats strange
It cannot be a diference in raw power of the machine, because most of the time the blit is only the sprite kiko, and there is not complex math or anything cpu intensive.
Oh Oh! the physics advances as dx = v*dt, where esentially the time to calc dt comes from time.clock(), where time is the std python module. That was suposed to be the cpu clock, in theory more acurate than time.time(). I would expect only small changes due to granularity. But what if in linux doenst go paralel to wall time, ie some type of elapsed time ?
Anyone experiencing this slowness can try this workaround and report?
In kiko/base.py , at the top of the file, change:
time_service = time.clock
to
time.service = time.time
I will look to test geting time from pygame, but let me look at the code.
Its ok if I rename this thread to kiko problems, just for newcommers ?
Any help apreciated.

By claxo on 2008/09/16 22:31:

typo!! sorry.
time_service = time.clock
to
time_service = time.time

By claxo on 2008/09/17 01:27:

Ok, I joined #pyweek and Zero|Byte did a quicktest, it works.So for Linux and Apple , please change in kiko/base.py , near the begining,
the line
time_service = time.clock
to
time_service = time.time

If something else crop , please post. Also any comment are wellcomed.