Images generated by RastaConverter

[Gunstar]

Yoda Contemplating. 66 colors.

 

 

YodaContemplating.xex

[drpeter]

13 hours ago, Gunstar said:

Yoda Contemplating. 66 colors.

 

 

YodaContemplating.xex 21.97 kB · 10 downloads

You're on a roll.  Absolutely astonishing images!

You'd imagine these were meticulously crafted pixel art, not automated conversions.

[Gunstar]

1 hour ago, drpeter said:

You're on a roll.  Absolutely astonishing images!

You'd imagine these were meticulously crafted pixel art, not automated conversions.

Thanks, the trick is meticulous conversions...try, try again until they come out right. (by my standards) It's not nearly as "automated" as you think to get such results. It's not something that can be taught without being in person (maybe via video), just vast experience and tons of failed conversions. Most people frankly just don't or won't put in the time I do though. You are a quick learner though, and if you keep at it at the pace you are now, you'll be pumping out conversions better and better. I've been doing it for about 3-4 years now I think, I'd have to go locate my first post in this thread...you don't have to be an artist to do these conversions, but it certainly helps to have an artist's eye, in changing the settings until you get it right. More experience equals less conversion attempts, which merely means about half a dozen to a dozen attempts, per conversion, at my level, instead of double or triple that many like it was for me in years past. You have to be willing to discard conversions that have been running for hours and hours and try again, even if the image looks almost perfect, but not quite.

 

I've got two more coming that are my usual PAL conversions. But my PAL machine has been down for nearly a week now, so I haven't been able to see any of these conversions on the real McCoy, Mostly to make sure there are no line-segment errors from overlapping sprites that crop up when viewed on real machines. But also to make sure there are no dark color streaks across black areas that can't always be seen on output .png images, or even an emulator, but they stand out like a sore thumb when viewed on a real machine. Hopefully there aren't to many of either in the images I've posted in the last week. So I'm temporarily going to do some NTSC palette images so I can keep seeing them on my computer, to know for sure they look as good there, as they look on the output images. I've been saying I was going to start doing more NTSC conversions anyway, since I got my NTSC 800 nearly a year ago. 

 

 

Edited September 26, 2019 by Gunstar

[drpeter]

23 hours ago, Gunstar said:

Mostly to make sure there are no line-segment errors from overlapping sprites that crop up when viewed on real machines.

I understood that these do show up in Altirra, like on real machines?

I certainly see some line artefacts that show up in Altirra but not in the output.png.

I have had some fun removing some of these by hand-editing the screen kernel in output.png.rp when the conversion is otherwise a good one.

[ivop]

6 hours ago, drpeter said:

I understood that these do show up in Altirra, like on real machines?

I certainly see some line artefacts that show up in Altirra but not in the output.png.

I have had some fun removing some of these by hand-editing the screen kernel in output.png.rp when the conversion is otherwise a good one.

I have done that once, too, in the past, but found it a total nightmare. Even finding the offending line took ages. Or do you have a special, fast procedure for that?

[Gunstar]

11 hours ago, drpeter said:

I understood that these do show up in Altirra, like on real machines?

I certainly see some line artefacts that show up in Altirra but not in the output.png.

I have had some fun removing some of these by hand-editing the screen kernel in output.png.rp when the conversion is otherwise a good one.

This is different than artifacts left behind by the converter, and I think it is only unique to viewing on a real machine, specifically because it was developed with Altirra and not real hardware, and as good as Altirra is, it's not 100% compatible with real hardware. I've talked about it many times before in this thread, with loads of links and documentation and quotes or copy/paste describing the issue in detail. If you do a search in this topic only for "line segment error" which is the name I gave it, those post where I mention it will come up. I don't edit or use any other software for my images. I don't even use masking. I use only the setting adjustments in Rasta itself until I get it the best I can by multiple attempts and going for settings that give me the best results in the fewest evaluations, trying to keep them below 150 million, after that the error chances increase ten-fold. A couple of my latest images I have ran up to 250 million evals, and have just hoped the line error didn't happen, since I didn't have a machine working to look. So some of my latest images may have line segment errors on them, I don't know. I'm now doing NTSC conversions that I can test on my NTSC 800.

Edited September 27, 2019 by Gunstar

[a8isa1]

After many attempts at these it's time to move on.

 

[NTSC]

 

[PAL]

 

