Images generated by RastaConverter

[Atari8man2004]

Bob Marley

colors: 66

plus src

 

Robert Nesta "Bob" Marley (February 6, 1945 – May 11, 1981) was an important Jamaican singer-songwriter and musician in the 1970s and 1980s. He made the style of reggae music very popular all over the world. His music told stories of his home and the Rastafarian religion that he followed. Some songs were about religion and some songs were about politics like Get Up Stand Up

 

 

Atari8man_NTSC_Bob_Marley.xex Atari8man_Pal_Bob_Marley.xex

Edited April 6 by Atari8man2004

[Atari8man2004]

Fruits

Colors: 56

plus src

 

 

 

Atari8man_NTSC_Fruits.xex Atari8man_PAL_Fruits.xex

[Atari8man2004]

Happy Clown I

Colors: 88

plus src

 

 

Atari8man_NTSC_Happy_Clown_1.xex Atari8man_Pal_Happy_Clown_1.xex

[+Stephen]

Purple Wolf - 25 colours.

Stephen_PurpleWolf.xex

[+Stephen]

Smiling dog series

Image 1 - 88 Colours

Stephen_Growl1.xex

[+Stephen]

Image 2 - 90 Colours

Stephen_Growl2.xex

[+Stephen]

Image 3 - 76 Colours

Stephen_Growl3.xex

[GravityWorm]

On 4/6/2024 at 6:18 PM, drpeter said:

Just to clarify for @Sheddy's peace of mind, there were no artifacts in the sense of things that Rasta thought should display differently due to errors in emulation- there were just areas in which, due to the limitations of the semi-random choices of the Rasta optimisation algorithm and the Atari hardware, a few simple hand-tweaks of the bitmap & kernel visibly improved things.

@drpeter

New version crashes 20% the time. Some memory fault. Something like segmentation fault or memory access violation

Edited April 8 by GravityWorm

[Sheddy]

1 hour ago, GravityWorm said:

@drpeter

New version crashes 20% the time. Some memory fault. Something like segmentation fault or memory access violation

Is that on your Linux or do you also use Windows version?

[GravityWorm]

12 minutes ago, Sheddy said:

Is that on your Linux or do you also use Windows version?

GNU/Linux

 

[Sheddy]

8 hours ago, GravityWorm said:

GNU/Linux

 

@dmsc any suggestions? I can only speak for the Windows compile which assumes SSE2 capable processor. I know there's lots of different Linux distro but assume other people have had success though.

[ivop]

11 hours ago, GravityWorm said:

@drpeter

New version crashes 20% the time. Some memory fault. Something like segmentation fault or memory access violation

You could try my Linux fork at https://github.com/ivop/RastaConverter

Started 12 years ago, and has a lot of fixes (compiler warnings fixed, deprecated code replaced). Never got around to create a proper patch to send upstream though. I recently merged the new Sheddy code.

 

It has Link Time Optimization enabled (faster), and it also supports Profile Guided Optimization. For the latter, type make pg first, run rastaconv-pg for a few minutes with real world data to collect profile data, then run make pu to build the final binary rastaconv-pu.

 

Edited April 8 by ivop

[GravityWorm]

But it crushes only when I run the executable.Then during the rendering it never crashed!

[drpeter]

46 minutes ago, GravityWorm said:

But it crushes only when I run the executable

That's odd. A Rastaconverter xex shouldn't be able to crash the host computer- only the emulated Atari. Can you post a screenshot of the crash?  Have you had this issue with any other Rasta xex files? This sounds like an issue from whichever emulator you have running on Linux. It was Atari800 if I remember correctly? (Am I correct in thinking that it is the xex executable which is causing a crash when executed, not the Rastaconverter exe executable?)

Edited April 8 by drpeter

[snicklin]

Has anyone ever considered porting this to Go (Golang)?

 

I thought it might be good to see if the concurrency capabilities of Go would make conversion quicker? It may not, as C++ is quicker than Go on a single thread. 

 

I have taken a look at the code, but it is a lot of work to do to potentially find out you have wasted your time.

 

I noticed some mentions of concurrency in the Rastaconverter code, but didn't really understand that side of it as I am not a c++ person, though can read general code. From memory from what I have read here, there is some concurrency.....

Edited April 8 by snicklin
typo

[GravityWorm]

6 hours ago, drpeter said:

That's odd. A Rastaconverter xex shouldn't be able to crash the host computer- only the emulated Atari. Can you post a screenshot of the crash?  Have you had this issue with any other Rasta xex files? This sounds like an issue from whichever emulator you have running on Linux. It was Atari800 if I remember correctly? (Am I correct in thinking that it is the xex executable which is causing a crash when executed, not the Rastaconverter exe executable?)

No the Rasta Converter executable (the new version!)  crashes!. Nor xex files
But new Rasta Converter only crashes in the begging. Never crashed during the rendering process...

[GravityWorm]

This executable crashes:

[Sheddy]

