I actually made the first version if this program a long time ago, before I became active in the community. I remade it a few nights ago and uploaded it to TICalc, but it basically works like this:

-Give it a list of coordinates and types
-It generates a hex opcode that draws the rectangles with the given coordinates and methods.

It takes input in the form of {x,y,width,height,type} and you can give it multiple rectangles. It does 6 rectangle types, including the typical black/white/invert, using OS bcalls. This is also a BASIC program that generates the opcodes. As well, it tries to optimise the opcode a little, so if there are 8 or more rectangles, it uses a different method of drawing them (generating an array of coordinates/types and reading them, using 29 bytes extra overhead, 4 bytes less for each rectangle).

Anyways, it was useful for me when I was working on BASIC RPGs to make an assembly program that drew a map. The download is below. With so many other tools available now, this type of program is a bit outdated

To make sure, you are using x*2^(-1/12), right? I tested that against my code and it gives exactly int(x*2^(-1/12)) for all but the two values mentioned...

Hehe, thanks I was also thinking of a version that uses a lot more RAM (6144 more bytes) to assign each pixel a velocity for each of 8 directions. Then the particles would move based on the velocity of the air currents. It would be very slow on these calculators since I won't be able to do easy bit tricks, though :[ However this would make it easier for tools such as placing bombs, fans, and other effects. Just place the objects, and the physics do the rest. Maybe on a faster calculator I could do it.

When I was working on the Grammer particle engine, I had an idea that I put to the side. I finally got around to testing it, and it was a bit of a success, so I will share it, even though it isn't a project.

If you have seen the Grammer particle engine, it is fast, but it gets slower as you add more particles. Eventually, after 2048 particles, it still gets almost 6FPS, but hope was that this alternative method would have speed independent of the number of particles on screen.

The trick? Instead of adding particles by pushing them on to a stack-like array of coordinates, I would use something like a graph buffer. In grayscale, we have a front buffer and back buffer. For this, we have a "fixed buffer" and a "particle buffer." When updating the LCD, these two get ORed together to show the particles superimposed on the fixed buffer.

Disadvantage:
You have to scan every pixel on the particle buffer to locate particles and move them accordingly.
Advantage:
-The particle buffer is a fixed 768 bytes and can hold up to 6144 particles (compared to 12288 bytes).
-Updating particles takes about teh same time no matter how many particles there are.
-Adding particles can be done with simple drawing commands since it is just a graphics buffer in disguise.
-Deleting particles is done with the same ease. Deleting individual particles with the other method is very slow, having to search through the buffer to locate the particle with the given coordinates.
-Performing large scale operations on a group of particles is very easy


My goal was to implement a simple rule to move down if possible, or move left/right. This is a standard rule. However, scanning each pixel individually would have been very slow. Instead, I scanned one row of pixels at a time, applying some bit logic to see which pixels can move in a given direction. This turns out to be really effective:

In fact, using a circle as the pen tool and updating the LCD cause the biggest speed bottlenecks. The number of particles on screen does not affect the speed at all since every pixel in the particle buffer is treated as a particle and has all of the transformations performed on it.

I decided to keep the pen tool as it is, but interleaving the particle updating with LCD updating gains some FPS.

Readme:
Run it with the Asm( token.
Use [ON] to exit.
Use arrows to move the cursor.
Use [2nd] to draw on the fixed buffer (makes impassable barriers).
Use [Mode] to draw particles.
Use [Del] to delete from the fixed buffer (deletes barriers).
Use [Y=]+[Up] to increase the radius of the circle.
Use [Y=]+[Down] to decrease the radius of the circle.
Multiple key presses are supported.
The F2-F5 keys shadow [up],[right],[left],[down]
15MHz is automatically set if it is supported by your calculator.
6MHz should still expect ~22FPS according to WabbitEmu.

EDIT: This is still buggy, see the next post for a working version, that also rounds.
oh, oops, I forgot to include "sub c" before the "neg", sorry:
Asm(444DAF57290929092929092929092917298A2917298A2917298A291791ED446F62)
At the end, before the ED44, there is now a 91. The asm code is:
ld b,h
ld c,l
xor a
ld d,a
add hl,hl ;2
add hl,bc ;3
add hl,hl ;6
add hl,bc ;7
add hl,hl ;14
add hl,hl ;28
add hl,hl ;56
add hl,bc ;57
add hl,hl ;114
add hl,hl ;228
add hl,bc ;229
add hl,hl \ rla ;458
add hl,bc \ adc a,d ;459
add hl,hl \ rla ;918
add hl,bc \ adc a,d ;919
add hl,hl \ rla ;1838
add hl,bc \ adc a,d ;1839
add hl,hl \ rla ;3678
sub c
neg
ld l,a
ld h,d
It rounds down, but because of rounding troubles, this is off on two values:
0 returns 255 (-1) instead of 0
196 returns 185, when it should round down to 184 (actual value is like 184.999365...)

196 isn't too much of a problem, but 0 is, so if that is an allowed value, you can fix it with an If statement, or for only four bytes:
Asm(7DB72821444DAF57290929092929092929092917298A2917298A2917298A291791ED446F62)


I know in IRC you asked about dividing an 8-bit number by the 12th root of 2. I have to rush to work in 9 minutes, so I didn't have time to test or convert to hex, but I think this might work:
ld b,h
ld c,l
xor a
ld d,a
add hl,hl ;2
add hl,bc ;3
add hl,hl ;6
add hl,bc ;7
add hl,hl ;14
add hl,hl ;28
add hl,hl ;56
add hl,bc ;57
add hl,hl ;114
add hl,hl ;228
add hl,bc ;229
add hl,hl \ rla ;458
add hl,bc \ adc a,d ;459
add hl,hl \ rla ;918
add hl,bc \ adc a,d ;919
add hl,hl \ rla ;1838
add hl,bc \ adc a,d ;1839
add hl,hl \ rla ;3678
neg
ld l,a
ld h,d
It assumes HL is the input and HL<256 (and also positive).

EDIT: Hopefully no typos or anything missed:
Asm(444DAF57290929092929092929092917098A2917098A2917098A2917ED446F62)258 t-states, you can also make it round for a few extra t-states...
EDIT2: 2 days later, I found the typos in the hex code, sorry.

It is better to ask outside of the intro forum, though. Somebody would have probably suggested that you make another topic to ask I hope the answer resolved your problem, though!

Wow, the progress here looks excellent since the last time I checked this out!