Everything that move is based upon last frame render time, thus intensive use of TICKS. So game speed is stable even in case of framerate variations.

I noticed that the virtual calc is very CPU intensive and works better on a freshly booted Windows. Then performances drop significantly over time.

Edit

I wonder if it could explain why sometimes the jump key isn't very responsive (eg if you don't press Enter long enough).

I didn't notice that. You mean on sim right ? Be aware that you are limited to 5 jumps per run now (forgot that in changelog, or was it previous version already ? nevermind).

Thanks.

That's what it is supposed to do but I messed up something I guess. Launching it with radian mode is funny ^^

Last minor snapshot (0.0.6) before major update !

The game is now fully playable, first post updated.

Next things to do :
graphics improvements (including but not limited to landscape, game logo, friendly time format, HUD, animated ball and more),
menus,
track selection,
user tracks creation and loading,
moar tracks !
powerups ?

Edit : my best time so far for this version is 21159 18361 18241 18188 18057 17570. (To myself : stop playing and go to bed dude !)

My suggestions were merely so that users do not end up resetting stored data. Cheaters will always find ways to cheat in games. I'm all for learning by viewing other people's code. Likewise with the archive idea. It is way to easy to delete the contents of a program at the moment, not to mention the entire list of programs in the catalog. At least with the archive feature it prevents accidents like this. The archive feature does not prevent users from viewing code -- they just have to take a few extra steps to do it so that they don't end up with a null-content program.

I don't really care about cheating. You're right it's impossible to prevent it and anyway, it's fun to make games, it's fun to play them, if anyone find fun to cheat, great, we're entertaining a lot of people ! ^^

A real permanent storage or archive, would be welcome yes, but I see it more to actually store data, than to prevent data loss from opening programs. Opening a program should not reset user data at all, in my mind. And this permanent storage already exists, this is User Variable. If only we could create data in it.
It is true also that it is too easy to delete or alter programs.

Yeah I don't like the idea of closed-source myself since it prevents people from learning as much. Such password protection would only be a las resort solution to the accidental openings of source. I prefer that HP just fixes super global vars so they remain intact until reformatting the calc.

Right now, a Zelda game for the Prime is impossible without weird workarounds

I agree, when a workaround, even weird, is the only solution, then it's a good solution, obviously. I was talking about actually fixing things in next OS version, instead of implementing workarounds, you see what I mean ?
 

Or just something like EXPORT +[varname] for saved vars if they don't want to make saving over compilation default.

You mean telling the compiler to store a variable elsewhere so that it's not reset at next compilation ? If yes, not a bad idea for a lot of cases, a problem is if you modify the program enough so that the variables you stored don't make sense anymore with your new code. Storing data outside of the code is better I think.

In my very humble opinion, trying to prevent people to look at programs code they installed on their calc only for this reason seems a bit disproportionate. I think the way the OS works is broken at the moment, and finding workarounds now is just like putting bandages on a wooden peg (if that makes any sense in english ^^ ).

Reading other's code (and tweak it) is the best way to learn. People will want to read the code, and putting a sword of Damocles saying "Don't open or you'll loose your score/progression/precious data" is not the way I want to make programs.

Prime is young enough and HP people is still working on it, let's report and claim, I'm sure a solution will be found (I'll stick with Users vars, until something better is suggested :p ).

For my part I'll use a Home List for now, with a warning at first launch. I know it's not ideal at all, but at least user can save their list in a user variable and restore it at will. Best compromise I found.

The speed of the FOR loop (too slow for realtime). COS and SIN could be precomputed but I doubt it would make a big difference.

I think FILLPOLY might work too, but I don't know if it can produce circles this smooth.

Not too bad ^^

FILLCIRCLE_P(cx, cy, r, color);

EXPORT circles()
BEGIN
   RECT();
   WHILE GETKEY() == -1 DO
      FILLCIRCLE_P(RANDINT(320), RANDINT(240), RANDINT(100), RANDINT(#FFFFFF));
   END;
END;

// quick, dirty and not optimal filled circles function
// (yeah, MAKELIST is better :p )
EXPORT FILLCIRCLE_P(cx, cy, r, color)
BEGIN
   LOCAL s, cl := {}, angle := HAngle;
   HAngle := 1;
   FOR s FROM 0 TO 359 STEP 10 DO
      LOCAL cp := {};
      cp := append(cp, EVAL(r * COS(s) + cx));
      cp := append(cp, EVAL(r * SIN(s) + cy));
      cl := append(cl, cp);
   END;
   HAngle := angle;
   FILLPOLY_P(cl, color);
END;