So when you try and run it, it just immediately crashes sometimes, but usually it runs fine. Weird! Maybe see if you can use @ivopLinux version. You'd probably need similar instructions to make it as @dmsc for your system. (Unless someone has already compiled a version for your Linux distro they can send you)

Edited April 9 by Sheddy

[GravityWorm]

19 minutes ago, Sheddy said:

So when you try and run it, it just immediately crashes sometimes, but usually it runs fine. Weird! Maybe see if you can use @ivopLinux version. You'd probably need similar instructions to make it as @dmsc for your system. (Unless someone has already compiled a version for your Linux distro they can send you)

"So when you try and run it, it just immediately crashes sometimes, but usually it runs fine."

Yes! And once it  runs it runs and never crashes!  So it does not bother me at all

 

[+MrFish]

Saw one of these yesterday afternoon. 100% solar eclipse, and all I had to do was step outside my door to view it. Awesome phenomenon!

 

 

mrfish - eclipse.xex

 

[drunkeneye]

11 hours ago, snicklin said:

Has anyone ever considered porting this to Go (Golang)?

 

I thought it might be good to see if the concurrency capabilities of Go would make conversion quicker? It may not, as C++ is quicker than Go on a single thread. 

 

I have taken a look at the code, but it is a lot of work to do to potentially find out you have wasted your time.

 

I noticed some mentions of concurrency in the Rastaconverter code, but didn't really understand that side of it as I am not a c++ person, though can read general code. From memory from what I have read here, there is some concurrency.....

 

why would you use Go?

i'd prefer strongly python, much more portable (and readable for me),

and there are a lot of genetic algorithm/programming tools (PyGAD),

and would allow for easy use of deep networks/reinforcement (PyTorch/Keras etc).

not sure, if these libraries exist in Go.

i do not believe that Go will be that much faster, will it?

would prefer strongly more efficient algorithms, or at least

have several options for that, instead of the late acceptance hill climbing.

 

 

Edited April 9 by drunkeneye
...

[snicklin]

1 hour ago, drunkeneye said:

 

why would you use Go?

i'd prefer strongly python, much more portable (and readable for me),

and there are a lot of genetic algorithm/programming tools (PyGAD),

and would allow for easy use of deep networks/reinforcement (PyTorch/Keras etc).

not sure, if these libraries exist in Go.

i do not believe that Go will be that much faster, will it?

would prefer strongly more efficient algorithms, or at least

have several options for that, instead of the late acceptance hill climbing.

 

 

Well, for a start, I can't program Python!
 

It is also a lot slower, so I wouldn't really be gaining anything there. Go is a quick language, not the quickest, but up there and allows concurrency easily.

 

As for libraries, I cannot comment on the mentioned libraries, are they totally applicable to this situation? I only ask because RC is a very specialised bit of software, would they help, I am not sure.... not being negative, I really don't know.

 

Good algorithms will always be better, but is there one better than LHC, also, I am not sure. A good algorithm with the right language would be a killer here. C++ though is well up there with the fastest languages, probably only beaten by C and Assembly.

 

 

 

[+Stephen]

My dog wanted to watch the eclipse with us.  66 colours.

Stephen_EclipseDog.xex

[drunkeneye]

1 hour ago, snicklin said:

Well, for a start, I can't program Python!
 

It is also a lot slower, so I wouldn't really be gaining anything there. Go is a quick language, not the quickest, but up there and allows concurrency easily.

 

As for libraries, I cannot comment on the mentioned libraries, are they totally applicable to this situation? I only ask because RC is a very specialised bit of software, would they help, I am not sure.... not being negative, I really don't know.

 

Good algorithms will always be better, but is there one better than LHC, also, I am not sure. A good algorithm with the right language would be a killer here. C++ though is well up there with the fastest languages, probably only beaten by C and Assembly.

 

 

 

 

personally, i don't think switching c++ for go will yield any real avantage.

the c++ code can use all cores, candidate solutions can be easily computed in parallel

and if i am not mistaken, basically this is what the code does. python is not as slow

as one might think, and with pylint or similar i think the evaluation can still be in c++,

only the 'method' could be in python, and this part should not be expensive.

 

no idea if an algorithm is better than LHC, but in C++ i don't see any easy way to

test other algorithms. this is why python would be very helpful, because there are many

implemented, just switch and test if it works better.  also, deep networks could potentially

map an image to code-- might need incredible many training data, but even if not perfect

could be a very good starting point for the LHC or other algorithms.

 

 

whatever, python is a "dead fish" without someone with much time at their hands.

 

 

[ivop]

2 hours ago, snicklin said:

It is also a lot slower, so I wouldn't really be gaining anything there.

Python is mostly used as a wrapper around C++ machine learning libraries. With PyTorch, CuPy, Theano, PyCuda, TensorFlow, etc. and a proper GPU you get thousands of threads instead of just a few with a CPU. Things like evaluating the proposed images can be done in parallel per pixel, i.e. thousands of pixels are evaluated simultaneously. We are speaking of at least a 100x increase in speed compared to evaluating pixel by pixel as it is now. And switching between different optimizers is easy.