New zView available!

[mikro]

Hi,

in case you don't follow dhs bbs: after some complains and inputs from MiNT and FireBee community I finally decided to release a new zView build. It's mainly a bugfix release, finally you should be able to run zView with memory protection enabled. Plus all plugins, the application, supporting libraries are updated & recompiled for 030+FPU so you should get the fastest possible code :)

https://sourceforge.net/projects/z-tools

[Dal]

Woo-hoo!

[joska]

Thanks Mikro Will you provide an offical Coldfire-version as well?

[mikro]

Jo: I'm not sure how to proceed on this, it's true there are some people like you who could be considered as true users but generally, it's still a non-existing machine :)

So I'm inclined to provide only internal versions right now, rebuild for CF is not a hard thing anymore so it's not a big deal to make a build now and then if needed.

[CiH]

Woo-hoo indeed

Any planned future improvements or enhancements in the pipeline?

[wongck]

[smilie=greencolorz4_pdt_12.gif]

Great stuff.
Another great feature to include would be a right click "Save as background" for a XaAES compatible background written into the correct Xaaes background graphic folder.

[lp]

Some new codecs for zView can be found here, use the 'Downloads' link in the sidebar:
https://bitbucket.org/lp_gfa/zcodeclib-for-gfabasic/

Codecs available:

TruePaint (aka PrismPaint) loads 1 to 8 planes only, I can't find any HC/TC examples, send me some
C.O.L.R. Object Editor, loads *. mur and *.pal if in the same dir otherwise assumes grayscale
ASCII art (grayscale), *.txt files as seen here: http://people.sc.fsu.edu/~jburkardt/dat ... scale.html
Spectrum 512, loads *.spu, *.spc, *.sps
Doodle *.doo
IFF, note it needs IFF.PRG in the codec dir as well
PNM, aka portable bitmap files with encoder
BMP and TGA are rebuilds with encoders added and yes they can save from zView

These are built with PureC and I think not working at the Firebee. Like anything new, backup any old codecs. If you run into files they won't load, I need a copy of the file to properly debug things.

[penguin]

... and in the recent issue of st-computer I wrote in my zView review "unfortunately there are no additional codecs available". Awesome stuff, Lonny!

[CiH]

I assume that you are not doing requests but a reworked animated gif codec would be great. There's quite a number that don't work currently or else don't display correctly.

[lp]

Actually I did rebuild the GIF codec with PureC, however the same bug remains with the background. I think this bug is noted in the issue tracker at zorro's site, but it's still unresolved. It's linked against libgif which by some stroke of luck I managed to build for PureC, but I'm not sure if the bug is related to that or if it's a more general problem in the codec itself.

[CiH]

Actually I did rebuild the GIF codec with PureC, however the same bug remains with the background. I think this bug is noted in the issue tracker at zorro's site, but it's still unresolved. It's linked against libgif which by some stroke of luck I managed to build for PureC, but I'm not sure if the bug is related to that or if it's a more general problem in the codec itself.

Ah, interesting to hear that this has been looked at/thought about before. Hopefully something can be done with this in due course.

[lp]

Ah, interesting to hear that this has been looked at/thought about before. Hopefully something can be done with this in due course.

Visit my bitbucket URL above and grab the gif.ldg I just uploaded. It's my PureC build + a fix for the messed up backgrounds.
It now loads and animates a rather large gif that didn't look right before. Let me know how it goes.

[CiH]

Visit my bitbucket URL above and grab the gif.ldg I just uploaded. It's my PureC build + a fix for the messed up backgrounds.
It now loads and animates a rather large gif that didn't look right before. Let me know how it goes.

Lonny, you rule!

The 'snowy background' has been vanquished on the three that I tried. Nice job!

For general information, there are three main issues for non or incorrectly displaying anim GIFs on zView.

1. The 'snowy background', which is now fixed

2. Some larger anim GIF's refuse to display on zView. I think this is memory allocation or amount of memory on the host machine. As something that balks on a 64 MB Aranym set-up, may be okay on a larger memory real Atari like a CT60. (Some even crash zView.)

3. A comparatively rare one, where the GIF displays, but does not animate. I guess this is down to differences in how this type of GIF is encoded? These are rare though.

Anyway, thanks for all your recent work on the codecs.

[lp]

