| Posted By
Charlemagne
on 2019-01-05
07:11:34
|  LUMYDCTT - RenderGFX - Need some help
Hello Everybody,
Well, I would like to implement a new feature in LUMYDCTT and I have already made some progress:
At this moment, you can ONLY render a picture (BMP, GIF, JPG, PNG and TIF) to a Black&White one and save it to a PRG (start at $2000), so you can see it if you load it after typing "GRAPHIC1,1" (or GRAPHIC2,1).
In the future I would like to make it more useful, so I need your help, such as:
- Graphicians (like MMS): What kind of softwares do they use for drawing their graphics? (eg.: Boredom: It looks like so clearly and colorful.)
- Coders (like Csabo): How can they show it? (I studied Larry's FLI Converter a little bit and the generated PRG.)
Do they use multicolor mode or manipulate some thing (eg. color attributes) on demand? ...and on this way they can cheat our eyes and we think of seeing more colors on the screen?
|
|
Posted By
gerliczer
on 2019-01-05
09:26:09
| Re: LUMYDCTT - RenderGFX - Need some help
IstvanV's plus4emu has a tool called p4fliconv. You should take a look at it to get ideas for your converter, what functions it should have and what modes it should support. IIRC, it also has some display routines in assembly source for the graphic modes. Obviously, you should give credit for everything you borrow from his tool, be it actual code or only non-trivial ideas.
|
|
Posted By
Csabo
on 2019-01-05
10:50:45
| Re: LUMYDCTT - RenderGFX - Need some help
The idea behind DFLI is simple. By default, in one character line (which is 8 pixels tall), you have 2 colors per character; foreground and background in hires, and two ink colors in multi. The colors themselves come from the color and luminance maps, which are specified by $FF14. In short: 2 colors for every 8x8 pixel area.
With DFLI, at every 2nd raster line, you change the value of $FF14, so that it points to a different color and luminance map. Therefore, you now have 2 colors for every 8x2 pixel area (or 8 colors for every 8x8 pixel area, if you want to put it that way).
Why the "D" in DFLI? We originally borrowed the name FLI from C64, where this exact same trick is done. The first FLI effects were done the same way, the MB part in Compy Xmas being the most prominent. I remember seeing that and being blown away by it  Anyway, so they changed $FF14 in every rasterline, which doesn't work out very well, and the color + luminance values get messed up. (This has been explained elsewhere, I don't want to go into the technical details.) To get around it, and have "proper" colors, we do this on every second line instead, so it's a "double" FLI.
That's it in a nutshell! Writing a DFLI routine is every coder's rite of passage, it's fine to look at other people's code, and then code your own variation, it's still going to be mostly the same.
Using interlace (quickly switching the pixels and colors at every frame) give even more colors at the cost of some flickering.
|
|
Posted By
MMS
on 2019-01-05
14:07:29
 | Re: LUMYDCTT - RenderGFX - Need some help
