I wanted to let the tropical sunset pic run a while longer as a test to see if it would maybe go back over the spot with the black line, but it never did resolve. I normally will let my images continue to run if I can still see visible changes happening and the normal distance is improving, and on some of the more complex ones this continues to happen well into the hundreds of millions of evals. I'm not convinced too many evals will cause issues. I started the tropical sunset image over and had a busy couple days at work and didn't have time to mess with it -- when I stopped it just now it was at 4.3 billion evals! I do appreciate your advice Gunstar, and I actually follow some of it :-)
Well, looking at all of these images, though on a PAL computer, so the colors are wrong and what I think is an error could just be my PAL Atari's color palette screwing it up, and not one of the line-segment errors (my term, there's actually a technical explanation below), but I only see what might be one in the leaves picture, so you seem to be evading this error. I reiterate that this only shows up when viewing the .xex's on real hardware.
But for me it seems to occur 99% of the time with more than 150 million evaluations, at which time it drops to about 50% of the time and 110 million evaluations has been the sweet spot for me of being 99% sure of no errors when I finally view the .xex on my real machine. So I have learned to do adjustments to my images before running it to get the quality of images I do between 50-150 million evaluations. My average is 110 million, but sometimes the image conversion looks great by 50 million, so I stop it to move on to another and to just not take the chance of having to start over due to the error, since the conversion is already so good at that point.
I will do some further experimentation doing billions of evaluations though, but in most of the other people's images that are posted, who run it for hundreds of millions of billions of evaluations the line-segment errors show up on my computer. But maybe it's just my wacky "Frankenputer" Atari with all it's mods and upgrades causing it and others don't get the errors when viewing them like I do. Maybe is my choice of custom OS, I'll try looking at some older images again with the standard XL/XE OS...but the error is a real one that is known to occur. as I've posted before from another thread.
ilmenit, on 21 Feb 2017 - 01:28 AM, said:
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.
The part I have in bold I have NOT found to be the case, in my experience it's just the opposite, a constant high chance of it happening almost every time, but there have been a couple images I posted that I forgot about and did run into the billions that did manage not to have it occur. But this is about one or two percent of the time in my experience. Now the error doesn't always appear in the exact same place on the image, but an error does occur somewhere, usually close to the first error.
Edited by Gunstar, Sat Apr 20, 2019 11:21 AM.