Animation (animated GIF)

[GoogleCodeExporter]

I'm thinking of a way to make GrafX2 powerfully edit multi-frame images, 
without hurting the usability with normal images.

The program would still have 2 images (Principal & Spare) loaded at same 
time, TAB still switching between them. but now an image would comprise of 
1 or more frames.
All frames of an image share the same palette and dimensions. At any given 
moment, only one frame is displayed (ie: #05)
Some keyboard shortcuts help quickly navigate to previous and next.

An extra screen allows showing and editing the "strip" of images (clone, 
del, displace ), setting each image speed, previewing the animation.

Difficulties:
Need to adapt Undo. Especially because an operation like Resize affects 
the pixel data of all frames.

Bonus:
Even for normal pixelling, a multi-frame Spare page can help memorize an 
important stencil and restore it later.

Original issue reported on code.google.com by yrizoud on 10 Oct 2008 at 1:59

[GoogleCodeExporter]

I'm all for multi-frame images, thats a good idea and could be used for a small 
layer system, too (with "magic pink" transparency, for example, eventually 
using a 
color code that is linked to a color of the menu)

However, gif can have a different palette for each frame. This may not be a 
problem 
because we can swap palettes when swapping frame, BUT there is also a 
transparency 
system (also "magic pink") allowing to display 255 colors in one frame, and 255 
others in the next one, and so on, giving full truecolor images when putting 
the 
framerate to maximum.
This kind of things will be hard to handle, but we can provide some multiframe 
and 
palette cycling :)

Original comment by pulkoma...@gmail.com on 10 Oct 2008 at 2:41

[GoogleCodeExporter]

I think animation could take cues from DeluxePaint. Shortcuts and so on.

Original comment by gro...@gmail.com on 14 Oct 2008 at 8:05

[GoogleCodeExporter]

I just tried Deluxe Paint (IV) on an emulator, to refresh my memories, and I 
still 
don't "get" the animation features (besides the frame navigation: next, 
prev,play..). If somebody knows them well and is able to give details, I'd be 
glad 
to hear about it.

Original comment by yrizoud on 16 Oct 2008 at 12:29

[GoogleCodeExporter]

Implementation note :
Also look at the layers in issue #7 , i think it will be good to look at them 
both 
in the same time as they require refactoring the same part of the code (S_Pages 
handling).

Original comment by pulkoma...@gmail.com on 24 Dec 2008 at 4:18

• Added labels: Level-Hard

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 14 Jan 2009 at 4:44

• Added labels: OpSys-All

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 9 Feb 2009 at 11:21

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 26 May 2009 at 7:50

• Added labels: Component-Pages, Milestone-2.1

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

as far people here can improve Grafx2 with animation (in a DeluxePaint style 
would be
great! :) ), please consider adding support to picture sequences, just like 
CinePaint
does - this would help interoperating Grafx2 with ffmpeg and imagemagick 
awesomelly!
- maybe would be a good idea Grafx2 calling Gifsicle commands externally for
converting them to animations and back to picture sequences?

Original comment by nitrofur...@gmail.com on 27 Jan 2010 at 5:17

[GoogleCodeExporter]

I believe that one important thing would be to allow alternative exporting as a
sprite sheet, not only gif. Different formats for different needs. :)

Original comment by qubodup on 31 Jan 2010 at 4:03

[GoogleCodeExporter]

this sprite sheet may need a preview window for letting us know, not only if 
the 
alignment we want is correct, as well if we would be working on really huge 
pictures 
(just imagine large images plenty of frames, and getting picture results far 
larger 
than 4096x4096 pixels, for example)

Original comment by nitrofur...@gmail.com on 31 Jan 2010 at 9:31

[GoogleCodeExporter]

Hi,
I came to this thread when searching for color/palette cycling, that PulkoMandy 
cited in the first comment. I think by now everybody knows about this 
technique's revival in an HTML5 experiment, but i'll cite it here anyway for 
the uninformed:

http://www.effectgames.com/effect/article.psp.html/joe/Old_School_Color_Cycling_
with_HTML5

So, I came to know about Grafx2 that can load and save IFF/LBM files and I'm 
using it. I don't want to use those old, legacy, unmaintained software just to 
do color cycling. I think implementing color cycling should be top priority now 
because I don't think any software nowadays have it. You can use GIMP or any 
other image editor to do animated GIF, but for color cycling you would need to 
digg deep into the legacy software underland.

I vote for color cycling based animation before anything else.

Anyone agrees?

Original comment by jntesteves on 29 Jul 2010 at 11:27

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 1:34

• Added labels: Milestone-2.4

[GoogleCodeExporter]

I like grafx2, but it's really need animation feature more than any other.

Original comment by Retr...@Yandex.ru on 9 Mar 2011 at 10:49

[GoogleCodeExporter]

Couldn't layers double as animation-frames, so that a sequence could be saved 
as an animgif? (Should be easy enough to implement some playfeature by just 
hiding/showing layers)

Original comment by annas...@hotmail.com on 11 Jul 2011 at 5:08

[GoogleCodeExporter]

It would limit the animation to 32 images (or 64, if the bitfields are upgraded 
to 64bit integers), so it's an idea that I abandoned early.

Original comment by yrizoud on 11 Jul 2011 at 5:31

[GoogleCodeExporter]

32-64 is plenty and enough for most (basic) things...if you're in the business 
of making +100 frame "movies" you'll probably go for a dedicated 
animation-program anyways.

Original comment by annas...@hotmail.com on 11 Jul 2011 at 6:22

[GoogleCodeExporter]

I prefer using your spritesheet script (maybe an improved and more integrated 
version of it) to playing with layers.

The problem is it adds yet another "dimension" to pictures. So far we have xy 
(the pixels), z (the layers), p (the colorpalette) and u (the undo steps). So 
our images are 5-dimension objects. Animation (t) adds a 6th dimension and 
things get really crazy. Using any other of the dimensions is possible, and has 
even been done, it's called colorcycling (using p), or spriteseet (using x and 
y). Using u is already planned in the autosave/working steps issue smewhere 
else. z was the only one left :)

Anyway, I think it's cleaner to actually add the animation feature, but I just 
wanted to work a bit more on the "oldies mode" stuff first. I'll start playing 
with the animation bar mockups :)

Original comment by pulkoma...@gmail.com on 11 Jul 2011 at 8:17

[GoogleCodeExporter]

What made my head spin was the problem of making the program work as well in 
anim and layer modes, switching at runtime depending on image (Imagine a 
layered image in Main and an animation in Spare...).
But maybe we can make it standalone separate program... when compiling grafx2 
without layer support, we already get something extremely close to the target, 
as it keeps multi-image support but the display is one image at a time, and the 
code is even simpler than current state. I'm starting a little spinoff of v2.3 
that loses layer support but gains animation instead (full frames only). This 
would be a standalone program; even skin files will not be compatible as I need 
new buttons. It will be impossible to reconcile both functionalities into a 
single program later, but it sounds like little effort for a working animation 
program, too good to pass up :)

Original comment by yrizoud on 11 Jul 2011 at 11:13

[GoogleCodeExporter]

I don't get why having animations and layers at the same time would be a 
problem.

I really want to have layers and animations at the same time. The simple case 
that comes to mind is an animated sprite on a static background. But more 
advanced things could be done too.

I think using both is not too much of a problem ; what worries me more is the 
backup system. I'm wondering if a separate backup-list for each frame of the 
animation would make sense. This would make animation almost as simple as 
switching to spare and back, but with more pictures.

Anyway, please don't make a fork. It is going to lead to two times the work in 
the end. Even branches we intended to merge ended up needing a lot of energy. 
It should be possible to make it work in trunk, with an ANIM buildtime option. 
For now ANIM will imply NOLAYERS, but later it can be changed. As for the skin, 
just add your buttons. Like the layerbar, they will not always get used, but 
this isn't really a problem.

