Jump to content
IGNORED

Images generated by RastaConverter


Philsan

Recommended Posts

I'm sharing a copy of the batch file that I use with RastaConverter in the hopes that somebody else may find it useful. I'm running an AMD Ryzen CPU with 8 cores and 16 threads, and I have found that by carefully selecting which CPU cores the processes run on I can greatly improve efficiency and throughput. For me I have 2 "core complexes," and if I make sure each process has all of its threads on the same complex it helps tremendously. With 4 instances of RastaConverter running simultaneously I'm getting around 120,000 to 140,000 evals/s using the settings in the batch file. I find that 4 threads per process seems to be the sweet spot for me, anything higher and I start to see greatly increased kernel CPU usage -- probably related to increased interprocess communication and coherency. Using the Windows start /AFFINITY feature makes it easy to get the processes running on the correct CPU cores.

 

I use 8 batch files, starting with rasta1.bat through rasta4.bat, and then rasta1d.bat (for dithering) through rasta4d.bat. The parameter for start /AFFINITY is a binary mask to select logical CPU cores, and each batch file is adjusted to start on the desired group of cores. So "F" would be 1111 or the first 4 cores. "F000" is 1111 0000 0000 0000 or the last 4 cores. See attached calc image for an example. My source images are in the directory above hence the /i=..\. Also, for some reason Windows decided to switch to powershell instead of the command prompt so I adjusted the batch file accordingly.

@echo off
if "%1"=="" goto usage
start /AFFINITY F000 .\RastaConverter.exe /i=..\%1 /pal=ntsc30 /contrast=%2 /brightness=%3 /gamma=%4 /s=10000 /threads=4 /distance=cie94 /dither=jarvis
goto end

:usage
echo Usage ./rasta.bat input_file c b g (where contrast=[-100,100], brightness=[-100,100], gamma=[0.0,8.0])

:end
pause

post-45441-0-54263500-1555539865.png

 

post-45441-0-35608500-1555539879.png

 

post-45441-0-23123600-1555540059_thumb.png

 

 

Please let me know if anybody finds this information helpful!

 

 

Edited by SpikedRN
  • Like 7
Link to comment
Share on other sites

First up are a couple of "what if?" pictures from the Sega Genesis/Megadrive. What if we had games for the Atari with title screens that looked this good? I mean the computer can display it right, so it's within the realm of possibility?

 

post-45441-0-34350000-1555581019.png

SEGA.xex

 

post-45441-0-92434500-1555580822.png

castle3.xex

 

 

I couldn't decide which ForestLake01 I liked better, so I kept them both. Which one does everybody like better? These went for about 1.4B evals.

 

post-45441-0-72206400-1555580911.png

SpikedRN.ForestLake01.xex

 

post-45441-0-32360600-1555580929.png

SpikedRN.ForestLake01.Dither.xex

 

 

Here's a couple more...

 

post-45441-0-13559700-1555580852.png

ForestLake02.xex

 

post-45441-0-55221300-1555580946.png

synth02.xex

 

I've got a few more that I'm working on that look promising -- I'll probably post them in a few days. These all look great on my 800xl and Trinitron monitor.

 

I'm hoping a black line in this one will resolve...

 

post-45441-0-08768400-1555581692.png

 

 

Happy converting!

Edited by SpikedRN
  • Like 12
Link to comment
Share on other sites

No .xex for the tropical sunset? If you have line segment errors showing up, like the black line you mention, that is due to to many evaluations and the only thing that can be done is stopping the image before this happens, from my VAST experience, I always keep evaluations between 100-150 million to avoid it, These errors only show up on real hardware. if the picture isn't good enough by then, you didn't start out with good settings. All of my images posted are between 50-150 million evaluations, which proves it can be done well within that. But then, even though I post some of the best images, it seems like no one ever takes my advice on these things, so whatever...good luck and nice pics!

Edited by Gunstar
Link to comment
Share on other sites

No .xex for the tropical sunset? If you have line segment errors showing up, like the black line you mention, that is due to to many evaluations and the only thing that can be done is stopping the image before this happens, from my VAST experience, I always keep evaluations between 100-150 million to avoid it, These errors only show up on real hardware. if the picture isn't good enough by then, you didn't start out with good settings. All of my images posted are between 50-150 million evaluations, which proves it can be done well within that. But then, even though I post some of the best images, it seems like no one ever takes my advice on these things, so whatever...good luck and nice pics!

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 :-)

 

post-45441-0-17820300-1555768242.png

sunset01.xex

 

post-45441-0-46521200-1555768270.png

CyberShadow_08.xex

 

post-45441-0-39143000-1555768281.png

CyberShadow_10.xex

 

post-45441-0-07220100-1555768306.png

ForestLake03.xex

 

post-45441-0-12446800-1555768346.png

solar01.xex

 

post-45441-0-66504600-1555768376.png

leaves01.xex

Edited by SpikedRN
  • Like 11
