Jump to content
IGNORED

Images generated by RastaConverter


Philsan

Recommended Posts

2 minutes ago, MrFish said:

The problem with a SAM Coupé is that the software library is next to nothing compared with the Atari 8-bit computers (unless your goal is 48K Spectrum software); and good luck getting your hands on one; and if you do, make sure you've got plenty of spare cash on hand.

 

The problem with a Atari 800/400 is that the software library not so perfect compared with the Commodore 64 and not all games from C64 are also on Atari...

Link to comment
Share on other sites

1 minute ago, GravityWorm said:

The problem with a Atari 800/400 is that the software library not so perfect compared with the Commodore 64 and not all games from C64 are also on Atari...

What does that have to do with a SAM Coupé?

 

Link to comment
Share on other sites

56 minutes ago, Beeblebrox said:

If cheap carts with the right tech could give all the benefits then it would be great to have them available, but I don't think they'd replace the other options out there. Thing is, most of the RAM upgrades either aren't that expensive, or are way more than just a simple Ram uprade. Multicarts, especially the likes of SIDE3, AVG and SUBAVG - offer so much more. 

 

For example  - a Rambo XL 256k upgrade for a stock 800XL will maybe cost £40 all in, maybe even cheaper. A 320k upgrade for an XE might cost £20 all in. True - you have to have the skills to install them, and they are per machine.

 

U1MB is around £90, but is way more than just an ram upgrade.

 

Brian's plug in PBI upgrade boards for the 800XL and 600XL can be switched between stock machines. Same goes for his 400 and 800 ram boards:

 

https://www.tindie.com/stores/5cfab/

 

On balance - for most people a plugin Multicart like AVG or SubAvg, which can be moved between the XL/XE lines (where extra cabling is required depending on whether an XE or XL), is a good balance. 

 

I agree with most what you wrote, but using a cartridge is more like metal fans would say "trü"...
Important benefit of cartridges - faster load time than disk... And the pictures from RC are big. Making a huge games could be more easy to make...
Like RPG, Adventure... Porting PC (EGA) Sierra games would be easier...

Link to comment
Share on other sites

Posted (edited)
21 minutes ago, GravityWorm said:

I agree with most what you wrote, but using a cartridge is more like metal fans would say "trü"...
Important benefit of cartridges - faster load time than disk... And the pictures from RC are big. Making a huge games could be more easy to make...
Like RPG, Adventure... Porting PC (EGA) Sierra games would be easier...

I totally agree with the use of the cart format in general. I am so glad that Atari saw fit to include them with the 8bit computer line. What I am meaning to say though is that we have the cart tech already in the form of some of the multicarts. Sure, they can be expensive, but they offer way more that just a basic way to load games.

 

So, I suppose what I mean was your idea of a super cheap cart, where, if it were able to do what you suggest and grant ram to a stock machine, it would still not give you the benefits of the established multicarts. Plus, of course, as FJC says above, it's rather moot as, for a lot of existing A8 games, because of memory locations, clashes, etc etc, it's not viable. 

 

I think, given a large amount of A8 owners will have at least 64k machines, and many of us have 128k or higher machines already, having the wide range of flash and multi carts already available is enough. It's so much easier these days to find an path to upgrading your A8's ram. 

 

 

 

 

Edited by Beeblebrox
Link to comment
Share on other sites

On 4/25/2024 at 2:50 PM, ilmenit said:

Beta10 has been released:
https://github.com/ilmenit/RastaConverter/releases/tag/Beta10

* pthreads dependency removed (laoo)
* Added thousands separator in statistics
* Added command line parameter to window title
* Changed default auto-save to "auto" to save SSD disks life

Hey @ilmenit,

Edit a day later: The very low performance seems to be related to using ciede as the distance comparison (in creating the image, not pre-compute). If I switch to YUV/Euclid I get much higher rates, in the hundreds of thousands even, but I need to test different thread counts to see if I get the same falloff behavior. If I can do a full set of tests I'll add that here for posterity.

I think something is up with the threading/distribution model in RastaConverter (using this Beta10 that you posted, but I believe this behavior goes back). Please note I am not complaining, I just thought I would just supply this info as maybe it is news to you. I downloaded source to take a look after I found this, but need to go back and download/install all the dependencies and set up includes etc so I can fully locally compile and experiment.