Hi! a really nice idea!
Thank you for mentioning me Actually I should say technically speaking I am more a user, but certainly happy to share my past experience.
(Larry even programmed his own tool, Chronos is more deeply involved in demo and game developments, and recently there are some new tools arised, Csabo and Luca are in everything )
Actually Csabo and gerliczer gave really useful technical details on the matter.
Let me share my view on the gfx creation process.
There are different approaches.
First, the dithering. Some people who creates gfxs, prefer zero dithering (George), Chronos is very good at nice dithering pics, while I try to keep it low, but the zero dithering is usually not enough for me. Larry even adds some noise to the original pictures because it works best with his converter's dithering routines, as the interlace routine seems to count special "off" colored pixels for the better color mix (and the final result is better).
Modes:
At the early years I preferred (multicolor) FLI (now we can call DFLI, as due to badline, really cannot 100% simulate the C64's FLI mode).
I had some initial slideshows with mixed modes (and mixed results ), tried to tinker with the different modes, including interlaced ones. Like the Conan slideshow (with uncompressed IHFLI pictures, huge. LOL)
I always felt, that with the 160x200 resolution (despite more available colors) we usually loose too much of the details, even in DFLI mode. It was evident when some fine details I wanted to keep, but was not possible with DFLI-
So in the few years I only made HFLI/DHFLI pictures with 320x200 resolution (or with IstvanV's routine, a little more vertical res than 200).
I think my first DHFLI one I really spent a lot of time to adjust the pictures, was the VDC Challenge.
Still, all those pictures are just converted pictures and the converted Plus/4 picture was NOT edited, just the original picture modified/finetuned several times in PC gfx editor to get a better end result (less bad pixels).
My method and tools (as you could read above, everyone uses his own method and settings)
-Basic picture editing, cropping tool for proper 1.6 aspect ratio: Irfanview
As a first step I usually reduce color depth to 128 or 64. I usually do not add Plus/4 palette, I select pictures look OKish with Plus/4 colors (green, blue, and golden colored pictures, also black/white are great. Red, orange colored pictures, and skin colors does not look too great with our palette)
Usually I add a median filter to prevent bad pixels popping up here and there. For this one in the past I used the Irfanview, but recently I changed to Paint.Net.
In Paint.Net I usually eliminate remaining orphan pixels and off colored areas. (if after conversion there are a lot of off colored dots, then I know that the color is NOK for the Plussy, Usually then I play with Gamma, or I recolor the area in Paint.Net to something better for the Plus/4. )
I use Plus4emu's gfx conversion tool with the GUI. The preview is a little too small to be really useful (so you continuoulsy need the YAPE or Plus4emu to doublecheck results. The source-code can be checked, but as I mentioned, I am just a happy user of the tool
Lot of great dithering methods, lot of settings for gamma, color saturation, etc. Really good.
Especially the X-shift is a great one if some areas are just not OKish. (but recently I had to stop using it)
After I see that the picture is >90-95% OKish, in the past I stopped here, saved e raw HFLI picture with maximum compression (it is lossless, so really great 9-10KB size even with the extra big attribute map), and IstvanV's slideshow routine made the rest.
In the last one year I started to use Abcug's Pixelshop to further edit the HFLI pictures. For that you need to save it into P4S format, and when I finished the job (eliminate of bad color zones, correct bad or orphan pixels, etc) IstvanV1's Plus4emu P4sconv will convert to the more you need (in my case: first check in PRG format, how it really would look on a Plus/4 (Pixelshop had a palette really does not work really well, so you need some level of imagination of the colors during editing).
There are soem setting ofn the meuat9ors worth to check.
While I really like Plus/4emu's picture, I found it a little overdithered. It means that in Quality 3 setting the gfx looks much better, than in reality. (and few years back I though my slideshows were better, than the reality 
YAPE's CRT emulation is just great.
Without CRT emulation the picture look too sharp, and you will never see such a picture on a CRT monitor, or even LCD TV.
|
|
Posted By
Charlemagne
on 2019-01-05
16:03:26
| Re: LUMYDCTT - RenderGFX - Need some help
gerliczer: thank you for this useful tip. I saw plus4emu in the old times, but I didn't recognize this converter. WoW, WoW and WoW again:
It's breath-taking and very fast. I like it!
Csabo: so, my first intuition didn't stand so far from the reality. AFAIK, in your sample demo found in Plus4IDE, you use $FF1E for waiting for horizontal position to change colors of lines. When you make DFLI, you use $FF1D instead and then change $FF14? Thank you for your explanation.
MMS: hmmm, you say... when I looked into Boredom source some weeks ago I could see IstvanV's slideshow routine??? I think you write programs to show your pictures, OMG I am so naive... Well you use some "simple" image editor to modify pictures in order to make its colours good for Plus4 and in the end you convert it into the proper type by a converter. How long does it take you to make a picture? Which one of your works was the most time consuming? What do you think about GIMP? Thank you for the detailed story.
Don't worry... I don't even want to reinvent the wheel. ...be happy.
|
|
Posted By
MMS
on 2019-01-05
17:35:58
| Re: LUMYDCTT - RenderGFX - Need some help
Hi,
The first time we saw IstvanV's routine is work, we were in a kind of shock too, I was in a picture conversion hype for some weeks Maybe I will find that thread...
Chronos made a lot of useful suggestions, and Istvan was kind to realize all those requests. I think he is also an outstading programmer.
GIMP is also nice, I have it. Paint.Net is a little oldschool compared to that, but starts much much faster.
My preferred one is AudoDesk Scetchbook, now it is competely free, worth to try it.
Very intuitive. (I use only legal programs, so do not have Photoshop and so, too expensive)
Time: when I have free time, I usually collect pictures from internet, make quick tests with 20-30 pictures collected and adjusted, and delete the less attractive ones. I just checked the folder I collect the photos/pictures for future/planned pictures slideshows (90% will hever happen).
Most of them are JPGs, and the folder size is 1.2GB, so you can imagine the quantity... LOL
Recently I switched to legal picture collecting sites, like 123RF, Shutterstock, Stockfresh, etc, to prevent legal issues.
They have better quality/less compressed images too (need less work before conversion).
The girl you see as the first picture of the VDC challenge took the most of my time, as I did no use the HFLI editor, but modified the original pic several (dozen) times to remove gliches. Well, it took maybe 12-15 hours with all the steps, but it was extreme case. Usually I finish such a picture with all those editing in less than 2 hours, or if it is beyond hope, I drop it and choose an other one. On the internet there are millions of good pictures.
Garfield was 8-10 hours to made, but mainly because I had to redraw the colorful logo with hands, and it is hard to put so many colors in hires on the screen. Seems the scene did not like it so much, though I think it is better than any Garfield picture made on C64
The last HFLI picture took a little more time, as it was a collage work with layers and fontsets, etc, and edited the picture in Abcug's Pixeslshop for some hours.
Maybe 7-8 hours in total, but I still improve it further to use in a new slideshow.
So collecting and converting pictures for yourslef could become a real hobby alone 
|
|
Posted By
gerliczer
on 2019-01-06
08:34:10
| Re: LUMYDCTT - RenderGFX - Need some help
About Charlemagne's question on FLI code. No, you don't wait in loops in FLI display routines. It must be quite tightly coded, especially when you want to change $FF15/$FF16 colours as frequently as it can be done, because you will trigger bad lines continuously. Therefore you will have 22(+3) cycles to do everything related to colour and luminance matrix change under quite strict timing constraints on bad line triggering. You can look at one half botched implementation in my Sweet DFLI C16 intro's source.
|
|
Posted By
MMS
on 2019-01-06
13:06:31
| Re: LUMYDCTT - RenderGFX - Need some help
BTW One question: changing attribute memory due to TED and CPU access may take some time and does not fit into the rastertime --> logically you can change every second line.
On the other hand, changing the background and 3rd color should be a much faster process. If I remember well, these two are also changed in every second line only.
Is it not possible to change these two color registers in every line, and all four in every second line?
I mean current method is easier to understand and work with, on the other hand for me it seems to be and area of further improvement of the format. (if I am correct with the current method)
|
|
Posted By
gerliczer
on 2019-01-06
13:38:47
| Re: LUMYDCTT - RenderGFX - Need some help
I think you misunderstood how FLI works, MMS. The attribute memory change does not take two raster lines, it can be done in one. But bad lines, where the TED reads attribute data, come in pairs, therefore you have to do $FF14 and $FF06 writes in every second line, unless you want colour and luminance maps mixed up. One load-store pair (sg like LDA im, STA abs) takes 6 clock cycles, so one could naively think that four updates could be done per raster line as there are up to 22+3 cycles in a bad line, but the $FF06 write must happen exactly at a specific cycle in the line which makes four register updates not feasible. AFAIK, even three is only doable with trickery.
|
|
Posted By
Charlemagne
on 2019-01-06
15:30:01
| Re: LUMYDCTT - RenderGFX - Need some help
While studying Multicolor mode a little bit...
Maybe... I discovered a bug in a description on Plus4World:
plus4encyclopedia/500234
Because of the followings say $1800 is luminance and $1C00 is colours:
1.: https://www.floodgap.com/retrobits/ckb/secret/264memory.txt
2.: https://www.c64-wiki.com/wiki/Commodore_Plus/4
What's more... I realized (what you know) that it seems the values of luminances are not in the same order as colours. It's interesting for me.
gerliczer: I will see your program, but now I would like to understand the basic theory in order to convert.
MMS: Do you use Multipaint by Dr. TerrorZ? It's brilliant and master piece. It helps me a lot to understand the colorization of Commodore Plus/4. So, I see whiz kids here, there and over there...
BTW, thank you for your helpfulness. Everything is useful.
|
|
Posted By
gerliczer
on 2019-01-07
02:35:01
| Re: LUMYDCTT - RenderGFX - Need some help
Well, actually, you don't have to understand the theory just to convert. You need that only if you want to write the display routine yourself. But that's not really necessary in a development tool, isn't it? 
|
|
Posted By
Luca
on 2019-01-07
02:38:40
 | Re: LUMYDCTT - RenderGFX - Need some help
Charlemagne: that text has been edited by George, ask him to fix it or do it by yourself, thank you.
|
|
Posted By
Charlemagne
on 2019-01-07
09:01:55
| Re: LUMYDCTT - RenderGFX - Need some help
gerliczer: I feel a very-faint irony in the back of your words, because I need to know a lot of things to convert a picture, of course... The aim of this converter is that you create GFX easily for your projects.
(For example, you perhaps do know a lot about flying, in vain, if you step out of the window on the forty-seven floor and you don't keep yourself on the air... ...unless you are Batman or Neo in the Matrix... ...and reading books is a time-wasting activity, if you don't know letters...)
Luca: OK, I sent a private message to George.
|
|
Posted By
MMS
on 2019-01-07
12:03:44
| Re: LUMYDCTT - RenderGFX - Need some help
Multipaint:
It is a fantastic GUI tool, and used it during the creaton of Sin City scene (a small animation with the help of Csabo), maybe two years ago. (BTW before that I made the changes in native MultiBotticelli and Botticelli (in emulator), I really like them)
On the other hand I dedicated myself to (D)HFLI mode (less limitations) and PETSCII (aa LOT of limitation) and do some experiment in SPECM (C64: Krissz editor), so in the last years I did not use Multipaint so much.
I see some ppl can create fantastic things in normal HIRES or MC, but those are beyond my humble skills...
|
|
Posted By
Chronos
on 2019-01-07
14:15:43
 | Re: LUMYDCTT - RenderGFX - Need some help
Before Pc age my workflow looked like: Sketch on paper, put a foil on it and using a marker to draw the lines and after i taped it onto the tv screen. Then i wired it into multi botticelli, spent countless hours on putting pixels here and there. Now i'm using Paint Shop Pro (and sometimes PhotoShop and Corel Draw) since ages for my graphics.
I have tested all the converters and i can say Pixel Polizei suits my needs the best. PP handling the multicolor limitations excellent! The second place on my imaginery top list is IstvanV's converter, but sadly there are some false color on the converted image. I've tested numerous times Dfliconv2 recently, and it can be excellent too, but there is some false (and dark) colors yet. Maybe we can do a better and brighter palette The other nasty thing about D2 is its non existent gui so you need to use tons of command line parameters
I hate most of the graphics tools written for commodore plus4 (both on pc and plusi) because they aren't handy, most of them written by programmers for programmers so using it a major pain in the ass
|
|
Posted By
Charlemagne
on 2019-01-11
16:15:05
| Re: LUMYDCTT - RenderGFX - Need some help
MMSZ: I don't know a lot of things, but I learn and try to do my best to make useful applications. I got some knowledge of PETSCII (http://www.kameli.net/marq/?page_id=2717) and turned out its author is the same as Pixel Polizei (later). What's more... it was used for Digiloi, too.
Chronos: Thank you for sharing your old and new drawing experiences. Well, in the old times, you drew so complex way as I made heroes of my programs: bit-after-bit in a checked exercise-book. Nowadays (in spite of MMS) you like using expensive editors for your graphics. GIMP, no, why? I had a closer look at Pixel Polizei:
At first glance it seems to be good and very fascinating, but after reading about it:
"There’s not much to it: load an image, check whether it’s ok and save it in another format. In the case of errors you can either fix them in your favorite paint program and retry or force the colors to comply."
It is a little bit ridiculous, because it is "only" a checking application and you have to use another program to correct the image.
Secondly if you zoom in the loaded picture you can realize that it's "only" an interpolated image, not a converted one, so you need a lot of extra work in order not to be a pain in your ass...
BTW: Here is the latest (and not completed of course, development in progress) LUMYDCTT v3.3.3:
Now you can set the sensitive value (Finetune: 0..255) of a "Black & White" picture.
I managed to find in my mind (it took some days) a nice interpolation of colours and you can see it if you check "320x200x128c" option (the rendered image only consists of the 121 colors of Commodore Plus/4 and uses all the colours not only 2 per 8x8).
You can select (Frame 1 or 2) which pixels are considered while rendering.
At the moment there is no a viewer before the picture, so it is not easy to see, but no impossible either:
1.: GRAPHIC4,1
2.: Load PRG... (F8)
3.: POKEDEC("FF15"), PEEK(DEC("1800")+1001)
4.: POKEDEC("FF16"), PEEK(DEC("1C00")+1001)
5.: GRAPHIC3,1
6.: Load the program again!
3, 4: Positions of 1000: luminances and colours of "background"($FF15) and "extra color"($FF16) are stored just like other values... ...$1800+1001: suitable value for $FF15... and ...$1C00+1001: suitable value for $FF16...
Have a painless rendering!
|
|
Posted By
Chronos
on 2019-01-14
05:38:52
| Re: LUMYDCTT - RenderGFX - Need some help
great news, i'll test your stuff soon!
|
|
Posted By
Charlemagne
on 2019-01-17
16:15:39
| Re: LUMYDCTT - RenderGFX - Need some help
Chronos: Thank you for testing...
Maybe..., another good news in LUMYDCTT v3.4.7:
Yes, here a little embedded editor goes. You can edit the rendered picture in "Black & White" and "Multicolor" mode. Multicolor editor is a little bit tricky because of double pixels.
0.: Load a picture.
1.: Select a part (a character from 40x25) on the rendered image.
2.: Click on it.
3.: Edit it by left-and-right mouse buttons.
The background ($FF15) and extra ($FF16) colour changing hasn't worked in the editor yet. Please, be patient.
Have a colorful editing!
[UPDATED]
Here is LUMYDCTT v3.5.5:
You can:
- edit the rendered picture
- save/load the edited picture
- set the quality
[UPDATED AGAIN]
LUMYDCTT v3.6.0:
+ Finetune (1..7) for "Multicolor"
+ Fix some bugs
+ Zoom the rendered image back (RMB)
+ Optimizing the render function (only when need)
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
