|  Post Your Message | |
| |
| | Previous Messages | Posted By
Archmage
on 2008-08-26
17:21:09
|  Re: So I want to do plus/4 gfx...
Thanks a lot you guys, Chronos, IstvanV, MMS and Csabo, for your elaborate answers. I really appreciate it. I think I can actually pull it off. You will hopefully see the result in a demo within the end of the year.
|
|
Posted By
Chronos
on 2008-08-26
12:26:43
 | Re: So I want to do plus/4 gfx...
hey istvan! WE using YOUR converter now, thats what u made it for!  its the point.. but sometimes we refer wrong to your programs, but i see more and more people using it... don't worry, its the best and we are all proud of ya!
|
|
Posted By
IstvanV
on 2008-08-26
10:59:24
| Re: So I want to do plus/4 gfx...
No, it replaces the palette of the input image to match the internal palette of the converter exactly. So, the color searching step is still done, it just reproduces the original indexed image as the input to the multicolor conversion process. Although in practice it usually does not seem to make any difference for multicolor modes, it is possible to disable the dithering by selecting any of the error diffusion type dithers and setting the limit to zero.
In the case of pixel exact hires conversion, dithering and the "optimize for PAL filtering" option should be disabled, and the luminance search mode should be either MinRMSErr or MinRMSErr_YUV_Downsampled.
|
|
Posted By
MagerValp
on 2008-08-26
10:16:42
| Re: So I want to do plus/4 gfx...
So it works with the palette index values, and discards RGB information?
|
|
Posted By
IstvanV
on 2008-08-26
05:56:36
| Re: So I want to do plus/4 gfx...
MagerValp: you can do that with my converter, but it only works with .gif and .xpm format files, and not .png. The image should use the full Plus/4 palette with all colors at the correct index, and preferably no transparent color. If the input file has these properties, then the sinc interpolation and the color approximation can be avoided.
|
|
Posted By
IstvanV
on 2008-08-26
05:48:38
| Re: So I want to do plus/4 gfx...
> Ohhhmmm, I just saw the pictures linked as Quality settings,I think I use a rather outdated version.... OpenGL2.0 no prob, I have Radeon HD2600 (certainly AGP, which is a kind of "retro" already)
Other than the different GUI theme, the display settings dialog looks the same for about a year. If the full display emulation mode does work correctly on your machine, then it should look like this http://www.sharemation.com/IstvanV/plus4.png.
|
|
Posted By
MagerValp
on 2008-08-26
05:06:14
| Re: So I want to do plus/4 gfx...
Are there any +4 converters that do pixel perfect conversions from a 128 color gif or png? No scaling, dithering, blurring, color approximation, etc. When pixelling you want perfect control over each and every pixel, and don't want the converter to try and second guess you. I have developed tools like this for the C64, but not for the +4.
|
|
Posted By
MMS
on 2008-08-25
13:51:23
 | Re: So I want to do plus/4 gfx...