In short what I see on a high core/thread machine is not just diminishing returns but negative performance past a few threads. Here's how I compared:
Machine 1 is an AMD 7950X3D (base clock 4.2Ghz), which is 16 physical cores, 32 threads, big piles of cache.
Machine 2 is Proxmox container running on an Intel N305, 8 cores/8 threads, 3.8Ghz, but the container is 4 threads. I wanted a stark difference - this processor is VERY under powered in comparison, with a very small cache, and I'm taking away half of its cores

Both machines are benchmarked in different ways (Geekbench, 3dMark) to establish they are working correctly and close to or above expectation in the general case.

I am treating evaluations as the primary metric between the examples. Rate is fairly volatile from update to update so I take a general read of what I think the average of that is when I note it here.

I am using the same image as input, no dithering, all the settings the same (color distance ciede, initial state empty so they all do the same workload, number of solutions 10000, auto save off). Then I vary the threads on Machine 1 to test. I let the image generation run for three minutes on stopwatch and then take a read of the values, so each of these is a snapshot at 3 minutes other than rate which is an eyeball average.

Machine 2 w/04 threads: ~8000 rate, norm distance 4.2, 1.536M evaluations
Machine 1 w/01 threads: ~14000 rate, norm distance 2.3, 2.488M evaluations
Machine 1 w/02 threads: ~18000 rate, norm distance 2.3, 3.235M evaluations
Machine 1 w/04 threads: ~15000 rate, norm distance 2.8, 2.975M evaluations
Machine 1 w/08 threads: ~10000 rate, norm distance 4.4, 1.984M evaluations
Machine 1 w/16 threads: ~7500 rate, norm distance 6.5, 1.452M evaluations
Machine 1 w/32 threads: ~9000 rate, norm distance 6.9, 1.885M evaluations

In all cases the threads are definitely doing something, as I can see them at 100% in process monitor. It seems a bit confusing to sort out what is actually performance here, am I wrong to treat norm distance as an overall quality indicator? The lower it gets the closer you are to the original image, with short term variation of course. By that measure as near as I can tell 2 threads helps, and it actually goes downhill from there - I don't expect efficiency to be linear, but this appears to be a net negative past 2 threads.

Edit: Forgot to mention, this is all under Windows. Would be easy to run the same comparison on the same hardware using Linux though.

Link to comment
Share on other sites

If you run with just one solution, the image will very quickly converge.  On my system (i9 12900) when the image is almost "done", I can get around 385,000 per second.  But, sometimes when the conversion starts, I am only getting 50,000 or so.  I am not sure if this info helps you at all, but you may want to check that.

 

I have not tried changing from 1 thread up to XX - I can go up to 24.  Let me run some tests, and I will either edit, or reply to this post.

Link to comment
Share on other sites

Yes, I put a very high solution range just to represent a large workload (and to make it completely equal among all machines). I can get much higher "Rate" values with solutions at 1 as you say, I suppose the question is are they better at achieving quality, as you might deny yourself a better overall image by narrowing the solutions - at low values you get little benefit from hill climbing, as you make less experimental incremental changes. Or at least that's how classical hill climbing is supposed to work, I've just assumed it's the overall approach here and that solutions = change rate.

  • Like 1
Link to comment
Share on other sites

4 minutes ago, gnusto said:

Yes, I put a very high solution range just to represent a large workload (and to make it completely equal among all machines). I can get much higher "Rate" values with solutions at 1 as you say, I suppose the question is are they better at achieving quality, as you might deny yourself a better overall image by narrowing the solutions - at low values you get little benefit from hill climbing, as you make less experimental incremental changes. Or at least that's how classical hill climbing is supposed to work, I've just assumed it's the overall approach here and that solutions = change rate.

Oh - I always run high solutions (8192) - the results are worth it.  Just wasn't sure if you would get different rates per thread doing it that way, as it may be the hill climbing part of the code causing the behaviour you are seeing.

Link to comment
Share on other sites

3 hours ago, Stephen said:

Oh - I always run high solutions (8192) - the results are worth it.  Just wasn't sure if you would get different rates per thread doing it that way, as it may be the hill climbing part of the code causing the behaviour you are seeing.

8192 is high?
My highest is about 34 567
Oh. I'm doing something wrong?

Link to comment
Share on other sites

16 minutes ago, _The Doctor__ said:

no, your images and atarimans look good

I'm doing images for Atari man :)
now :)
I did set: 12 345

Link to comment
Share on other sites

Posted (edited)
6 hours ago, gnusto said:

Yes, I put a very high solution range just to represent a large workload (and to make it completely equal among all machines). I can get much higher "Rate" values with solutions at 1 as you say, I suppose the question is are they better at achieving quality, as you might deny yourself a better overall image by narrowing the solutions - at low values you get little benefit from hill climbing, as you make less experimental incremental changes. Or at least that's how classical hill climbing is supposed to work, I've just assumed it's the overall approach here and that solutions = change rate.

 

