Hot off the presses ... jEmplode 22! http://www.jempeg.org

My first draft at an animation editor is in there ... I don't know how to actually put it on the player yet (MarK? Empeg guys?), but it reads and writes the animation binary format (if you turn empeg/rio.h into binary files, it will read them in and you can play with the penguin).

Mike

This is looking kick ass man. Not sure i understand the workflow... but it's gonna be cool i can tell. =] Thanks again for all your work man. Jemplode is giving the Cambridge boys a lot to live up to.

I was afraid the flow would be confusing... Frame reuse makes the UI confusing. Here's the overview:

The left side is managing unique frames, the right side is managing the sequencing of those frames.

So the slider on the left lets you slide among unique frames. If you want to add a new unique frame, hit the left button next to the slider. This will add a new blank frame. If you want to copy the current frame (i.e. you want to just change it slightly) hit the second from the left button and it will duplicate the frame and let you edit it. If you want to just keep your unique frames organized, you can use the left and right arrows on the left side to reorder frames.

So now you have unique frames made, but you have to add frames to the sequence list to actually create an animation (the left side is basically your pool of frames to choose from). Basically, drag the slider on the left to select the frame you want to add to the sequence, then hit the left button in the sequence view (the right-hand view) to add the frame to the sequence. You'll see the frame appear in the list box. Adding a frame to a sequence multiple times only adds a reference, so you won't take a big hit on memory (look at the Empeg penguin for an example of frame reuse). You can use the Up/Down arrows on the sequence view to move individual frame references up and down in the animation. Essentially the sequence list box is the play-order of the animation from top-down. In fact, if you hit play, you'll see the selection box scroll through the sequence that you setup.

That's basically it ... Other random stuff -- The trash can on the left deletes the current frame, the trash can on the right deletes the current sequence entry. If you click on a sequence entry, it will jump to the frame number. The numbers next to the sequence frame tell you the sequence number and the frame number it's pointing to. You can play, pause, and step-forward/step-back in the sequence view.

Let me know if it's still weird. Unfortunately, the reusable frames thing makes for a somewhat counterintuitive UI, but once you get the hang of it, it's not too bad, and you can actually do some kind of neat stuff with it. I personally think it's cool to play the Empeg penguin and see the slider jumping around --- you can really see how they reuse frames with that. I know, I'm a loser, but it's cool

... and by the way, I think I spend more time playing catchup with the Empeg guys than they do with me. They get huge props on Emplode -- I have to work my butt off every time they do a new release to add their new features in.

Frame reuse makes the UI confusing.

I don't think so. I understood the frame reuse thing immediately in your UI. Watching the penguin animation play back it makes it very obvious what's going on.

This is very impressive, I can't wait until these can be flashed into the player. Too fun!

I have an idea in that area, by the way. Okay, the location of the animation in flash memory is going to be variable depending on the version of the kernel, right?

So what if Mark gave us an FTP hook in /proc, just like the current hooks for empeg_bootlogos and empeg_kernel, called "empeg_bootanimations". Since his kernel can calculate the address of the animations, he can just provide that hook.

The only limitation is that it would have to limit the size of any uploads into that address space: If you create an animation, it has to be smaller than the factory animation or you'll overwrite other stuff in the kernel memory.

True, it would preclude doing it over serial, and preclude doing it on a Mark1 player, but it would be a quick solution to the problem of sending animations to the player.

How large are the animations that people have produced thus far? (expressed as the actual observed file size, in bytes, please).

Thanks

I don't think anyone's produced any new animations yet, Mark.

Well, then kind of a moot point, isn't it.

Cheers