I took shot at this picture as well.   I wasn't able to disguise the LINE dither nor process out the errors (right cheek).  On the Atari the image looks better a couple feet back from the monitor.

 

 

[NTSC]

 

These were processed using my saturation 50 palettes.  If viewing in Atari800 emulator you'll need my palettes (see my sig) or in Altirra bump the saturation to 50 for the PAL image. For NTSC there's a bit more tweaking.  Saturation also 50, hue start is -44, and hue step 24.1, 

 

On real hardware you might need to boost saturation of your monitor some but the colors are achievable.

 

-SteveS

 

 

a8isa1_chameleon2.xex a8isa1_chameleon2_PAL.xex a8isa1_mouth.xex

[drpeter]

On 9/27/2019 at 7:04 PM, ivop said:

I have done that once, too, in the past, but found it a total nightmare. Even finding the offending line took ages. Or do you have a special, fast procedure for that? 

I use Altirra to help with this.

 

My method is to guess the offending line by rough estimate of vertical position on the screen then inject an obvious colour change into one of the main colour registers by editing the the kernel found in output.png.rp in the Generator folder at the estimated line- I use $38 as a nice bright red.

 

e.g. LDA #$38

       STA COLORBAK

 

Obviously when doing this you have to make sure you're replacing (ideally redundant) kernel processor instructions or NOP instructions with instructions having an equivalent  numbers of cycles.  Essentially, for instructions used in the Rasta-generated kernel except the end-of-scanline 3 cycle zero-page CMP ..., LD. #.. instructions or NOP are 2 cycles each and all other instructions are 4 cycles each.  So, for example, the above instructions would need to replace 6 cycles, so perhaps NOP; NOP; NOP or LDX #34; LDX #78; NOP

 

Then run build.bat and examine the output.xex in Altirra with scanlines turned on, so it's easy to count how many scanlines away from the guesstimated scanline (where the injected red colour appears) the line segment error actually occurs.

 

Using Ctrl F7 in Altirra to see how the scanline colours in the xex are derived is very helpful in order to see what kind of adjustment to the kernel will likely solve the problem- usually adjusting a processor register save to a colour register or adjusting a processor register save to a player horizontal position register.

 

I have found I only need to do this guesstimate once or twice to find the exact offending line in a given kernel.

[drpeter]

On 9/27/2019 at 11:23 PM, Gunstar said:

specifically because it was developed with Altirra and not real hardware

Yes, but I understood from previous posts from Ilmenit that following the development of RastaConverter Altirra had been updated to duplicate the relevant real hardware behaviour...?

[ilmenit]

18 hours ago, drpeter said:

Yes, but I understood from previous posts from Ilmenit that following the development of RastaConverter Altirra had been updated to duplicate the relevant real hardware behaviour...?

If executed picture on real Atari and Altirra is different, report it  to @phaeron . For sure he will be interested in fixing it.

[Gunstar]

14 minutes ago, ilmenit said:

If executed picture on real Atari and Altirra is different, report it  to @phaeron . For sure he will be interested in fixing it.

I forget who developed what, so are you talking about fixing Altirra or Rastaconverter? We've been discussing this error for a couple of years that I've been doing conversions, and the programmer has said he's not interested in doing anything more for Rastaconverter and has long since moved on. Altirra has been updated, but not Rastaconverter.

Edited September 30, 2019 by Gunstar

[ivop]

Well, as I understood it, the developer (ilmenit, posted just above you), is not 100% confident he understands all the caching stuff phaeron added to speed things up. Best would be if phaeron fixed the bug. He knows what it is, because it triggered him to improve Altirra's emulation to display this line errors like real hardware, which it didn't previously IIRC. But I believe phaeron has expressed he has no desire to fix this. On a sidenote, if rastaconverter's evaluation algorithm were to emulate this correctly, sometimes "line errors" could even be beneficial, if evaluated to the right colors.

 

 

[phaeron]

10 hours ago, ivop said:

Well, as I understood it, the developer (ilmenit, posted just above you), is not 100% confident he understands all the caching stuff phaeron added to speed things up. Best would be if phaeron fixed the bug. He knows what it is, because it triggered him to improve Altirra's emulation to display this line errors like real hardware, which it didn't previously IIRC. But I believe phaeron has expressed he has no desire to fix this. On a sidenote, if rastaconverter's evaluation algorithm were to emulate this correctly, sometimes "line errors" could even be beneficial, if evaluated to the right colors.

