emkay Posted February 19, 2017 Share Posted February 19, 2017 (edited) Am I the only one who always encounters that problem of false bands? You let run a picture day after day.... you think .... it's almost great.... and then... The Generator shows a proper picture, while the resulting exe shows wrong bands. Even tries, to remove them by hand, is only a temporary solution.... it it will bring them back... Any solutions ? Edited February 19, 2017 by emkay Quote Link to comment Share on other sites More sharing options...
Sheddy Posted February 19, 2017 Share Posted February 19, 2017 Is it this bug? http://atariage.com/forums/topic/200118-images-generated-by-rastaconverter/page-6?&&do=findComment&comment=2568902 Ilmenit has said that it is due to the complex behaviour of real atari player missile graphics midline reposition. Only Altirra emulates it properly. Do you use on off file? I experienced problems with wrong results using them sometimes. Quote Link to comment Share on other sites More sharing options...
emkay Posted February 19, 2017 Author Share Posted February 19, 2017 Is it this bug? http://atariage.com/forums/topic/200118-images-generated-by-rastaconverter/page-6?&&do=findComment&comment=2568902 Ilmenit has said that it is due to the complex behaviour of real atari player missile graphics midline reposition. Only Altirra emulates it properly. Do you use on off file? I experienced problems with wrong results using them sometimes. Currently using Altirra 2.81... "On Off File" ? Quote Link to comment Share on other sites More sharing options...
Sheddy Posted February 19, 2017 Share Posted February 19, 2017 (edited) Would have to check my messages for exact quote, but basically, Rastaconverter does not have totally accurate emulation of player missile on overlap (of itself?) during midline reposition (whereas at some point Altirra was fixed to work in the weird way of real Atari). So your picture will probably look good on older emulator, but not on real thing. Onoff file in rastaconverter7 beta is to deny use of players or colours on defined scanlines. (For example, if you wanted to use player0 as a mouse pointer over top of picture, you tell rastaconverter in the file that player0 is off in all the scanlines, and it won't use it) Edited February 19, 2017 by Sheddy Quote Link to comment Share on other sites More sharing options...
emkay Posted February 20, 2017 Author Share Posted February 20, 2017 Even in earlier version, I recognized those bars or even lines in the vertical center of a huge unicolor field. So, to me there is a bug in the hill climbing calculation. If you use less colors, or more dithering / transitions, the bug won't happen. 1 Quote Link to comment Share on other sites More sharing options...
Sheddy Posted February 20, 2017 Share Posted February 20, 2017 That should say "deny change of players or colours" Quote Link to comment Share on other sites More sharing options...
emkay Posted February 20, 2017 Author Share Posted February 20, 2017 Interestingly, you could cross any color without having the bars removed. Use the same colors, makes the bars disappear. Quote Link to comment Share on other sites More sharing options...
emkay Posted February 20, 2017 Author Share Posted February 20, 2017 And after "undo" the changes... Quote Link to comment Share on other sites More sharing options...
ilmenit Posted February 21, 2017 Share Posted February 21, 2017 Would have to check my messages for exact quote, but basically, Rastaconverter does not have totally accurate emulation of player missile on overlap (of itself?) during midline reposition (whereas at some point Altirra was fixed to work in the weird way of real Atari). So your picture will probably look good on older emulator, but not on real thing. That is correct. The bug happens when sprite is repositioned to a position where it overlaps the previous position of the same sprite. Therefore it happens e.g. when register HPOSPx is set to a new position in range HPOSPx-SpriteWidth to HPOSPx+SpriteWidth. RastaConverter in this case needs to decide how to fill sprite memory with such overlap and it does it improperly. At the time of development I had no real Atari and I used Altirra Hardware Reference manual + Altirra emulator for testing. Phaeron later fixed the bug in the emulator to have it behaving like real Atari but the bug wasn't applied to RC due to lack of my personal time to continue to work on RC. It happens rarely, mostly during the long optimization process when optimizations are getting really to extreme. In such case the only really option is to start conversion again. Due to non-deterministic optimization process there is a high chance that the bug won't appear in the other conversion. 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted February 21, 2017 Author Share Posted February 21, 2017 Restart a 2.000.000.000 job ? No way. There have been several issues to get worked around. Particular in that picture the following happens: Some false calculations produce irregular lines into the picture, always in the center of a bigunicolor vertical field ( 1 ). PMg doesn't get correctly registered. Which seems to split into two parts. ( 2 ) shows a band, as is decribed above. As you may see, getting ( 3 ) registered right, it's gone. Quote Link to comment Share on other sites More sharing options...
pirx Posted February 21, 2017 Share Posted February 21, 2017 We only could dream that someone would continue Rasta development. Unfortunately the entry barrier is rather high - one needs to understand not only very minute details of Atari hardware, but also relatively complex algorithms. 4 Quote Link to comment Share on other sites More sharing options...
ilmenit Posted February 21, 2017 Share Posted February 21, 2017 We only could dream that someone would continue Rasta development. Unfortunately the entry barrier is rather high - one needs to understand not only very minute details of Atari hardware, but also relatively complex algorithms. While the optimization algorithm itself is trivial the hard parts are related to optimizations (caching of emulation) combined with multi-threading. As Phaeron greatly contributed to these parts and he is still actively developing Altirra he could be the best person to fix this bug properly. 4 Quote Link to comment Share on other sites More sharing options...
emkay Posted February 21, 2017 Author Share Posted February 21, 2017 2.400.000.000 evals. Almost perfect... Good, to know the bugs, and to find the workaround 6 Quote Link to comment Share on other sites More sharing options...
emkay Posted February 21, 2017 Author Share Posted February 21, 2017 51 colors ... btw. 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 22, 2017 Share Posted February 22, 2017 I don't think it is necessarily a good idea to implement the true hardware behavior in RastaConverter because there are many variants of hardware that would exhibit bugs there -- not only various software emulators, but also potentially hardware emulators such as VBXE and FPGA-based systems. The rarity of the issue implies that leveraging these corner cases would not be advantageous, and thus not worth the compatibility issues with whatever people might use to view the programs. As such, it'd probably be better to detect problematic the conditions and just raise the score to infinity to reject the evaluation. Unfortunately I don't think I can make this change -- I have enough projects backed up as it is. 1 Quote Link to comment Share on other sites More sharing options...
ilmenit Posted February 22, 2017 Share Posted February 22, 2017 Such workaround is a good idea :-) While it would be the best to have different options rejection of potentially problematic solutions may be the easiest. I'll try to look at it having some free time. 3 Quote Link to comment Share on other sites More sharing options...
ivop Posted February 22, 2017 Share Posted February 22, 2017 Good, to know the bugs, and to find the workaround Exactly how did you work around this bug? I stumbled upon it once and just restarted the conversion. Quote Link to comment Share on other sites More sharing options...
emkay Posted February 23, 2017 Author Share Posted February 23, 2017 (edited) Exactly how did you work around this bug? I stumbled upon it once and just restarted the conversion. Name it "breaking the solution row". The converter runs fast and gets even slower after every "Distance step" . A Distance is always a fully calculated solution. Well, the first versions of Quantizator, made that easier and Versions of Rastaconverter stopped doing changes, after the source picture has been changed. But the latest versions work again, using that "trick". You find all necessary information in the OUTPUT.(png).RP file. Where you can change the name of the source picture. Now, if some details were missed, while those errors occure, make a copy of the source file. Find the regions of that errors and change the pixels with full false pixels. White to black, black to white, green to red, blue to yellow.... what colors have been used in the picture... Save the picture. Change the name in the RP file. Run the converter, until the regions have been recognized and redrawn partially. After a while of that "false" drawing, replace the picture in the RP file, back to the original, and let run it... Keep in mind that the converter always writes data into the RP file when it get's closed. So changes in the RP file will stay, when the converter isn't running. If errors occure again, make a new copy of the original, changing the ranges of the obvious errors.... The converter would run into the same errors on and on. If solutions turn slower and slower, the errors will also come back slower and slower. So the wanted details, get more time to get corrected. That's it. Edited February 23, 2017 by emkay 4 Quote Link to comment Share on other sites More sharing options...
Sheddy Posted February 26, 2017 Share Posted February 26, 2017 (edited) Hmm, maybe Rastaconverter is not best way to start understanding C/C++, but I can't figure out how the player data (pixel data) restored on continue? The output PMG file is not read back in(?), and there would seem to not be enough state in the "output so far PNG" and RP file to restore that, on the face of it? Edited February 26, 2017 by Sheddy Quote Link to comment Share on other sites More sharing options...
ilmenit Posted February 26, 2017 Share Posted February 26, 2017 PMG data (nor bitmap data) is not stored. Color of the pixel is selected on runtime according to the state of the registers. Quote Link to comment Share on other sites More sharing options...
Sheddy Posted February 26, 2017 Share Posted February 26, 2017 Obviously it works, but.. ? Interesting! Looks like I need to learn some more. Thanks Ilmenit Quote Link to comment Share on other sites More sharing options...
Gunstar Posted April 5, 2017 Share Posted April 5, 2017 I Am I the only one who always encounters that problem of false bands?You let run a picture day after day.... you think .... it's almost great.... and then...dif.pngThe Generator shows a proper picture, while the resulting exe shows wrong bands.Even tries, to remove them by hand, is only a temporary solution.... it it will bring them back...Any solutions ? I have started using Rasta in the past few weeks, yo might have downloaded my grab bag of Rasta pics, and yes, I have encountered this on multiple occasions. I've seen it happen in front of my eyes with it flickering before it goes permanently false, and on a couple of occasions, when the flickering started, I reset the computer, and then the next time I load it, it did not maintain the false bands like the ones I did not stop. Quote Link to comment Share on other sites More sharing options...
Gunstar Posted April 5, 2017 Share Posted April 5, 2017 That is correct. The bug happens when sprite is repositioned to a position where it overlaps the previous position of the same sprite. Therefore it happens e.g. when register HPOSPx is set to a new position in range HPOSPx-SpriteWidth to HPOSPx+SpriteWidth. RastaConverter in this case needs to decide how to fill sprite memory with such overlap and it does it improperly. At the time of development I had no real Atari and I used Altirra Hardware Reference manual + Altirra emulator for testing. Phaeron later fixed the bug in the emulator to have it behaving like real Atari but the bug wasn't applied to RC due to lack of my personal time to continue to work on RC. It happens rarely, mostly during the long optimization process when optimizations are getting really to extreme. In such case the only really option is to start conversion again. Due to non-deterministic optimization process there is a high chance that the bug won't appear in the other conversion. I've completed the conversion, made the .XEX file, and displayed it perfectly sometimes several times, and then one time I display it, the problem I posted above occurs. I have not had it happen during the conversion itself. So I'm not understanding you i don't believe. But, I do usually do a non-dithered and dithered versions of images, and if this occurs when diplayed on my real Atari, it generally only happens to one or the other. Quote Link to comment Share on other sites More sharing options...
emkay Posted April 5, 2017 Author Share Posted April 5, 2017 I have started using Rasta in the past few weeks, yo might have downloaded my grab bag of Rasta pics, and yes, I have encountered this on multiple occasions. I've seen it happen in front of my eyes with it flickering before it goes permanently false, and on a couple of occasions, when the flickering started, I reset the computer, and then the next time I load it, it did not maintain the false bands like the ones I did not stop. Some very nice pictures in there. The bands are clearly indicators of a calculation bug. Just like 5.1+5.2=11 . It's depending on the complexity of the content in a scanline. If using non dithering and the picture has less colours to calculate, the counting mistake will be there fast. If you restart the calculation, the engine might take other parts/solutions than before. So it will take just longer till the error will be displayed. The solution of temporarily exchanging the picture with false colors where the errors appear, is like a reset on that calculation . It will be there again after a while, but other parts of the picture have the chance to get more calculations, resulting in an overall better picture. 3 Quote Link to comment Share on other sites More sharing options...
ivop Posted July 30, 2017 Share Posted July 30, 2017 Currently I'm converting an image that is displaying this behaviour very quickly. Usually before 2M evaluations are reached. "Fixing" it by the above mentioned method only works for a short time and then the artifacts reappear. Sometimes at the same places, sometimes they move around a bit. It's really unworkable, which is a pity because the image looks great after 50M evals (55+ colours, very little banding). Adding dither did not help. It keeps stumbling on this bug. So, any chance this will be fixed, either by ilmenit or phaeron? Or can either of you give me some pointers to fix it myself? Thanks in advance! I can send the offending image if that helps. 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.