Ohhhmmm, I just saw the pictures linked as Quality settings,I think I use a rather outdated version.... OpenGL2.0 no prob, I have Radeon HD2600 (certainly AGP, which is a kind of "retro" already )
|
|
Posted By
IstvanV
on 2008-08-25
10:09:07
| Re: So I want to do plus/4 gfx...
> Note the quality setting of 3, which enables the emulation of PAL filters and scanline shading (this requires an OpenGL 2.0 compatible video card and drivers).
By the way, this will be improved somewhat in the next version.
|
|
Posted By
MMS
on 2008-08-23
16:01:36
| Re: So I want to do plus/4 gfx...
Hi,
Never mind, your program already at top level, actually -as I see- the best on the world.
If it works like this, I will use it in this way.
Nothing "mission impossible", but it hurts, that my idea does not work, and even more I gave wrong suggestions )
With the Photoshop (and the usage of Plus/4 palette in PC graphics) I have only one problem namely that I do not want to buy it, and actually every program on my PC is legal free or shware, and I do not want to change it. Maybe I try with Photofiltre this option too. It is a long story, why I made this limitation for myself, in one sentence: I am a SW-developer, and I was fed up with the cracked and free copies, I think it killed the Amiga too.
|
|
Posted By
IstvanV
on 2008-08-23
09:37:24
| Re: So I want to do plus/4 gfx...
> I could not finish it previously: because I suppose, that graphical programs written for that single purpose (Photofiltre, Pant Shop Pro, etc) doing the rescaling in a more dvanced ptimalizations, than your program, with all respect to you and your converter, but it cannot be the best of the world in all aspects.
I may add an option to skip all scaling/offset/etc. entirely, although it needs many changes to the code, so it will not be in the next version, which I plan to release very soon. However, the pixelizing to 640x400 method should work well, because the scaling operations should then just reproduce the original image without changes (other than rounding errors, but that is not significant, since the image is stored in 32 bits per channel float format internally).
Also, the pixel exact .gif/.xpm mode was added exactly for this purpose, and it allows doing not only the image scaling, but also the color reduction and dithering in Photoshop etc. as well, which I assume would do these tasks better too than my crappy converter
|
|
Posted By
MMS
on 2008-08-23
09:08:51
| Re: So I want to do plus/4 gfx...
I could not finish it previously: because I suppose, that graphical programs written for that single purpose (Photofiltre, Pant Shop Pro, etc) doing the rescaling in a more dvanced ptimalizations, than your program, with all respect to you and your converter, but it cannot be the best of the world in all aspects.
|
|
Posted By
MMS
on 2008-08-23
08:33:10
| Re: So I want to do plus/4 gfx...
Hi Isvan, thanks for great feedbacks.
Especially on the resizing it is very useful, I will try it. But what if the converter would support 320x200 (160x200) native resolution? As then no second internal resizing would be needed, just the wise color selection
|
|
Posted By
Csabo
on 2008-08-23
08:16:47
| Re: So I want to do plus/4 gfx...
Archmage, I'll mention my Gfx Edit again. Apparently there have been some new versions in the pipeline ;-) I recently did a DFLI logo and while doing that some of the shortcomings of the editor really became apparent, so I fixed some things up.
|
|
Posted By
IstvanV
on 2008-08-23
08:04:28
| Re: So I want to do plus/4 gfx...
> Sometimes (interestingely) the preview have better results, than in the Emu. (maybe my monitor settings).
The preview of the image converter is identical to plus4emu in OpenGL mode with the settings shown here http://www.sharemation.com/IstvanV/p4dispcfg1.png for all modes other than interlaced hires FLI, in which case the settings are as shown here: http://www.sharemation.com/IstvanV/p4dispcfg2.png.
Note the quality setting of 3, which enables the emulation of PAL filters and scanline shading (this requires an OpenGL 2.0 compatible video card and drivers).
The image conversion in p4fliconv is also always optimized for the palette of the plus4emu version with which the converter is distributed.
> - Resize to 320x200. Use the Lacnzos method
The image scaling in p4fliconv first resizes the input image to 640x400 (at least for simple hires/multicolor modes; in all cases, however, the size of a character at the intermediate resolution is 16x16 pixels) with anti-aliased sinc interpolation, and then downsamples that to the actual output resolution with simple box filtering. Therefore, you should pixelize the image to 640x400 (4x2 pixels in multicolor mode), and not 320x200 if you want to avoid additional image scaling artifacts in the converter.
> I found GIF reducing the overall color palette too reduced
Using the GIF format can actually be useful for pixel exact conversion, because the converter treats it in a special way if the colormap matches the Plus/4 colormap (with all colors at the correct indices, and no colors removed to "optimize" the palette): the sinc interpolation is replaced with nearest-neighbor "interpolation", and the image palette is replaced to match the internal floating point YUV colormap of the converter exactly, to avoid palettization artifacts.
|
|
Posted By
MMS
on 2008-08-23
06:55:55
| Re: So I want to do plus/4 gfx...
Regarding original image:
My first set of pictures were converted before P4Fliconv to a format I supposed could be the closetst ot Plus/4 format.
I use irfanview, as all the "sophisticated" tools I need
- Resize to 320x200. Use the Lacnzos method
- In the Effects, select Pixelize, and set it to 2 wide,1 high. then the picture become 1-to-1 to a real multicolor Plussy resolution, just have much more colors...
- Sometimes when I feel the colors are matching to Plus/4, I reduce number of colors to 256, 128 or 64 with Image/Decrease color depth. 256 would have the same result as GIF. But if the picture do not have close spectrum (eg very colorful picture with red, green, blue, purple parts in different areas), then the 256 of GIF you may find too limitied to cover every colorshade. If you import in JPG, these areas handled by P4FLICONV separately, with their own colorpalettes, as I see
- Now comes the P4FLICONV, try to keep the limit value low, otherwise overdithering may happen (which in fact high limit value looks great in FLI and HIRES pictures)
Nowadays I DO NOT resize the pictures to 320x200, or 160x200 befroe conversion. I found that P4FLICONV also makes it with pretty good result, so why I should spend more time on it? But in few cases (like anime, or concept art linegraph), it makes sense to make a 320x200 JPG with 160x200 resolution.
About hit ratio:
-When a picture -after all your efforts and time- look crap after conversion, do not spend more time on it. No way you can make it goodin Multibotticelli.
-I collected now thousands of pictures, and at least 300 I tried to convert till now. The hit ratio was very low at the beginning: from 100 picture I selected only 15-20 looked really OK, and only 10 looked so great almost no handpixelling needed.
now i have the eyes to able to see the right colors in the originals, so my hitrate went up to 10 OK from 40-50...
Interestingly some multicolor conversion looked crap (like Jupiter or Titan moon), by accident I selected HIRES, and it was fantastic
Although Plussy has a lot of blue colors (4 different), somehow it does not come out.
Greens are nice.
Orange is dissapointing, as it is too flat, not vivid. Yellow is crap. Brown is more a dark orange. Red is a dark pink.
So I suggest to look first green palette pictures. Purple also OK
But it is still my own view, when some releases will come, then it may
by confirmed by others, if my work was nice, or just speakign a lot of bullshit here.
|
|
Posted By
MMS
on 2008-08-23
06:27:23
| Re: So I want to do plus/4 gfx...
Hi,
Still i found the best the following method, please keep in mind, that because of afterwards editing I always use simple 160x200 multicolor images:
1) take any good resolution image. JPEG is OK too. I found GIF reducing the overall color palette too reduced
Plus/4 converter like strong colors, the fine dithering works well only in B/W
2) Open Istvan's latest FLIconverter (p4fliconv.exe). Select Multicolor (surprisingly the normal Hires sometimes resulted great images too).
3) With the Preview mode check the output. Floyd is the best for multicolor conversion.
It takes some time, the more dithering I select, it takes the longer.
Max. 1-2 minutes on my AMD64 3000+.
By the way the Preview heavily loads our CPU by running the emulator in the background.
4) Play with the Limit and Dithering diffusion parameter. Pixel-exact conversation (as I see) works the best with 0.02-0.04 limit, and 0.5-0.6 diffusion parameter. If you use the Limit value as default, even full flat area of color would be dithered too, and would look crap.
Multicolor quality I always put to 30, but you may have different experince. In HIRES converion push both dithering and limit value to maximum.
Try as many times needed with apply button, till the Preview does not show a good result.
5) I always save it in PRG (runnable) and Raw image form too (Multibotticelli can handle).
Even before I close the P4FLIConv, I always doublecheck with Plus4emu and Yape too, how the runnable version looks like. Sometimes (interestingely) the preview have better results, than in the Emu. (maybe my monitor settings). in Yape try to turn on the Screen/Display Type/video Display emulation and use Digitized colors. As I see, it could be the closest to the picture would be seen on a Party or on a real Plussy
6) If the runnable version looks OK, then I open Starcommander, and import the raw image to a .D64 file.
7) I start Multibotticelli, attach the disc, open the converted picture, and then starting the pixel-war, to remove the incorrect pixels, which looks NOK (any conversion will have that (typically green dots in black area, etc), but here -due to low resolution- really visible)
8) Typically 3-6 hours of work in Multibotticelli could be enough to correct mistakes and optimize some colors (which looked OK in the original, but look not nice after conversion).
When more work needed (eg recolor full parts, as eg the reddish-orange was converted to pink, and I hated that) it can go up to 10-12 hours. But I am a slow graphician...
Just to able to compare: check the MMS Graphic box, there is a raytrace art I fully handmade with Microillustrator: it took ~45hours to finish. So the converter may save me 20-30 hours of pixel-drawing WORST case, but can save even more.
But frankly speaking, my handmade one looks little better
To use it in a demo, just have to remember the background color and the 3rd color, as multibotticelli's output is a normal bitmap picture (as far as I know).
Have fun!
|
|
Posted By
IstvanV
on 2008-08-22
17:54:03
| Re: So I want to do plus/4 gfx...
> Doing a picture on a C64 in any format, save it as a .prg and then convert it?
It probably makes more sense to create an image with the Plus/4 colormap using any PC graphics software, save it as a .gif file, and then convert that to a multicolor/multicolor FLI Plus/4 image in a way that is as close to being pixel exact as possible. If there are areas with visible error, then one could try to change those parts in the source image, so that it is easier to convert without attribute clashes.
When converting images from the C64, you will basically have the disadvantages of both machines, that is, the 16 colors limitation of the C64, and also the more attribute clashes of the Plus/4 due to having fewer colors that can be set independently for each cell. But since there are very good pictures for the C64, it may still be interesting to try
|
|
Posted By
Archmage
on 2008-08-22
15:25:01
| Re: So I want to do plus/4 gfx...
I am now getting involved in a real plus/4 demo project (with a real coder  ).
So, the only thing that bugs me now is this: I still don't know how to go about doing my gfx. P1 the plus/4 version is cancelled. What I can deduce from this thread, and its spin off, is that the option that most people go for is conversion - am I right? Doing a picture on a C64 in any format, save it as a .prg and then convert it?
I am no tech head, all I know is how to pixel, so any advice on how to go about this (that does not involve Botticelli  ) would be much appreciated. Thanks!
Archmage
|
|
Posted By
IstvanV
on 2008-02-01
08:32:53
| Re: So I want to do plus/4 gfx...
Yes, at least it seems others refer to this type of effect as "overscan", so I used the same term. With the current display routine I use, the vertical resolution can be 200, 228, 232, or 248, and can be doubled (in hires mode) with interlacing for a maximum of 496 lines.
|
|
Posted By
bubis
on 2008-02-01
05:12:31
| Re: So I want to do plus/4 gfx...
Might sound a stupid question, but what do you mean on overscan? Gfx on the border?
|
|
Posted By
IstvanV
on 2008-01-30
19:29:16
| Re: So I want to do plus/4 gfx...
I do already have some MC code that works, even if some improvements may be needed. Although implementing modes for which there are already good converters is probably not as important anyway, while the hires with true interlace and overscan is new and obviously useful. By the way, I do have both GUI and command line interface in my SVN code: which one is used depends on the command line arguments (i.e. if there are no files specified, the GUI starts).
|
|
Posted By
Chronos
on 2008-01-30
16:41:31
| Re: So I want to do plus/4 gfx...
istvanv's converter is that s**t! please implement the classic formats (multi/hires) too and it will be the ideal converter for me ..
|
|
Posted By
Chronos
on 2008-01-30
16:21:05
| Re: So I want to do plus/4 gfx...
gimme dfliconv and all converters!!! i still using dfliconv! i want gui and batch converting.. and and and remove the lil pink boxes and other garbage from the converted pics.. and istvanv! hack it together with a gui! an easy use easy configurable stuff... ok, enuff cryin'
|
|
Posted By
Luca
on 2008-01-30
12:43:39
 | Re: So I want to do plus/4 gfx...
