| Posted By
Luca
on 2008-01-14
16:30:54
 |  plus4emu FLI converter
[This thread follows up from this post. The last IstvanV's revision of his own converter is this one.]
I see that Istvan Varga is making the very first Plus/4 dedicated image converter, he looks addicted to the matter, he's coding it very versatile and working, he's damn fast in doing it.
I repeat: the first ever. We just had examples of picture drawing programs, we never got an all-formats converter, and we'd never seen a FLI picrure quality like this.
Yes, I am the first one to pray for a global stuff which can do everything, and I see Istvan's stuff as a good starting point to achieve, in a short time at this speed, exactly that tenaciously craved target.
Gaia, beg your pardon, but in few rows you asserted: the plus/4 graphicians need different stuff; this converter would aim to be like honey for c64 ppl that only because of this would be interested; because this is "another converter" on Plus/4 (eh!?  ) it wouldn't be enough to let c64 ppl income with new releases; native Plus/4 graphicians are a crazy variable and can't be predicted in their decisions; the same ppl (graphicians) that would be interested in different stuff at point 1 to be honest hare a bunch of few desperate guys 
Well, of course I exxagerated in order to laugh, but i must admit I'd never thought at this program as an appealing fruit for the c64 masses, it's a pretty interesting point of view anyway...
Also, my wish (and hope) would be to see the sceners shake their face and restart enjoying the little black box, before awaiting interested ppl from other scenes: nukem has recalled to us we lack of simple and polite releases; Degauss has recalled to us you can spend few hours to show your skill in optimizing a 256bytes demo and collect interest (see Pouet) about this, also because his achievement enter an important field of scenes'interaction
And finally: if you have a secret Plus/4 conversion stuff hidden somewhere, dig it out, 'coz I can't recall it in my mind! .
Happy to discuss this topic with all of us, finally a bit of life! Much happy to discuss this at pH=7! 
|
|
Posted By
Degauss
on 2008-01-14
17:01:45
| Re: plus4emu FLI converter
In between all this, i'd like to drop an idea:
I'm no graphician so i don't really know what kind of tools a real graphician would prefer, but i know the ruleset for a +4-FLI-picture is quite hard to master: picking the right BG/FG-Color values, probably X-Shifts... terrible. So my idea always was to have some sort of "converter-assisted pixelling": You should be able to pixel freely with all the 121 colors and let the converter help you finding (and solving) the areas where you were putting too much colors in. If done right, that could be a simple "addon" upon a straight converter-tool.
To be honest, this is what i always wanted to do with my converter, but ATM i like Istvans better.
p.s.: An example where "converter-assisted pixelling" could be a benefit is this: As a graphician, you would normally choose the most used color in a line to be assigend to the FF15-register. A converter probably would decide differently: It would use the videomatrix for the most used color so FF15 is still free to resolve an important color-bug somewhere else in the line (at least, thats what my converter does to reach a higher color-density)
|
|
Posted By
Luca
on 2008-01-14
17:03:27
| Re: plus4emu FLI converter
Hey Ingo is claiming a smart-converter!
|
|
Posted By
Litwr
on 2008-01-19
00:45:45
| Re: plus4emu FLI converter
Excuse me but how to run this p4fliconv.7z?
|
|
Posted By
IstvanV
on 2008-01-19
05:11:29
| Re: plus4emu FLI converter
The archive is in 7-Zip format, which you can unpack with tools that can be downloaded from here: http://www.7-zip.org/download.html. On Windows, just extract it to a plus4emu installation directory, so that p4filconv.exe is in the same directory as plus4emu.exe, and src/SConstruct is overwritten. On other platforms, it can be built from the included source code; first, unpack the latest plus4emu source package, and extract p4fliconv.7z to the same directory, overwriting SConstruct, for example, assuming that you have plus4emu-1.2.5.tar.gz and p4fliconv.7z in the current directory:
tar -xpzvf plus4emu-1.2.5.tar.gz
mv plus4emu-1.2.5 src
7za x p4fliconv.7z (type 'Y' to overwrite SConstruct)
rm p4fliconv.exe
cd src
(edit SConstruct, and disable win32CrossCompile and maybe buildRelease as well;
also edit src/gldisp.hpp, and replace the 'private:' at line 33 with 'protected:')
scons p4fliconv
If building from source code does not work for some reason, you can also run the Win32 version with WINE. I plan to release a new minor update to plus4emu in a week or so, which will include the image converter utility.
|
|
Posted By
Litwr
on 2008-01-19
05:22:16
| Re: plus4emu FLI converter
Thanks. However why to use so exotic format? Is it much better than tar.bz2? BTW the mentioned site with 7-zip is offline now. 
|
|
Posted By
IstvanV
on 2008-01-19
05:37:56
| Re: plus4emu FLI converter
I have very limited space on the sharemation site, since there is a quota of only 5 MB. When compressing large binary files, LZMA compression can be about 20% smaller than bzip2, which can be useful when I often have to delete old files to free space for the new ones. However, if no one needs the old converter comparison package (p4imageconv.rar) which is 1.7 MB, I can delete it, and replace the other files with plain old .zip packages. So, can I delete p4imageconv.rar ?
Of course, this issue will be irrelevant when the next plus4emu version is released on SourceForge.
I just tried downloading the p7zip sources, and there seemed to be no problems.
|
|
Posted By
Litwr
on 2008-01-19
05:41:06
| Re: plus4emu FLI converter
Yes, yes, I've also found many links in net - all is ok! thanks again.
|
|
Posted By
IstvanV
on 2008-01-27
18:59:38
| Re: plus4emu FLI converter
Are there any bugs or other issues that need to be fixed before it can be released ?
|
|
Posted By
Luca
on 2008-01-27
19:03:46
| Re: plus4emu FLI converter
Mmmmmno, I played a lot with it, you only have to balance the image, the sensibility, contrast etc... It's a joyful toy anyway
|
|
Posted By
IstvanV
on 2008-01-28
07:30:40
| Re: plus4emu FLI converter
It could also be possible to add more video modes, for example the earlier greyscale only conversion, although the only advantage it has is being able to set attributes independently for 8x1 blocks, rather than 8x2, which is not much compared to the disadvantage of losing colors.
Another idea, originally from TLC, is using NTSC mode to increase the horizontal resolution, as well as to make the visible area wider (41.6 characters), but I do not think this overclocking trick is very useful in practice, particularly since it only allows MC resolution with 3-4 colors for the whole screen. An example of two images in one PRG file, and conversions of the same images in the high resolution color mode for comparison can be found here:
http://www.sharemation.com/IstvanV/ntsc/ntsc.prg
http://www.sharemation.com/IstvanV/ntsc/image1.prg
http://www.sharemation.com/IstvanV/ntsc/image2.prg
What would be really useful is adding full multicolor mode conversion with "horizontal interlace", although it is probably the most difficult one to implement.
|
|
Posted By
Luca
on 2008-01-28
07:41:08
| Re: plus4emu FLI converter
IstvanV, I really would like to see multiformat conversion in one tool, starting for the most simple ones: plain bitmap MC and 4 fixed colours characterbank based MC with char compression in variable sizes (yes, exactly, the logos stuff).
With your code's features, both would have great colour clashes reduction routines...
PS: brrrr, your example pics scare me everytime :)
|
|
|
|
Posted By
IstvanV
on 2008-02-01
08:38:48
| Re: plus4emu FLI converter
This updated version (http://www.sharemation.com/IstvanV/flitest/mcfli_test2.prg looks slightly better, although it is still not quite perfect. Any opinions ? Should I include this mode, or is it not useful enough (note that the MC conversion is also rather slow at the moment) ?
|
|
|
|
Posted By
IstvanV
on 2008-02-21
10:15:35
| Re: plus4emu FLI converter
I have now changed the multicolor FLI converter to take advantage of the increased resolution of the two background colors, although it only seems to result in a very minor quality improvement, and it does slow down the conversion somewhat. In fact, for most images, just changing the old code to optimize the palette more results in better quality/speed ratio. The algorithm could probably be improved, though.
|
|
Posted By
Degauss
on 2008-02-21
13:06:11
| Re: plus4emu FLI converter
Hi Istvan!
Just a suggestion: Try some other test-images. My experience was that sooner or later you find images with "troublesome" conditions (high contrast areas etc).
|
|
Posted By
IstvanV
on 2008-02-22
10:03:43
| Re: plus4emu FLI converter
Hi ! It does of course make more difference with test images that really require the high color resolution (e.g. a screenshot of the 'flitest.prg' example), but for typical images there are usually only a few lines where the background colors change within a pair of lines. However, this is probably in large part because the current algorithm basically does the old-style conversion first, and then tries to reduce the error in a second pass by changing the background colors separately for each line. I have experimented with various ways of optimizing the colors in a single loop, but so far this always resulted in either too much slowdown, or slightly worse - rather than better - quality, or both.
|
|
Posted By
IstvanV
on 2008-02-23
07:54:32
| Re: plus4emu FLI converter
I have just noticed that TLC FLI Collection, which was released in 1998, uses interlacing to increase the vertical resolution, although it is apparently not mentioned in the description. However, there seems to be a minor problem: the fields are swapped on plus4emu, YAPE 0.79, and my real Plus/4 and TV card as well. Is this hardware specific (i.e. there may be TVs or monitors on which the effect works correctly), or is it a bug in the demo ?
|
|
Posted By
Gaia
on 2008-02-23
10:28:20
| Re: plus4emu FLI converter
It's an unfinished routine, not even a demo, so probably a bug, but only TLC could tell...
|
|
Posted By
IstvanV
on 2008-02-25
10:23:13
| Re: plus4emu FLI converter
Dr. Death: for now, I have simply made the multicolor conversion quality adjustable in the configuration, so the user can choose from lower quality, but fast conversion, to higher quality but very long processing time (which is normally only to be used for the final version of the image). With the new display routine, more video modes (non-interlaced hires and multicolor FLI, and simple hires mode without FLI), and C64 image format reading support, a new "beta" version will hopefully be available soon.
|
|
Posted By
IstvanV
on 2008-02-27
14:07:09
| Re: plus4emu FLI converter
It can be downloaded now from here: http://www.sharemation.com/IstvanV/p4fliconv_sse.7z
There is also another download (p4fliconv.7z) for older machines; it is only useful if you have a CPU that is not at least a Pentium 4 and does not support SSE/SSE2 instructions.
|
|
Posted By
Luca
on 2008-02-28
17:54:29
| Re: plus4emu FLI converter
Uffff, doesn't work to me
|
|
Posted By
IstvanV
on 2008-02-28
19:24:57
| Re: plus4emu FLI converter
I have uploaded the packages again (with some minor bugs fixed), so the downloads should work now.
|
|
Posted By
Luca
on 2008-02-28
20:17:11
| Re: plus4emu FLI converter
The sample is somewhat incredible, but the .exe doesn't work to me, giving an MS error message
|
|
Posted By
IstvanV
on 2008-02-29
07:14:25
| Re: plus4emu FLI converter
Does the version that was included with plus4emu 1.2.5.2 also crash on the same machine ? If not, then make sure that the file mingwm10.dll is also extracted to the same directory as p4fliconv_gui.exe; the simplest way to get a working installation is to extract the package to a plus4emu installation directory, overwriting any old files (this also allows running the program from the start menu). You can also try the slower non-SSE build in case the problem is caused by the use of special CPU instructions (the previous versions were all compiled with the settings of the "compatibility" package).
Some more questions: does the crash occur immediately on start-up, or the program starts, but crashes later, for example when opening a file ? Does command line conversion using the console version (p4fliconv.exe) work ? What is the actual error message ?
|
|
Posted By
Luca
on 2008-02-29
07:56:58
| Re: plus4emu FLI converter
I've just tried all this before moaning: .dll, non-sse, overwriting etc... Yes, all the previous versions ran on that machine, and the error message is the classic MS error window, and it occurs immediately at doubleclick.
|
|
Posted By
IstvanV
on 2008-02-29
09:25:40
| Re: plus4emu FLI converter
This is really strange. I do not know what change could have introduced this problem. Do the old 1.2.5.2 exe files run now, if you reinstall those (without changing anything else) ? Did you try the command line interface (for example, just running 'p4fliconv.exe --help' to see if that works, or some simple conversion like 'p4fliconv.exe foo.jpg foo.prg') ?
It would also be interesting to see where the crash happens in the code; although the files do not have debug information, if you could post just a stack trace of code addresses (included with the error message or error log generated by Windows), that would be useful.
By the way, what version of Windows are you using ? Does anyone else also have this problem (all the .exe files run fine on my machine) ?
|
|
Posted By
Luca
on 2008-02-29
09:57:28
| Re: plus4emu FLI converter
I use a simple traditional XP with SP2, and once reinstalled the old version, everything works ok...
|
|
Posted By
IstvanV
on 2008-02-29
10:11:14
| Re: plus4emu FLI converter
Well, then I do not have much ideas left. Although someone mentioned having problems on a dual monitor machine earlier, but as far as I know, that should have been solved by upgrading the FLTK library. In any case, if you can send the complete error log generated by Windows (with the stack trace etc.), that could help finding out where the program actually crashes.
|
|
Posted By
IstvanV
on 2008-02-29
14:17:08
| Re: plus4emu FLI converter
Any news ? Since I cannot reproduce the problem myself, I cannot fix it without more information
|
|
Posted By
Luca
on 2008-02-29
14:46:17
| Re: plus4emu FLI converter
Waitwaitwait, the non-SSe works fine for me
|
|
Posted By
Exin
on 2008-02-29
15:01:39
| Re: plus4emu FLI converter
Hmmmm...this version of the FLI converter with gui gives me rather small images....The image size part in the gui version seems bugged and fixed to 128....
|
|
Posted By
IstvanV
on 2008-02-29
16:08:46
| Re: plus4emu FLI converter
Luca: thanks for the information, finally some good news I assume this means that it is not necessary to investigate this problem further, and I should just continue to build both SSE and non-SSE versions (the latter do run about 1.5 times slower on my machine for multicolor conversions, so the difference is not insignificant) ?
Exin: this problem sounds even more weird. For me, the GUI controls seem to work fine under WINE, and native Windows as well. Is 'Vertical size' the only one that is not behaving as expected ? Can you change it by clicking on the number with the mouse, and then dragging to the left or right with the mouse button held down, or by typing in a value directly, or are both methods broken ? Is it possible to set the value on the command line (with the -size N option) when starting the GUI, or does that get changed to 128 too ?
|
|
Posted By
Luca
on 2008-02-29
16:30:52
| Re: plus4emu FLI converter
Just to say: to me it's work fine, and the new "x-opening" for the .prg viewer is cool Now I'm playing with Koala conversion
|
|
Posted By
IstvanV
on 2008-03-01
11:23:55
| Re: plus4emu FLI converter
On a somewhat related note, would it be useful to have special support for reading images that use the Plus/4 palette, and converting those to the multicolor formats with as close to pixel exact quality as possible ? While it can already be done, it requires very specific conversion settings, image size, and input palette to avoid additional quality reduction due to interpolation and color mapping (particularly in the case of the very dark and bright colors which are clipped in the RGB colorspace).
The image opening/closing effect in the viewer can actually be enabled/disabled with a flag in the image data (perhaps a description of the data format would be useful ?), although there is no configuration option yet in the converter UI to change that. The effect can also be easily changed in the viewer source.
|
|
Posted By
IstvanV
on 2008-03-02
09:48:37
| Re: plus4emu FLI converter
There are updated downloads now with some minor bug fixes.
|
|
Posted By
Luca
on 2008-03-02
19:36:34
| Re: plus4emu FLI converter
So, let's perform some testing with the very last version, in particular about palettes.
This is Fantasy Hair drawn in Koala Paint format by Almighty God on C64 for the Oxyron Party 2008. Please look at the colour clashes because of the c64's 3 colors per char feature (especially in the mostright low corner, around the sign).
|
|
Posted By
IstvanV
on 2008-03-03
08:05:31
| Re: plus4emu FLI converter
There is also some visible quality reduction in the dithering of the red circle. However, if the brighter pixels at the lower right corner are more of a problem, then it may make a difference to change the scaling of the U and V error with respect to the Y error (that is, how important is the color information compared to the luminance). This is fixed to 0.5 in the current version, but changing the value to 0.25 results in this image (using plain multicolor mode, of course, FLI would look better):
http://www.sharemation.com/IstvanV/fantasy_hair_mc.prg
Now the bright pixels are mostly gone, at the expense of more merging of colors with identical luminance. Would it be a useful feature to make the color error scale adjustable in the advanced settings ?
|
|
|
|
Posted By
Luca
on 2008-03-03
09:50:53
| Re: plus4emu FLI converter
Yes, a dedicated setting for this kind of operation would be quite friendly, 'cause it looks to be a common point for any kind of converting from C64 MC (looking forward to their features which will appear). Of course, the real fixing will be performed via pixel editing, but that would also be a very valid help.
Moreover, looking for a comfortable Multi Botticelli editing, it would be also cool a RAM color uniformity: take a charsized area with its own Col1 and Col2, located in (x,y); if a color(e.g. Col1) in the charsized areas close to it is the same of Col1 or Col2 in (x,y), then (x,y) will swap that color to Col1 too. It will be very useful even in the HiRes case!
|
|
Posted By
Degauss
on 2008-03-03
18:05:26
| Re: plus4emu FLI converter
argh, i missed all recent developments... gotta catch up soon.
|
|
Posted By
IstvanV
on 2008-03-04
17:33:34
| Re: plus4emu FLI converter
Luca: the multicolor error calculation tuning parameter is now implemented, and the downloadable package is updated (note that there is a single http://www.sharemation.com/IstvanV/p4fliconv.7z file now, and it contains both the compatibility and fast SSE build of the program).
I will also try implementing the "editor friendly" color RAM use later; I assume it is only needed for the non-FLI modes ?
|
|
Posted By
Luca
on 2008-03-04
22:06:43
| Re: plus4emu FLI converter
Yes, non-FLI only, it's a feature that will be very useful for further editinf of C64 converted MCM and HR pictures.
Looking forward to a charset stuff too...
|
|
Posted By
IstvanV
on 2008-03-05
11:05:38
| Re: plus4emu FLI converter
Well, I recall you have suggested three logo editor formats (Logo Paint, Logo Editor V2.0, and Logomaker +40), so which one should be implemented first ? Is a greyscale-only conversion sufficient, or should the colors of the original image also be converted (which may possibly not look very good with a 128x64 4 color format) ?
There are a few more changes I planned, but do not know if any of these are actually needed by anyone:
- GIF (and generally indexed) format reading
- pixel exact reading of images using the Plus/4 palette, similarly to the way the C64 formats are handled
- more dithering modes (e.g. ordered with simple non-randomized patterns)
|
|
Posted By
Luca
on 2008-03-05
11:35:12
| Re: plus4emu FLI converter
Logo Editor V2.0 as first. Greyscale-only is enough, because the converter simply should "reduce and dither" an usual bmp/png/jpg, or a c64 one...or a Multi Botticelli one too, why not?
|
|
|
|
Posted By
IstvanV
on 2008-03-06
06:16:56
| Re: plus4emu FLI converter
Although I did not mention it yet, but the download was updated yesterday, so you can already test if the color remapping is an improvement in practice. A bug has also been fixed.
|
|
Posted By
IstvanV
on 2008-03-10
11:17:12
| Re: plus4emu FLI converter
Here is a simple multicolor Logo Editor V2.0 conversion: http://www.sharemation.com/IstvanV/blahlogo.prg
This only displays black and shades of grey, but it is possible to change it to any gradient by editing the palette at $1100-$1103. To create a Logo Editor compatible file from this, just save the memory area $6000-$6800 to disk in the TEDMON. The converter will also allow saving Logo Editor files directly when the "raw" mode is enabled, but these files do not include palette information (however, the four color palette is printed on the GUI after conversion).
Should I upload a new version that includes this format ?
|
|
Posted By
Luca
on 2008-03-10
12:16:30
| Re: plus4emu FLI converter
Wonderful! Yes, upload it absolutely, wanna play a bit with that stuff!
Ah, I did not see you've uploaded the converter some days ago..
|
|
Posted By
IstvanV
on 2008-03-10
19:06:56
| Re: plus4emu FLI converter
The updated version is now uploaded.
|
|
Posted By
Luca
on 2008-03-11
06:51:08
| Re: plus4emu FLI converter
I had a little time to try the new features the past night, and I have to say it was GREAT FUN! Especially playing with dithering, X/Y position and, most of all, X/Yscale!
|
|
Posted By
Degauss
on 2008-03-11
13:41:19
| Re: plus4emu FLI converter
Have to second Luca. Besides the fact that the tool is very useful, it reminds me a bit of Llamasofts Psychedelia
@Istvan: I don't want to be bold about feature-requests but: How about an export-option that results in a .bin-file and a short driver (would make it easier for a demo-coder to use your tool)
|
|
Posted By
IstvanV
on 2008-03-11
17:09:07
| Re: plus4emu FLI converter
I am not sure if this is exactly what you meant by a .bin file, but checking the option 'Write the raw FLI data only' allows for saving just the actual video data without any viewer code. The assembler source of the FLI viewer (p4flidisp.s) is included with the package, and can be compiled with ca65; the code takes up the first 2K of the basic memory (not including the unrolled FLI display code which is created by the viewer at run-time), so it is not particularly short, but for use in an actual demo, many unneeded parts can probably be removed.
The non-FLI modes use the formats of Botticelli, Multi Botticelli, and Logo Editor V2.0, and the files are loaded to $7800-$9F40 (graphics) or $6000-$6800 (character sets).
The FLI data format is loaded to $17FE, with the end address ranging from $6000 to $E500, depending on the details of the video mode (interlacing, overscan, etc.). A short documentation is available here: http://www.sharemation.com/IstvanV/fli_mem.txt. Hopefully there are not too many typing errors
Files can also be saved in compressed format, if the 'PRG compression' is set to a greater than zero value, although this format is somewhat complex, and slow to decompress. A "raw compressed" file includes only the compressed video data (loaded to the same start address as without compression), with no decompressor or viewer code at all. The non-raw compressed files (like the sample programs included with the downloadable package) are self extracting and include the viewer.
Of course, more output format options can be added, if needed.
|
|
Posted By
Degauss
on 2008-03-12
08:28:33
| Re: plus4emu FLI converter
Oh, that was my fault. I didn't notice the "Write the raw FLI data only" option. Yes, thats everything a demo-coder needs.
Which compressor did you use?
|
|
Posted By
IstvanV
on 2008-03-12
09:54:12
| Re: plus4emu FLI converter
The compressor is my own code, it is somewhat similar to the zip/gzip format, but the compression ratio is better. However, it has the disadvantage of a large and slow decompressor, so you would probably want to use an external compressor instead in most cases; the viewer does not include any code for decompressing, it just calls a subroutine through the vector at $17F4 if the data is flagged as being compressed.
|
|
Posted By
Exin
on 2008-03-16
19:28:29
| Re: plus4emu FLI converter
Is it time to demand format features?
additional File formats:
Pixelshop (Hires and multicolor)
FliEdit (Multicolor fli)
|
|
Posted By
IstvanV
on 2008-03-17
08:42:43
| Re: plus4emu FLI converter
I have thought of adding PixelShop format support earlier, or writing a separate utility for converting between various Plus/4 FLI formats, although the P4S format does not seem to allow for including all the information that is in the converter output (for example, X shifts cannot be saved, so that should be set to zero in the conversion options).
Perhaps it would also make sense to have an utility to convert from P4S to the p4fliconv format, so that the files edited with PixelShop can be displayed with my FLI viewer ?
I am not sure what 'FliEdit' is, since I could not find a program with this name. Is it FED ? If yes, then it should be simple, but the format is limited to 160x200 multicolor FLI with X shift = 0 (that is, it is not possible to correctly save this type of file if any other converter settings are used).
|
|
Posted By
IstvanV
on 2008-03-17
09:02:39
| Re: plus4emu FLI converter
By the way, this utility does not seem to be listed on the "Tools" page.
|
|
Posted By
Exin
on 2008-03-17
12:46:27
| Re: plus4emu FLI converter
Hi there
Xshift is almost useless for real drawings, so not needed.
And Pixelshop doesn't have FLI support. Maybe you could add a seperate chart for the output file format. Including an orption whether to include the X shift value or not.
|
|
Posted By
IstvanV
on 2008-03-17
14:25:12
| Re: plus4emu FLI converter
Hi ! From the documentation and the user interface I thought that PixelShop supports FLI. So, I can assume that it is actually unimplemented or buggy ? If that is the case, is PixelShop limited in practice to plain 320x200 hires or 160x200 multicolor formats with no FLI, overscan, or interlace ?
Any information on what "FliEdit" is (I could not find a program with this exact name, and there are multiple editor utilities for Plus/4 multicolor FLI) ?
|
|
Posted By
IstvanV
on 2008-03-18
11:50:43
| Re: plus4emu FLI converter
I did some tests now, and it seems that PixelShop can read FLI images, and also images with a height other than 200. While I did not check how reliably it works in those cases, it will probably be enough to reject interlaced FLI and X shift only, anything else can be saved in P4S format.
|
|
Posted By
Luca
on 2008-03-18
14:27:12
| Re: plus4emu FLI converter
I played with the converter and some old images in hours today, having lot of fun with a bunch of friends, playing with the features, converting and passing on the Plus/4 in order to see the final result . I simply love this powerful toy, we should find a friendly name for it.
|
|
Posted By
IstvanV
on 2008-03-19
19:04:38
| Re: plus4emu FLI converter
Exin: I have mostly implemented the new output formats now, and an updated version that can save P4S and P4I (FED) files will be available soon. I will also add a separate utility that converts from P4S to all the supported output formats.
|
|
Posted By
IstvanV
on 2008-03-19
19:09:32
| Re: plus4emu FLI converter
Luca: well, the current name of 'p4fliconv' is probably not very imaginative, but finding good names is not something I am particularly good at However, if there is a suggestion for a better replacement, it can be renamed.
|
|
Posted By
Degauss
on 2008-03-19
20:43:26
| Re: plus4emu FLI converter
hi istvan!
a first suggestion: fli-circus. handling all the different aspects of the image conversion must be comparable to drilling fleas
after a long time of just reading the thread i played for quite a while with this tool and i have to say i like it very much. the thing i like most is the preview-option (PAL-preview! how cool is that!), the real-interlace-mode and the support for all relevant formats.
i don't want to bomb you with feature-requests, but i like to make some suggestions for further improvements. there are only few things i would love to see and these are just ideas, so please don't kill me:
1. your "preview" mode already shows the final result. from my experience and due to the highly saturated nature of the +4-palette i always felt the need to see a preview after all the preprocessing-steps (like gamma-correction etc..). in my converter (see below) i solved this with a preview that shows an "idealised" picture, color-reduced and dithered to the +4-palette.
2. different x-shifts per line (i know, i'm quite fixated on this )
3. interlaced modes where both fields share the same videomatrix. (this should be quite useful for all cases/demos where you don't have too much ram left)
4. a bit more exotic: special support for monochromatic modes. the display-kernel-routine only refetches the luminance-attributes.
5. even more exotic: an adaptive approach that decides if the display-kernel-routine refetches the color or luminance portion to reduce error.
-------------
my converter:
you can download a WOP-version of my converter here:
http://www.jache.de/download/flinteractive_preview.zip
the application is full of rough and dirty code, tends to crash and has lots of inferior approaches (e.g.: i use RGB instead of YUV all the time). so don't look too close
look at the readme-file to see how you can play around with the scrollbars and keys 1-5 to have a quick (pre-)preview. maybe this is something you would like to have in your app aswell. i still think its handy to compare "optimal" versus "possible". that would be even more interesting in your app, since you are able to show a PAL-preview.
regards
degauss
|
|
Posted By
Chronos
on 2008-03-20
03:17:32
 | Re: plus4emu FLI converter
you guys are real gods! the converter getting better and better day by day!
|
|
Posted By
IstvanV
on 2008-03-20
18:43:58
| Re: plus4emu FLI converter
Hi Degauss !
Changing the display of the original image to be affected by the color correction settings would be easy, although it would need to be updated (which is slow) whenever those settings are modified. A color reduced and dithered "ideal" image is somewhat more tricky, considering that all the various video modes need to be supported, while the PAL preview is actually Plus/4 emulation, so it just loads and runs the generated program. But it would be a useful feature for the multicolor modes, which do work by creating the "ideal" dithered image first, and then converting it, so I will try implementing it eventually.
The X shift can already be set independently by the converter for every line when it is set to "optimized" in the options (although in the specific case of interlaced hires FLI, it is only allowed to change by at most one pixel per line; in the other modes, all possible values are searched by brute force, for example the multicolor FLI modes try 4x4=16 combinations for each pair of lines). Or did you mean being able to set it manually for each line ?
Adding bitmap-only interlace modes is indeed on the list of features to be implemented. If I recall correctly, you did already mention this some time ago, but I did not get to actually implement it yet.
I do already have an older utility (interlace6.cpp) that converts to greyscale-only hires FLI where the luminance attributes are updated for every line, rather than pairs of lines, and also posted some example programs earlier. It is very simple code, though, so many improvements could be made.
I tried your converter, the quality is actually very good.
|
|
Posted By
Degauss
on 2008-03-21
09:18:03
| Re: plus4emu FLI converter
Hi Istvan!
Ah, i guessed you're running the prg in your emu. So i guess there's no "elegant" way of showing a plain pixelarray through a PAL-filter. I found out that instead of having a preview-mode, it's also ok to load/save the "give good results"-settings.
If i would have looked a bit more closely on your documents, i would have noticed that the x-shifts are independent per line, sorry . a thing i was wondering about: is there a reason for the constraint in hires-fli (x-shift can change one pixel at most)? i presume the resulting image would have too much jitter-effects otherwise, right?
Regards
Degauss
|
|
Posted By
IstvanV
on 2008-03-21
20:02:33
| Re: plus4emu FLI converter
Hi ! Yes, the limitation of X shift change in interlaced hires FLI mode is mostly an attempt to make the output more stable, but it also reduces the number of combinations to be tested if four lines are optimized at once, there are only 81 iterations instead of 4096 then.
By the way, while the file format may suggest that background colors can also be set independently for each line, it is actually only the case if there are at most 200 lines per field. Otherwise, the FF15 color can only be changed in odd lines if the FF07 value does not change in the same line.
|
|
Posted By
IstvanV
on 2008-03-21
20:10:21
| Re: plus4emu FLI converter
The beta package (http://www.sharemation.com/IstvanV/p4fliconv.7z) is now updated. As requested by Exin, PixelShop and FED format files can be written, and there is also a new utility (p4sconv) that can convert P4S files to any of the supported output formats. Other than that, there are various minor changes, more dithering modes, and a preliminary interlaced multicolor FLI mode where only the bitmaps are interlaced. It does not interlace the background colors and X shift either, though, so the quality is not optimal; these limitations can hopefully be removed later.
|
|
Posted By
IstvanV
on 2008-03-23
20:13:13
| Re: plus4emu FLI converter
Another minor update: the bitmap-only interlace is now also implemented in high resolution mode, and in multicolor mode it can interlace the background colors for a small improvement in quality. The X shift is still not interlaced in either of these new modes, though.
|
|
Posted By
IstvanV
on 2008-03-28
13:05:07
| Re: plus4emu FLI converter
The p4fliconv.7z file has been updated again: colors are now dithered more accurately in multicolor modes if ordered dithering is used; previously, the hue was inaccurate at low saturation. Assembler sources for decompressing the "raw compressed" format are also included now; the code might need to be cleaned up somewhat, but it seems to work. By the way, one change in the previous version that I did not mention is different error calculation in the multicolor modes - it may need more experimenting, but it does look better now than with the older releases.
|
|
Posted By
Exin
on 2008-04-03
16:42:02
| Re: plus4emu FLI converter
Hi Istvan!
With SSE you robably mean SSE2? It doesn't seem to work on my Pentium 3 Notebook.
Exin
|
|
Posted By
IstvanV
on 2008-04-03
18:32:20
| Re: plus4emu FLI converter
Yes, the SSE binaries (p4fliconv_sse.exe and p4fliconv_gui_sse.exe) were compiled with the Pentium 4 instruction set, and use both SSE and SSE2. All other .exe files use only Pentium 2 instructions, and should run on most machines, although multicolor FLI conversion (which takes the longest time, at high quality and using optimal X shifts) is about 1.5 times slower on my machine when using the non-SSE executables.
|
|
Posted By
IstvanV
on 2008-04-04
19:25:40
| Re: plus4emu FLI converter
There is a new p4fliconv.7z package available for download now. It adds support for reading .gif and .xpm files, although transparency is currently ignored (unlike in the case of RGBA PNG files, where it blends with the border color), and named colors like "Black" instead of "#000000" in .xpm files are not allowed. XPM format images that use a palette that has at least 128 colors and is sufficiently similar to the Plus/4 palette are handled in a special way, similarly to .koa and .ocp: the color indexes are mapped directly to Plus/4 colors, the image size is scaled only by integer ratios and without interpolation, and color correction is disabled.
Other changes include the addition of yet another dithering mode (mostly for interlaced multicolor modes, where dithering is often problematic), and some optimizations in the decompress.s file, which, if enabled, improve the speed by a few percents at the expense of increasing the code size by 6 bytes.
|
|
Posted By
Luca
on 2008-04-05
02:45:48
| Re: plus4emu FLI converter
This damn toy is becoming more funny release after release.
Playing with it, you feel you can obtain great stuff with green and blue, but it's difficult to match the right compliance with reds: you have to play alot with the variables in order to mach an uniform red, for example as background colour.
A pretty nice feature would be the automatic colour correction range, something that plays against the dithering itself, something that says:"every color between #xxxxxx and #yyyyyy belongs to be #$B2 (e.g.) in the very end".
|
|
Posted By
IstvanV
on 2008-04-05
06:49:30
| Re: plus4emu FLI converter
Do you mean color accuracy problems in high resolution modes ? That is a known issue with the algorithm used there, since it basically just does a greyscale conversion and then adds colors, so the luminance has a higher priority than color information. Multicolor FLI modes are implemented differently and are better in this respect, and also allow the user to adjust the relative importance of luminance vs. color. Or is it a different issue than what I was referring to ? Can you post an example that shows the problem ?
|
|
Posted By
Luca
on 2008-04-05
07:11:44
| Re: plus4emu FLI converter
Oh well, it's not a "problem" in the word's meaning.
Simply, I guessed it would be a quite fine feature, forcing a whole range of colours to be performed as one single +4 palette's colour.
I pointed out this is quite useful in case of red, a weak point for the system. Take as an example, a simple red screen: the converter will use dithering in order to match the exact RGB; instead of that, you could simply force it to be plain +4 palette red, avoiding dithering! We may have a complete list of these "brutal forcing", in a separated window:
- from #888888 to #A2A2A2 -> #$41 (midst gray)
- from ...
What do you think about?
|
|
Posted By
Patrick
on 2008-04-05
19:38:33
| Re: plus4emu FLI converter
guys, why i don't have a preview of the image after resizing and calculating? yes, the preview option is on! now i open an image resize it and save and check it out in yape. normal way to it?
|
|
Posted By
Luca
on 2008-04-05
20:09:56
| Re: plus4emu FLI converter
Did you use "PRG with viewer" as output format? Did the converter itself show the converted stuff once you performed the conversion?
|
|
Posted By
Patrick
on 2008-04-05
20:14:50
| Re: plus4emu FLI converter
yes, i used the "PRG with viewer" as output. the conveter didnt show the image after it did his work. i used yape for that...after converting-->save image--->view it in yape..
|
|
Posted By
IstvanV
on 2008-04-05
20:33:08
| Re: plus4emu FLI converter
Patrick: if the preview mode does not work, that means that you either have an old video card without OpenGL 2.0 shader support (which is required by the PAL emulation mode of plus4emu and p4fliconv), or plus4emu - which is needed for the Plus/4 ROM image files and configuration - is not installed. In the latter case, the preview would look like a crashed Plus/4 with garbage displayed. For the first case, I could try building an alternate version of the converter that is more compatible with old machines, at the expense of lower preview quality.
|
|
Posted By
IstvanV
on 2008-04-06
10:21:47
| Re: plus4emu FLI converter
Well, the code should actually have worked even without shader support, and fall back to lower quality, but in practice this was only functional in the emulator, and not the converter. I have a fix for this problem now, although vertical interlace is still not displayed correctly in the converter preview without shaders (there is a picture, but it is too bright). A new p4fliconv.7z file will be uploaded later today.
Luca: OK, I will add this color replacement feature in a later version. Although with the new "pixel exact" reading mode one could also create a pre-dithered image with the Plus/4 palette using an external image editor, the color range mapping might be useful anyway.
|
|
Posted By
IstvanV
on 2008-04-06
18:35:31
| Re: plus4emu FLI converter
The updated package is now uploaded. Other than fixing (mostly) the preview on old video hardware, there are a few minor changes: transparency in .gif and .xpm files is now implemented - transparent pixels are replaced with the border color, .xpm format support is improved somewhat, and the p4sconv utility has a new command line option to set the border color.
|
|
Posted By
IstvanV
on 2008-04-07
12:11:37
| Re: plus4emu FLI converter
Somewhat off-topic: here is a very simple utility that can create Plus/4 palettes in binary or text format, which can be used for example with DFliConv or Dr. Death's flinteractive: http://www.sharemation.com/IstvanV/plus4palette.zip
By default, it saves a palette that is identical to plus4emu in PAL mode with the default settings, but some parameters can be adjusted. For example, with these values, it would reproduce - not exactly, though, due to RGB clipping - the palette of p4fliconv with the default RGB range scale (-0.02 to 1.03) and no color correction: yMax=0.9714, yMin=0.019; this could be useful when comparing the various converters. Another example for an approximation of the YAPE 0.80 palette (some hues, particularly 'green' are different): yMax=0.9333, yMin=0, saturation=0.2133.
About the converter: would it be a good idea to add a link to it on the Tools page ? While it may still need some polishing, it could be already useful enough and has some features that are not in the two converters currently listed there.
|
|
Posted By
Degauss
on 2008-04-07
13:09:13
| Re: plus4emu FLI converter
I think this converter surely is developed enough for the tools page
|
|
Posted By
IstvanV
on 2008-04-09
18:39:15
| Re: plus4emu FLI converter
I have created a very simple example program that loads converted images from disk: http://www.sharemation.com/IstvanV/flitest/sample.d64. It is pretty lame, but does show reading and displaying files that were saved in the "raw compressed" format.
|
|
Posted By
Exin
on 2008-04-09
21:15:04
| Re: plus4emu FLI converter
Hi there.
I'm pretty frustrated by now. I really would like to create a picture for a multicolor charset. Interesting is, i load a monochrome (1bit) picture, but after converting, its always pretty grey scaled. Even if the picture dimension is 320x200 or 160x200.
Is there some workaround that i have missed? Anyways, would be lovely if a conversion to Charset would be integrated. (Generated characterset). I know, a software conversion to characterset would be extremely slow. But what the heck. I would even polish the charset with an editor.
With "Amount of characters to be used" please. 
...or at least a function, convert to monochrome (fore and background color) :D
|
|
Posted By
Exin
on 2008-04-09
21:17:30
| Re: plus4emu FLI converter
With scaled, i mean in grayscales. Sorry.
|
|
Posted By
Luca
on 2008-04-10
03:25:55
| Re: plus4emu FLI converter
Exin: Put your "Color Saturation" to 0 and you'll have monochrome.
|
|
Posted By
IstvanV
on 2008-04-10
06:32:41
| Re: plus4emu FLI converter
For conversion to a multicolor character set, you can use the "Logo Editor V2.0 multicolor" mode.
To get 1-bit monochrome black and white output, check "Use 1 bit (black and white) luminance" and set the color saturation multiplier to zero. For this type of conversion, you would probably want to use one of the diffuse dither types, with the limit parameter set to the maximum value.
For the problem of "greyscale output from monochrome input", there are two possible explanations: the new colors may be the result of interpolation (resizing the input image) or dithering. The latter can be avoided by selecting any of the diffuse dither types and setting the limit to zero. To avoid interpolation artifacts, resize the input image with an external image editor to a resolution that is twice that of the standard hires resolution (that is, 640x400 for a normal non-FLI graphics mode, both hires and multicolor), using no interpolation.
There is also a special "pixel exact" image reading mode in the latest version: if the image is in .xpm format, and uses the Plus/4 palette with at least 128 colors and no transparency (the colors do not need to match exactly - it can be a palette from any emulator, but the order within the palette must be correct with no colors missing), then interpolation and color correction are disabled, and the palette is internally replaced with that of the converter.
|
|
Posted By
IstvanV
on 2008-04-10
10:53:52
| Re: plus4emu FLI converter
I noticed that the converted images do not look exactly as they should on my real Plus/4, and made some tests to see if the luma table (which was calculated from the TED documentation, and is also used in YAPE) is correct.
The following table shows the luma levels taken from the TED documentation ("calculated"), as well as those from my real machine (the two "measured" rows, where S is based on the voltage on the S-video output, while C is the composite output, and "Digitized1" is based on a screenshot of the composite output), the "digitized" palette from YAPE (which is based on another real machine), and VICE, all normalized to the same range as in the documentation:
Black 0 1 2 3 4 5 6 7
Calculated: 2.000 2.400 2.550 2.700 2.900 3.300 3.600 4.100 4.800
Measured / S: 2.000 2.437 2.611 2.686 2.921 3.393 3.844 4.096 4.800
Measured / C: 2.000 2.434 2.608 2.681 2.916 3.388 3.840 4.093 4.800
Digitized1: 2.000 2.431 2.600 2.679 2.912 3.387 3.833 4.086 4.800
Digitized2: 2.000 2.419 2.608 2.661 2.881 3.332 3.814 4.087 4.800
VICE: 2.000 2.438 2.613 2.700 2.875 3.400 3.750 4.100 4.800
Note that level 5 in particular seems to be too dark (3.6, while all the others are at least 3.75), and it does actually make a visible difference. So, should I change the palette in the converter and emulator to match more closely the real machines ?
Another color issue: the "green" color has a phase angle of 230 degrees in the current version of YAPE, while it is 240 on my Plus/4 in PAL mode, and 244 in NTSC mode (after conversion to YUV colorspace). In the "digitized" palette of YAPE, it ranges from 236 to 240, and the TED documentation says it is 241 (which is also what I use in the emulator sources). Since the difference between 230 and 241 is visible, I wonder which one is actually correct ?
|
|
Posted By
Gaia
on 2008-04-11
06:48:06
| Re: plus4emu FLI converter
I used to measure different green and luminance values for different machines (I have like 10), I never had the time to figure out the exact reason. It seems there was really a difference between different TED chips as pointed out earlier by not other but Exin himself I guess (at least for the luminance).
And how did you measure? Just because the TED docs have these as luma levels, which are the actual TED pin voltages, while what you're probably measuring on the S-Video output is a not-entirely-linearly transformed luminance signal that went thru some analogue circuitry (this alone could make machine luminances to be different). I used to have a correction for this in Yape, but it turned out to be more confusing than convincing.
|
|
Posted By
IstvanV
on 2008-04-11
09:26:44
| Re: plus4emu FLI converter
Yes, the values shown above are calculated from the voltages measured on the composite and luma outputs. These seem to be fairly consistent with those based on screenshots of the composite output (the largest difference from the measured composite values is 0.008, or about 0.29% of the total range). However, if there is any non-linearity in the video output, that should probably be emulated too, just like in the case of sound.
What would be most useful is to have access to more data from real machines, so any good quality screenshots of measurements are welcome.
In any case, the difference is quite large in the case of the level 5, so it may very well be an error in the documentation, just like the 'dark blue' hue for PAL. I will probably change that to 3.75, but I may also consider using the table from VICE, since it is apparently quite close to my machine.
|
|
Posted By
IstvanV
on 2008-04-11
09:28:30
| Re: plus4emu FLI converter
Sorry, I meant screenshots or measurements, not screenshots of measurements
|
|
Posted By
Gaia
on 2008-04-11
10:37:15
| Re: plus4emu FLI converter
If I recall correctly, the non-linearity was particularly present in the brighter range in there. The luma signal from the TED goes thru an R/F modulator with some resistor network. I know there were several versions of R/F modulators not just TED chips, maybe even the resistor values are different...
See:
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/plus4/manual/p4-11.gif
|
|
Posted By
IstvanV
on 2008-04-11
12:31:36
| Re: plus4emu FLI converter
It may add some non-linearity, depending also on the characteristics of the TED output, although level 2, 3, and 6 seem to be fairly accurate and consistent, and only 5 differs by a relatively large amount. Of course, it would be possible to test the TED output directly, however, I suspect that it would still not match the documentation. As I mentioned earlier, the most useful information would be data from many different machines.
By the way, the values in the VICE source code seem to make the same assumption as the pepto.de C64 palette, by dividing the black-white range into 32 equal steps, and choosing levels only from those. Although the results seem to be surprisingly similar to what I measured, I do not know why this restriction would actually exist in the hardware, and of course it ignores the possibility for any non-linearity.
|
|
|
|
Posted By
Luca
on 2008-04-12
10:29:35
| Re: plus4emu FLI converter
Test hardware: Plus/4 PAL, Commodore 1802.
real machine's "colortest_1.prg":
- YAPE (calculated): mediocre, white looks darker, and the gradient is too smooth, whereas in the real machine there's a difference in luma around LUM4;
- YAPE (digitized): very good for lighter greys, a bit worse for darker greys, which appear too smooth in their transition;
- plus4emu (video default): halfaway between YAPE digi and YAPE calc
real machine's "colortest_2.prg":
- YAPE (calculated): quite bad, because YAPE makes it appear extremely smooth;
- YAPE (digitized): good, especially in the midst LUMA greys;
- plus4emu (video default): very bad, especially the "central light column" displayed by the emu.
|
|
Posted By
IstvanV
on 2008-04-12
11:31:26
| Re: plus4emu FLI converter
So, how does it look on your real machine ? I have already seen the images in emulators Or did you mean comparing the real machine to emulators, and found "YAPE digitized" to be most similar ? If that is the case, then I will probably change the palette, since my real machine is also closer to the "digitized" than to the "calculated" palette (see table above).
By the way, colortest_1.prg was generated with the "calculated" palette, and should look as expected (i.e. a smooth linear gradient) with the default plus4emu - use software mode or the highest quality, otherwise the color depth is reduced to 16 bits - or YAPE palette. For colortest_2.prg, I modified the table as follows:
2.00 2.42 2.60 2.70 2.90 3.33 3.75 4.10 4.80
|
|
|
|
Posted By
Luca
on 2008-04-12
12:57:03
| Re: plus4emu FLI converter
Uh...yes I compared'em with the real machine, I guessed you directly asked for that
|
|
Posted By
IstvanV
on 2008-04-12
13:14:13
| Re: plus4emu FLI converter
OK, sorry for the confusion. So, if I understood correctly then, you found that using YAPE with the digitized palette is closer to the real machine ?
|
|
Posted By
Luca
on 2008-04-12
13:47:11
| Re: plus4emu FLI converter
Yes, not a perfectly fitting one, but closer than others for sure.
|
|
Posted By
Gaia
on 2008-04-12
17:09:19
| Re: plus4emu FLI converter
I checked my sources and I used to have these luma values at one point for the calculated palette:
2.00, 2.4, 2.55, 2.7, 2.9, 3.3, 3.9, 4.3, 4.9
The 4.3 was too bright probably anyway but the 3.9 is close I think. In the end I got sort of fed up with comparing and reverted back to the docs
|
|
Posted By
Exin
on 2008-04-13
22:38:56
| Re: plus4emu FLI converter
Thanks for all the info!
|
|
Posted By
Exin
on 2008-04-17
16:45:55
| Re: plus4emu FLI converter
Anyways, i was looking for a tool that converts to a fullscreen character screen with a modified charset....
|
|
|
|
Posted By
IstvanV
on 2008-04-19
12:57:39
| Re: plus4emu FLI converter
For testing the palette changes, I have uploaded an emulator executable that uses the modified luma table: http://www.sharemation.com/IstvanV/plus4emu.exe.7z. You can try running the previously posted example programs to see if this version is more consistent with real machines than the original one.
|
|
Posted By
Luca
on 2008-04-19
13:40:01
| Re: plus4emu FLI converter
Tested!
Yes the new palette's colors are very close to the real ones. Their Achilles'Heel is the darker greys: on the real machine you can cleary see a luminance level between two greys in which the whole matter changes radically.
All the rest is very good, especially the "asymmetric video stripes" (one lighter, the mirror opposite one darker) you can see in colortest_2.prg.
Looking forward to the pixel perfect converter feature, I've just chosen some Atari800 pics as specimen ;)
|
|
Posted By
IstvanV
on 2008-04-19
14:20:49
| Re: plus4emu FLI converter
Are the dark greys worse than in the previous version, or better, but still not enough ? How do the screenshots I posted compare to the picture on your machine ?
|
|
Posted By
Luca
on 2008-04-19
15:57:01
| Re: plus4emu FLI converter
The darker greys are better than before, but the difference between LUM4 and LUM3 seems to be very accentuate on the real machine, and not so smooth as the emulation shows.
Weird, your example jpg are smooth too, unlike my Commodore 1802 monitor's output with average contrast set.
Moreover, the emulator "greys" look as tending to a slight purple-grey, instead of plain grey...
The best would be a photo or something...
|
|
Posted By
IstvanV
on 2008-04-19
19:21:05
| Re: plus4emu FLI converter
Well, for now, I updated the converter to use the same modified palette: http://www.sharemation.com/IstvanV/p4fliconv.7z
This version also includes some optimizations in the FLI display code (p4flidisp.s), slightly better support for "pixel exact" conversion in high resolution modes when "optimize for PAL filtering" is disabled, and some other minor changes. Note that the monitor gamma parameter is now interpreted differently, and the default and recommended value is 2.2 (the previous default 1.33 would not look very good now).
|
|
Posted By
Luca
on 2008-04-20
07:27:48
| Re: plus4emu FLI converter
Uhmmm...how to activate the pixel exact feature?
|
|
Posted By
IstvanV
on 2008-04-20
08:51:29
| Re: plus4emu FLI converter
The input file should be in .xpm format, and have a palette that looks similar to the Plus/4 palette, with at least 128 colors and no transparency. Here is a simple example file: http://www.sharemation.com/IstvanV/flitest/test.xpm
Try converting it in high resolution non-interlaced FLI mode; notice that the result is not accurate if "optimize for PAL color filtering" is enabled, so it should be turned off for this type of conversion (older versions were not correct in either mode).
The no transparency limitation could be eliminated (in fact, I have intended to that already, just forgot about it), but the restriction to .xpm format is because the library I use for reading images only preserves the colormap of this format, all others are either converted to RGB or unused colors are removed.
|
|
Posted By
Luca
on 2008-04-20
10:52:06
| Re: plus4emu FLI converter
Ok, I converted an Atari800 pic in a 320x200 .xpm with a 256 (2*128) Photoshop plus/4 palette. Once switched off the PAL optimizing feature, I itred to convert (in MCM of course), but I failed, probably due to the differencies between my palette in *.act format and yours. Apropos, may I have your palette in .act?
|
|
Posted By
IstvanV
on 2008-04-20
11:17:08
| Re: plus4emu FLI converter
The palette should not really matter, unless it is very different so that the picture is not recognized as having a Plus/4 palette. But it would be easier to find out what the problem is if you posted the xpm file.
The PAL optimization trick - and most other "advanced" parameters with the exception of 1-bit luminance, and MC color error scale - is only used in hires modes.
|
|
Posted By
IstvanV
on 2008-04-20
11:54:10
| Re: plus4emu FLI converter
For creating .act palettes, you can use the plus4palette utility that I posted earlier (it is updated to be consistent with the emulator changes). However, accurate color matching without using xpm files is somewhat problematic, since very dark and very light colors are clipped in the RGB colorspace, and the converter would assume incorrect hue for those colors (e.g. $79 instead of $78) unless a low contrast palette is used and the conversion settings are adjusted accordingly.
|
|
Posted By
Luca
on 2008-04-20
12:37:10
| Re: plus4emu FLI converter
Argh! plus4palette.exe produces an .act file which refuses to load into Photoshop
|
|
Posted By
IstvanV
on 2008-04-20
13:11:59
| Re: plus4emu FLI converter
Perhaps because the file only contains 128 colors, rather than 256 ? I have replaced plus4palette.zip with a modified version that writes a 256 color (768 bytes) palette if binary format is selected.
However, I am not sure if different palettes are the reason why you have problems with converting .xpm files (the converter should accept palettes that are only similar to trigger the pixel exact reading mode, as long as all colors are at the correct index, for example 113 is white etc.); could you post an example that does not work as expected ?
|
|
Posted By
Luca
on 2008-04-21
10:22:32
| Re: plus4emu FLI converter
Yes, true: tried the correct palette, and nothing has changed
This is what I tried to perform: I downloaded the winner picture in the Atari gfx compo at Forever 9 party, Neptune's Daughter drawn by Powrooz/Laresistance; then I cutted it 320x200, I assigned my plus/4 palette, then saved as .bmp, converted to .xpm. At this point, I tried to convert it to a regular Plus/4 MCM pic, but this process hasn't performed a pixel exact conversion, due to several dithering workarounds, as if the colours have to be adjusted. Hence, I reduced both dithering values to zero, but the resulting pic was awful and no pixel exact conversion has been performed for the second time.
|
|
Posted By
IstvanV
on 2008-04-21
12:05:49
| Re: plus4emu FLI converter
Try converting this file: http://www.sharemation.com/IstvanV/flitest/f9_neptuned.xpm
Notice that this image is not resized to match the window size exactly in the non-preview mode, and color correction settings are ignored.
If you have problems creating xpm files that are recognized as having the Plus/4 palette, then probably the files are saved with an "optimized" palette that includes only the colors that are actually used, or have a transparent color; in any case, the pixel exact mode is only activated if every palette index in the image can be used directly as a Plus/4 color code.
This alternate image in PNG format is only resized to 640x400 with no interpolation so that image scaling artifacts are avoided: http://www.sharemation.com/IstvanV/flitest/f9_neptuned_640x400.png. It is still converted with color correction and dithering.
|
|
Posted By
Luca
on 2008-04-21
13:25:35
| Re: plus4emu FLI converter
Hence, probably I'd been quite unlucky, choosing this converter.
I'd chosen no transparent color, and this lets me think about an automatic palette stretching by this program...
I've also chosen a strange target picture: it seems to be 288x208, instead of 320x192 as I expected...
|
|
Posted By
IstvanV
on 2008-04-21
13:58:41
| Re: plus4emu FLI converter
I tried the XPMConvert utility, and it does indeed reduce the palette to 18 colors, and I did not find a way to disable this feature. The file I posted above was created with the GIMP; loading an indexed mode .bmp file with it and then simply saving it as .xpm seems to preserve the original palette, although I also used the GIMP to convert the image to the Plus/4 palette. There are probably other utilities that would work, too.
I could also build the converter with a modified version of the FLTK library that does not "optimize" the palette of .gif files (which is the reason why the only format that currently works for pixel exact image reading is .xpm).
|
|
Posted By
Luca
on 2008-04-21
14:17:29
| Re: plus4emu FLI converter
Eh, yeah, must admit, .xpm is not the most usual format in the world...
|
|
Posted By
IstvanV
on 2008-04-21
18:57:49
| Re: plus4emu FLI converter
OK, I have replaced the p4fliconv.7z package with a new version that includes the GIF palette patch. It should hopefully also improve support for transparency.
|
|
Posted By
Luca
on 2008-04-22
09:02:53
| Re: plus4emu FLI converter
Arrrgh, I failed again! 
How to obtain the pixel exact result with a .gif?
|
|
Posted By
IstvanV
on 2008-04-22
10:26:56
| Re: plus4emu FLI converter
Is it possible that the file was saved with the unused entries removed from the palette again ? Also, I only tested transparency with .xpm files before uploading; in the case of .gif, it is still possible to use transparency (for example http://www.sharemation.com/IstvanV/flitest/F7_wally.gif), but it can be tricky depending on which palette index is used as the transparent color. So, unless you really need transparency, it is best avoided when using .gif files.
|
|
Posted By
Luca
on 2008-04-22
10:41:43
| Re: plus4emu FLI converter
Oooh, finally I did by .gif, probably because ACDSee saved a wrong palette for.gif. I tested the 320x200 cutted neptune's daughter and the result is very good, apart some wrong particulars, maybe caused by the machines'differencies in colour attributions once you change the real screen display by cutting sides.
|
|
Posted By
Luca
on 2008-04-22
13:37:26
| Re: plus4emu FLI converter
Aaaah fantastic! I've found the ultimate employment for the pixel exact feature: the hires conversion is fantastic! As a test, I tried to convert the best and most complex ZX Spectrum pictures, all 100% succeded!
OT: I didn't spot out the Atari's graphic mode used for Neptune's Daughter, probably they changed the video mode from 40x24 to 36x26...
|
|
Posted By
IstvanV
on 2008-04-22
17:03:07
| Re: plus4emu FLI converter
Yes, these look good; since the Spectrum is limited to 2 colors per 8x8 cell, a lossless conversion should be possible (other than the colors being somewhat different). The Atari pictures are more difficult, and even in FLI modes there may be a small amount of error depending on the source image; perhaps it could be made lossless with a higher limit for the multicolor quality setting, but I am not sure.
|
|
Posted By
IstvanV
on 2008-04-23
17:14:08
| Re: plus4emu FLI converter
Dr. Death: well, it would be probably easier to find there for those who do not follow the forum threads. It could also be mentioned at the plus4emu page, rather than being listed as a separate tool, although the version included with the emulator is somewhat outdated (maybe it would be time to get working on a new emulator release ).
|
|
Posted By
Exin
on 2008-06-04
08:32:06
| Re: plus4emu FLI converter
Seems the source is gone. Can someone post another source for the converter please?
|
|
Posted By
IstvanV
on 2008-06-04
09:03:41
| Re: plus4emu FLI converter
The converter and related utilities are included with the latest version of plus4emu at http://sourceforge.net/project/showfiles.php?group_id=192837&package_id=226942&release_id=601490, as mentioned in the announcement. I use the sharemation.com site for temporary storage only, since it has a quota of 5 MB space, and 5 MB can be downloaded per 3 hours.
The "i686" build is slower, but runs on older machines, while the "pentium4" one uses SSE and SSE2 instructions for better performance (like p4fliconv_sse.exe in the previous downloads).
There are no converter changes since the last "beta" download, though (I do plan to implement better hires conversion eventually).
|
|
Posted By
IstvanV
on 2008-06-15
13:32:40
| Re: plus4emu FLI converter
Well, this is probably not really of much interest, but I have an improved version of the compress utility: http://www.sharemation.com/IstvanV/compress.zip
Regarding the converter: other than the above mentioned new high resolution algorithm, I could add support for "pixel exact" reading of images that use a C64 pallette (to allow for converting VICE screenshots directly); would that be useful ?
|
|
Posted By
Luca
on 2008-06-15
13:49:00
| Re: plus4emu FLI converter
Yeah why not? Direct conversion from a 320x200 .gif with no palette dithering correction! But beware, coz any c64 emulator produces its own palette's gif output!
|
|
Posted By
IstvanV
on 2008-06-16
12:10:19
| Re: plus4emu FLI converter
Here is a simple test of the above compressor utility with a few demos and games (the results are self-extracting PRG file size | time to decompress), and for comparison, results from other programs are also included. Note that the pucrunch'd version of Thalassa does not work.
Original Compressed Exomizer PuCrunch
----------------------------------------------------------------------
Heartfixer 95% 25961 15720|2.95 16053|3.04 16559|2.78
Icicle Works 30977 14188|3.04 14078|3.50 14912|2.68
Mercenary 60673 32984|6.88 34144|8.48 34722|5.96
Monopsy 2 60642 35121|6.80 35109|3.09 35824|5.79
Thalassa 60649 20308|4.55 21244|5.43 20993|4.11*
Threeve 60673 45289|8.52 45251|3.18 46167|7.13
Trailblazer Plus 23041 8167|1.79 8031|2.30 8538|1.65
Treasure Island 28595 10788|2.34 10727|2.99 11135|2.12
We are the Cure 53182 14758|3.40 15922|3.95 15476|3.10
XeO3 59633 18706|4.24 19067|4.77 19403|3.80
Zenith of Puberty 60448 33812|6.30 35326|6.35 35983|6.12
----------------------------------------------------------------------
Decompressor size ~680 ~280 ~360
|
|
Posted By
IstvanV
on 2008-06-17
10:25:25
| Re: plus4emu FLI converter
Luca: of course, some amount of variation in the palette should be allowed (like it already is in the case of .gif's using the Plus/4 palette). I will probably just use the VICE palette as reference, and detect any colormapped image as having the C64 palette if there are exactly 16 colors and the difference from the VICE palette is not too large.
|
|
Posted By
IstvanV
on 2008-06-24
09:02:39
| Re: plus4emu FLI converter
OK, the C64 palette detection is added. However, it seems I will not add the new hires conversion algorithm, as it is not really better than the old one in practice.
|
|
Posted By
Luca
on 2008-06-24
16:09:39
| Re: plus4emu FLI converter
To be added in 1.2.6.2?
|
|
Posted By
IstvanV
on 2008-06-24
16:18:04
| Re: plus4emu FLI converter
Well, I could release that soon, if no important changes are left to be made.
|
|
Posted By
IstvanV
on 2008-07-08
08:12:28
| Re: plus4emu FLI converter
Any opinions on the updated utilities ?
|
|
Posted By
MMS
on 2008-07-08
15:34:28
 | Re: plus4emu FLI converter
FIRST OF ALL: CONGRATULATION for the Converter !!! Fantastic!!!!
Well, I tried out the FLI modes, and I am really impressed. Although I think the simple Multicolor mode is not used till it's limits on PLUS/4, excpet few examples.
I believe the "conversion" is a very good starting point, but finetuning is REALLY needed on most of the cases. The wise preadjustment of the original picture for the converter is more than welcomed to get the best results, I have some tricks I won't share )
As I like to hand-draw the converted picture, I conveted to Multicolor, and finetuned with Multibotticelli.
I spend ~30 minutes on JPG-optimization/preadjustment, 1 hour on the best setting during conversion, and almost 10 hours to finetune the picture to it's current state.
Far from the perfect, but I have to stop somewhere, as this picture would be only the first of a 6-7 pieces of collection on ConceptCars. I hope you like it... I will look for a coder in 2-3 months to put these pictures into some demo, juts FYI )
By the way, it looks better with video display emulation, the colors are better mathing to the original.
Converted (work in progress):
http://img2.tar.hu/mmszoli/img/35345353.gif#3
Original:
http://kep.tar.hu/mmszoli/50589723/35345781#2
I should highlight, that this is the BEST CONVERTER I have ever seen for Plus/4, and the preview function is great to see the differences of different shading methods, settings. I made some trials in the past with ConGo, Project one and other converters, but witha lame starting result, took months to finish, especially because they did not know the PLUS/4 palette, and I was too lazy to create a modified program for this.
In fact I realized now (on emulator), how BAD is the PLUS/4 palette on the orange, red and yellow colors. They are not vivid at all, the yelow is a light brown, red is almost pink. Orange is not hars at all. I do remember on my first picture (Lotus espirit) I suffered on the Red color too, and it was on a real C16, so i am almost sure the converters and monitor show similar colors now. Yeah, I could be happier with more intensive colors, and if the black would have also 8 shades, and would continue in the white's brighter 8 shades... Then Plus/4 could do great B/W digitized pictures in 16 shades, best in 8 bit...
huh, an other silliness in the design of this great machine...
|
|
Posted By
MMS
on 2008-07-08
16:27:45
| Re: plus4emu FLI converter
Back to LUCA's past comment on dithering and color matching: i have a damn good picture with a flower and a ladybug. the complete background has 2 shades of green, flat colors. BUT the converter -because it did not math to any PLUS/4 color EXACTLY, made a dithering.
In fact I started to write a converter months ago, but gave up to lack of time. My original concepr was that I will create a routing, which generates a "globes" around the single plus/4 colors in the 3D color-map, with a defined radius (it can be a setting). If the color on the original JPG/GIF file is within that "globe", than it became that speicfic color. Otherwise dithering is needed between the two closest color. With big enough radius the complete color map could be covered. I used this idea instead of the method LUCA said below, because the sperad of the colors in PLUS/4 is moved to the blue/green area (more color details in that spectrum), and would be hard to specify same radius for each color.
If you want, I upload the mentioned original picture and the conerted one, to get what I mean, and how I modified it with Multibotticelli to look better (do not have that "converted picture" feeling)
I hope you got the idea, and it is not bullshit
|
|
Posted By
IstvanV
on 2008-07-08
16:42:11
| Re: plus4emu FLI converter
The converter optimizes the picture for the plus4emu palette (in PAL mode), and the preview is also based on the same emulator (with full display emulation quality). Since you seem to be using YAPE, I recommend the "digitized" colors, which are slightly closer to my palette than the "calculated" ones.
The Plus/4 palette indeed does not allow for changing the saturation, and the single fixed saturation is lower for colors on the V axis than for U, relative to the maximum possible value, and this is most visible in the case of red.
For getting the best results in multicolor mode, I recommend using the Floyd-Steinberg dithering mode instead of the default ordered dither with randomization, and it may be useful to experiment with the 'MC chrominance error scale' parameter, and also 'Multicolor quality' (note that sometimes a lower quality will produce a better looking image, despite the worse error value). Small changes to the scaling and offset can also make a significant difference due to how the details of the image are aligned with the 4x8 character cells.
I think the best mode overall (assuming that file size does not matter) is interlaced multicolor FLI, although it requires some experimenting with dither modes. The hires FLI modes can be very good for some specific images, though, but not for some others.
|
|
Posted By
MMS
on 2008-07-08
16:42:13
| Re: plus4emu FLI converter
I made a try on the Neptune with my preadjustments and settings, and it is not SO bad... OK, not as sharp as the original one, and some colors did not exactly match, but the lady is nice, just with the converter itself. With Multiboticelli it could be dmade to be perfect.
http://img2.tar.hu/mmszoli/img/35347113.gif#3
|
|
Posted By
IstvanV
on 2008-07-08
16:52:06
| Re: plus4emu FLI converter
Note: my previous post was in response to the one from 15:34:28, and not the newer message
By the way, have you tried using the "pixel exact" image reading ? This would allow for avoiding the dither, and converting a .gif image that already uses the Plus/4 palette (with the colors in the exact same order, and preferably no transparency - this way, the converter should recognize that it is indeed using the Plus/4 palette, even if it is from different emulators) to multicolor mode with the least possible error.
In fact, there have been some conversions of "Neptune's daughter" in this topic earlier, and I think I still have the files somewhere.
|
|
|
|
Posted By
IstvanV
on 2008-07-08
18:06:00
| Re: plus4emu FLI converter
More on dithering: you may try using lower 'Dither limit' and/or 'Dither diffusion parameter' values to avoid dithering colors that are "almost" the same as a Plus/4 color, and also changing brightness/contrast/gamma slightly can help adjusting large uniformly colored "background" areas closer to a Plus/4 color so that the dither reduction can be effective.
|
|
Posted By
MMS
on 2008-07-09
04:43:49
| Re: plus4emu FLI converter
Yeah, I already played a lot with the settings. To reduce the dithering to minimum is the 0.02 parameter looks OK, pixel-exact is the 0.000.
In fact the Jarvis dithering was the best for those cars I tried till now, and with max (30) multicolor value. I could play a lot with the setting on hue and the search method. Anyhow, it is a gret tool, and thanks for your useful comments and this fantastic tool!
It makes my work much faster, saving dozens of hours for me on each picture (I am not a superfast graphician, eg. I worked >50hours on the ball graphics you can find under my profile. There are much faster graphicians outside ).
I believe there are so many great arts, wallpapers, etc, that it makes no real sense to start everything from the roots, anyhow I am not an artist who expresses himself in the graphics, but a graphician want to make the best graph ever
|
|
Posted By
MMS
on 2008-07-09
05:20:08
| Re: plus4emu FLI converter
Yeah, do not take the Yape wrong, I do use yours too!
Just because YAPE was fist on my PC, this is the default program, when I doubleclick on the Multibotticelli.prg. Your emulator eg. shows much more exactly the FLI pictures.
By the way, only on the Emulators the FLIs "jumping/wobbling", or on the original PLUS/4 also?
|
|
Posted By
IstvanV
on 2008-07-09
07:35:11
| Re: plus4emu FLI converter
> I could play a lot with the setting on hue and the search method.
Actually, those only affect the hires modes. For multicolor, the settings that do have any effect are all those that are on the first page (but Vertical resolution and X shift are for FLI modes only), and Use 1 bit luminance and MC chrominance error scale from the second page, as well as the C64 palette when reading .koa or .ocp files. The other 'advanced' settings are used only by the hires conversion.
On the other hand, hires modes ignore the "multicolor" parameters, unless the MinRMSErr_YUV_Downsampled search mode is set. The luminance/color interlace settings are used only by "Interlaced hires FLI", but not in the above mentioned search mode.
Perhaps I should write detailed documentation to explain the various options, as some of them may not be very intuitive, but it could also be a good idea to change the GUI to make options that have no effect in a particular mode inactive/"greyed out".
> Your emulator eg. shows much more exactly the FLI pictures.
Which is expected since the converter uses plus4emu for displaying the preview (you can also see a BASIC screen if you click preview while there is no image loaded ), and the palette is also the same.
> By the way, only on the Emulators the FLIs "jumping/wobbling", or on the original PLUS/4 also?
Do you mean the flickering effect in interlaced modes ? That is normal, since interlace works by showing two alternating pictures with one being offset horizontally (multicolor) or vertically (hires) by a half pixel for virtually doubled resolution. Interlacing can make the selection of dither mode tricky sometimes, since the dither patterns can degrade to ugly flickering artifacts (particularly Floyd-Steinberg in interlaced multicolor FLI).
However, the flickering may be worse in emulators, since the monitor refresh rate is usually not an integer multiple of the Plus/4 vertical refresh rate (49.86 Hz), resulting in uneven/jittery flickering. In plus4emu, there is a special "resample to monitor refresh rate" mode that can be used to make the display of demos much smoother, but this is not recommended for other usage like programming, since it adds latency to the video display, makes the controls laggy, and increases the CPU usage.
|
|
Posted By
MMS
on 2008-07-09
08:05:54
| Re: plus4emu FLI converter
Hi,
Thanks for the comments.
You wrote the program, so you know better
Yeah, I know the basics of FLI technics (theoretically, not to program any ), and was really shocked some years ago, how many colors they could should virtually on a C64, and started to think about the possibilities on PLUS/4. But as there were no easily useable converters knowing PLUS/4 palette, and not to speak about the editing possibilities afterwards, I still stick to normal multicolor. Yeah, and on the forum here some guys mentioned, that they do not like those flickering pictures (although the details I can see in thois way are really impressive...)
My question was, if this flickering is similar strong on the real HW with TV/C=Monitor, or better? Since FLI introduced, I had no chance to check it on a real commodore PLUS/4.
I can image, that due to the speed of the electronics in the real commodore the TV screen can show only much more speared, thus more plastic, and less vibrating picture.
Even more, does the PLUS/4 flickers MORE than the C64, or HW point of view the possibilies are similar? I suppose the viewers are based on similar free-source, or convertered programs ()but I could be wrong here too).
Again, thanks for your time!
|
|
Posted By
IstvanV
on 2008-07-09
08:56:28
| Re: plus4emu FLI converter
There are actually a few other converters for the Plus/4: P4PC FLI Converter by Larry (this is a Java GUI application that can convert to hires FLI), DFliConv by Bubis (a Java command line converter that supports several video modes), and Dr. Death's http://www.jache.de/download/flinteractive_preview.zip, which is not released yet, but is already a quite good converter for 304x264 interlaced multicolor FLI.
While the possibilities for FLI editing are rather limited indeed, you can try FED (a simple DOS program for editing 160x200 multicolor FLI - p4fliconv supports its file format, but you need to set the X shift to zero and the vertical resolution to 200), or PixelShop which can also edit FLI images in a somewhat limited/buggy way (only the pixels can be changed, but not the colors); like in the case of FED, the FLI mode must be non-interlaced, X shift should be zero, but the vertical size is not required to be 200. Finally, there is FLI Editor by TLC: this is a native Plus/4 program, and seems to be fairly good, but its file format is not supported by converters.
The flickering in interlaced modes is generally not as bad on a real TV or monitor, as there is no jitter, although in plus4emu or the converter preview the motion blur effect may reduce the intensity of flickering. On the other hand, it does look worse than the 'resample to monitor refresh rate' mode that removes jitter and at the same time adds some motion blur as a side-effect.
|
|
Posted By
IstvanV
on 2008-07-18
12:49:40
| Re: plus4emu FLI converter
An update to the compression benchmarks: I have created a modified version of the compress utility that does not use Huffman coding. While this uses a fairly simple format, the results are actually still quite good for some files, and the decompress code is smaller and faster (see also the older table above for comparison):
Original Slow Fast
----------------------------------------------------------------------
Heartfixer 95% 25961 15708|2.95 16196|2.26
Icicle Works 30977 14176|3.04 14736|2.26
Mercenary 60673 32972|6.88 34266|5.02
Monopsy 2 60642 35109|6.80 35209|4.51
Thalassa 60649 20296|4.55 20555|3.31
Threeve 60673 45277|8.52 45495|5.53
Trailblazer Plus 23041 8155|1.79 8313|1.33
Treasure Island 28595 10776|2.34 11055|1.76
We are the Cure 53182 14746|3.40 15332|2.53
XeO3 59633 18694|4.24 19134|3.10
Zenith of Puberty 60448 33800|6.30 35585|5.05
----------------------------------------------------------------------
Decompressor size ~670 414
|
|
Posted By
Degauss
on 2008-07-22
01:11:38
| Re: plus4emu FLI converter
Have to try this one... Amazing results
|
|
Posted By
Chronos
on 2008-07-22
05:44:28
| Re: plus4emu FLI converter
its breaking the habits ( ) but im using conversion vice-versa. so i made something on pc (and sometimes on plain paper and need to scan it fast), convert it to plusi, and capture from yape, fix it in paint shop pro, apply plusi palette and convert back to plus4, because there is a lot of time saving stuff in paint shop pro... i cannot set the correct values in istvan's converter (mainly using simple multicolor) and prefer yet dfliconv for this process... but if there is a way to do it fast for a lazy graphician like me any help appreciated... the other thing comes in my mind, please update the download link for your compressor, i want it badly or if u give me permission, i want it to use in our products..
|
|
Posted By
IstvanV
on 2008-07-22
09:53:00
| Re: plus4emu FLI converter
Chronos: do you mean editing the converted image in Paint Shop Pro, and then converting it again ? For this purpose, you may want to use the "pixel exact" image reading mode of p4fliconv; this means that you should save the image to be (re-)converted with a Plus/4 palette in .GIF format, preferably with a size of 320x200 for simple multicolor mode. You can see that the image was actually read in the pixel exact mode from the fact that it is not scaled to the full window size, and it is also loaded much faster.
While the converter uses the plus4emu palette internally, it does allow for some differences and still recognize the GIF file as having the Plus/4 palette; so, VICE and YAPE screenshots would still work if you use those for some reason. However, it is important that all colors are present in the palette - it should not be "optimized" by removing the unused colors, and non-Plus/4 extra colors should not be added, either - at the correct index (so that color #113 is white etc.), and transparency should be avoided too, as it can also change the ordering of colors.
In this mode, all color correction (brightness, gamma, etc.) settings are ignored, but you can still adjust the "multicolor quality" and "MC chrominance error" parameters to fine-tune the conversion.
The current "slow" version of the compressor that uses Huffman coding is actually included with plus4emu as 'compress.exe' in the top level installation directory, and the compressed PRG formats of p4fliconv also use the same type of compression. You can also find the assembler sources of the decompressor and the FLI viewer in src\util\p4fliconv:
decompress_sfx.s - self-extracting decompressor
decompress.s - for use in demos etc.
p4flidisp.s - viewer for FLI images saved as "raw" PRG files by p4fliconv
All the above files can be compiled with CA65, and can be used freely for any purpose without restrictions. Note that the decompress sources include some compile time flags at the top of the file that can be used to make the code slightly smaller and faster. If you still have one of the older p4fliconv.7z packages, you may find a sample program that loads images from a set of compressed files on a disk.
The list of command line flags for the compressor can be printed with the --help option, but here are a few examples of basic usage:
Compress: compress -8 -start x1015 -fastsfx -nocleanup xeo3.prg xeo3_compressed.prg
Test compressed file: compress -t xeo3_compressed.prg
Extract compressed file: compress -x xeo3_compressed.prg xeo3_uncompressed.prg
The "fast" version is not released yet, as it still needs some experimenting to see if it can be improved.
|
|
Posted By
Chronos
on 2008-07-22
10:24:30
| Re: plus4emu FLI converter
thanks for explanation of things.. it points to what blind i'am.. the compressor is in the front of me already i'll test the things soon..
an exact example for this vice-versa conversion is our never ending bomber project.. there was several times i made something and then dcd told me "its good but i prefer it in blue (when it was red for example) and not there rather here.. coloring and moving objects in m.botticelli is not easy and frustrating sometimes..
on the other hand, the icon project parked, but not forgotten.. i just not satisfied with the results.. i choose other techniques than before (yape) and it was a mistake maybe (?!)
|
|
Posted By
IstvanV
on 2008-07-22
13:36:08
| Re: plus4emu FLI converter
More on the compress utility: the version in the 1.2.8 emulator package includes some minor bug fixes and decompressor size optimizations.
|
|
Posted By
Chronos
on 2008-07-22
15:41:11
| Re: plus4emu FLI converter
hehe i was lame..again! on my home computer i used the 1.2.5 version, and therefore i missed a lot of new functions..
|
|
Posted By
MMS
on 2008-07-24
15:19:54
| Re: plus4emu FLI converter
Never mind, Istill use 1.2.6 So far so good
By the way, even Arnord "Conan" is well recognizable after a simple multicolor conversion, without touching it. If you familiar enoug with the tool, and can spend 1-2 hours on a specific picture, it could really give great results. (I wish I have better oranges and reds on Plus/4, for skintones, phhhh)
|
|
Posted By
IstvanV
on 2008-07-29
19:24:05
| Re: plus4emu FLI converter
Chronos: some new results with the same files. These can be compared with the previous tables; the times are with blanked display. Original Compressed
-------------------------------------------
Heartfixer 95% 25961 15589|2.17
Icicle Works 30977 14142|2.65
Mercenary 60673 32711|5.73
Monopsy 2 60642 34785|2.69
Thalassa 60649 19878|3.86
Threeve 60673 45267|2.63
Trailblazer Plus 23041 7983|1.59
Treasure Island 28595 10686|2.06
We are the Cure 53182 14633|2.80
XeO3 59633 18479|3.48
Zenith of Puberty 60448 34185|4.65
-------------------------------------------
Decompressor size ~480
|
|
Posted By
IstvanV
on 2008-08-01
12:38:56
| Re: plus4emu FLI converter
So, is any of the above modified (faster) versions useful and worth releasing ?
|
|
Posted By
IstvanV
on 2008-08-02
17:08:43
| Re: plus4emu FLI converter
Well, I assume it can be safely deleted then.
|
|
Posted By
siz
on 2008-08-03
10:14:04
| Re: plus4emu FLI converter
István, don't be so impatient. As you can see the visits are not so frequent here so probably most of the people did not even see you question.
Speaking for myself: I did not have the time to check your tool or even do anything plus/4 related.
|
|
Posted By
IstvanV
on 2008-08-09
16:21:24
| Re: plus4emu FLI converter
OK, it is not deleted yet, so if someone wants to use it, it could be released.
|
|
Posted By
Csabo
on 2008-08-09
16:31:01
| Re: plus4emu FLI converter
I have an idea related to the compression utility. Let's write a meta-tool that takes a .PRG file as the input, and compresses it with compress, exomizer and let's say pucrunch using all available options. (I know pucrunch had a few options that would determine the end result, I'm not sure if the other two do.) It would then display all the resulted new .PRG files and end user could pick the smallest one. Come to think of it, this could even be a simple batch file.
|
|
Posted By
IstvanV
on 2008-08-09
17:44:44
| Re: plus4emu FLI converter
I have uploaded a package of the original compress utility with some optimizations (it runs about 3-5 times faster while producing identical files), a new experimental version that is based on the exomizer format but extends it with some new features, source code of the compressors and decompressors, and the Lua script that was used to measure the decompression times to http://www.sharemation.com/IstvanV/compress.7z.
The program does have a number of options that affect the compression ratio and speed, as well as decompressor size and speed; the list of options can be printed with the --help command line flag.
The newer version has more options, the decompressor is smaller, faster, and does not use the color memory ($0800-$0BFF), it works better on already compressed or very redundant (long runs of the same byte) data, but there is no Huffman coding used. So, it is basically a modified exomizer compression with "delta" matches (which helped a lot e.g. in the case of Mercenary and Zenith of Puberty), variable prefix size for 3-byte or longer matches, and multiple blocks in the same compressed stream (this allows extracting blocks to separate memory areas, and also makes it possible to improve the compression by changing the encoding for different parts of the file, but the compression is quite slow).
|
|
Posted By
IstvanV
on 2008-08-21
19:14:18
| Re: plus4emu FLI converter
http://www.sharemation.com/IstvanV/compress.7z is now updated. The new version supports three different compression methods that can be selected with the -m0, -m1, and -m2 options. The following table shows how the various modes perform on a set of 13 files:
Original Exomizer Compress-m0 Compress-m1 Compress-m2
-------------------------------------------------------------------------------
Heartfixer 95% 25961 16053|3.04 15693|4.36 15569|3.00 15904|2.98
Icicle Works 30977 14078|3.50 14161|4.50 14098|3.63 14158|3.50
Mercenary 60673 34144|8.48 32958|10.20 32661|7.82 33840|7.73
Monopsy 2 60642 35109|3.09 35094|10.10 34693|3.77 35126|3.51
sample (304x248 MCIFLI) 54529 34466|5.67 34176|9.98 34262|5.87 34196|5.73
sample2 (304x248 MCIFLI) 54529 31865|6.00 31200|9.47 31519|6.17 31515|5.96
Thalassa 60649 21244|5.43 20282|6.75 19841|5.34 20973|5.24
Threeve 60673 45251|3.18 45262|12.64 45241|3.74 45357|3.66
Trailblazer Plus 23041 8031|2.31 8141|2.65 7982|2.19 8068|2.08
Treasure Island 28595 10727|3.00 10761|3.46 10666|2.83 10787|2.74
We are the Cure 53182 15922|3.95 14731|5.03 14514|3.83 15696|3.68
XeO3 59633 19067|4.77 18680|6.29 18325|4.74 19075|4.58
Zenith of Puberty 60448 35326|6.35 33785|9.33 34176|6.39 34889|6.12
-------------------------------------------------------------------------------
Decompressor size ~280 ~660 460 431
All the above tests were done without blanking the display, so that the times can be compared directly, and with the exception of -m0 (which could be 25 bytes smaller without all the code that saves, sets, and restores $ff06 and $ff19), effects were disabled.
|
|
Posted By
IstvanV
on 2008-09-11
17:08:57
| Re: plus4emu FLI converter
There should probably be a separate thread for this, but did anyone try the compress utility (it is now included with plus4emu 1.2.9, the above link does not work) ?
|
|
Posted By
Chronos
on 2008-09-12
05:00:38
| Re: plus4emu FLI converter
i've just continue my thinking.. so you asked what might be helpful for us..
for myself a batch converting option will be for converting animations.. (but when we developed adventures in mono, i made a perl script for the dfliconv since the numerous frames we used in mode 4x4). but i doesn't know worth to develop it, because i used occassionally.
|
|
Posted By
IstvanV
on 2008-09-12
06:07:31
| Re: plus4emu FLI converter
The converter can be used from the command line, so you can simply write a .bat file that converts all files in a directory. For example, the following batch file would convert all .png files in the current directory to raw compressed 160x240 non-interlaced multicolor FLI images (p4fliconv.exe and compress.exe should be in the PATH):@echo off
for %%i in (*.png) do p4fliconv.exe -mode 5 -size 240 -xshift 0 0 -outfmt 1 -mcquality 30 -dither 2 1 0.95 %%i %%i.fli
for %%i in (*.fli) do compress.exe -m2 -9 -fli %%i %%i.cmp
del *.fli
ren *.png.fli.cmp *.fli You can print the command line usage for each utility with the --help option:compress.exe --help
p4fliconv.exe --help
|
|
Posted By
Chronos
on 2008-09-12
07:30:49
| Re: plus4emu FLI converter
ok its enough!
|
|
Posted By
MMS
on 2008-09-12
10:50:45
| Re: plus4emu FLI converter
OK, I have an idea, and it actually needs a lot of afterwork, but just as a question (Chronos just mentioned something beforehand). Not something brand new or brilliant idea, just for potential new function in converter.
I had the idea to create a slideshow from a comic. Loading time of next picture is critical, so I want as many pictures in the memory as possible. Then load in batches with fastloader.
Thinking about the possibilities I came to a conclusion, that if I want pictures, then they just took too much from the memory (HIRES could be OK due to resolution issues, 10K with full screen, max 8-10 screens, if not full screen ones).
But if I may use the HIRES Botticelli feature to save a full screen into characterset (2K) + charmem (1K)+color (1K)+brightness(1K), then a full screen picture uses up 6K only, saved 4K per HIRES picture (if could be described with 256 different self-defined characters). If only half/third pictures used, then have a higher chance to fit into 256 different characters (full height 200 lines). As there are usually several repeating parts in the comics (eg white part, plack parts) I successfully converted two pictures with really good results.
Unfortunately Botticelli can save only full picture, half not (I mean half picture would be 500byte char + 500byte color+ 500byte brightness + 2K charcset)
So the idea: in the converted there are almost everything to get this as final output: the HIRES converter, the conversion into charset (logo editor?).
OK, let's take it as a personal brainstorming, if you like the idea.
Maybe there are already such converter available (maybe crosstool too?), just I am not aware, and the Logo editors have rather strickt limatations on the nr. of used colors.
What would be needed more (as you know, I am a lazy bastard ):
-An algorith, counting, if the current picture fits into the 256 character limit. Warning if not, retry by user after new conversion, or new dithering&gamma adjustment (they has the biggest impact).
-An improvement in the hires converter, which sometimes made hidden dithering, mean that in Botticelli screen it looked as a full white 8x8 field. But it counted as separate character. Then I checked it closer (put the rastermap), and turned out the 8x8 field built up from dithered white background and white foreground pixels. It took some time to repair them. Valid in black also.
- Selection of area would be converted and exported. Yeah, this one would need a UI change, so I am a very brave man pointing this out.
- After conversion the exact lenght (byte) of the exported data to be shown, important when the import of the data happens.
What do you think? I know it would be a huge change, but demomakers would like you sooo much )
|
|
Posted By
MMS
on 2008-09-12
10:56:38
| Re: plus4emu FLI converter
Or you think that compressing the picture may have a better result (less than 6K per full screen hires picture, and I do not have this limitation of max 256 different 8x8 area), and this conversion into charactersets is just a loss of energy?
|
|
Posted By
Chronos
on 2008-09-12
13:38:38
| Re: plus4emu FLI converter
dcd have an irq loader with on-the-fly de-exomizer capabilities...
|
|
Posted By
IstvanV
on 2008-09-12
16:39:37
| Re: plus4emu FLI converter
You can also use my compressor to get slightly better compression than with exomizer. If the images are similar and have many areas that are the same as in the previous one, then it may also be a good idea to load multiple images as a single compressed block of data, or use a special compression that can use the previous image as part of the dictionary.
The dithering of uniform colored areas in hires mode will be fixed in the next release.
|
|
Posted By
MMS
on 2008-09-12
17:38:56
| Re: plus4emu FLI converter
Thanks for your quick response.
Anyhow, that converter is a fantastic, and very frexible tool. It already saved me SOOO much time...
Please do not take my feedback, that I would like to address you extra tasks, I know it is a very time-consuming hobby. Especially because having an idea may need only minutes, while the realization can be dozens of hours... I just sharing ideas could shape your tool perfectly matching to all expectations: you may like or dislike my inputs, or could completely useless to you. Any hour you spend in the development, I do respect, as it make our like much easier, and Plussy can become the dominating 8-bit platform with the super graphics we can create with the help of that.
(OK, I just dreaming).
|
|
Posted By
IstvanV
on 2008-09-14
05:18:51
| Re: plus4emu FLI converter
Well, the dithering of uniform black or white areas in hires modes is not very difficult to fix, so that can be done in the next release, as well as the no dithering and no interpolation modes requested by Chronos. Other than that, there will be a couple of bug fixes in the emulator, and some fixes and minor improvements in the compress utility.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
