Re: [TilEm-devel] Screenshots

[Thibault D. <t.d...@gm...>]

Hi,

yippee !
I've finally resolved my last problem on multicolor gif creation.
Now, there's no problem for creating monochrome or multicolor gif using your
(modified) palette creator and tilem_lcd_get_frame (modified for monochrome
or not modified for multicolor)
I will work on it tomorow, for the moment it's just a kind of "proof of
concept".
But I'm really happy :p

>>
> >> What do you mean by that?
> >>
> >
> > The timer value for catching the frame (from core).
> > See "g_timeout_add(100, tilem_animation_record, emu); " line 445 in
> screen.c
> > currently.
> > Because changing this value speeds the screenshot "independantly" from
> gif
> > frame delay.
>
> This should probably be changed, frames should be collected in the
> core thread so they're synchronized with the emulator clock.
> g_timeouts don't give precise timing anyway, and 10 fps is rather
> slow. :)
>

Yes, you're right, it was just a temporary solution :)


Currently the display is set to a fixed rate of 25 fps (40 ms per
> frame.)  That's probably fast enough for animations.  I guess we could
> in theory make it configurable.
>
> >> The output file format should, I think, be detected based on the file
> >> name.
> >>
> >
> > Ah, you want to drop the current (new) combobox ?
>
> Do you think this makes sense?  It's the way e.g., the GIMP works by
> default.
>

I keep it just for the moment for "easy debug" purpose, but it will
disappear.


>
> >> In our case, the palette won't change from one frame to another, it's
> >> a fixed set of 256 colors (which can be generated using
> >> tilem_color_palette_new().)
> >>
> >
> >
> > Yes, that's true palette doesn't change and in our case there's only one
> > palette used for all frames.
> >  I'm currently trying to use your function for generating palette and
> using
> > it.
> > Same thing for getting the content lcd, I'm trying to use your (new)
> > functions.
>
> OK.  I'm also planning to make some changes in how the screen is
> updated, both in the core thread and on the GUI side, to better take
> advantage of the new API.  We'll probably want screenshot recording to
> hook into that somehow.
>
> > By the way, for monochrome, palette is just black and white, or I think
> > wrong?
>
> Yeah, I guess the idea would be to use just the most significant bit
> (i.e., pixel values 128 and higher are black, 127 and lower are
> white.)  In this case we can create a 1-bit GIF file, which will be
> somewhat smaller; the other formats won't see so much benefit, since
> gdk-pixbuf is limited to 24-bit RGB.
>

I've done a modified version of this function to have only 0 and 1 (1
replace 128) because I plan to use a palette with only 2 colors for
monochrome.
I've made a modified version of palette generator to have a byte array
instead of dword which is padded with 0000000 on the most significant byte
(3 other are red green blue). The modified version do not have this blank
and is easy to use. But you can change these stuff, I've just do it to help
me ;)


> What I'm currently thinking is to define a TilemAnimation object,
> which would actually be a subclass of GdkPixbufAnimation so it could
> be plugged into a GtkImage; the TilemCalcEmulator could handle
> "recording" a single animation, which when completed would be handed
> off to the GUI for previewing and/or saving.  The actual file output
> could also be part of this class.
>


I've studied a little GdkPixbufAnimation before doing gif animation and it
was not really a good idea (at this time) to use it because gdk doesn't have
any way to convert this animation to gif. But now, with the new options,
compress, contrast, delay etc... that we are currently working on, it could
be a good solution.
GdkPixbufAnimation should be really useful to replay a gif which is not
saved... (as you say).
But, I see it more like an improvement than an obligatory thing.
Do you agree with me?

Regards.


Thibault.


PS: great job for the new file diablog (filters ^^).