mode4 clash fixer tool

[emkay]

2 hours ago, rensoup said:

To be fair, even with such a crap palette, the quality of some of the C64 pictures are mindblowing. Many are simply impossible to convert on the A8.

I show you something funny.... just to point to what is really missing here. 

Some decades earlier , I had some idea of showing colorful pictures with a very low CPU usage. It was also the goal to keep the use of the palette free. 

You might guess it, that it was intentional to give coders ideas ....

 

Well, I did some presentation effect, using the palette  . I did show the image in grey tones (fading in) , and then tuned the colors in. 

 

 

 

Guess what happened. 

 

 

About ten years later , I was talking about the MCS idea. A coder said that they did see my MCS collection , but they didn't see the use of it , because it takes too long to have the colors on the screen. 

That was one of that moments when I thought "the Atari must be cursed" ....

 

Edited July 1, 2020 by emkay

[+Philsan]

...and the interesting thing is, that this is vice-versa true, too. (Don't even have to take RastaConverter images for that...)

Exactly.

Some images are impossible for A8 (high resolution) and other images are impossible for C64 (more than 16 colors and faithful conversions from original pictures).

But Atari 400/800 came out 2.5 year before C64.

 

[rensoup]

3 hours ago, emkay said:

The POP picture could be an easy task. It uses only 11 colors and the border has a color. 

You cannot import a picture like that into G2F directly. A lot hand redraw is needed.

 

didn't say it was difficult, it was just an interesting coincidence...

 

3 hours ago, emkay said:

Even the gollum picture was done, changing the picture to 5 colors (grey) , and set the least used color to the background color . The 4 color import is error free then. Then I drew the missing color by editing the PMG. 

That's why I did this tool, to try to avoid messing too much with 5 color pictures by going through all possible combinations and let the user select one for exporting.

 

I would then be able to use this pic with another coloring tool... which I have yet to write.

 

3 hours ago, emkay said:

Both gollum picuters can be displayed one after one on the Atari. But C64 cannot show one of them at all. 

 

Really ? why ? (Not familiar with the c64 at all)

 

 

[rensoup]

2 hours ago, emkay said:

Well, I did some presentation effect, using the palette  . I did show the image in grey tones (fading in) , and then tuned the colors in. 

I don't like all of them but the sentinel eye pic is nice. Sphinx too, it's just 5 colors, right?

 

1 hour ago, Philsan said:

2 hours ago, Irgendwer said:

...and the interesting thing is, that this is vice-versa true, too. (Don't even have to take RastaConverter images for that...)

 

Exactly.

Some images are impossible for A8 (high resolution) and other images are impossible for C64 (more than 16 colors and faithful conversions from original pictures).

But Atari 400/800 came out 2.5 year before C64.

 

Sure, but I'm starting to look into Mode4 palette/PMG changes and the DMA cost for mode4 is so high that it's difficult to do a single full palette change (5 colors) at an arbitrary point on the screen. Yes you have PMGs but they are quite limited too.

 

The problem is that all those restrictions don't seem very compatible with real world cases. You can have lots of colors on screen but only a few in a large zone.

[emkay]

5 hours ago, rensoup said:

I don't like all of them but the sentinel eye pic is nice. Sphinx too, it's just 5 colors, right?

 

sentinel 8 colors

sphinx 6 colors

 

It's now 30 years ago. I wrote some conversion tools. Such multicolor picture converters weren't even in the mind by others, if you understand. The time killed the disks. 

You might know that back then some intros existed that showed the "powers" of the Atari with the content of a ripped and reduced to 4 color images from the C64. Some scroller below  and some POKEY tune was played.

 

Today a graphics tool on the PC could exist that allowed procedural graphics. A mix of  an emulation that shows the clear restriction, an editor that allows to edit the graphics as the Atari offers, and some active drawing helper plus some palette animator and a depacker... that would be great.

This would be a milestone and finally allow to create "100%" images. 

Graph2fnt is too buggy , and the editor somehow denies to use the Atari's features as they were given.

Rastaconverter uses far to much CPU with a very low gain of satisfying results. Just by the fact that it is not using character mode and, the hill climbing doesn't take care of details. 

 

 

 

[emkay]

5 hours ago, rensoup said:

 

 

Really ? why ? (Not familiar with the c64 at all)

 

 

The C64 just doesn't have the colors . 

Alike whatever image you see on the C64. It is somehow pinkish , lilac, or somethimes brownish. 

You never see a "golden" touch, or a blue field. Also, the Atari has no real red, there are more than 32 red tones, making a red scene possible. 

 

Remember:

 

 

 

 

Btw. : Why don't you give the method a try, to convert images from 5 to 4 colors and to use the PMg for the 5th (or more) color , to get rid of the color clash?

[superrune]

I always adjusted my Commodore monitor to compensate for the C64's somewhat earthy tones. If you boost the contrast and saturation just a bit on the Commodore 1084s, the C64 will look pretty incredible

[rensoup]

18 hours ago, emkay said:

Today a graphics tool on the PC could exist that allowed procedural graphics. A mix of  an emulation that shows the clear restriction, an editor that allows to edit the graphics as the Atari offers, and some active drawing helper plus some palette animator and a depacker... that would be great.

This would be a milestone and finally allow to create "100%" images. 

My project is a little more modest... I only need it for one picture after all.

 

It'd be more of a converter. The user create a picture in a way that helps it select what to output (by using layers). The converter would be aware of DMA timings of course.

I don't think there's any point recreating an art package just for this, it would just be inferior to all the art tools that already exist.

As for showing restrictions, we've got emulators... One problem is figuring out a way to get a decent turn around time between the art package and the emulator.

 

18 hours ago, emkay said:

The C64 just doesn't have the colors

Sure, I thought there were other restrictions.

 

18 hours ago, emkay said:

Btw. : Why don't you give the method a try, to convert images from 5 to 4 colors and to use the PMg for the 5th (or more) color , to get rid of the color clash?

It works for this image but when you have all 5 colors used all over the picture, it's just better to try fixing the clashes with the tool. The gollum pic has only 39 clashes but Superrune's PoP one has 181. 

[rensoup]

7 hours ago, superrune said:

I always adjusted my Commodore monitor to compensate for the C64's somewhat earthy tones. If you boost the contrast and saturation just a bit on the Commodore 1084s, the C64 will look pretty incredible

Don't say that too loud ?

[emkay]

7 hours ago, rensoup said:

My project is a little more modest... I only need it for one picture after all.

 

OK. Looks like you want to convert some title pic of a game in progress that is created in a C64 image tool.

 

7 hours ago, rensoup said:

It'd be more of a converter. The user create a picture in a way that helps it select what to output (by using layers). The converter would be aware of DMA timings of course.

Layers is a good hint.

 

7 hours ago, rensoup said:

I don't think there's any point recreating an art package just for this, it would just be inferior to all the art tools that already exist.

As for showing restrictions, we've got emulators... One problem is figuring out a way to get a decent turn around time between the art package and the emulator.

 

You mean "figuring out a way to convert graphics from one platform to the other"

 

 

7 hours ago, rensoup said:

Sure, I thought there were other restrictions.

 

It works for this image but when you have all 5 colors used all over the picture, it's just better to try fixing the clashes with the tool. The gollum pic has only 39 clashes but Superrune's PoP one has 181. 

 

In theory , if all is optimized, you get hard time to convert images from the C64 to the Atari.

Color Cells on the C64 can change 2 colors per cell.

On the Atari it is only possible when using GPRIOR 0. And then the logics were different.

The only real basis of conversion is the way to reduce everything to 4 colors. Then you could do an analyzing of bit pairs and resulting colors per cell. To adjust the pixel then to filter low detail variations and high detail variation. The low detail variations (for up to 3 colors. 2 playfield + 1 restricted background) ) to use for the color cell switches, when the 4x8 pixel range fits. The wider ranges can be colored with the 2nd layer, named PMg   .

You know, the C64's VICII could show thousands of colors, or even 256 colors, without the need of the CPU. But there are only 16 colors. There are also restrictions in color usage. Even the CPC can show more colors in games (it looks arcade like sometimes) , because it is possible to adjust the 16 available colors. And the MSX2 can offer a real VGA range of colors inside the available 16 colors.

So, in the Result, and if you put something more real to the images, the C64 only has the best results in the grey tones. As soon as color come to the image. You want a blue sky?  Well, you could use 6 colors. The "turkis blue" plus all grey tones for the clouds. You want a bird on it? Add 2 more colors.

The weird part is where C64 always uses pixel transition, to mix the available colors to suggest a new one. Those pixels destroy the image, the bigger the screen gets. On the Atari it is the same. But here very often could a single color remove a "block of pixellation". This looks nicer on big screens then, and reduces the need of more colors in a range, and allows to use a player , or a cell change, where it is needed to keep the details of an image.

 

If you read that correctly, you might find workable filter rules.

 

 

 

 

[rensoup]

13 hours ago, emkay said:

OK. Looks like you want to convert some title pic of a game in progress that is created in a C64 image tool.

Not exactly, the picture is greyscale so far (5 intensities)... For the coloring I'm figuring out what's possible per scanline and then I'll incorporate that in my converter.

I'd like to have PMG repos/resize/recolor, prior0 (not all at once on the same scanline of course.)

 

[emkay]

1 minute ago, rensoup said:

Not exactly, the picture is greyscale so far (5 intensities)... For the coloring I'm figuring out what's possible per scanline and then I'll incorporate that in my converter.

I'd like to have PMG repos/resize/recolor, prior0 (not all at once on the same scanline of course.)

 

Hm. Why the restriction to 5 lumas? If it is only about 1 picture, could I help with something? Sometimes I like to go through some masochism and use G2F for something special

[rensoup]

4 hours ago, emkay said:

Hm. Why the restriction to 5 lumas? If it is only about 1 picture, could I help with something? Sometimes I like to go through some masochism and use G2F for something special

I'm not sure why Supperune chose 5 but it looks pretty good. Anyway, I'd rather use PMGs with prior0 to try and get more colors.

That picture is going to need a lot of tricks and perhaps compromises so it needs a custom solution (unfortunately).

 

I'll be posting updates of the tool for anyone to try.

[emkay]

5 hours ago, rensoup said:

I'm not sure why Supperune chose 5 but it looks pretty good.

 

hmmm....

 

https://csdb.dk/release/?id=158857&show=summary

 

 

5 hours ago, rensoup said:

 

 

 

 Anyway, I'd rather use PMGs with prior0 to try and get more colors.

 

Why not, if the image allows that?

At the end of the day it will be needed to change the graphics in dedicated blocks. Doin that before it will be imported to any atari format, might offer a lot time saving. 

 

 

5 hours ago, rensoup said:

That picture is going to need a lot of tricks and perhaps compromises so it needs a custom solution (unfortunately).

 

I'll be posting updates of the tool for anyone to try.

 

I'm watching

[tebe]

HCM-0 (Prior = $00), HCM-2 (Prior = $24)

[tane]

By the way, I'm looking for an artist for an ending screen of this game. It started as a just a couple of hours parallel project, but now it'll have several enhancements, and it deserves one more addiction to be even better:

• It must be G2F, 1 screen is enough.
• Related to the end of the game, with similar graphics style.
• Artist's credits can be embedded in the image.
• If you're motivated, PM.

 

 

 

[rensoup]

 

After quite a bit of work on my coloring tool, here's the first colored picture I've managed to get out of it:

 

At least now I understand the limits of changing graphics registers mid scanline (it's worse than I thought!):

 

1.Changing colors on time is very limited, 1 color change would be done somewhat accurately but anything more and you're off by many pixels. 

2.Changing PLAYERs attributes is a bit more more flexible (currently unsupported) although still not that great.

3.Changing MISSILEs attributes is a bad idea due to the register sharing on MISSILE sizes. 

The best part is of course that none of the above works in mode4 because mode lines eat every cycle while the line is displayed ?

 

So yeah Mode4 is as crap as ever... (Only good pratical use of it I've seen is Playsoft's Galaga port) which means it's a bit of dead end but I'll keep doing more tests to see how much more I can squeeze out of it.

Then I'm probably going to switch this tool to ModeE...

Side note: Now that I understand DMA use, I'm even more gobsmacked that the original ANTIC & GTIA designers implemented 4 MISSILES instead of 4 extra PLAYERS (3 extra cycles only!!)

 

2nd Side Note: I fixed the color matching code so it's closer to the original (I thought perhaps some postprocess was applied in Altirra but that's not the case)
 

gollum.obx

Edited July 25, 2020 by rensoup
added 2nd side note

[Synthpopalooza]

I did this once ... but it uses a flicker mode.

 

does a good job on most c64 pix tho.

 

[emkay]

6 hours ago, rensoup said:

 

After quite a bit of work on my coloring tool, here's the first colored picture I've managed to get out of it:

 

 

 

Looks great. 

Could be the missing link between G2F and Rastaconverter  incl. best of both worlds .

 

[emkay]

Btw: Mode 5 and DMA .

You'll never get as good looking pictures, if you turn to Mode E.

Remember there is a "free" change within 40 columns of two colors, while midline changes on the left side are rather limited.

The limits could be changed by using the 1st or the 2nd line of an image to convert, to reduce the need of midline changes. Player positions also could be set "a line above" ... 

[rensoup]

On 7/25/2020 at 5:16 AM, Synthpopalooza said:

I did this once ... but it uses a flicker mode.

 

does a good job on most c64 pix tho.

 

Seems like you spent some time on this... My goal is not to convert C64 pics though even if I'm using some to test the tool. 

 

I think coloring done by an artist would give the best results too... 

 

Interesting read nonetheless.

 

[rensoup]

On 7/25/2020 at 8:43 AM, emkay said:

 

Looks great. 

Could be the missing link between G2F and Rastaconverter  incl. best of both worlds .

 

Thanks, I don't know where that tool will sit but I hope it can be recycled for more than just PoP... 

 

6 hours ago, emkay said:

Btw: Mode 5 and DMA .

You'll never get as good looking pictures, if you turn to Mode E.

Depends on the picture I guess ... that 5th color means 0 cycle available every 8th scanline so PMGs can't be repositioned on those.

 

6 hours ago, emkay said:

The limits could be changed by using the 1st or the 2nd line of an image to convert, to reduce the need of midline changes. Player positions also could be set "a line above" ... 

You still can't reposition PMGs in Mode4 (having 2 P0 on the same scanline) so you can't really set them 1 line early.

[rensoup]

Tried a 2nd picture with the tool... 

 

  

 

I guess you figured it out but C64 is on the left.

 

• It's only 7 colors but it works alright even though I did a pretty crap job with the PMGs...
• I used Prior 4 so PMGs are under the Playfield (I used Prior 0 for Gollum)... I can change Prior anywhere on the screen but I don't know if that'll be useful
• I added a rainbow at the bottom just because it's really easy. The glitch on the left is because I got the screen timing start wrong.
• The brown colors aren't perfect matches (search for the closest color in the Atari Palette)  didn't really look if there are better colors available.

 

thesarge.obx

Edited July 27, 2020 by rensoup

[Synthpopalooza]

27 minutes ago, rensoup said:

Seems like you spent some time on this... My goal is not to convert C64 pics though even if I'm using some to test the tool. 

 

I think coloring done by an artist would give the best results too... 

 

Interesting read nonetheless.

 

Ideally I would like to have an assembly routine that loads and displays the koalas in this PCIN mode.   The idea is, blending the 9 colors of Graphics 10, with the same PF0-PF3 plus BG of Antic 4.  Where PF colors overlap, checkerboard dithering can be done.

 

My method has two drawbacks:

 

1.  FLI's are not rendered 100%, black spaces appear.

 

2.  My method has problems with skin tones and some greys.  It might require a whole new color palette setting to fix these.  

 

But I think it was a good experiment.

[emkay]

38 minutes ago, rensoup said:

Thanks, I don't know where that tool will sit but I hope it can be recycled for more than just PoP... 

 

Depends on the picture I guess ... that 5th color means 0 cycle available every 8th scanline so PMGs can't be repositioned on those.

 

You still can't reposition PMGs in Mode4 (having 2 P0 on the same scanline) so you can't really set them 1 line early.

If you reposition the PMg, ofcourse it cannot be done in the DMA time.

Particular, if you convert images from C64 to Atari, 40 columns alignment is given.

Together with GPRIOR 0 , you have the possibility of adding 8 colors without any CPU cost.

I see the easier handling, if Mode E is used, because the logics keep the same every line. 

 

I hope, you will keep the mode 4 , because palette manipulations can be done on a still image for presentation enhancement, or simple recoloring afterwards, if color registers weren't exhausted in raster changes.

PMg repositioning granted