With the success of my re-make of BLOXORZ on the monochrome 83+/84+, and by popular demand, I have begun work on BLOXORZ for the CE.

The reasonable thing to do would be to take the existing BASIC BLOXORZ and re-work the Pt(, Line(, and Text( calls to fit the new color screen. And in fact, thanks to DJ Omnimaga's tip, using CEPORT did work pretty well.

But, that is not as satisfying as what could be: a true recreation of the game. Not just in mechanics, but in graphics as well. Keeping to the nature of what I believe to be the allure of calculator programming, I wanted all of the development work to be on-calc. But at the same time, the performance and graphic capability of an assembled program would be necessary.

And for this, only one option exists: ICE (Paired Designer v5 for making graphics).

ICE is, at this point, deprecated. PT archived the GitHub in 2022, with the latest development coming to an end shortly after it was made LLVM compatible in 2021. But since it uses the CE toolchain clibs, and those are still in development and backwards compatible, ICE still runs on the latest CE's!

Here are some demo screenshots:



Demo Video - - - Source (GitHub)

Features Implemented
X - Title Screen with Glow Effect
X - Sprites for all Game Elements
X - Custom Font
X - Block Graphics (for spinning, and animating movement)
X - Fade-from/to-Black for Stage Background
X - Wipe-up/down animation from bottom for stage field
X - "Swirl" out animation around the hole when stage is complete (custom arctan approx function)
X - Converted all 20 stages from the BASIC level data format to new integer-only ICE format
X - Moving the Block around the Stage, rolling on its side, end-on-end, and animating the movements.

TODO:
- Progress Save / Resume Game
- Load Stage
- Move Counter
- Coloring/Shading the Block sprites
- Detect when block falls off stage
- Falling animation
- Detect when block goes in hole (completes stage)
- Going in hole animation
- Bridges and Switches
- Split/Teleport blocks
- Rejoin split blocks

Just this demo is already 21kB compiled, but that already includes all the graphics. The core mechanics for the rest of the features shouldn't add more than ~8kB.

Really impressive work on this, downloaded the video and it's really slick.

I think the file size seems pretty good from your projections.

Thanks for the encouragement, tr1p1ea!

Had some more time to work on this in the afternoon today, and made some good progress:



- Tweaked the Swirl animation slightly. Still not happy with it, though. The framerate (top-left corner /10) tanks to 15 and looks really choppy, very much unlike the 25-30 fps normally.

- Most importantly, the block is moving across the field! The rolling animations are all made up of the same 9 sprites:
- Cube
- tilted right 10 degrees
- right 30 degrees
- right 60 degrees
- right 80 degrees
- down 10
- down 30
- down 60
- down 80
By stacking the cubes below/beside/behind the another, the illusion of a 2x block is created, and all the variations of 4 orientations transitioning bi-(2)-directionally along 2 axes with 5 frames of animation (4x2x2x5=80 unique positions) can be made from just 9 sprites.

I am very happy with the way the animations turned out. They chug along, easing in and out of lying flat on the board. It has a sort of "jumping bean" feel.


So far, the block just rolls around on the same plane as the field, but uses position index that is compatible with the stage data layout. The starting position is loaded from the level data when the stage is loaded. Checks for "on the board" and "in a winning position" are easy enough to implement (and can largely be lifted from the BASIC version).

Since the level data is in a different format from the BASIC version, getting the bridges to open and close is the next large design hurdle. If I aim to copy the original game as closely as possible, that means needing to encode and animate more things about the bridges, such as where they are tucked under the stage and rolling them out from underneath. I think I'll instead just blink the bridge area red or green when the bridge changes state, and not deal with the unfolding animation.

The GitHub has been updated with the source and the compiled BLOXORZ.8xp if you want to give it a try. [2nd] triggers the "win" swirl animation, and [clear] triggers the fizzle out "lose" animation. Both advance to the next stage in this demo.

This is a whole new level of depth. I have never seen such detailed graphics on a calculator, good luck with adding textures to the block. Keep up the stunning work! I am thoroughly amazed!

This looks amazing, especially the animations. 🙂

I've made quite some progress on this over the week programming on-calc, but have come across some interesting behavior when running this in CEmu to get screenshots.

In the Load Stage screen, when all 6 numbers have been entered, the 6-digit number is displayed as a null-terminated string in the center on the screen. In CEmu, another two 00s are added to the end.



Here is what it is supposed to look like (using tihub.org emulator, same on a physical calculator):


Is there any clue what is going on? The .8xp is hosted here: GitHub. Relevant ICE source file is BMENU.

The only thought I have is about how I'm writing to the string to be displayed. Start with assigning "123456" to Str1, which I assume would put 7 bytes starting at &Str1: {49, 50, 51, 52, 53, 54, 0}, then I copy six 0s into Str1, which should make the bytes {0, 0, 0, 0, 0, 0, 0}. The seventh byte is always 0, so the PrintString functions should see that 7th byte as null and stop printing. Should I explicitly store seven 0s?

Testing after a MEM-reset [2nd, +, 7, left, enter] on both a physical CE Python and the same calculator's rom in CEmu, I can no longer re-create the "extra 00s" issue. It may have been a weird state that the emulator was in? Not being able to reproduce the odd behavior is concerning.

EDIT:

After further testing in CEmu and on a physical calculator, I can reproduce the behavior on both. I will modify the source to explicitly write the null terminator after the last character, instead of relying on the Str1 assignment that ICE does.

EDIT TWO:

Replacing
Code:

with
Code:

and adding
Code:

after storing the latest typed character seems to have fixed the final string not being null-terminated.

It's probably overkill/redundant setting the byte after each typed character to \0, but better safe than sorry.

can someone link it in internet archive because I cannot get to GitHub for some reason