1NG Posted August 7, 2012 Share Posted August 7, 2012 Short: Hand Painting & G2F -> few colors per line using simple rasters, Quantizator -> lots of colors using complex rasters There are two different applications for different needs. Try to paint the bird obove by Hand -> impossible with G2F. Try to get a G2F-Painted cool Picture to be found by Quantizator -> (nearly) impossible Ofcourse the bird is possible in G2F. Show it or it didn´t happen. In G2F you can use up to 23 colours per scanline, if you want. Wow! But how can that be used by a painter? I would like to see a handmade picture with 23 colors per line, made by G2F. The Rastaconverter allows up to 16 colours. On Sat Aug 4, 2012 11:45 AM you wrote 13. Now 16, so it is getting better every day! :-) But fortunately the FAQ tells the facts."How many different colors in line can we have?" The problem with G2F is the missing automation for editing the rasters. The problem with Rastaconverter is the "colour-usage-decision" which is not correct. I understand that now the problem Quantizator as painting program is solved. Now the colors are adressed: In the FAQ are some examples about that. The older versions of Rastaconverter acted on every change of the source pic, so, basically, an automated tool for creating graphics was there. No, because if you don´t want random, that is not a solution. Or have something changed here? You need to tell exact how it has acted. (And you can´t). But if you can not, how can it create automated solutions (without errors)? The new version has even more bugs and crashes sometimes, when editing the source picture... 5.1 works fine for me. Maybe you have testet more and can share experience here. Can you provide a complete example? (Can simply be a bug.) This is not only a try to make Quantizator look bad, or is it? (Everytime another thing is bad.) Take it, leave it or improve it. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 7, 2012 Share Posted August 7, 2012 Short: Hand Painting & G2F -> few colors per line using simple rasters, Quantizator -> lots of colors using complex rasters There are two different applications for different needs. Try to paint the bird obove by Hand -> impossible with G2F. Try to get a G2F-Painted cool Picture to be found by Quantizator -> (nearly) impossible Ofcourse the bird is possible in G2F. Show it or it didn´t happen. Making demonstration and everyone is ignoring it? No time wasting here. In G2F you can use up to 23 colours per scanline, if you want. Wow! But how can that be used by a painter? I would like to see a handmade picture with 23 colors per line, made by G2F. Using the importer/code generator of the Converter is a good start. The Rastaconverter allows up to 16 colours. On Sat Aug 4, 2012 11:45 AM you wrote 13. Now 16, so it is getting better every day! :-) But fortunately the FAQ tells the facts."How many different colors in line can we have?" Funny. Ilmenit doesn't know his own tools? a) I wrote the best case seem 13 colours. Which includes the use of colour in a workable image. b) Many pictures have up to 16 colours per scanline. The problem with G2F is the missing automation for editing the rasters. The problem with Rastaconverter is the "colour-usage-decision" which is not correct. I understand that now the problem Quantizator as painting program is solved. Now the colors are adressed: In the FAQ are some examples about that. The older versions of Rastaconverter acted on every change of the source pic, so, basically, an automated tool for creating graphics was there. No, because if you don´t want random, that is not a solution. Or have something changed here? You need to tell exact how it has acted. (And you can´t). But if you can not, how can it create automated solutions (without errors)? The new version has even more bugs and crashes sometimes, when editing the source picture... 5.1 works fine for me. Maybe you have testet more and can share experience here. Can you provide a complete example? (Can simply be a bug.) This is not only a try to make Quantizator look bad, or is it? (Everytime another thing is bad.) Take it, leave it or improve it. No need for me to make the converter look bad. Ilmenit tries the best himself to do so. Check my "error" list and trying to find solutions for perfect images on the A8 could do miracles. But, it seems to be the goal to have always disrupted images there.... Quote Link to comment Share on other sites More sharing options...
1NG Posted August 7, 2012 Share Posted August 7, 2012 (edited) BTW: The color problem is way complexer then the example above, because usable areas overlap. But maybe it is an example to understand. Some calculation helper.... We have 160x240 pixel. So in no way we could have more than 160x240 colours (38400) on the screen. This is also limited by the FIXED palette of 128 colours and the available colour switches per scanline. The only REAL problem is the calculation of the available colours per scanline with that. This limitation and the fact that an image has to be "an image" , limits the colour count even more. Mostly a "real" colour picture ends up in less than 60 colours , and it is FULL ALIKE whether the picture originates from real colours or from a 512 colour picture. And btw. one of my self written tools back in the 80s was a picture converter.... So what is the complexity here? Low, because of the few colors? My guess is, that it is very expensive to calculate: Maximum: 160x240 pixels in a line with 128 colors per pixel possible. This means that only 2 by the power of (160x240*7) different pictures can exist on a Atari 8 Bit But that is a number with over 80.000 digits! http://www.wolframal...i=2^(160*240*7) Good news: Even, if you don´t count mirrored and inverted etc that is way to much to see them all. Bad news: To much to calculate them all. (Of course this maximum is not possible, because not every color is possible at every pixel. But only the bits of a normal picture without raster program have are 8500 Bytes (with PM) with 2^(8500* posibilities 2^((40+5)*, a number with 108 digits. Per line.) Limited real: Looking at the raster program: A typical rp-line has 7 changes of 128 colors but on different positions. With nops ld_ sta_ it has about 20 commands a line. ld_ hat 3, st_ 3 and nop is only one command. 7 commands in 20 places but every ld_ can have 128 different values to load (even some more if used for PM Positions), every sta has a color register or PM Position as parameter. About 10^51 possible raster programs per line. Still way way to much to do them brute force. And they are influenced by the previous line, which has not been taken into account here. This is combinated with the posiibilities from the bitmap and PM (108 digits number from above) I am not a mathematician, so something can be missed here. But the big numbers don´t lie: A lot of complexity here! Much more than it seems on a short look. Edited August 7, 2012 by 1NG Quote Link to comment Share on other sites More sharing options...
1NG Posted August 7, 2012 Share Posted August 7, 2012 No need for me to make the converter look bad. Ilmenit tries the best himself to do so. But, it seems to be the goal to have always disrupted images there.... Aua! I am out here. Quote Link to comment Share on other sites More sharing options...
Bryan Posted August 8, 2012 Share Posted August 8, 2012 No need for me to make the converter look bad. Ilmenit tries the best himself to do so. Holy shit, dude. Are we not devoting enough of our free time to your hobby? Quote Link to comment Share on other sites More sharing options...
+Stephen Posted August 8, 2012 Share Posted August 8, 2012 No need for me to make the converter look bad. Ilmenit tries the best himself to do so. Holy shit, dude. Are we not devoting enough of our free time to your hobby? Funny how he never provided useful information in all of his "bug" reports. I found a simple bug, posted the files I used, and 30 minutes later, had a response. Imagine that. I really am now thinking he's just a devoted troll. 2 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted August 8, 2012 Share Posted August 8, 2012 Short: Hand Painting & G2F -> few colors per line using simple rasters, Quantizator -> lots of colors using complex rasters There are two different applications for different needs. Try to paint the bird obove by Hand -> impossible with G2F. Try to get a G2F-Painted cool Picture to be found by Quantizator -> (nearly) impossible First, I am a computer scientist with a very good understanding of mathematics. So, don't get my question wrong. Why do you think G2F rasters aren't complex? It has much more possibilities then Quantizator. From an artist point of view, you use only non-complex rasters. Maybe that iswhat you ment. Then I apologize for the misunderstanding. However, I can't see any (unsolveable) problem to display and modify Quantizator pics in G2F. It is my understanding that G2F can change any regjster. If I missed something, pleasetell me. No need for flaming. 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted August 8, 2012 Share Posted August 8, 2012 No need for me to make the converter look bad. Ilmenit tries the best himself to do so. Holy shit, dude. Are we not devoting enough of our free time to your hobby? Funny how he never provided useful information in all of his "bug" reports. I found a simple bug, posted the files I used, and 30 minutes later, had a response. Imagine that. I really am now thinking he's just a devoted troll. Interesting. So you don't have the slightest clue of what I'm writing about? This reminds me of RMT. People 1st say: It doesn't work... then ... after proving , it works... people ignore it. Even after tunes like "logical 3" and "Zamzarah" .... I read post, I would have proven nothing and people don't use it. I'm not doing the same crap with the graphics. Because MY sparetime is rather low. No need for me to make the converter look bad. Ilmenit tries the best himself to do so. Holy shit, dude. Are we not devoting enough of our free time to your hobby? You do? Quote Link to comment Share on other sites More sharing options...
emkay Posted August 8, 2012 Share Posted August 8, 2012 Short: Hand Painting & G2F -> few colors per line using simple rasters, Quantizator -> lots of colors using complex rasters There are two different applications for different needs. Try to paint the bird obove by Hand -> impossible with G2F. Try to get a G2F-Painted cool Picture to be found by Quantizator -> (nearly) impossible First, I am a computer scientist with a very good understanding of mathematics. So, don't get my question wrong. Why do you think G2F rasters aren't complex? It has much more possibilities then Quantizator. From an artist point of view, you use only non-complex rasters. Maybe that iswhat you ment. Then I apologize for the misunderstanding. However, I can't see any (unsolveable) problem to display and modify Quantizator pics in G2F. It is my understanding that G2F can change any regjster. If I missed something, pleasetell me. No need for flaming. You missed nothing. Rastaconverter uses limited rules for importing the graphics, to make the import routines easier. No problem with that. Quote Link to comment Share on other sites More sharing options...
+Sauron Posted August 8, 2012 Share Posted August 8, 2012 emkay, if you don't cease with continuously shitting in this thread, you will find yourself on mod preview. Consider this your one and only warning from me. 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted August 8, 2012 Share Posted August 8, 2012 emkay, if you don't cease with continuously shitting in this thread, you will find yourself on mod preview. Consider this your one and only warning from me. What is this now? Really, this A8 "community" is really the biggest heap of weirdness. If it is "shitting" if one explains errors and gives clues to solve them, what is "shitting" then? I make a video of a proved conversion with a recreatable better result and all I get the title "liar"? You guys don't even bother when someone directly attacks others or is using bad language. But explanation of bugs rings your Bells? You should also read the thread better. People always insult me and attack me... the cause is they don't understand the slightest word. And that's why it looks like "shitting", which is actually YOUR word. Quote Link to comment Share on other sites More sharing options...
+Sauron Posted August 8, 2012 Share Posted August 8, 2012 No need for me to make the converter look bad. Ilmenit tries the best himself to do so. You can't seriously tell me that comments like this are not shitting in the thread? I've had enough of you, and so have many others. 3 Quote Link to comment Share on other sites More sharing options...
ilmenit Posted August 8, 2012 Author Share Posted August 8, 2012 Some calculation helper.... We have 160x240 pixel. So in no way we could have more than 160x240 colours (38400) on the screen. This is also limited by the FIXED palette of 128 colours and the available colour switches per scanline. The only REAL problem is the calculation of the available colours per scanline with that. [...] My guess is, that it is very expensive to calculate: [...] I am not a mathematician, so something can be missed here. But the big numbers don´t lie: A lot of complexity here! Much more than it seems on a short look. 1NG, don't bother. We have already tried to explain the problem complexity in this thread (there, again and again) so it is pointless if somebody still thinks that "the only REAL problem is the calculation of the available colours per scanline". The RastaConverter FAQ contains a section about the problem complexity. 1 Quote Link to comment Share on other sites More sharing options...
ZylonBane Posted August 8, 2012 Share Posted August 8, 2012 I've only read maybe 1% of posts in this thread, so this has probably already been answered-- Would it be correct to assume that the randomization algorithm, for each scanline, only introduces colors that exist on that scanline? Quote Link to comment Share on other sites More sharing options...
ANTIQ Posted August 8, 2012 Share Posted August 8, 2012 #117 Quote Link to comment Share on other sites More sharing options...
JohnBuell Posted August 9, 2012 Share Posted August 9, 2012 Maybe it's time to close this thread and start over? Quote Link to comment Share on other sites More sharing options...
emkay Posted August 9, 2012 Share Posted August 9, 2012 No need for me to make the converter look bad. Ilmenit tries the best himself to do so. You can't seriously tell me that comments like this are not shitting in the thread? I've had enough of you, and so have many others. So have a closer look on what has been there before. The pictures mostly look only good if in a thumbnail. Having them fullscreen shows that the main image isn't really recognizable. Solving the problem was the cause, ignorance was the result. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 9, 2012 Share Posted August 9, 2012 Some calculation helper.... We have 160x240 pixel. So in no way we could have more than 160x240 colours (38400) on the screen. This is also limited by the FIXED palette of 128 colours and the available colour switches per scanline. The only REAL problem is the calculation of the available colours per scanline with that. [...] My guess is, that it is very expensive to calculate: [...] I am not a mathematician, so something can be missed here. But the big numbers don´t lie: A lot of complexity here! Much more than it seems on a short look. 1NG, don't bother. We have already tried to explain the problem complexity in this thread (there, again and again) so it is pointless if somebody still thinks that "the only REAL problem is the calculation of the available colours per scanline". The RastaConverter FAQ contains a section about the problem complexity. This ignorance rolls toenails. You have to build a "circle" of checking the resolution, the possible colours, and the resulting dithering. A white dot... or line in the center of a black range doesn't make the range grey. It let it to look even darker then. Different types of dither should only be used , if the depending pixels get common. So it's not a solution! You all can be happy, I'm out of this useless Thread. Quote Link to comment Share on other sites More sharing options...
ZylonBane Posted August 9, 2012 Share Posted August 9, 2012 Thread Gains +1 Production Points 1 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 23, 2012 Share Posted August 23, 2012 Help needed on this attempt please... The image seems to work better keeping the background white rather than black but still it misses out a few tiny pieces that make the end picture no good. Then the executable produced doesn't appear correctly in Altirra messing the colours within the right eye? Evaluations had got up to 300M for the last good one and didn't improve at 400M so I stopped there. It had done most of the picture before this though. I'd hand corrected the original image to remove aliasing and guess I could shave some of the medium pick shadow from the right hand side to avoid the corruption there, but the dark blue error in the left eye is puzzling? Thanks, Mark oddie-test.zip Quote Link to comment Share on other sites More sharing options...
ilmenit Posted August 23, 2012 Author Share Posted August 23, 2012 (edited) 1. Differences of the output in Altirra and RC are known. This is the still the unfixed bug in RC. The perfect sprite emulation is not that easy. No emulator does it properly (maybe excluding Altirra after recent patches). This bug appears in most of the generated pictures, but when a picture is more colourful it usually not visible. 2. Do not expect pixel perfect conversions (those small horizontal lines): http://github.com/il...i/FAQ#wiki-1to1 Probably you have to wait for G2F with RC output loading to correct it. But from the test version of new G2F I see that Tebe has similar problem with proper sprites emulation like everyone else. 3. For low color pictures you can try /init=less or /init=smart or /init=empty to see if it gives better results Edited August 23, 2012 by ilmenit Quote Link to comment Share on other sites More sharing options...
+JAC! Posted August 23, 2012 Share Posted August 23, 2012 (edited) Hi ilmenit, From the FAQ I know you only use 4x players. Here some that are missing inthe FAQ :-) - Are missles also 4x? (probably yes) - Are P&M always at the same x position (probably not) - Is the same PRIOR value used per screen/area/scanline and which (always 1/0/PF priority) ? Edited August 23, 2012 by JAC! Quote Link to comment Share on other sites More sharing options...
Xuel Posted August 23, 2012 Share Posted August 23, 2012 Hi ilmenit, From the FAQ I know you only use 4x players. Here some that are missing inthe FAQ :-) - Are missles also 4x? (probably yes) - Are P&M always at the same x position (probably not) - Is the same PRIOR value used per screen/area/scanline and which (always 1/0/PF priority) ? - All missiles are 4x and are used for the left and right borders. Fifth player is set and COLPF3 is set to black. Missile DMA is off and GRAFM is set to $FF. - Player positions can change, sometimes multiple times per line. - PRIOR is fixed at $14. Players cover two playfield values and are covered by the other two. Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 24, 2012 Share Posted August 24, 2012 (edited) The oddie issue looks like a HPOSP0 write timing problem rather than the overlay issue. It can't be the overlay issue because the overlay issue causes RastaConverter to believe that P0 should be there when it isn't, and this is the opposite case where P0 is not displaying as intended. The code is attempting to reposition P0 at $7D at cycle 61 on scanline 61, but it looks like this is one cycle too late. Altirra matches the output of the real hardware, but I may have to adjust the values in my hardware manual. Edit: Suck, my 130XE is showing temperature-sensitive behavior for HPOSP0. It starts out the same as the 800XL and then when it warms up it requires writes one cycle earlier for odd values of HPOS. Edited August 24, 2012 by phaeron 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 24, 2012 Share Posted August 24, 2012 Missile DMA is off and GRAFM is set to $FF. Note that if Player DMA is enabled in Antic, it also does Missile DMA - so that extra cycle is still lost. 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.