emkay Posted July 27, 2020 Share Posted July 27, 2020 40 minutes ago, rensoup said: 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 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. Quote Link to comment Share on other sites More sharing options...
tebe Posted July 27, 2020 Share Posted July 27, 2020 Gollum_C64_Rensoup_Tebe.g2f Gollum_C64_Rensoup_Tebe.xex Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 27, 2020 Share Posted July 27, 2020 That is such an amazing image. I still cannot believe what can be done with 160 pixels and a single digit number of colours! Great work all around. Quote Link to comment Share on other sites More sharing options...
emkay Posted July 28, 2020 Share Posted July 28, 2020 (edited) 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 July 28, 2020 by emkay Quote Link to comment Share on other sites More sharing options...
rensoup Posted July 28, 2020 Author Share Posted July 28, 2020 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 Quote Link to comment Share on other sites More sharing options...
rensoup Posted July 28, 2020 Author Share Posted July 28, 2020 On 7/27/2020 at 11:41 PM, tebe said: Gollum_C64_Rensoup_Tebe.g2f 7.85 kB · 9 downloads Gollum_C64_Rensoup_Tebe.xex 11.98 kB · 14 downloads Are you using my clash fixer tool while claiming you authored this pic entirely in G2F ? Quote Link to comment Share on other sites More sharing options...
rensoup Posted July 28, 2020 Author Share Posted July 28, 2020 On 7/27/2020 at 11:49 PM, Stephen said: That is such an amazing image. I still cannot believe what can be done with 160 pixels and a single digit number of colours! Great work all around. Absolutely (here's the source https://csdb.dk/release/?id=94476 ) 100% handrawn too ? 2 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted July 29, 2020 Share Posted July 29, 2020 What I'm about is to add the color FX everywhere when possible. Tebe did a nice fade in already. Colors can do their own work. A small demonstration... 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted July 29, 2020 Share Posted July 29, 2020 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? Quote Link to comment Share on other sites More sharing options...
rensoup Posted August 1, 2020 Author Share Posted August 1, 2020 On 7/29/2020 at 11:37 AM, emkay said: Keeping the registers of the colors changable, allows to do real pallette fx . Unfortunately that would make the kernel code up to 15% slower ? Quote Link to comment Share on other sites More sharing options...
rensoup Posted August 1, 2020 Author Share Posted August 1, 2020 So I added more stuff to the coloring tool that help simplify the pics a little and here's another test: rambotox.obx 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 1, 2020 Share Posted August 1, 2020 On 7/29/2020 at 1:08 AM, rensoup said: Are you using my clash fixer tool while claiming you authored this pic entirely in G2F ? nah... Tebe just showed his tool and the pic. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 1, 2020 Share Posted August 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 1, 2020 Share Posted August 1, 2020 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 Quote Link to comment Share on other sites More sharing options...
emkay Posted August 1, 2020 Share Posted August 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
rensoup Posted August 1, 2020 Author Share Posted August 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 1, 2020 Share Posted August 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 1, 2020 Share Posted August 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 2, 2020 Share Posted August 2, 2020 The problem is , you guys don't see what is possible , that's why missing software won't see the light. . A recently released prod might give some clues. 256b for a scene lightning effect... Quote Link to comment Share on other sites More sharing options...
rensoup Posted August 3, 2020 Author Share Posted August 3, 2020 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... Quote Link to comment Share on other sites More sharing options...
rensoup Posted August 3, 2020 Author Share Posted August 3, 2020 (edited) 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 August 3, 2020 by rensoup csdb 2 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted August 3, 2020 Share Posted August 3, 2020 Is it possible to render this where the dither pattern is reversed? I have an idea ... Quote Link to comment Share on other sites More sharing options...
emkay Posted August 3, 2020 Share Posted August 3, 2020 6 hours ago, rensoup said: 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. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 3, 2020 Share Posted August 3, 2020 Found the original https://auralcrave.com/en/2018/03/14/scarlett-johansson-the-smashing-pumpkins-a-video-tribute-to-true-beauty/ Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 3, 2020 Share Posted August 3, 2020 Well the obvious thing now is to throw RC at it (would probably go well with some prep like making the background a uniform luma so colours don't go to waste) Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.