Something let me think that nothing else has been able to come without a dfliconv around
|
|
Posted By
bubis
on 2008-01-30
12:13:46
| Re: So I want to do plus/4 gfx...
It is starting to become a waste of time to finish my dfliconv .
|
|
Posted By
Luca
on 2008-01-29
18:01:34
| Re: So I want to do plus/4 gfx...
Heh what a pity, at this point I was very fond of it
|
|
Posted By
Gaia
on 2008-01-29
17:57:45
| Re: So I want to do plus/4 gfx...
Guys, PLEASE, let's move to another topic, I can't believe this is still growing... give it a subject like "Project One" or "plus/4 gfx cont." or somesuch if you want to.
|
|
Posted By
Luca
on 2008-01-29
17:53:36
| Re: So I want to do plus/4 gfx...
Well, I wanna have both, editors and converters. I also wanna have a flying mule. And a cyan coloured yoyo that flashes when...ok you got iy.
Things are nicely moving on both sides, but ask me if I would see the IstvanV's work slow down in order to add editing options, and I'll say NO. Better, I'll say NEXT: IstvanV is coding something never existed before on this platform, while defining which are the gfx formats that would be typical on a Plus/4. He will collect all under one very effective converting routines bunch, and finally we shall have a real picture about everything we can call "graphics" on the Plus/4.
At that time, heh well yes, a cool editor will be able to take charge of the whole load, giving to the graphicians an ultimate tool to draw on this machine.
Project One has ready editing features, and could be a great forthcoming for the usual Plus/4 formats, I want it to be real exactly like you too
|
|
Posted By
Chronos
on 2008-01-29
13:36:57
| Re: So I want to do plus/4 gfx...
Project one for the masses !!!! WE Want it, WE need it!
|
|
Posted By
Archmage
on 2008-01-29
05:08:36
| Re: So I want to do plus/4 gfx...
Gaia: Word. I am still waiting for the plus/4 version of Project one (OSWALD!!!) or a just as simple equivalent with the option to save a picture as an executable. There is obviously a great deal of important activity done on the conversion front in this thread. But personally I'd like to do gfx directly for the plus/4, not by means of conversion. So that was why I started the thread. Botticelli simply doesn't do the trick for me. I feel like a spoiled brat crying for new toys here, but still...
|
|
Posted By
Gaia
on 2008-01-14
11:57:35
| Re: So I want to do plus/4 gfx...
Istvan: thanks for the effort you have put into finding Yape's bugs, I appreciate constructive criticism. While your deduction of the possible problem was impressive, luckily the problem appeared to be just an unnecessary 'if' statement in the code.
And now if I was to give constructive criticism: while I am no big fan of converted picture shows, these pictures look very good indeed. What most creative people (read: graphicians) are really waiting for, however, is still a nice drawing program with support for all (FLI) video modes I believe. Preferably a native one. At least that's what a lot of C64 graphicians seem to be willing to use. If we had some good native drawing programs, these guys would pick the plus/4 just for its gorgeous FLI modes and we had lots of new releases coming in. I wish I would be proven wrong but another converter is not gonna mobilize these people, no matter how good it is. I am not sure about native plus/4 graphicians, but we do not have that many to be perfectly honest.
Also, if I may have a suggestion: could we move this discussion to another topic, you guys, as this tends to grow beyond all limits by now. Cheers.
|
|
Posted By
IstvanV
on 2008-01-14
11:22:28
| Re: So I want to do plus/4 gfx...
A preliminary GUI converter is now available: http://www.sharemation.com/IstvanV/p4fliconv.7z
Some minor functionality is missing, and bug fixing and cleaning up the code may be needed, but it mostly works. Any suggestions about changes to be made to improve the program are welcome.
The package should be extracted to a plus4emu installation directory, and the .exe file can be run from there.
|
|
Posted By
IstvanV
on 2008-01-12
16:49:49
| Re: So I want to do plus/4 gfx...
The fliconv.7z package has been updated again: this time, there are some speed improvements, fixed PRG size for non-overscan modes, and some color interlacing changes that may or may not look better. The next thing to do will be to start reorganizing the code for a GUI version.
The YAPE bug is most likely in the emulation of the internal DMA position counter, which is similar to $FF1A/1B, but cannot be accessed directly. However, it can be changed by writing to $FF1E. The problem could be that YAPE either does not increment, or does not latch this counter before the first DMA (these should be already enabled from line 0), or maybe the horizontal timing or the condition for latching is not correct. It did take some work for me a while ago to find out how these registers should be emulated accurately
I do not know why increasing the joystick threshold makes the problem worse, but if/when you do not need it, just disable it in the keyboard configuration window.
Here is a summary of the image converter command line options:
-ymin MIN
-ymax MAX
These basically adjust brightness and contrast by scaling RGB values from a 0 to 1 range to 'ymin' to 'ymax'. If the maximum is set lower than the minimum, the result will be a negative image.
-scale X Y
-offset X Y
Resize and shift the image. Scaling by 1.0 means using the default size. The offsets are in half TED pixel units, that is, the virtual screen resolution is assumed to be 768x576. Positive offsets mean shifting to the right and down, respectively.
-saturation M P
Multiply the color saturation by 'M', and then raise it to power 'P' relative to the TED saturation. This can be used to compress the saturation range before conversion.
-gamma G M
Apply a gamma correction of 'G' (> 1 is brighter) to the luminance (Y) component of the image, and assume a monitor gamma of 'M'. The difference between the two parameters is that the latter is applied both to the image and the internal luminance table as well.
-dither M L S
Set dither mode (0: ordered, 1: diffuse), limit, and error diffusion factor (0 to 1). Error diffusion dithering is more advanced, but is also more likely to have artifacts due to the palette being different for each 8x2 area of the image. The dither limit is useful to avoid too much added noise with ordered dithering.
-pal N
Optimize for the limited color resolution of PAL displays if N is 1, or disable this feature if N is 0. While slower to calculate, it is generally recommended, and looks better in most cases.
-xshift S0 S1
Set horizontal shift (0 to 7) for each interlaced field. There are two special settings: -1 automatically optimizes the X scrolling for the least amount of error, and -2 uses random values for every line. Optimal scrolling can only be used for both fields at once, and is the default. Only -xshift 0 0 allows a full 40 column display, in any other case the width is reduced to 38 columns.
-border N
Set the border color (0 to 127). This is also the assumed color of any pixels with out of range coordinates ("empty" areas are filled with border color by the resize operation), as well as the background color for RGBA images.
-nointerlace N
Use interlaced (1) or normal (0) vertical resolution. Even if -nointerlace 1 is used, "flickering" interlace is still enabled.
-size N
Set the vertical size of the FLI display. Supported values include 200, 228, 232, 248, 400, 456, 464, and 496. This option also implies setting '-nointerlace' depending on the selected resolution. 248 and 496 will only work on PAL machines, while the smaller sizes can also be displayed on NTSC. With 200 or 400 lines, BASIC memory is used up to $B400, however, using the higher resolutions will increase this to $E500.
-y1bit N
Quantize luminance to 1 bit (black and white) if 'N' is 1. This effect looks best with full diffuse dithering (use -dither 1 1 1).
-no_li N
By default, luminance attributes are set independently for each 8x2 pixel block. With N=1, this is reduced to 8x4 by not allowing the interlaced fields to have different attributes. While the reduced attribute resolution generally means worse quality, it may be useful to avoid comb-like artifacts sometimes in interlaced modes.
-ci N
Color interlace mode (0 to 2). 0 disables color interlacing, 1 interlaces colors with neighboring hue only, and 2 will also interlace any color with grey to display half saturation. Higher settings take longer time to calculate, and do not necessarily look better.
-searchmode M P
Select the algorithm that is used to assign the two luminance codes for each 8x2 block, as well as the error calculation formula. Mode 0 sums the square of differences, and tries to make the sum the smallest possible. In mode 1, the luminance levels nearest the darkest and brightest pixel are used. Mode 2 is like mode 0, but the error is multiplied by 'P' for every pixel that would be out of range. Mode 3 selects the luminance codes so that no pixels will be out of range. Mode 4 is similar to mode 0, but takes into account the possibility of dithering, and uses the 'P' parameter (0 to 0.5) to add extra error to the "dithered" levels. Mode 5 is another variation of summing the square of differences, but tries to move towards the levels nearest the darkest and brightest pixel (as in mode 1) as long as the increase in error does not exceed a threshold determined by the 'P' parameter (usually in the range 0.01 to 0.03).
-raw N
If 'N' is 1, only the raw FLI data is written to the PRG file, and the 1K display routine is not included.
|
|
Posted By
Luca
on 2008-01-12
03:47:29
| Re: So I want to do plus/4 gfx...
Various facts:
- I can recognize the typical YAPE's output on the real machine when I press reset: for a moment, the screen looks like the current YAPE's output, could this info be useful, Attila?
- I increased the joy's threshold value, the bug stands still but it goes now playing randomly with the joy BEFORE THAN THE PREVIOUS CASE; anyway, as I said, I had had a real machine with exactly the same bug, does exist an explication for this habit?
- I'll test the new stunning release when I'll be at home after work, I guess at this point we may need an info file reporting command line options usage and main features for the coders
|
|
Posted By
IstvanV
on 2008-01-11
19:16:22
| Re: So I want to do plus/4 gfx...
The picture looks very good
I have another minor update: http://www.sharemation.com/IstvanV/fliconv.7z
This allows selecting the number of lines - 200, 228, 232, 248, 400, 456, 464, or 496 - on the command line, fixes the PRG file size bug and a few other minor problems (the output may look slightly different, though), and is also somewhat faster.
|
|
Posted By
Chronos
on 2008-01-11
16:01:05
| Re: So I want to do plus/4 gfx...
fck'in cool :D
|
|
Posted By
Luca
on 2008-01-11
12:46:52
| Re: So I want to do plus/4 gfx...
...and just to be clear, the emulator's screenshot is CRAP compared to the real machine's output!
|
|
Posted By
Degauss
on 2008-01-11
12:11:21
| Re: So I want to do plus/4 gfx...
TED likes green. And i like the converter output. A really good job Istvan.
|
|
Posted By
Luca
on 2008-01-11
12:03:37
| Re: So I want to do plus/4 gfx...
Running at home after work, I stopped my bicycle at Cascine's Park and took this picture. Once at home, I put a SID music (I used #$E8 for the CMP $FF1D) in $E800 with the picture I got, and that's the final result.
I simply love this fantastic converter, it should be spread like hell, it would support all the other formats, included HIRES, MC and 4COLORS!
|
|
Posted By
Luca
on 2008-01-11
08:20:45
| Re: So I want to do plus/4 gfx...
What a stupid I'd been, I should be very tired late night: I used a $C000-$CFFF tune and I didn't relocate it .
Tonight I'll check if would be possible to use a 2x SID tune in the bigger one...
|
|
Posted By
IstvanV
on 2008-01-11
05:42:27
| Re: So I want to do plus/4 gfx...
The memory usage is actually slightly less than what would be expected from the size of the generated PRG files, since there is a trivial bug in the converter that makes it save 4K more data than needed. So, the real memory usage is $1001-$E4FF, rather than $1001-$F4FF. That is still much more than the $1001-$B3FF of the original 400 line version, though. Perhaps the best solution would be to allow the selection of any particular size (400, 456, 464, or 496); the memory layout of the FLI data in the larger versions is mostly backward compatible with the smaller ones (the overscanned versions have the data shifted by 24 characters), which makes the implementation easier, and other than limiting the number of lines, the converter would only need to choose from the various display modules. I thought that 464 would be a good default, since it is still NTSC compatible, and has an aspect ratio of about 4:3, which is probably the most common for images.
The YAPE bug is probably related to the manipulation of the internal DMA position counter by FF1E writing tricks. Although it already did not work correctly, since interlaced resolutions are not supported yet by YAPE.
The joystick getting stuck can indeed be annoying. You can avoid this problem by increasing the threshold in the options, or just disabling the use of joystick input if you do not need it anyway. I think it would be possible to prevent the joysticks from being interpreted as key presses in Plus/4 programs by writing the row select value to FD30 only, and #FF to FF08, rather than writing the row select to both registers.
|
|
Posted By
Luca
on 2008-01-10
19:57:48
| Re: So I want to do plus/4 gfx...
Even more incredible stuff! I saw in the sample the "press space" check falls now at $FF1D = #$E9 in order to cover the whole screen raster, and this means there are only #$4D left to complete a whole screen. Moreover, the overscan version occupies a wholesome slice of the memory.
Yape 0.78 really hates this overscan, hope it will be fixed soon.
EDIT: in the late night (I was quite tired ;) ) I tried to set a quick IRQ in order to run a SID music. No problems with the original one since $FF1D = #$CC, of course. On the countrary, I ad problems setting a little #$18 long IRQ for the music in the overscanned version: I tried to set it from #$E9 and beyond, but it never worked :(
I'll check it again after work...
About plus4emu 1.2.5: when I execute the emulator, it begins to print a long string of "4" chars, as the joy1 stucks to the right. Rotating randomly the joy1 stops the bug. Why? I had had a real plus4 with the same bug.
|
|
Posted By
IstvanV
on 2008-01-10
19:07:21
| Re: So I want to do plus/4 gfx...
A slightly modified (still command line only) version that increases the vertical size to 464 (232) or 496 (248) lines is now also available:
http://www.sharemation.com/IstvanV/interlace7_overscan.7z
It also has new options for image scaling and offset. The 496 line PRG files only run on PAL machines, while the smaller ones should theoretically also work on NTSC.
|
|
Posted By
Luca
on 2008-01-09
20:09:04
| Re: So I want to do plus/4 gfx...
I did some attempts: it's astonishing. Waiting for a GUI driven version...
|
|
Posted By
IstvanV
on 2008-01-09
18:53:13
| Re: So I want to do plus/4 gfx...
There is now an experimental version of the converter that can read PNG, JPEG, and BMP files (currently only true color and greyscale files are supported), and also automatically resizes the input image to 640x400 before conversion. However, large images (>1920x1200) are generally not recommended, and if the aspect ratio is not 1.6:1, then some of the display area will not be used (the unused areas are filled with border color). Here is the download link: http://www.sharemation.com/IstvanV/interlace7.7z
The basic usage is just something like
interlace7.exe someimage.jpg outfile.prg
however, getting the best quality may require some experimenting with the various parameters.
A simple GUI probably does not take a lot of time to create, so I will try building one soon. Perhaps it would also be a good idea to design it so that new conversion methods and different display formats can easily be added.
For error calculations, I use the sum of the square of the differences most of the time, but in the case of luminance codes, I also try to ensure that the resulting range is not too limited (e.g. by multiplying the error for out of range pixels).
|
|
Posted By
Luca
on 2008-01-09
10:43:52
| Re: So I want to do plus/4 gfx...
I tried to put on a valid RGB-with-no-header image to convert it but I failed. Then I loaded image5_i.prg on a real machine: using my good old 1802 monitor, the pictures looks incredible, never saw something of this kind before, it's like amiga with a bit of waving flickering.
I'm religiously waiting for a .png .bmp.jpg .gif support by now. Congrats, IstvanV!
|
|
Posted By
Degauss
on 2008-01-09
08:10:22
| Re: So I want to do plus/4 gfx...
Hi Istvan!
I would like such a kind of utility but due to a lack of time, i'm sorry to say that i can't volunteer
Yes, the overscan-images were done with my converter. In "Notizen" I took a rather bad input-image, so the quality here isn't too well. These are also results from a basic RGB-error-function (Sum of absolute differences). I'm still seeing some "bad decisions" made by the converter with that error function.
The interlaced DFLI-Overscan was a bit tricky to design: I still wanted to have some space in memory left for other routines like music, decrunchers, loaders and stuff. On the other side i needed to unroll the whole display-code into memory, since i was modifiying so many registers. That was a difficult task, because in some cases i needed to split-up the display code into slices and scatter them into unused areas of the videomatrices. At the moment, a picture from my converter covers $1000 - $F000 (with about 4KB of empty/usable space in smaller slices within that range).
Would you like to beef up your routine to a full-featured converter? I thought so about my converter but then i had the idea it might be a bigger use if would enhance my converter to become a paint-program. I think it'll be nice to be able to paint with the full-palette in an idealized screen-mode and let a converter assist you to choose the right videomatrix/ted-register-values...
|
|
Posted By
IstvanV
on 2008-01-09
06:39:19
| Re: So I want to do plus/4 gfx...
It would be actually fairly simple to add support for 24 bit PNG, JPEG, and BMP images, by using the Fl_Shared_Image class. A GUI could also be created, possibly using a built-in instance of plus4emu for full size image previews with PAL emulation. Does anyone like the idea of writing such utility ?
By the way, is your multicolor converter the same one with which overscan.zip and the first part of Notizen aus der Provinz were created ? These look very good.
|
|
Posted By
IstvanV
on 2008-01-08
17:24:20
| Re: So I want to do plus/4 gfx...
The conversion is fairly simple. It first converts the input image to YUV format, and finds optimal pairs of luminance values from the 9 possible levels for each 8x2 block, finds the best horizontal shifts (running the luminance code search in a loop, and choosing the shift values that give the least amount of error), and generates bitmaps with ordered or diffuse dithering. There are 6 different methods for calculating the luminance error and finding the best values, this can be selected on the command line.
Only when that is all done is the color (U and V) information converted, taking into account that the color resolution is lower than the luminance resolution (there is both horizontal blur and averaging with the previous line - the result usually looks much worse if this filtering effect is ignored by using the '-pal 0' command line flag). For each 8x2 block, a pair of color values is searched for the non-black pixels, to minimize U and V error; non-grey colors can be interlaced with the nearest hue.
This simple approach of trying to create the best possible greyscale image first and then adding colors to it tends to work reasonably well in image areas where luminance changes and color changes occur at the same time (e.g. bright yellow vs. dark green), but is not very good when there are only hue or saturation changes within a single 8x2 block.
|
|
Posted By
Degauss
on 2008-01-08
14:55:33
| Re: So I want to do plus/4 gfx...
Thats very interesting. In my MCFLI-Converter i tried to modify as many values as possible (FF15/FF16 per line or FF07-trickery if that results in less error).
What kind of error-function do you have? I always calculate the error in RGB-space but i always had the odd feeling its the wrong thing
|
|
Posted By
IstvanV
on 2008-01-08
14:48:42
| Re: So I want to do plus/4 gfx...
Yes, it can set the horizontal scroll independently for each line, and tries to optimize the scroll for getting the best image quality. It is possible to disable this on the command line (thus increasing the visible area to 320x200 or 320x400), or set fixed scroll values for the two fields of the interlaced image manually. The display routine also supports multicolor mode with ff15/ff16 colors set for each 2-line block, but that is not used by the converter.
|
|
Posted By
Degauss
on 2008-01-08
11:46:26
| Re: So I want to do plus/4 gfx...
Ah, i see.
The results of your converter are pretty impressive. Since its 304x200 i assume you're playing around with the scroll-registers aswell, right? ( I didn't look at the source atm)
|
|
Posted By
IstvanV
on 2008-01-08
05:06:56
| Re: So I want to do plus/4 gfx...
image5_i.prg and image5_n.prg were created with my utility. The first one has 304x400 resolution (note that it currently may not work correctly in YAPE), while the second one is a regular 304x200 hires FLI image. For each .prg, file, there is a corresponding .jpg which was captured from the composite video output of my real Plus/4. The commands used for conversion were:
interlace7 -mgamma 1.25 -searchmode 5 0.025 -saturation 1 0.75 image5.rgb image5_i.prg
interlace7 -nointerlace 1 -mgamma 1.25 -searchmode 5 0.025 -saturation 1 0.75 image5.rgb image5_n.prg
The current version of the converter only supports reading 640x400 raw RGB images without a header. However, if there is demand for it, I could add PNG format support and maybe automatic resizing as well.
|
|
Posted By
Degauss
on 2008-01-07
20:03:49
| Re: So I want to do plus/4 gfx...
Istvan!
Which one is your converters output? image5_n.prg looks brilliant to me.
|
|
Posted By
IstvanV
on 2008-01-04
10:45:37
| Re: So I want to do plus/4 gfx...
I was able to improve the conversion somewhat, although I do think it is still not quite perfect yet, but does look relatively good already. This package compares the image conversion of DFliConv, P4PC FLI Converter, and my utility: http://www.sharemation.com/IstvanV/p4imageconv.rar. It includes the PRG files created and screenshots made on a real machine (composite video).
|
|
Posted By
Chronos
on 2008-01-02
16:03:43
| Re: So I want to do plus/4 gfx...
any news about project one?
i love multi botticelli but it will made a new taste for me (probably)..
|
|
|
|
Posted By
Degauss
on 2007-12-28
02:27:33
| Re: So I want to do plus/4 gfx...
@Istvan: These Hi-Res pictures actually look quite cool. I wonder how they might look if you were using multicolor as the underlying screenmode (to have colored images).
|
|
Posted By
IstvanV
on 2007-12-26
18:18:42
| Re: So I want to do plus/4 gfx...
Well, the comment about YAPE bug does not seem to apply to the new version 0.78. It still does not display the increased resolution, though.
|
|
|
|
Posted By
IstvanV
on 2007-11-27
17:59:43
| Re: So I want to do plus/4 gfx...
By the way, these do not work in YAPE 0.77. So, I recommend using the real machine, or a more accurate emulator like plus4emu 1.2.4 (use software mode for full resolution, or the quality=3 TV emulation mode, otherwise the increased vertical resolution is lost).
|
|
Posted By
IstvanV
on 2007-11-27
17:43:09
| Re: So I want to do plus/4 gfx...
Here is some very simple 320x400 greyscale FLI (should theoretically work on NTSC machines as well):
http://www.sharemation.com/IstvanV/interlace6a.prg
http://www.sharemation.com/IstvanV/interlace6b.prg
|
|
|
|
Posted By
IstvanV
on 2007-09-22
16:53:15
| Re: So I want to do plus/4 gfx...
I am somewhat confused. The Pepto page basically says that:
sqrt(U * U + V * V) = constant
and
R = Y + 1,140 * V
G = Y - 0,396 * U - 0,581 * V
B = Y + 2,029 * U
This is really the same as what I am using (the formula in my 2007-09-02 post is equivalent to the above one with minor rounding differences), and is also in VICE, although VICE seems to do some small amount of gamma compressing by default, and uses different hue values. On the other hand, YAPE 0.76 is different, as I described earlier, at least with the BMP format screenshot I checked.
|
|
Posted By
Gaia
on 2007-09-18
18:22:16
| Re: So I want to do plus/4 gfx...
OK, I have reviewed the formulas I have. They were from the infamous 'Pepto' article. Problem is: they are wrong! He talks about Y'UV instead of YPbPr which is the analogue equivalent of YCbCr. When I rebase the color difference signals for YPbPr I get much more consistent hue values and looks more like the real thing.
This means that VICE's palette handling probably isn't good either... it's based on this article (doing YUV) without rebasing to [-0.5;+0.5]. Now I see why Charles Poynton never ceases complaining about the confusion around Y'UV.
I'll probably fix this soon(ish). Another palette change (in RGB mode), yay...
References:
http://en.wikipedia.org/wiki/YCbCr
http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.txt
http://www.pepto.de/projects/colorvic/
|
|
|
|
Posted By
Gaia
on 2007-09-14
12:00:14
| Re: So I want to do plus/4 gfx...
Yeah, I know, it's just another of those "laziness bugs"... But thanks.
|
|
Posted By
IstvanV
on 2007-09-14
09:41:17
| Re: So I want to do plus/4 gfx...
Another NTSC vs. PAL issue: I noticed that you average the chroma with the previous line in NTSC mode when using the video display emulation mode. Although I do not actually have any NTSC TV, so this could be wrong, but since there is no phase alternation like in PAL, I assume the vertical filtering is not needed ?
|
|
Posted By
IstvanV
on 2007-09-13
12:28:24
| Re: So I want to do plus/4 gfx...
When referring to normalization vs. not normalization, I meant different scale factors applied to U and V. The following simple program reproduces the colors of YAPE 0.76 with good accuracy (usually +/- 1 error for the integer RGB values):
http://www.sharemation.com/IstvanV/yapecolors.c
It can be compared to the code I posted on 2007-09-02, which is based on plus4emu 1.2.1 (there are a few minor color changes in 1.2.2, but that is not relevant). U and V are both multiplied by 0.18 there before the standard conversion, while in yapecolors.c, U is multiplied by 0.15 and V is multiplied by 0.21. The reason why I use the same scale factors for both U and V is that this way the hue and saturation are more consistent between the calculated colors and the screenshots (i.e. I get less variation in the chroma level), and also the phase angles for simple colors like red or green result in "pure" colors. But I could be wrong, or have a bad TV card.
I did not read the articles yet, but will have a look later. By the way, in digital video, U and V actually have the same range like I assumed it was the case in YAPE, although the colorspace is more accurately called YCbCr then. In analogue video, the V level is higher I think (by the 0.615/0.436 ratio), so if the TED generates a color subcarrier with a more or less constant amplitude, then my formulas are correct.
|
|
Posted By
Gaia
on 2007-09-13
08:23:17
| Re: So I want to do plus/4 gfx...
Some of your results are indeed very close to my hue table and others are somewhat off. Maybe my YUV->RGB conversion formulas are different, because I don't do normalization, I just clamp illegal RGB values as they come (not very nice). I see you have posted yours. I'm gonna compare them with mine. To be honest I did my own RGB->hue calculations but I also relied on external apps that's how I came up with a range of hue values (min,max) instead of one.
At one stage I think it'd be important to gain common ground on the palette issue, let's not have the misery that plagues the C64 emulation world.
I am not sure if you have read the article 'All you wanted to know about the VIC-II colours'. It has a few glitches but that was basically the basis for the Y'UV based palette. The most interesting part is a mail that was written by Bob Yannes, one of the designers of the VIC-II chip. Although the TED was done by a different guy, they might have kept some of the characteristics like choosing hues from opposite sides of the color wheel. Another good reference would be Charles Poynton's article(s) about color conversions (albeit that's mainly about digital video).
(BTW, while checking I have noticed I had a bug, the NTSC hue lookup table was being ignored since a few releases. So even if I had there 350 for the dark blue, the PAL value was showing up....)
|
|
Posted By
IstvanV
on 2007-09-10
16:08:41
| Re: So I want to do plus/4 gfx...
I simply used screenshots from tvtime, with various tricks to get the most accurate results. But I think the main reason why you get different values is actually the formulas used. Here is some simple code with which I convert r, g, and b (in the range 0 to 1) to y, u, v, p (phase), and c (chroma level):
double y = 0.299 * r + 0.587 * g + 0.114 * b;
double u = 0.492 * (b - y);
//u /= (0.886 * 0.492);
double v = 0.877 * (r - y);
//v /= (0.701 * 0.877);
double p = std::atan2(v, u) * 45.0 / std::atan(1.0);
if (p < 0.0)
p += 360.0;
double c = std::sqrt(u * u + v * v);
Notice the commented out lines. Those would normalize u and v to the range -1 to 1. From a screenshot of YAPE, I assume that you use equations where u and v are normalized. That is, I get more consistent results when I enable the commented out code. The following table shows the phase angles of simple RGB colors like #ff0000 etc. calculated with either formulas:
Red 103.5 108.6
Green 240.7 231.6
Yellow 167.1 170.8
Blue 347.1 350.8
Magenta 60.7 51.6
Cyan 283.5 288.6
The ones on the left are based on my conversion code, and should look familiar.
|
|
Posted By
Gaia
on 2007-09-10
12:01:05
| Re: So I want to do plus/4 gfx...
The dark blue does indeed not look like blue but more like very saturated pink/purple-ish. Orange may have the same phenomenon, but less visible. I am still not sure about green, on my machine I never really got the green phase values of the spec, apparently you did (which reminds me the HongKong made TED chip topic a bit).
I am not sure how you have measured, but ideally - assuming noone has a vectorscope these days of course - one could take the source for a TV tuner program (DScaler, TVtime) and adjust it to dump basically all the signals, not just colors. I always wanted that but never found the time and will to get around doing it.
|
|
Posted By
IstvanV
on 2007-09-10
11:30:19
| Re: So I want to do plus/4 gfx...
I have now done similar tests for NTSC on the same machine, using the TLC NTSC trick to have the colors appear on a PAL display. The results are (documented, measured, converted to PAL/YUV):
70 69.7 (102.7)
250 245.5 (278.5)
20 22.6 ( 55.6)
208 211.6 (244.6)
314 311.9 (344.9)
134 138.8 (171.8)
90 92.3 (125.3)
115 120.5 (153.5)
162 161.6 (194.6)
50 47.5 ( 80.5)
232 229.7 (262.7)
290 289.6 (322.6)
350 350.4 ( 23.4)
180 180.2 (213.2)
The dark blue color is now almost exactly as documented, unlike in the PAL case. It does not really look like blue, though. The orange is indeed different, but that could still be just random inaccuracy.
Until now, I have assumed that the NTSC colors should look the same as PAL. But the difference can be emulated, I will just need a total of 20 colormaps instead of 16 to reproduce all possible effects.
|
|
Posted By
Gaia
on 2007-09-09
17:10:56
| Re: So I want to do plus/4 gfx...
I don't know the right value either, right now I'm using 7 for PAL and 23 for NTSC because the NTSC color phase (23 - 33 = 350) does look good and comes out at around the same value when comparing with a screenshot. So, there must be some discrepancy with the PAL vs NTSC phases. It'd surprise me if they had used separate resistor banks for them, so it's maybe a chip bug. Or it could be some decoder hue related issue that only NTSC has? Also, PAL values usually are just phase shifted by 33 degrees, but orange seems to be off, so that could be a typo (in the NTSC column in this case, I suspect).
By the way, I was getting more like ~223-233 for green on my machine (maybe other colors were also different)...
|
|
Posted By
IstvanV
on 2007-09-09
08:01:50
| Re: So I want to do plus/4 gfx...
More on the colors: below is a list of phase angles from the TED specs, compared to values calculated from screenshots of a real machine (the number in parentheses is the chroma level calculated as sqrt(u*u + v*v)). Most of these are quite close, but "dark blue" is very different. Does anyone know what it should really be ?
103 103.7 (0.178) Red
283 282.2 (0.180) Cyan
53 51.4 (0.175) Magenta
241 239.9 (0.185) Green
347 346.6 (0.171) Blue
167 167.2 (0.184) Yellow
129 130.8 (0.180) Orange
148 147.1 (0.180) Brown
195 195.5 (0.185) Yellow-Green
83 88.6 (0.176) Pink
265 269.0 (0.184) Blue-Green
323 321.5 (0.174) Light Blue
23 0.2 (0.172) Dark Blue
213 214.6 (0.183) Light Green
|
|
Posted By
IstvanV
on 2007-09-09
07:36:13
| Re: So I want to do plus/4 gfx...
Regarding the interlace code, it is still not exactly like the TV standard. There are 624 (311.5 + 312.5) lines instead of 625, and the equalization and vertical sync pulses are also slightly different. So, it may not necessarily work on all TVs, and probably does not work yet on emulators other than plus4emu. Here is the original version.
I have added a simple 'dec $ff1d' to fix the colors, and the FF1E writing is adjusted so that the change is closer to an exact half line (28 and 29 characters).
|
|
Posted By
Csio
on 2007-09-05
10:44:44
| Re: So I want to do plus/4 gfx...
ingo-krakking-house rullering all over the plus4 scene!
gfx box #55!!!!
|
|
Posted By
Luca
on 2007-09-05
03:53:38
| Re: So I want to do plus/4 gfx...
The Dynamic Duo is dangerously packing, gosh Oswald!
|
|
Posted By
Degauss
on 2007-09-05
03:45:51
| Re: So I want to do plus/4 gfx...
Oswald!
You know it: Throwing out things is more easy than putting things in - Almost as easy as passing arrays around. Looking forward to your mail...
|
|
Posted By
Oswald
on 2007-09-05
03:32:05
| Re: So I want to do plus/4 gfx...
Dr. Death,
Thanks for the offer, I'll take it However ATMO I don't plan to add support for variable X shift / line, and interlace for colors. (makes things hairy on a lot of levels) Other than these I can make a great use of your converter. I'll drop you a mail, and then we can talk about the details. Please note that my coding skills are weak regarding modern platforms, but I hope we can work out how to pass arrays and stuff around
|
|
Posted By
TLC
on 2007-09-05
02:56:22
| Re: So I want to do plus/4 gfx...
István: the routine above that you have posted looks like a firstie; ie. the first known routine to create correct interlace mode on Plus/4.
|
|
Posted By
Luca
on 2007-09-05
01:38:20
| Re: So I want to do plus/4 gfx...
Pufffff, I'd seen the Dr. Death's gfx stuff months ago but it continues to impress me anytime... 
|
|
Posted By
Degauss
on 2007-09-04
19:27:43
| Re: So I want to do plus/4 gfx...
Hi Oswald!
I did a converter that does the things you're asking for. It tries to make use of as much TED-registers (BG/FG-Color and X-Scroll-Register) as possible while doing FLI every 2nd line. The algorithm is "close to brute force" but also tries reduce the set of parameters to be tested. You can tell the converter how "deep" to test against an optimal solution.
Here's a glimpse of my converter's output. Try these in YAPE:
http://www.jache.de/download/overscan.zip
(The Images are all interlaced, overscan and make use of the X-Scroll-Register, so the effective resolution is 304x264)
Most of the other options (dithering, deflickering, contrast/saturation-adjustment, etc) won't be of any interest for your application. But another fine feature is support for overscan-images that are 264 lines in height. There are some troubles with memory-layout with images that large, my converter handles all this.
The converter was coded in Delphi, but i could make a DLL that interfaces with your VB-Code - that would solve the "speed-problem" you were talking about. Tell me if this is interesting, and i send you the converter incl. sources (which look pretty messy ). Maybe we can have a talk about how a DLL-interface for your app could look like.
I would love a cooperation since i always wanted to extend my converter to a paint-program but never found time.
|
|
Posted By
TLC
on 2007-09-04
18:00:03
| Re: So I want to do plus/4 gfx...
If not him, I'm gonna do that... no, just kidding, but seriously, sitting on a high horse and spitting is dull. I did like your works I'd seen on C64 previously, but these recent comments here, well, didn't help me to maintain my respect to you, sorry to say that.
|
|
Posted By
Oswald
on 2007-09-04
13:36:13
| Re: So I want to do plus/4 gfx...
okay, done so far regarding plus4 mode:
- user control, which can display the various palettes, report clicks, etc.
- handling of different palettes / different mahcine types (lot of gui rewrites)
- paletted brightness color filter
- color sensitive color filter
- editor for the Hue-Brightness table which is used by "color sensitive" mode
- such a table in the mentioned editor
- users will be able to edit these tables and use their own
todo (only regarding plus4):
- color restriction for multi/hires mode
- setpixel routine for multi/hires
- IO
- ability to change the 2 background color each line
questions:
-can someone support me with a native plus4 all round displayer for plus4 executables?
-is it possible to change the 2 background color on each line while doing fli every 2nd line? (if so Im all to support it, d800 is missing badly)
any coders around? looking for a nice way to optimise background colors / line in the converter. ATMO my idea is to check what colors are missing the most, and use those. Sadly brute force is not an option as 121x121 cases / line is too much.. (for VB that is, could be fast enough in other languages
|
|
Posted By
Oswald
on 2007-09-04
13:20:46
| Re: So I want to do plus/4 gfx...
MagerValp, go and tell graham, fsf, the vice team, bsa, and the police.
|
|
Posted By
MagerValp
on 2007-09-04
05:09:24
| Re: So I want to do plus/4 gfx...
Well, the VICE team and the FSF does, so...
However, maybe Graham can be convinced to provide an implementation under a more permissive license.
|
|
Posted By
Oswald
on 2007-09-03
10:37:48
| Re: So I want to do plus/4 gfx...
Mager, I couldnt care less.
|
|
Posted By
Archmage
on 2007-09-03
09:26:05
| Re: So I want to do plus/4 gfx...
Yay! Just to let you tech-heads know: I am really really looking forward to using this! Keep it up, good Oswald!!! :D
|
|
Posted By
MagerValp
on 2007-09-03
09:08:15
| Re: So I want to do plus/4 gfx...
Oswald: VICE is GPL'd, so if you take the PAL emulation from VICE and put it in a DLL, you have to GPL all projects that link to it. This is why libraries are usually LGPL licensed...
|
|
|
|
Posted By
Chicken
on 2007-09-02
16:33:03
 | Re: So I want to do plus/4 gfx...
It wasn't visible on my (long gone  ) Commodore monitor either but my PHILIPS monochrome (amber) monitor lets you adjust the display so that you can see the complete borders (and more ).
Cool that you were able to reproduce it. Just judging from the screenshot it looks like what I saw. I never saw this on a color monitor so what happens if you write different values to $ff19 (not just shades of black)? Do you get colors in that vertical line or just "luminances" (ie greys)? If I remember TLC's screenshot explained that (I think only luminance had an effect) but I don't have it here.
|
|
|
|
Posted By
Chicken
on 2007-09-02
07:16:32
| Re: So I want to do plus/4 gfx...
Siz said...
"(BTW I can remember that on my friends black and green monochrome monitor we were able to see the difference between the shades of black.)"
I can't second this but I noticed a vertical line on the very left border which changes its luminance for the various "black" settings of the border color ($ff19). This vertical line is about 4 pixels wide (just a guess) and left of the "normal" border area.
TLC sent me an oscilloscope screenshot which illustrated this.
So in fact there are differences in the "shades of black"
Istvan:
Have you noticed this line? I don't think emulating is necessary and it won't add "beauty" to the display part. However, for completeness maybe we should look into this.
|
|
Posted By
Oswald
on 2007-09-02
07:07:30
| Re: So I want to do plus/4 gfx...
btw, is there no TRUE white color on the TED ? a color that is brighter than anything else ?
because at the end of a color gradient when you get a 24 bit white color which has hardly HUE information, there's no way to tell which of the 16 brightest hue to use...
|
|
Posted By
IstvanV
on 2007-09-02
06:51:24
| Re: So I want to do plus/4 gfx...
A minor correction: in the line 'y = brightnessToYTable;', there should be an array index of 'b' (it was converted to bold formatting by the forum software).
|
|
Posted By
IstvanV
on 2007-09-02
06:47:38
| Re: So I want to do plus/4 gfx...
Looks like I was a bit late with posting By the way, the actual formulas used for calculating these colors might be more useful than just the resulting table. The following code converts 'color' (0 to 255) to red, green, and blue values that are identical to those in p4pal1.txt. colorPhaseTable[] is mostly based on the TED documentation, while brightnessToYTable[] and the constants 0.032 (for black) and 0.18 (chroma level) are from the picture of my Plus/4.
static const float brightnessToYTable[8] = {
0.180f, 0.238f, 0.265f, 0.345f, 0.508f, 0.661f, 0.748f, 0.993f
};
static const float colorPhaseTable[16] = {
0.0f, 0.0f, 103.0f, 283.0f, 53.0f, 241.0f, 347.0f, 167.0f, 127.5f, 148.0f,
195.0f, 83.0f, 265.0f, 323.0f, 1.5f, 213.0f
};
int c = color & 0x0F;
int b = (color & 0x70) >> 4;
float y = 0.032f;
float u = 0.0f, v = 0.0f;
if (c)
y = brightnessToYTable;
if (c > 1) {
float phs = colorPhaseTable[c] * 3.14159265f / 180.0f;
u = float(std::cos(phs)) * 0.18f;
v = float(std::sin(phs)) * 0.18f;
if (y > 0.975f)
y = 0.975f;
}
float red_f = (v / 0.877f) + y;
float blue_f = (u / 0.492f) + y;
float green_f = (y - ((red_f * 0.299f) + (blue_f * 0.114f))) / 0.587f;
int red = int((red_f > 0.0f ? (red_f < 1.0f ? red_f : 1.0f) : 0.0f) * 255.0f + 0.5f);
int green = int((green_f > 0.0f ? (green_f < 1.0f ? green_f : 1.0f) : 0.0f) * 255.0f + 0.5f);
int blue = int((blue_f > 0.0f ? (blue_f < 1.0f ? blue_f : 1.0f) : 0.0f) * 255.0f + 0.5f);
|
|
Posted By
Oswald
on 2007-09-02
06:40:53
| Re: So I want to do plus/4 gfx...
thanks for the help.
in the work version I can already "convert" into plus4 hires fli, however no attribue handling / pixeling ability whatsoever is done yet. but the results are very promising
|
|
Posted By
IstvanV
on 2007-09-02
06:24:35
| Re: So I want to do plus/4 gfx...
The format of the text files is simple interleaved r, g, b, r, g, b, etc. values. So for 256 colors (of which the second half is actually redundant) there are a total of 768 numbers. The first three are for color #0, the fourth to sixth are for color #1, the seventh to ninth are for color #2, and so on. The 12 numbers per row is not significant, it is only formatting.
|
|
Posted By
Archmage
on 2007-07-18
05:18:30
| So I want to do plus/4 gfx...
... but I'd really prefer using mouse to ye olde way of joystick/arrowpad. I've tried Pixelshop, which didn't really work for me. For one I don't think I got it to work properly, as I only got black and white. Maybe it's just me.
So, is there any other Win-based software that have save formats for the 264 family?
Alternatively, I've been thinking about painting in Photoshop with the colour and size restrictions of the plus/4. But this means I need a plus/4-palette file for Photoshop. Any of those around? And how should I go about converting them? I have a lot of trouble getting the java based conversion tools on this site to work properly. Maybe it's just me again.
Help appreciated!
Arch
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
