Roto-zoom animation

[Asmusr]

Sometimes' Piet Mondrian pictures gave me an idea for an animation that would work in the TI's odd color modes. The animation is a simple roto-zoomer programmed in Java, resulting in 360 256x192 images.

I originally planned to run the animation through a project I have been working on for a while: a 'video encoder' that takes a series of images and calculates how to get from one image to the next with the fewest possible changes. The encoder is also programmed in Java, but the result can be played back on the TI given enough storage space. Unfortunately I could not get the desired result from the encoder because it's based on "half-bitmap" mode, which is more flexible than graphics I mode, but makes double buffering difficult. If you want to see how far I got with this, open "rotozoom-encoder-8.bin". This example uses around 1100 bytes for each of the 360 frames, which fits nicely into a 512K cart. As you can see it has a lot of noise, resulting from the lack of double buffering.

I then switched to Graphics I mode, and instead of using the encoder I imported each image using the map import code from Magellan (which was improved in the process :-). This method resulted in more bytes per frame, so I could only fit half of the frames (180 frames) into a 512K cart, but on the positive side Graphics I mode can easily be double buffered. The result is quite pleasing to look at as you can see from "rotozoom8.bin" and "rotozoom8.rpk".

Note that these carts do not require 32K as the code is running primarily from scratchpad.

rotozoom-encoder-8.bin

rotozoom8.bin

rotozoom.rpk

[sometimes99er]

He he. Very nice.

[+arcadeshopper]

so good

[+Ksarul]

I like this!

[Asmusr]

Made a YouTube video, just adding it here:

 

[whoami999ster]

On 2/17/2017 at 5:46 PM, Asmusr said:

Sometimes' Piet Mondrian pictures gave me an idea for an animation that would work in the TI's odd color modes. The animation is a simple roto-zoomer programmed in Java, resulting in 360 256x192 images.

 

 

 

 

 

 

 

 

 

I originally planned to run the animation through a project I have been working on for a while: a 'video encoder' that takes a series of images and calculates how to get from one image to the next with the fewest possible changes. The encoder is also programmed in Java, but the result can be played back on the TI given enough storage space. Unfortunately I could not get the desired result from the encoder because it's based on "half-bitmap" mode, which is more flexible than graphics I mode, but makes double buffering difficult. If you want to see how far I got with this, open "rotozoom-encoder-8.bin". This example uses around 1100 bytes for each of the 360 frames, which fits nicely into a 512K cart. As you can see it has a lot of noise, resulting from the lack of double buffering.

 

 

 

 

 

I then switched to Graphics I mode, and instead of using the encoder I imported each image using the map import code from Magellan (which was improved in the process :-). This method resulted in more bytes per frame, so I could only fit half of the frames (180 frames) into a 512K cart, but on the positive side Graphics I mode can easily be double buffered. The result is quite pleasing to look at as you can see from "rotozoom8.bin" and "rotozoom8.rpk".

 

 

 

 

 

Note that these carts do not require 32K as the code is running primarily from scratchpad.

 

 

 

 

 

rotozoom-encoder-8.bin 512 kB · 22 downloads

 

rotozoom8.bin 512 kB · 24 downloads

rotozoom.rpk 106.1 kB · 9 downloads

What is meant for double buffering ? 

 

[Asmusr]

4 hours ago, whoami999ster said:

What is meant for double buffering ? 

It means you have two screen buffers: one that's displayed and another where the next frame is being drawn. When the frame is ready you show that buffer instead and start drawing the next frame in the buffer that was displayed before, and so on. If you sync the buffer flipping with the VPD's vertical refresh you can get flicker free animations. The 9918A is good at double buffering because you can choose where in VRAM the different tables are stored. Double buffering is most important at high speed and when you change multiple tables at the same time, e.g. patterns and name table.

[whoami999ster]

... but in which memory area did you stored all the 180 frames.

just to simplify ... then you load the first two frames in the buffers and then load/dispaly the name table with the content of the first buffer and then load the second one in the and in the mean time you get a new frame from the "frames staging area" and so on all this into an infinite loop ?

something like that? or I'm very far from... 

[senior_falcon]

The usual wizardry from Rasmus! Very nice!!

[+Lee Stewart]

4 hours ago, whoami999ster said:

... but in which memory area did you stored all the 180 frames.

 

He used a 512 KiB cartridge as he described here:

 

On 2/17/2017 at 11:46 AM, Asmusr said:

This example uses around 1100 bytes for each of the 360 frames, which fits nicely into a 512K cart.

 

ROM cartridges, such as the 512 KiB cartridge @Asmusr used, employ bank-switching in the >6000 – >7FFF memory space of the CPU.

 

...lee

[whoami999ster]

that's exactly this 512K that make me confused (with all the rest LOL) .... to much wizardry here  ... KiB stand for Kbits ? 

I know that my explanation is at kid-garden level ... but help me and I will grow up quickly ... I'm reading tons of document/books and i need time to metabolize but with practical example everything is boosted... 

 

@Asmusr : no way to have an example of one frame from the demo? 

 

Thanks for your patience and your time

Sincerely 

Francesco 

[Asmusr]

1 hour ago, whoami999ster said:

@Asmusr : no way to have an example of one frame from the demo? 

The frames are all there in the cartridge bin. The first frame starts at offset 300 hex. It consists of:

 

Color table: 32 bytes

Total number of patterns in frame: 1 byte

Number of patterns for run 1: 1 byte

Start pattern index for run 1: 1 byte

Patterns for run 1: number of patterns * 8 bytes

...

Number of patterns for run n: 1 byte

Start pattern index for run n: 1 byte

Patterns for run n: number of patterns * 8 bytes

Name table: 768 bytes

End marker: 1 byte. 255 if last frame in ROM bank, 0 if next frame is in the same ROM bank.

 

The next ROM banks starts at address 2000 hex, 4000 hex, and so on and the first frame in a bank is always at offset 300 hex.

[+mizapf]

2 hours ago, whoami999ster said:

KiB stand for Kbits ?

i = binary powers

KiB = Kilo(binary)byte = what we used to call KB earlier; 1 KiB = 1024 byte

MiB = Mega(binary)byte = 1024 KiB

1 KB is now 1000 byte (which would be the ideal case, but it is clear that not everyone will follow that recommendation)

 

https://en.wikipedia.org/wiki/Binary_prefix

[+Lee Stewart]

2 hours ago, whoami999ster said:

KiB stand for Kbits ?

 

“KiB” is the International Electrotechnical Commission (IEC) abbreviation for “KibiByte”—short for “Kilo Binary Byte”. The “Ki” part stands for 2¹⁰, which is what we all use(d) for a binary “kilo” in “kB” or “KB” for “kilobyte”. This definition was necessary to avoid confusion with the International System of Units definition of “kilo” (abbreviated ‘k’) as 10³.

 

‘B’ always stands for “byte” and ‘b’ for “bit”—so, 512 KiB is 512 x 2¹⁰ = 512 x 1024 = 524288 bytes.

 

...lee

[GDMike]

7 hours ago, Lee Stewart said:

B’ always stands for “byte” and ‘b’ for “bit”—so, 512 KiB is 512 x 2¹⁰ = 512 x 1024 = 524288 bytes.

Ahh. I was waiting to see the bit representation...so I just multiply by 8

 

Edited November 25, 2020 by GDMike