[Staff] Microhertz - TI-83/TI-83+ Scene Demo

Post by **benryves** » Mon 13 Feb, 2006 11:49 am

Download

I haven't been able to fully test the 83 version, and don't know how LCD-driver friendly the 83+ version is for people with SEs.

It's been a little side project to keep me going and as a testbed for Brass and Latenite.

Timendus · Post by **Timendus** » Mon 13 Feb, 2006 12:00 pm

You... I... This... How... WTFBBQ?!

CoBB · Post by **CoBB** » Mon 13 Feb, 2006 12:14 pm

PR at best!

Post by **tr1p1ea** » Mon 13 Feb, 2006 1:01 pm

This is truely awesome. Like is said on IRC, its 'FRIGGING' awesome!

.

Great stuff ben, the lens effect was my favourite.

KermMartian · Post by **KermMartian** » Mon 13 Feb, 2006 1:45 pm

ZOMG ROFLMONGERS!
Nicely done once again, Ben.

DJ_O · Post by **DJ_O** » Mon 13 Feb, 2006 2:13 pm

HOLY $#!T!!!! Now if only this was implemented into games, even SNES games wont have those effects

awesome work ben!

kalan_vod · Post by **kalan_vod** » Mon 13 Feb, 2006 2:57 pm

I've only seen the screen shots, and just seeing them this looks amazing! I can't wait to get home to try it out.

Jim e · Post by **Jim e** » Mon 13 Feb, 2006 3:34 pm

the lens is also my favorite. Great job!!

coelurus · Post by **coelurus** » Mon 13 Feb, 2006 4:53 pm

Fun to see some innovative stuff, lead people on the right track Ben

Post by **benryves** » Mon 13 Feb, 2006 5:09 pm

Thanks everyone

Nothing here is really ground-breaking, but I've always enjoyed this sort of programming more. If anyone dares to read the source, it shouldn't be too difficult to follow. Lots of basic trig and Bresenham goes on in there, plus some cheating with precomputed tables (which might explain the massive binary size...)

As for "hidden" keys;
Tunnel: cursor keys control movement
Flipping card: up/down control movement, left+right takes a screenshot, inverts it and uses that as the card's "texture".
Cylinder: up+down (held) inverts the text.

thegamefreak0134 · Post by **thegamefreak0134** » Mon 13 Feb, 2006 5:39 pm

Nothing here is really ground-breaking, but I've always enjoyed this sort of programming more. If anyone dares to read the source, it shouldn't be too difficult to follow. Lots of basic trig and Bresenham goes on in there, plus some cheating with precomputed tables (which might explain the massive binary size...)

....... How can you even speak of trig as basic??? (OK, so what if I'm advanced 2 years already in math, whats your point?)

Just the screenshots look awesone here. I'll go take a real look in a minute. Someday, I hope to understand how these demos are even made...

Post by **benryves** » Mon 13 Feb, 2006 5:47 pm

thegamefreak0134 wrote:....... How can you even speak of trig as basic??? (OK, so what if I'm advanced 2 years already in math, whats your point?)

Basic, as in nothing more complex than:

Code: Select all

x = centre_x + circle_radius * sin(angle)
y = centre_y + circle_radius * cos(angle)

Though, in this demo, that's only used once - for other wiggly text stuff, I just use a straight sine table.

Timendus · Post by **Timendus** » Mon 13 Feb, 2006 6:01 pm

Yeah, it's huge, but very cool none the less

The lens is my favourite too. How exactely does that work..?

(I know, I could take a look in the source, but I'm a lazy slacker

)

Jim e · Post by **Jim e** » Mon 13 Feb, 2006 6:19 pm

; Leave the LCD driver in a happy state!

You're so considerate of the lcd. Most people wouldn't think twice about leaving it happy, most people just order her around.

Now would I be correct in assuming that the lens effect is a BIG table, or is there some serious math coding. It's weird, I chose not to look at screenies, and try it out on actual hardware, and all that ran my mind was trying figure how you were doing things.

Excellent job yet again.

Post by **benryves** » Mon 13 Feb, 2006 6:20 pm

Timendus wrote:Yeah, it's huge, but very cool none the less
The lens is my favourite too. How exactely does that work..?

Very simply, and can easily be altered to change the effect. Each pixel of the area the lens is over is put through a transformation table. Like the tunnel, this is precomputed. The lens is 32x32 pixels, so the transformation table is 32x32 elements. Each element has an X and a Y, so the most basic transformation table would be:

Code: Select all

.for y, 0, 31
    .for x, 0, 31
        .db x, y
    .loop
.loop

This is a "neutral" table, as each pixel coordinate gets transformed back into the same coordinate.

Code: Select all

.for y, 0, 31
    .for x, 0, 31
        .db x/2, y/2
    .loop
.loop

This one would "zoom" the area under the lens by two - for example, the point (16,16) of the lens would map to position ( 8,8 ) of the old area under the lens.

Code: Select all

.for y, 0, 31
    .for x, 0, 31
        .db 31-x, y
    .loop
.loop

This would flip the image in the y-axis under the lens.

A sort of pseudo-code would be:

Code: Select all

transform[32][32] ; transformation table

lens_x = 10 ; \_ position of lens
lens_y = 10 ; /


old_area[32][32]; old area under the lens

; Copy the area under the lens to a temporary buffer
for x = 0 to 31
    for y = 0 to 31
        old_area[x][y] = get_pixel(lens_x+x, lens_y+y)
    next y
next x

; Redraw the lens, applying the transformation:
for x = 0 to 31
    for y = 0 to 31
        set_pixel(lens_x+x, lens_y+y) = old_area[transform[x][y].x][transform[x][y].y]
    next y
next x

To get the correct lens transformation table, I cheated - making a 32x32 bitmap where each pixel was a different colour, blowing it up to 3200x3200, running two "spherize" transformations in Photoshop, then dropping back to 32x32. I could then work out where each of my individually-coloured pixels had gone to, and built the table out of that.

EDIT: Reading this back, the explanation sucks. Er...