I'm in the final stage of developing DYNATRIS - a Tetris clone for the HP Prime. The game is implemented in Python and runs at 50 FPS.

Why 50 FPS in Tetris-like game?
Well... I like when things happen on screen and I can spend a lot of time perfecting my programs and games graphically.

Key features implemented:
- Smooth piece movement instead of grid increments
- Bidirectional piece rotation
- Super Rotation System (SRS)
- Soft drop
- Hard drop with trail effect
- A kind of explosion effect during line clearing
- UI panels: Level, Next piece, Piece statistics, Lines cleared, Score.

What I've managed to create so far can be seen in the recording below.



No title screen yet - I want to avoid making it generic, so I need to think it through carefully.

Any comments or suggestions are welcome.

Wow, I haven't seen these features in tetris games anywhere!(save for some CE ones) Maybe the title screen can include a game being played blurred in the background while having options with a fancy cursor that moves with a blurring effect.

I'm quite interested in how you got the explosion effect working (like, looping through a few houndred coordinates all being subject to gravity or whatnot). Oh, and are you trying to recreate the NES version of tetris? (At least the functulality I guess)

This tetris clone surely has some of the better and more complete features I have seen. Good luck with the title screen! 😁 😁 😁

This looks really nice! I love the animations. The Prime G2's refresh rate goes from 55-125hz. Would it be possible to increase your fps cap to 100fps to take advantage of the high refresh rate display and get smoother animations?

Thank you for the feedback!


Unfortunately, there's currently no possibility to write code in C/C++ or assembly for HP Prime. Blurring graphics in each frame as a moving background would require an efficient low-level algorithm that would calculate blur pixel by pixel, which in Python is unachievable at 50 FPS. It would probably be difficult to achieve even 1 FPS with such an effect. Although it's quite possible that new graphics commands will be added over time allowing direct framebuffer operations, which would significantly increase graphics capabilities.


Actually there aren't hundreds of coordinates here, but a maximum of 40 (x, y) pairs. You can clear no more than 4 lines simultaneously, and each has 10 elements, so these aren't such large quantities to process. Of course, each element requires gravity calculation and motion vector correction in every frame, and then comes the scaling effect of elements until their complete disappearance, but in this particular case these aren't very computationally intensive.


Before I started coding, I looked for inspiration and reviewed several Tetris implementations for calculators, including those on the CE series (I also own a TI-84 Plus CE and a Casio FX-CG50). I didn’t find anything particularly outstanding, except for Tetric A/Tetrizm, which offer different game modes. I’ll probably implement something similar for the title screen’s game mode selection. However, it's possible I missed something and that there are other noteworthy implementations out there.

As for NES, I was partially inspired by that version, but it wasn't my main direction.
After planning all the features, I designed the game screen entirely from scratch—first in a graphics program, then by faithfully recreating it using graphics commands instead of bitmap images, to minimize memory usage.


Thank you very much for the kind words. 🙂
I already have an idea for the title screen, but I need to check if the HP Prime can handle it performance-wise.

Thanks! 🙂

100 fps? Yes, it’s possible 😁

You should know that on actual G1/G2 hardware, this runs more smoothly than in this recording. That’s probably because the emulator can’t refresh the screen fast enough—even at 50 fps it drops some frames. So even if the screen capture tool is set to 60 fps, it still can’t record frames that the emulator drops.

Anyway, I tested this and the difference between 30 fps and 50 fps is noticeable, but between 50 fps and 100 fps it’s barely perceptible (assuming the G2 is set to a high refresh rate). Though, it's probably also a matter of taste and sharp eyesight.

I managed to optimize the rendering, especially the part that handles the explosion. Currently, tetromino movement — including input handling, position checking, and smooth animation — takes only 3 ms on the G1 and 1 ms on the G2. The processing and rendering of the explosion animation take 12 ms on the G1 and 4 ms on the G2. This theoretically allows for 83 fps on the G1 and 250 fps on the G2.

Additionally, I introduced changes so that all timings are now based on timers (regardless of the current fps). Thanks to this, I can assume a refresh rate of 100 fps (which is realistic even on the G1, excluding the explosion animation). And in cases where this time is exceeded, the game's smoothness won't suffer — only during heavier moments will the fps drop on the G1, but the movement/animation shift will still be calculated proportionally to the time elapsed since the previous frame, so a momentary drop in fps will be imperceptible to the human eye.

In summary, I now have a unified codebase for the G1, G2, and emulator, rendering at 100 fps (although the G1 can't actually display that many), and sometimes on the G1 it may drop to 83 fps (only during the explosion animation).

I also ran into a minor issue with horizontal tetromino movement, which is smooth by design. As the level increases, the tetrominoes fall faster, so I added a mechanism to increase horizontal movement speed accordingly. However, at higher levels, this led to a problem — the speed became so high that it was very difficult to move a tetromino by just one cell left or right, since even a quick tap often resulted in jumping two cells instead. I had to introduce a maximum speed limit, as I didn’t want to sacrifice smooth movement in favor of stepped movement.

That said, I’m considering an alternative: applying the same speed limit for the initial cell movement, and then allowing faster horizontal motion — scaled to the current level — if the key is held down.

I still need to experiment with that...

Congratulations, that's very impressive!

If only other calcs had such a powerful python 👀 (instead, TI has a great amount of modules and support for accessories, so now they need to make it fast...)

Amazing work 🙂.

Thanks!

Almost everything is ready 🙂 I just need to prepare a short documentation and I’d like to compress the code so that the application is smaller. I think I’ll publish the first release within two days.

The title screen might not be sensational, but with a fully animated background running at dozens of frames per second, it's hard to achieve more. Maybe it might be worth limiting the frame rate for more interesting, though less fluid, effects.



The code has been compressed. I’m finishing the documentation...

Dynatris is available for download here.

All comments are welcome, especially constructive ones.
Please let me know if you encounter any bugs — though I hope there aren’t any.

You should make it for the TI-84 plus CE.

There is one here: https://www.cemetech.net/downloads/files/1347/x1347

is there a way I can download this on my calc using a Chromebook I have ZERO access to connectivity kit