Sorry, have too many other things going on to work on RastaConverter right now -- I don't even remember which computer I had the build tree on -- but I do have some ideas, if anyone else jumps in. It's not necessarily as simple as just emulating what the actual hardware does, because of the existing emulations that don't faithfully reproduce all the bugs. This includes not only software but now also hardware emulators, where GTIA's P/M graphics logic is replicated in FPGA. It's also not trivial to mimic the hardware behavior as I had to completely rewrite Altirra's sprite engine at the time to fix it, and RastaConverter's is written differently.

 

The idea that I had was, instead of replicating the bugs, detecting the problematic cases and forcing the error to $HUGE_VALUE instead to kill the evaluation. This would just cause RC to avoid the problematic cases. I don't think this will affect quality as the corner cases in question aren't very useful and don't seem to be hit much given how huge this thread has gotten without too many instances. This would also avoid carrying additional state from one scanline to the next, which would be necessary to emulate some of the cases in question otherwise and complicate evaluation.

 

Another approach would be to just add a tactical nuke function to the program, where you can tell it to rewrite the bad line to do nothing but set existing state for the next line, and thus have it begin re-iterating that line from scratch. Still a manual process to notice and correct the issue, but easier to fix and potentially useful in other cases.

 

If you are using Altirra to track down the offending line position, Alt+clicking on the display when the debugger is enabled will display the scanline number under the cursor. In the most recent test versions, Alt+Shift+click will also drop you in the vicinity of that beam position in the history, to show what code was being run around that time.

 

[ilmenit]

Sorry for misunderstanding. I understood the last posts that there were new issues discovered in Altirra and pictures displayed there were different from real Atari. RastaConverter to have the problem fixed would require serious refactoring and neither me nor Phaeron has time for this. Even simpler approach of identification problematic cases would be quite time consuming.

[drpeter]

6 hours ago, phaeron said:

It's not necessarily as simple as just emulating what the actual hardware does, because of the existing emulations that don't faithfully reproduce all the bugs. This includes not only software but now also hardware emulators, where GTIA's P/M graphics logic is replicated in FPGA.

Should anyone with the time and the skills wish to take this on, I would strongly suggest restricting any revisions of RastaConverter to producing output aiming to display correctly on genuine hardware.  Attempting to produce output targeting 'inaccurate' emulations, hardware or software, is really not necessary!  Rather, as phaeron has done, those emulations should be updated if necessary to better emulate genuine hardware.

 

6 hours ago, phaeron said:

If you are using Altirra to track down the offending line position, Alt+clicking on the display when the debugger is enabled will display the scanline number under the cursor. In the most recent test versions, Alt+Shift+click will also drop you in the vicinity of that beam position in the history, to show what code was being run around that time.

 

Thanks, that's a really useful tip ?

[Gunstar]

Here is my first NTSC image I am willing to post. It's not up to the normal standards I shoot for, but I'm really having to relearn the way I do things to get good results on NTSC, at least with the current palette I am using. Tested on a real NTSC Atari 800.

 

This image still has some dark green color-banding, but it's at least on the forest area where it should be. The colors I am seeing on the real computer are quite different from the .png image posted. I think I need to find a better NTSC palette.

 

I went back a looked at some of my early NTSC images, back when I was posting both PAL and NTSC for a while, without seeing the NTSC images on a real Atari. It makes a big difference to be able to see the images on a real Atari. They all have terrible errors in them, mainly dark color banding across black, which is difficult to see on the PC .png's.

 

 

Colorado. 51 colors, NTSC, 228 vertical line over-scan, full-screen, for better 4:3 NTSC ratio. Not near perfect yet, some further testing needs to be done to get the correct ratio on NTSC 4:3 screens, but it's better than 240 images that get cut off with a much worse screen ratio on NTSC. I attempted at 220-24 at first, but it didn't seem to be full screen, but I do see about 4-8 lines are cut off now, so I had it right before and my monitor's vertical positioning was out of wack. 

Colorado.xex

Edited October 4, 2019 by Gunstar

[drpeter]

On 10/1/2019 at 3:54 AM, phaeron said:

If you are using Altirra to track down the offending line position, Alt+clicking on the display when the debugger is enabled will display the scanline number under the cursor

Hi,

I can't get this to work. I am using Altirra 3.20.  Which debugger windows should be enabled for this to be displayed?

[phaeron]

9 hours ago, drpeter said:

Hi,

