New update 090926

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (https://www.hpmuseum.org/forum/forum-3.html)
+--- Forum: HP Prime (https://www.hpmuseum.org/forum/forum-5.html)
+--- Thread: New update 090926 (/thread-25448.html)



RE: New update 090926 - komame - 2026-09-24 17:25

Kevin,

Well, there are two things worth mentioning here:

  1. There is definitely still quite a bit of untapped potential in the HP Prime, so I think the performance could be improved quite significantly. I managed to optimize some parts of the code and I am attaching those changes as version 1.02, but there is still more that could probably be optimized. I would just need more time to look into it properly, which unfortunately I do not have at the moment.

    One thing I would recommend changing is the way the timing is handled. The current performance measurement used to determine the delay seems to be quite unstable. There are more reliable ways to handle this without having to tune it specifically for a particular platform. In particular, I would not use WAIT as the actual frame-time reference. It can still be useful for filling the remaining frame time, ideally with a small safety margin, but the timing itself should be based on a more reliable reference. I can show you an approach that works much more consistently.

  2. There is indeed a BLIT_P bug in the new firmware! I have already filed a ticket in the bug tracker. In general, BLIT_P is faster in the new firmware, but there is one particular case where it is much slower, and your game happens to use that case quite heavily (although it is fairly easy to avoid).

    The issue is related to the c (color-key) parameter. When it is specified, the new firmware becomes significantly slower. However, the same graphical effect can be achieved by initializing a GROB with a transparent color and then drawing opaque elements onto it. This way, the resulting GROB can be blitted without specifying the c parameter, while the bitmap still retains its transparent background.

    This is actually even faster than using BLIT with c, so in practice it is better to avoid that parameter whenever possible, and in many cases this can be done without major changes to the code. That is exactly the workaround used here. Ultimately, the ICON definitions themselves could already contain transparent bitmaps.