Interesting but 3 minutes is barely started!

If you run your tests multiple times you should see very varied norm distances as everything about RastaConverter is the randomness of solutions.

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

2 hours ago, Beeblebrox said:

I tend to run 25000 solutions as standard, always with yuv/yuv and always a mask, sometimes dithering. 

i did 10 000 but then i drooped having a standard

Link to comment
Share on other sites

13 hours ago, gnusto said:

Yes, I put a very high solution range just to represent a large workload (and to make it completely equal among all machines). I can get much higher "Rate" values with solutions at 1 as you say, I suppose the question is are they better at achieving quality, as you might deny yourself a better overall image by narrowing the solutions - at low values you get little benefit from hill climbing, as you make less experimental incremental changes. Or at least that's how classical hill climbing is supposed to work, I've just assumed it's the overall approach here and that solutions = change rate.

Here's some results of a quick test I did, from 1 to 24 threads.  It was a pretty linear increase in processing rate vs # of threads.

Threads		Rate
01		24,000
02		52,000
03		51,000
04		115,000
05		112,000
06		132,000
07		145,000
08		125,000 50% CPU
16		224,000 100% CPU 4.47GHz
24		370,000 100% CPU 4.49GHz

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Stephen said:

Here's some results of a quick test I did, from 1 to 24 threads.  It was a pretty linear increase in processing rate vs # of threads.

Threads		Rate
01		24,000
02		52,000
03		51,000
04		115,000
05		112,000
06		132,000
07		145,000
08		125,000 50% CPU
16		224,000 100% CPU 4.47GHz
24		370,000 100% CPU 4.49GHz

 

Thanks for comparing - Did you happen to note norm distance? Were the higher thread counts "better" in the same amount of time? And all of these were sampled at the same amount of time passed?

Could be some AMD specific thing, I suppose. But if it is it's weird because the cores are definitely active. I have high core Intel machine to test on as well, so I'll do that.

Link to comment
Share on other sites

53 minutes ago, gnusto said:

Thanks for comparing - Did you happen to note norm distance? Were the higher thread counts "better" in the same amount of time? And all of these were sampled at the same amount of time passed?

Could be some AMD specific thing, I suppose. But if it is it's weird because the cores are definitely active. I have high core Intel machine to test on as well, so I'll do that.

I only let these run for about a minute each to get the rates.  But yes - the normal distance improved at a correspondingly faster rate, as the rate increased.  Not to say the normal got better when more threads were used.  But, let's say the best that could be achieved was a normal of 10, the more threads I use, the faster I approach 10.

Link to comment
Share on other sites

21 minutes ago, Stephen said:

Continuing my theme of old Mopar ads, here is a 61 colour version of a Dodge Super Bee ad.  I'm working on a few more.

DodgeSuperBee_Progress.thumb.jpg.d9fb1775af967037286810d85b5cb444.jpg

Stephen_DodgeSuperBee.thumb.png.9f7f863b9116b6e75ec8cd043c7bdd1b.png

SuperBee1.jpg.a902fb9b1dd24d77e16247325c0a13f7.jpg

Stephen_DodgeSuperBee.xex 22.1 kB · 1 download

Subtitle text for ' Dodge introduces a new model Super Bee 'would be nice.

  • Like 1
Link to comment
Share on other sites

I was curious so looked it up: $3074 from 1968 inflation adjusted is $27600 today.

However, the average salary in 1968 was $4786, so $3074 was 60+% of that salary. The average US salary now is $63,795. Since there is no Super Bee in modern times (they actually brought back the name but dropped it again 10 years ago, we'll ignore that), a closely related Dodge equivalent might be a V8 R/T charger, which goes for around $45K. $45K is about 70% of $63,795. More expensive in a pure buying power sense to be sure, but not as bad as I thought it would be.

 

Amusingly, the starter price v8 Super Bee was a 117 inch wheel base sedan with 335bhp, weighing about 3500lbs. A starter v8 Charger is a 120 inch wheel base sedan with 370bhp (the Hemi is 485bhp though), weighing about 4370 lbs. The modern car has worse horse to weight but clocks in faster, probably because of better suspension, transmission. 0-60 in 1968 was ~6 seconds, 0-60 on an R/T is 5.2.

The older car looks approximately 1,068.2% better though. Around there somewhere.

  • Like 1
  • Thanks 1
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...
×
×
  • Create New...