Original comment by pulkoma...@gmail.com on 12 Jul 2011 at 7:56

[GoogleCodeExporter]

Pulkomandy, I really wanted a rich layer+anim system too, but we're setting 
unreasonable goals... I had more screen mockups for multi-layer animation, but 
when I see the complex GUI controls I need to write, it's extremely 
demotivating.
On the other hand, my 2.5-hour little prototype has already support for 
999-frame images and storing durations internally (with undoable changes) I 
only need to load/save them in GIF, adapt the toolbar, preview anim, and *poof* 
: Grafx2 2.3 "animation edition". At least something to watch and use and get 
fresh ideas and renewed motivation. And something to give to the 3 people who 
gave suggestions for simple animation in the past month: Asterix (on 
pixeljoint), LorD (on amigaimpact), DawnBringer.

I still keep an eye on how to make the source common anyway (common skin 
format, macros with different implementations etc.) but I don't want this 
concern to stall me.

Original comment by yrizoud on 12 Jul 2011 at 11:15

[GoogleCodeExporter]

If you need widgets, I can have a look at it.

I'm still planning that event-driven GUI rewrite, so just send me your mockups 
and I'll start to play with them.

Original comment by pulkoma...@gmail.com on 13 Jul 2011 at 6:21

[GoogleCodeExporter]

Here's a working prototype.
Hold the buttons >> or << with right mouse button to move to next image at the 
right speed (=preview animation)
Don't mix this with normal grafx2... Skin files are incompatible, and config 
files are not backward compatible.
Limitations:
- GIF files that use 'do not dispose' compression trick don't load well.
- Help isn't complete
- Auto-save causes noticeable freeze every minute, while editing huge 
animations (Like a 555-image animation by stickman)
- Only one skin converted
- Not fully tested. /!\ Use with caution /!\

Original comment by yrizoud on 22 Jul 2011 at 6:52

Attachments:

• grafx2anim-a1-win32.zip

[GoogleCodeExporter]

