Jump to content
IGNORED

mode4 clash fixer tool


rensoup
 Share

Recommended Posts

40 minutes ago, rensoup said:

Tried a 2nd picture with the tool... 

 

thesargeC64.png.166c2606b43baadbb6e7b3d2cea9360a.png  thesargeA8.png.c9e2575e817e4972d21e1bfca9d3a2ce.png

 

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

 

Nice

40 minutes ago, rensoup said:
  • 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.

 

Not sure, if the C64 palette is correct either.

Typically, I chose color 1 for the C64 brown, and color 2 at a brighter value for the lighter red tone of the C64. The lighter red seems one step too dark on the conversion.

The rest is fine.

 

Link to comment
Share on other sites

The funny part with the Gollum picture is that is has been created on the C64 to show the depending lumas.

Possibly to show the superiority over the Amstrad, wich has only 3 (black, grey, white)

As it is done in fixed 5 lumas , it is naturally easy to adapt for the Atari. But then, it will be even more important to allow palette manipulations, to show the superiority over C64, Amstrad , and other 8 bits ;)

Did anyone see palette rotations in such pics? There is a little. Just like my MCS slideshows. Mostly the rotations were done to give some color to characters, of if some "FX" is shown.

The mighty part of the palette is the fx while looking at a running program. It just has to keep the artistic touch, to be impressive.

Edited by emkay
Link to comment
Share on other sites

On 7/27/2020 at 4:15 AM, emkay said:

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.

I'll probably support both modes as the differences are pretty small

Link to comment
Share on other sites

Keeping the registers of the colors changable, allows to do real pallette fx . 

Some added indexed colors should be possible. 

Some routine added that allows to set the chosen set of colors and the type of changing in a dedicated time ans speed. 

Till today I haven't seen that on the Atari. 

Imagine the color changes together with some changes of the image on the fly.

Standard, weird, or fierce... whatever... evil, friendly? Colors can add to the image... only on 8 bits, it has to be still images with fixed colors?

 

Link to comment
Share on other sites

8 hours ago, rensoup said:

Unfortunately that would make the kernel code up to 15% slower ?

 

Why?

 

Just a table besides the kernel  that keeps the changed register , the value, and the position in the RAM. 

Ofcourse including the intention to keep colors as less changed as possible.

Link to comment
Share on other sites

31 minutes ago, emkay said:

Why?

 

Just a table besides the kernel  that keeps the changed register , the value, and the position in the RAM. 

Ofcourse including the intention to keep colors as less changed as possible.

simply because reading color table cost more time than just an immediate value... LDA # vs LDA table or even LDA table,x

Link to comment
Share on other sites

48 minutes ago, Heaven/TQA said:

simply because reading color table cost more time than just an immediate value... LDA # vs LDA table or even LDA table,x

It's not what I'm writing about.

The kernel itself will not get slower, if some data is stored elsewhere, when the picture is created.  

 

From that data, you can get the placed colors , and do the same changes wherever that same value is stored.

Only the color changing will need more CPU , not the kernel.

 

Link to comment
Share on other sites

1 hour ago, emkay said:
2 hours ago, Heaven/TQA said:

simply because reading color table cost more time than just an immediate value... LDA # vs LDA table or even LDA table,x

It's not what I'm writing about.

The kernel itself will not get slower, if some data is stored elsewhere, when the picture is created.  

 


Yes it will for the reason Heaven gave you... 

 

15% is an extreme case, it really depends on how often the colors change, -not so much on the number of colors-.

 

You can have a 16 colors pic with few color changes and another 16 color one with changes all over the screen.

Link to comment
Share on other sites

1 hour ago, rensoup said:


Yes it will for the reason Heaven gave you... 

 

???

 

 

1 hour ago, rensoup said:

15% is an extreme case, it really depends on how often the colors change, -not so much on the number of colors-.

Why would some

lda $00, sta $1234

 

be faster than

 

lda $10, sta $1234

 

?

 

1 hour ago, rensoup said:

You can have a 16 colors pic with few color changes and another 16 color one with changes all over the screen.

 

That's why some index data table should be written, to have the chance of writing the colors new, after the screen has been finished.

So a color change routine could look there and adjust the colors afterwards, if recommended.  

Link to comment
Share on other sites

Let's say the table shows

 

1234, 10, 1111 (color register , value, memory position of the value change in the DLI whatever)

1235, 20, 2222

 

After a requested color change, the routine searches for all 10 values and changes them to , let's say 12.

The routine also changes the values in the table to the new one.

As the registers can change, the routine ignores the register number.

To assure not to change values to an exisiting one, there also could be a short table that keeps the amount of max. colors of the image, and which colors were in use already.  

 

Link to comment
Share on other sites

On 8/1/2020 at 2:43 PM, emkay said:

That's why some index data table should be written, to have the chance of writing the colors new, after the screen has been finished.

So a color change routine could look there and adjust the colors afterwards, if recommended.  

 

Well... That could actually work, it would be slow (with a table at least) but it would not slow down the kernel.

 

Not my priority though...

 

Link to comment
Share on other sites

scarlettC64.png.153cba4f87bd1fddd995dd56b5485915.png  scarlettA8.png.9a91e7d9d16f7be7ed9dd141b7c2b2c4.png

 

So here's another pic ( https://csdb.dk/release/?id=136765 ) ... This one's actually pretty easy to convert.

 

I'm realizing that it's not really possible to match the C64 colors (Scarlett had a serious tan at first!) so I picked them manually but it's a bit of a mixed bag.

 

 

scarlett.obx

Edited by rensoup
csdb
  • Like 2
Link to comment
Share on other sites

6 hours ago, rensoup said:

scarlettC64.png.153cba4f87bd1fddd995dd56b5485915.png  scarlettA8.png.9a91e7d9d16f7be7ed9dd141b7c2b2c4.png

 

So here's another pic ( https://csdb.dk/release/?id=136765 ) ... This one's actually pretty easy to convert.

 

I'm realizing that it's not really possible to match the C64 colors (Scarlett had a serious tan at first!) so I picked them manually but it's a bit of a mixed bag.

 

 

scarlett.obx 23.95 kB · 5 downloads

Sometimes it is better to change the colors from the original. 

That green shine in the eyes looks like excuse for the weird lighnting. Yellow light on the hair, green liegt on the eyes, white light on the lips....

In the Atari version, the hair and skin look definitely better.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...