Jemplode animation editor wish

I just had an idea for doing an actual animation. When I went to implement it in the animation editor, I discovered that it's missing a key feature...

Copy and paste among frames and to/from other applications.

I certainly wouldn't expect to hand-draw every single frame. Without copy and paste features, I wouldn't even begin to know how to get a really nice animation done.

I'm not asking for the complex task of region-selecting and copying/pasting selected regions. I mean, just being able to copy a whole frame to the clipboard, paste it into Paint Shop Pro, work on it there, and paste the edited frame back into the animation editor.

holy crap... that just gave me a cool idea... which would require cut/paste to work. It involves a gameboy camera... you figure out the rest...

(i don't know why i'm posting this here... it's random, but here's a short some friends and i did with a gameboy cam (or 6). It's a 750k or so gif anim, be warned. Let it load all the way then watch it again at the speed it's supposed to be at)

Too funny!

My copy of IE slowed down the frame rate significantly towards the end of the playback, despite the fact that the whole thing had long since downloaded. Must be a bug.

yeah, you know... i just noticed that too. That's really weird. I've looked at that thing hundreds of times and it's never slowed down at the end like that. Weird.

so yeah... i'm gonna have video start up animations! hehehe....

OOoo..! like a turntable of my car or something... too cool

And before somebody asks: Each frame of an animation takes 1KB of space, but frames can be reused within the same animation at no extra cost (well, 4 extra bytes per frame). There's currently about 130KB available. The Hijack kernel will probably continue to grow over time, chewing up more and more of that space. The animation rate is currently fixed at 12 frames/second.

Cheers

Is there anything in the current system to prevent the custom animation from being too large?

A system where each frame indicates where on the display the new frame section goes, and how big it is, would reduce unneeded information.. All of the actual animation in the default animation occurs on the right section, so the "Empeg" portion doesn't need to be stored after the first frame.. More complex animations wouldn't be able to use this to the same degree.. Just a thought..

so the "Empeg" portion doesn't need to be stored after the first frame..

I think you're referring to deltas: A given frame only stores the modified pixels of the prior frame.

While I agree that deltas are a much more efficient way to store an animation, this is not supported in the PLAYER SOFTWARE, it only plays back full frames. So the editor must also work this way, too.

They wanted to do deltas, but didn't get around to it.

Nothing I know of in JEmplode, but.. now that you mention it..

Hijack limits the animation to 63 frames max. Anything larger is ignored.

Cheers

We can easily do deltas if we want to. This is completely kernel-space, no player software is involved.

cheers

How does the data get to the player? Does Hijack copy the animation from flash into RAM and then directs the player to the animation? What prevents Hijack from recreating the "real" animation from the deltas when it does this?

>What prevents Hijack from recreating the "real" animation
>from the deltas when it does this?

"Show me the code" -L.Torvalds

-ml

>How does the data get to the player?

It is directly addressible, in place, in flash eeprom.

>Does Hijack copy the animation from flash into RAM
>and then directs the player to the animation?

The "player" in this case is a simple for-loop inside the kernel, which copies an animation frame directly to the display memory.

-ml

Someone is going to ask this sooner or later, so it might as well be me.

If we can create an animation, and park it as a file on the hard drive (I realize boot animations are stored in flash) could the next step be to create a userland hijack app to play them.

If that was done, could it be called from the hijack display blanker stuff to act as a screen saver?

PeterK

jEmplode limits you to 60k of data right now -- Totally arbitrary limit, but I wanted to make sure you didn't write over your kernel.

Mike

I need to look into this one ... Copy and paste inside of Java is notoriously a piece of crap. Worst case = I let you load and save individual frames as PNG.

Mike

I'll let you write this one The UI for this would be a HUGE pain.

Mike

Extra Extra! Time Magazine Nominates Empeg BootUp Animations and the Animation Editor the Largest Request-For-Enhancement Can-of-Worms Ever for 2002! Makes Coders Regret Programming It!

If everyone is talking deltas = just storing frame diffs, that may not be too hard (we would both just have to agree on the file format). Maybe I misunderstood the original request -- I thought he was talking about sprites (like how GIF animations support specifying that certain blocks of a frame are just copyRect'd to another location). That would suck :\

The delta method is better IMO.. I wouldn't mind working on it, but Java ain't my bag..

I will assume you mean that the player code is not open to hacking..

You previous answer about the player reading from the datastructure in flash answers this question.

Edit: I assumed wrong..

Ok.. so the simple for-loop in the kernel, could (Disclaimer: Hypothetical suggestion, no expectation of actual code to be written by anyone..) interpret the frames as stored in flash and update the display buffer as needed.. Thus, be able to handle delta frames if someone so desired..

I think I'll take you up on your challenge of showing you the code.. Of corse, I could use some pointers as to how to use the toolchain.. The docs included stop just short of providing any real information about how to use it.. I generated a cpp exec that outputted code, how helpful... :|

Edit: NM.. I figured it out.. My last run at getting the toolchain on my system ended in frustration, even after rolling my own.. and getting everything installed correctly.. now I go off to read the code and see how things work.. ta-ta..

You've at least got read/write PNG now... Each OS is going to have it's peculiarities for copy/paste images from the clipboard. For windows I'm going to need Java code that can produce a a DIB from a java.awt.Image to be able to put it into the clipboard ... I either have to write it or find it somewhere ...

Mike