Cool, nice start. But there seem to be some issues with (gif's) 
clipping/delta-compression, whatever. As you often get areas filled with a 
solid color and other quirks (on some frames) when loading an anim.

Original comment by annas...@hotmail.com on 23 Jul 2011 at 5:21

[GoogleCodeExporter]

That's the "do not dispose" mentionned above. Basically each frame in a gif can 
be painted on top of the previous ones, and we don't handle that properly yet :)

Original comment by pulkoma...@gmail.com on 23 Jul 2011 at 3:25

[GoogleCodeExporter]

Second alpha.
- Now loads GIF images that use disposal method "do not dispose" for extra anim 
compression (ex: http://www.pixeljoint.com/pixelart/63454.htm)
- Now loads GIF images that use smaller image descriptors for extra anim 
compression (ex: Stickman's 555-image animation 
http://www.pixeljoint.com/pixelart/56897.htm)
- Images now use animate speed of Firefox (It's arbitrary, but better than 
lockup when all images have duration 0, and makes Jinn's animated alien visibly 
blink: http://www.pixeljoint.com/pixelart/63865.htm )

Original comment by yrizoud on 28 Jul 2011 at 12:19

Attachments:

• grafx2anim-a2-win32.zip

[GoogleCodeExporter]

Ok, that fixed it for some, here's one that still isn't right: 
http://www.pixeljoint.com/pixelart/63475.htm

Original comment by annas...@hotmail.com on 28 Jul 2011 at 5:29

[GoogleCodeExporter]

Updated version. Fixes loading of the above image.
It's a pretty cleaned-up source: compiling normally produces the stable grafx2 
2.3, compiling with NOLAYERS=1 produces the anim version.

Original comment by yrizoud on 19 Oct 2011 at 7:28

Attachments:

• grafx2anim-a3-win32.zip

[GoogleCodeExporter]

Updated version. Based on latest 2.4wip instead of stable 2.3, and the "adjust" 
tool is now fixed.

Original comment by yrizoud on 31 Oct 2011 at 7:05

Attachments:

• grafx2anim-a4-win32.zip

[GoogleCodeExporter]

Hi, I'd like to help making it a reality that the average user can access this 
functionality with no trouble.
In my opinion, it is an acceptable compromise to have a global mode, either 
LAYERED or ANIMATED, so that the background artist can use LAYERED and the 
sprite artist can use ANIMATED. 

IMO, having both at the same time would actually be bad (too much interface 
complexity).

Anyhow!
Looking over the code, the locations where NOLAYER is mentioned, the most 
important thing to enable such functionality is to allow widgets, specifically 
buttons, to be hidden/unhidden, so that the layers buttons can be 'replaced' by 
the animation buttons, or vice versa.

Where do you think I should start, after I add a 'Visible' field to the 
Buttons_Pool definition?

Original comment by 00a...@gmail.com on 19 Feb 2012 at 12:08

[GoogleCodeExporter]

Showing/Hiding toolbars already works fine.
The needed change is more likely ability to show :
 * No bar at all
 * Only layer bar
 * Only animation bar
 * But not both

The runtime switch would do strange things to the current picture, so we need 
to udate it as well.

I wonder if the state should be global or main/spare dependant.

Original comment by pulkoma...@gmail.com on 19 Feb 2012 at 8:21

[GoogleCodeExporter]

Main/spare dependant : indeed. Even more than that, each undo step of an image 
should keep the information whether it's layer mode or anim mode : For example 
if you're editing a layered image and Load an anim, it switches to anim. If you 
undo, you get back your layered image in Layer mode.

The bottleneck is Pixel_in_current_screen(), it's a function that can be called 
hundreds of time per second while painting, I fear that an extra if() in there 
will reduce performances noticeably.

The buttons/toolbar system will need to allow multiple occurences of the same 
buttons ("add layer" is the same as "add frame") It's not only the graphics/UI, 
they also share the same keyboard shortcut.

Original comment by yrizoud on 20 Feb 2012 at 10:21

[GoogleCodeExporter]

Isn't Pixel_in_current_screen a function pointer (or pointee) already ? If so, 
the overhead is 0 because we can just make another function next to it and 
point to the right one.

Original comment by pulkoma...@gmail.com on 20 Feb 2012 at 5:39

[GoogleCodeExporter]

This one is not yet, but that could be an option (especially if it handles the 
cases "direct" (as used in anim), "layered", "constraint L<4", "constraint 
L=4").

I just notice that the function could already have been split in two, one 
"with_preview", and the other without. This would also have saved an if(), at 
the cost of a bit of repeated code.

Original comment by yrizoud on 21 Feb 2012 at 11:11

[GoogleCodeExporter]

I've just tested locally, and it works pretty well. I just need to find the 
prettiest way to update the function pointers. The mode5 depends on variables 
like "Main_current_layer", which changes in many places. I also notice that 
themode5 is really not stable enough: Load a mode5 image, switch to spare, try 
to draw = crash.
This case really needs to have a specific "image type" in T_Page, so that it 
can cleanly be turned on/off according to main/spare, and for example if you 
edit a mode5 image, then Load a non-mode5, then Undo.

Original comment by yrizoud on 21 Feb 2012 at 7:44

[GoogleCodeExporter]

Time to move some globals to T_Page struct maybe ? Or am I doing too much 
Object-Oriented development out of GrafX2 ?

Original comment by pulkoma...@gmail.com on 21 Feb 2012 at 7:59

[GoogleCodeExporter]

00ai99, Pulkomandy, I hope you don't mind that I've advanced the topic myself 
in the main branch. At the beginning I only wanted to clean some tricky parts 
so that the way is clear for a modification of the menu system, but then I 
realized there was a subtle way to make everything work at once with minimal 
change and thus, minimal chance of breaking. At the moment the trunk only 
manages layered images and mode5 ones, compiling with NOLAYERS=1 is temporarily 
broken and meant to disappear entirely. The target is a single executable that 
behaves as fast as NOLAYERS when editing anims (ie suitable on slow platforms), 
and as fast as normal version when editing layered images. The bonus is that 
single-layer images could use the faster NOLAYERS rendering, so the program 
should eat less CPU when working on single-layer images.
I'll add a handful of safeties on mode5 (resolution constraint, make a backup 
step before adding layers etc), but not immediately enhance it.

Original comment by yrizoud on 28 Feb 2012 at 4:11

[GoogleCodeExporter]

This is good news!
by "the trunk only manages layered images and mode5 ones", do you mean that I 
should not yet expect anything too sensible from animation? I found that I 
could add frames, but couldn't tell which frame I was currently working on, 
other than from the number at the bottom.

Original comment by 00a...@gmail.com on 28 Feb 2012 at 10:19

[GoogleCodeExporter]

Yes, the animation bar buttons do what they're supposed, but the graphic 
rendering still uses the layer view system in all cases.  So for example the 
'play' buttons has no visible effect, since it doesn't changes the layer 
visibility flags (Main_layers_visible) that tell the display system which 
layers/frames are 'on'. 

Original comment by yrizoud on 29 Feb 2012 at 12:01

[GoogleCodeExporter]

I'm progressing well, just hitting an unforeseen difficulty :
When loading a GIF file, it's impossible to know if the file is an animation 
(made in any other program) or a layered image made in grafx2. It's a problem 
because after a file is loaded in the wrong mode, it can't be converted back:
- anim loaded as layers has been limited to 16 frames and forgets how images 
replace each other (the GIF 'disposal method' data)
- layers loaded as anim has been 'flattened' as if disposal method was 'do not 
dispose': frame 2 contains pixels 1+2, frame 3 contains pixels 1+2+3 etc.
At worst, this means the program would require the user to set the right mode 
before loading an old image. From now on, I must put an indicator in layered 
GIF files, so the program recognizes them with certainty when you load it later.

Original comment by yrizoud on 2 Mar 2012 at 5:23

[GoogleCodeExporter]

A quite solid WIP is packaged: 
http://code.google.com/p/grafx2/downloads/detail?name=grafx2-2.4wip1916-win32.zi
p
Feel free to test and comment.

About the above issue, I solved it using the following rule: if it loops, it's 
an animation. If it doesn't, it's loaded as layers.

Original comment by yrizoud on 4 Mar 2012 at 5:41

[GoogleCodeExporter]

May need default shortcuts for anim next/previous frame. Maybe PageUp/PageDown, 
stealing the defaults that scroll the palette.

Original comment by yrizoud on 9 Mar 2012 at 1:31

[GoogleCodeExporter]

Ah, now I can do a bit of animation.

I have no idea where the play button is. Is there currently a play button? It 
needs to be more obvious, if so.

Original comment by 00a...@gmail.com on 12 Mar 2012 at 5:48

[GoogleCodeExporter]

Also, when I'm editing frame time, I can't change the number until I delete the 
spaces on its left.

Original comment by 00a...@gmail.com on 12 Mar 2012 at 5:58

[GoogleCodeExporter]

Thanks for testing. The 'Play' is by right-clicking the 'previous frame' or 
'next frame' buttons, it advances the animation while you're pressing it. I 
should at least update the tooltip.
Frame time: I have such a habit of right-clicking fields to clear them that I 
never noticed this huge bug, which is present since the first animation 
version, 8 months ago :-/

Original comment by yrizoud on 12 Mar 2012 at 9:19

[GoogleCodeExporter]

Hi there folks. Is there 'animating ' version for macosx or amigaos somewhere 
around. I love grafx2 but i need ability to animate very badly. I can use other 
apps to make animation out of single image but would prefer to be able to do 
all in grafx2. Thanks in advance for any help.

Original comment by ferinstorm on 12 Mar 2012 at 5:01