This does look awesome Matref! Damn shame it isn't a bit faster though.

I swear I tried to make it fast though I don't think there's much to be done about it in Axe.

That really does look cool! Is there a source? If I ever get free time, I might want to look into optimizing it with assembly or something.

I'm sure you can make it at least twice faster with ASM, because if I had to make the drawing code in C it would be (direct translation from Axe) :for(y = 0; y < 64; y++)
  for(x = 0; x < 96; x++)
    plotSScreen[y * 96 + x] = texture[ (ylut[y * 96 + x] & 7) * 8 + xlut[y * 96 + x] ];

Lemme get on my PC and I'll attach the source.

I actually thought of doing that a couple times with nRayC.

Apparently it is null-terminated, since he says he tested and it worked. I never tried without filling Str1 with zeros, so I can only say that my method works.

There is, if you want to have input multiple times during the program. In this case, if you input ABCDEF and then ACDE, Str1 will contain ACDEEF if you don't fill it with zeros before each input.

Woah that looks great! :O Also, screenshot 2 gave me some ideas since the tiles were from supersonic ball, but of course I would need to learn how to do mode 7 (and have it run fast) on the HP Prime.

Oh I didn't notice that

Of course it's useless its only point is to look good x) and be as fast as possible (actually, not very fast).

Hey guys,

Graphically impressive (read : useless) programs had always been my thing, so when I figured out that I could do some intense LUT-based demoscenes-like programs (my first one was actually nSpeedX3D, it uses the same concept), I took the only programmable machine that was near me : my TI-83+. Could have been my PC, but I was at school.

So, in a mere 3 hours I wrote a small LUT generator that takes X, Y as input (the center of the screen being 0,0) and gives U, V as output. Basically, X and Y are screen coordinates, and U and V are texture coordinates, so I use those to draw things on the screen with a bit-per-bit basis - very slow in Axe, but w/e, it was meant only to look good, not to be fast. Actually, you can argue a bit about it looking good, but I couldn't really do any better with Axe's precision and the z80 calcs' LCD.

So yeah, basically, to perform a plane deformation, you don't need many things :

• A texture (I use a 8*8 one),
• Two 6144-bytes LUTs (yup, that's a lot), one byte for the X of each pixel, one byte for the Y,
• Two equations, one that gives U, one that gives V.

So first, you want to make sure everything works. So you just do U = X and V = Y. It gives this.



(Note how the LUT generation takes ages. We actually generate 12288 coordinates.)
Now that you're certain it works, you can start doing actually funny and interesting things

r = sqrt(x² + y²)
a = tan^-1(x,y)

u = x * 8 // abs(y)
v = 512 / abs(y)


u = x * cos(r * 2) - (y * sin(r * 2)) // 256
v = y * cos(r * 2) + (x * sin(r * 2)) // 256


u = 1.0 /* (r * 256 + 0.5 + (sin(a * 5) // 2))
v = a * 3 * 256 /* 3.142


u = r * cos(a + r) // 320
v = r * sin(a + r) // 320


u = a
v = 1.0 /* r


Also, the whole program includes those 5 scenes and is only 1354 bytes. So it can be done very lightly.

To use it, just put a number between 0 and 5 inclusive in Ans before running Asm(prgmPLDEFORM). You need at least 13800 bytes of free RAM though. No test is done to see if Ans is out of bounds, but that shouldn't do anything else than displaying random garbage. Binaries attached, source will come later (when cleaned).

I'm going to make everything more ergonomic and release it as a pure eye-candy program I guess (among with some additional equations).

Hum actually you're right. Here's the first routine : Asm(7D291F6F) ; and the second one : Asm(7CCB1CCB1D1F67).