I can't get this to work. I am using Altirra 3.20.  Which debugger windows should be enabled for this to be displayed?

The only window you need is the normal display window, but the emulator needs to be stopped in the debugger (Debug > Run/Break). Once stopped, holding Alt and clicking/dragging looks like this:

 

[drpeter]

7 hours ago, phaeron said:

The only window you need is the normal display window, but the emulator needs to be stopped in the debugger (Debug > Run/Break). Once stopped, holding Alt and clicking/dragging looks like this:

 

Ah, thanks!

[+Philsan]

Mona Lisa by Leonardo da Vinci (1452 - 1519), 35 colors.

 

 

Philsan_MonaLisa.xex

[drpeter]

Jacques Chirac 1932-2019

Prime Minister of France from 1974 to 1976 and from 1986 to 1988

 

On life in politics-

'I was not averse to the women, but nor did I overdo it'    - it is left to the reader to reflect what 'overdoing it' might mean in French political circles...

'Promises are only of importance to those who take them seriously'

 

drpeter_Chirac.xex

Edited October 6, 2019 by drpeter

[drpeter]

My border collie Holly.

 

drpeter_Holly.xex

[drpeter]

English Lake District, Buttermere, looking east from the edge of Burtness Wood toward Gatesgarthdale and the Honister Pass.

November 2017

 

On the left are the lower slopes of High Snockrigg fell, then Robinson and in the distance Dale Head. On the right, Honister Crag leading upward to the summit of Fleetwith Pike.

The tiny patch of green visible at the far extremity of Buttermere is the low pastures of Gatesgarth Farm at the foot of the pass.

 

Co-ordinates of viewpoint: 54.53289,-3.27482

Map of area in view: https://osmaps.ordnancesurvey.co.uk/54.52701,-3.22803,14

drpeter_Buttermere.xex

[Gunstar]

Well, after a week of trial and error, and just about deciding to give up on NTSC conversions, due to terrible palettes, I rediscovered @a8isa1 's custom NTSC palette that saved the day! Not my best work, but at least it isn't full of false colors and dark color streaking across black (when viewed on real hardware) that I could not get rid of with any other NTSC palettes. Now that I can make decent conversions in NTSC, I'll work more on producing proper screen aspect ratios in future attempts.

 

Dark Reflections. 50 colors, 160x224. NTSC.

  

DarkReflections.xex

Edited October 9, 2019 by Gunstar

[a8isa1]

1 hour ago, Gunstar said:

Well, after a week of trial and error, and just about deciding to give up on NTSC conversions, due to terrible palettes, I rediscovered @a8isa1 's custom NTSC palette that saved the day! Not my best work, but at least it isn't full of false colors and dark color streaking across black that I could not get rid of with any other NTSC palettes.

 

Dark Reflections. 50 colors, 160x224. NTSC.

  

DarkReflections.xex 20.6 kB · 1 download

You might be surprised to learn that my NTSC palettes exist because I was attempting to get Altirra's colors to look like my real 800 with a scan converter and a CRT VGA monitor.  They are intentionally wrong.

 

Decades ago I read an Atari 800 field service note that describes adjusting the color trim pot so that hue 1 and hue 15 appear equal on the screen.   That's how my 800 stands to this day.  I eventually learned that this type of adjustment was incorrect.  However, I have no way to accurately put any of my Ataris back to the factory setting.

 

Moving years ahead to the release of some version of Rastaconverter.    Since my 800 is out of adjustment then the colors rendered in picture conversions of course would not align.  To my surprise there wasn't a position for the pot that would make the colors align. 

 

I assumed my 'scan converter' (basically a cable TV set-top box designed for a desktop computer) and CRT monitor combo were way off the mark with respect to the NTSC specification. 

 

I decided to view Rastaconverter picture on emulators only.

 

Some time later I learned that I could adjust Altirra's colors to resemble my real Atari.  This in turn got me to wonder if I used the now custom Altirra palette in Rastaconverter if the colors might look correct on my 800XL (by this time the 800XL was my daily driver).   The colors were considerably better.  Almost totally aligned.  I tweaked the hue starting color and hue angle.   My palettes are set where I stopped tweaking.   Atari Blue-green and cyan(ish) hues still don't seem to line up correctly.  The other colors are very close. 

The saturation levels in the palettes don't affect what a real Atari can output but they subtly affect choices made by Rastaconverter during the processing.

 

-SteveS

 

Edited October 9, 2019 by a8isa1