|  Post Your Message | |
| |
| | Previous Messages | 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.
|
|
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-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
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
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
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
Chronos
on 2008-09-12
07:30:49
| Re: plus4emu FLI converter
ok its enough!
|
|
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
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-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
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-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
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
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
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-02
17:08:43
| Re: plus4emu FLI converter
Well, I assume it can be safely deleted then.
|
|
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-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
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
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
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
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
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
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
Degauss
on 2008-07-22
01:11:38
| Re: plus4emu FLI converter
Have to try this one... Amazing results
|
|
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
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
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
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
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
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
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
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
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: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: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
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
IstvanV
on 2008-07-08
08:12:28
| Re: plus4emu FLI converter
Any opinions on the updated utilities ?
|
|
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
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
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
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-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
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-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
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
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-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
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
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
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
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
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-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-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
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
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
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
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-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-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
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
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
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
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
07:27:48
| Re: plus4emu FLI converter
Uhmmm...how to activate the pixel exact feature?
|
|
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-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
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
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
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
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
Exin
on 2008-04-13
22:38:56
| Re: plus4emu FLI converter
Thanks for all the info!
|
|
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
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
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
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
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
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-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
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
09:28:30
| Re: plus4emu FLI converter
Sorry, I meant screenshots or measurements, not screenshots of measurements
|
|
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
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-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
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
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
Exin
on 2008-04-09
21:17:30
| Re: plus4emu FLI converter
With scaled, i mean in grayscales. Sorry. 
|
|
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
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
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-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
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-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-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
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
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!
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