Link to comment
Share on other sites

 

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:snapback.png

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
  • Like 2
Link to comment
Share on other sites

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%...

Thanks for the detailed info on this bug. I'll have to get into the habit of checking my images on real hardware around 50m evals if it still looks like it's going to resolve more detail and I need to let it run longer.

 

As for the colors, I found settings that look good on my NTSC hardware, but I think I'll run some PAL images too. What's a good palette to use? Laoo?

Edited by SpikedRN
Link to comment
Share on other sites

Thanks for the detailed info on this bug. I'll have to get into the habit of checking my images on real hardware around 50m evals if it still looks like it's going to resolve more detail and I need to let it run longer.

 

As for the colors, I found settings that look good on my NTSC hardware, but I think I'll run some PAL images too. What's a good palette to use? Laoo?

It really depends, my go to is the Altirra palette for 90% of my images, but if I'm doing images with flesh tones and more earthy colors then I usually see which looks best between Laoo, OlivierP and Jakub.

  • Like 1
Link to comment
Share on other sites

Thanks for the detailed info on this bug. I'll have to get into the habit of checking my images on real hardware around 50m evals if it still looks like it's going to resolve more detail and I need to let it run longer.

 

As for the colors, I found settings that look good on my NTSC hardware, but I think I'll run some PAL images too. What's a good palette to use? Laoo?

It's probably safe to let it run to about 75 or 100m evals before you check, if it's not resolved enough in 50. But I do recommend practicing getting the right settings before running so that the picture is about 90% by the time it hits 50m, it makes for much better pictures even if you do run them longer, IMHO. Judge my advice by my submissions, that's all I have to say about it. One thing I do use the 50m mark for is if the picture isn't looking 90% by then, I stop, re-adjust settings and start over; save a LOT of wasted time...

Edited by Gunstar
Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

Hey Atari friends! I thought it would be fun to see how well our Atari can do when compared to the NES. I think the 6502+ANTIC+CTIA trio do an amazing job here, but feel free to judge for yourself!

 

First I have some images from Contra on the NES. Seems like the Atari can easily reproduce the graphics. Some of you may know this game as Probotector.

 

post-45441-0-91300600-1558115620.png

srn-contra01.xex

srn-contra01-pal.xex

 

 

post-45441-0-22283500-1558115691.png

srn-contra02.xex

srn-contra02-pal.xex

 

 

post-45441-0-75637500-1558115727.png

srn-contra03.xex

srn-contra03-pal.xex

 

 

post-45441-0-56009100-1558115774.png

srn-contra03b.xex

srn-contra03b-pal.xex

 

 

post-45441-0-96349700-1558115843.png

srn-contra03c.xex

srn-contra03c-pal.xex

 

 

Here are a few from Super C on the NES.

 

post-45441-0-11230400-1558115896.png

srn-superc01.xex

 

 

post-45441-0-74152500-1558115923.png

srn-superc03.xex

srn-superc03-pal.xex

 

 

post-45441-0-64458700-1558115971.png

srn-superc04b.xex

srn-superc04b-pal.xex

 

 

The Atari makes the NES graphics look easy, so how about if I step it up to the Megadrive?

 

Here's Streets of Rage 2

 

post-45441-0-25004800-1558116633.png

srn-sor2-10b.xex

srn-sor2-10b-pal.xex

 

 

post-45441-0-15758300-1558116680.png

srn-sor2-12b.xex

srn-sor2-12b-pal.xex

 

 

post-45441-0-75723600-1558116718.png

srn-sor2-5b.xex

srn-sor2-5b-pal.xex

 

 

I'm honestly amazed at how well the Atari does with these. What do you think?

  • Like 14
Link to comment
Share on other sites

I'm honestly amazed at how well the Atari does with these. What do you think?

Yes, they look really good. Good choice of source material and thanks for providing both PAL & NTSC.

  • Like 3
Link to comment
Share on other sites

 

I'm honestly amazed at how well the Atari does with these. What do you think?

 

These are wonderful thank you. Is there a way to slideshow them? Would love to have the A8 sit and automatically cycle many images every 5 or so seconds with a smooth transition (no loading screen, etc).

Edited by Sugarland
  • Like 1
Link to comment
Share on other sites

There's not really a way to display as well as load using SIO devices - almost all cycles are consumed by the RC kernal.

 

With IDE class devices it could probably be achieved - losing 2/3rds of the CPU per frame would mean slowdown but given we've had FMV + audio with IDE it should be doable here also.

  • Like 1
Link to comment
Share on other sites

 

These are wonderful thank you. Is there a way to slideshow them? Would love to have the A8 sit and automatically cycle many images every 5 or so seconds with a smooth transition (no loading screen, etc).

A batch file through SDX can achieve a "slide-show" and near-instant loading when combined with APT partitions on a SiDE 2/MyIDE II or other similar solutions.

 

Just such an example of a batch file was posted in this thread some time ago. It can probably be found by searching this thread with key words like SDX and batch.

  • Like 3
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...