Lonny, you rule!

No problem.

The 'snowy background' has been vanquished on the three that I tried. Nice job!

For general information, there are three main issues for non or incorrectly displaying anim GIFs on zView.

1. The 'snowy background', which is now fixed

I found a bug in the transparent color handling that is used to render the background.

2. Some larger anim GIF's refuse to display on zView. I think this is memory allocation or amount of memory on the host machine. As something that balks on a 64 MB Aranym set-up, may be okay on a larger memory real Atari like a CT60. (Some even crash zView.)

Animated gifs are definitely memory intensive. The higher the resolution and pixel count the more ram it's going to eat. It literally is converting each frame into a bitmap block ready for the VDI to blit. It's also buffering the background color index's of the previous frame, this is where the bug was found, in the transparent color handling. I haven't studied it in full detail, but there might also be a buffer holding the entire gif file as well. Imagine in TC mode, ((WIDTH x HEIGHT) x 3) x FRAME_COUNT, plus any other miscellaneous buffers during the load process.

3. A comparatively rare one, where the GIF displays, but does not animate. I guess this is down to differences in how this type of GIF is encoded? These are rare though.

Anyway, thanks for all your recent work on the codecs.

The transparent method is a way to get the file size down, it's sort of like delta compression only noting pixels that actually change from one frame to the next. A lot of gifs are not encoded this way. If you have certain images that choke, I need the actual image file for testing.

[lp]

CIH sent me a GIF that refused to animate via email as it exceeded the upload limit at the forum. Please re-download the GIF.ldg at my bitbucket url as this issue has also been resolved.

The particular gif CiH sent me had 0ms set for all frame delays.

The technical bits. The problem really is zView, it does some math on the frame delay and determines it can't be animated, so it shows the first frame and that's that. I don't think zorro expected 0 as a frame delay.

This is a typical problem with gif creators and they upload them like that. After googling it for a while I discovered how the web browsers deal with it, usually by setting some minimum frame delay such that it don't make the cpu hit 99% load. However, there was some controversy over what that minimum value should be and it might vary from browser to browser. What I did was watch it in FireFox and then tweaked the frame delay until it looked like it was running the same speed. Ended up at 10ms which was discussed. Anyway, the updated codec checks the delay of each frame, any frame set to 0ms is up'd to 10ms. This makes zView happy and thus it now animates it.

[CiH]

The particular gif CiH sent me had 0ms set for all frame delays.

It now works fine

Before this weekend, zView would not properly display around half the GIF's tried. Now this should be reduced greatly.

[AtariCrypt]

This is the best news I've heard lately. Thank you!
Steve

[lp]

I uploaded two more codecs:
Art Director and STAD

I know these aren't massively popular, but for me it's more of an exercise in 'C' than anything.

I'm sorry these aren't working at the Firebee. Apparently the PureC fix in FireTOS doesn't work on LDG libraries even though internally I am pretty sure LDG uses a pexec() call. I tried to rebuild one with AHCC, but that didn't go well.

[lp]

Two more codecs for the heck of it, MacPaint and Atari Portfolio Graphics.

[lp]

There's now a Sun Raster codec available. It will load some images GemView rejects and also has an encoder.

[lp]

Today's coding session, a GFA Raytrace codec. Loads compressed files as well.

[lp]

I just uploaded a PNG codec based on the open source PNG decoder by Cerebral Vortex Software Development.
About the decoder: http://www.cerebral-vortex.net/index.php?id=94

It's about 270kb smaller than the one built using libpng/gcc. I'd consider it somewhat experimental and do backup your old codec if you decide to give it a go.

[lp]

Just uploaded a codec for Tiny images, supports TN1, TN2, TN3, and TNY.

[lp]

Yet another zView codec, this time CrackArt. Loads CA1, CA2, and CA3 files. I could not find any sample CA2 or CA3 files, however they should work. If anyone can point me to some samples online, or send me some, that would be cool.

[lp]

I just uploaded a codec for PhotoChome (pchome.ldg), it's based on St2BMP by Hans Wessels that was placed in the public domain. It's mostly his work, all I did was figure out how it worked an rolled it into a codec. Cheers to Nyh for releasing his code.

https://bitbucket.org/lp_gfa/zcodeclib-for-gfabasic/ -> Download link