+Stephen Posted May 20, 2013 Share Posted May 20, 2013 I got an error ... Missing MSVCR71.dll. Do you need some runtime library installed first? Thanks, Bob UnZIP and drop this file in the directory where the Rasta exe is running. MSVCR71.zip Quote Link to comment Share on other sites More sharing options...
snicklin Posted May 20, 2013 Share Posted May 20, 2013 I've just been doing some tests of the new threaded code and I'm not getting the above mentioned rates, but I am getting some far, far better rates than previously. However, I wouldn't expect 20 or 30K a second as I am running Windows XP through Virtualbox on an I5 running Linux Mint. It appears to do be doing well, and the normal distance is coming down around every 1500 evaluations, even after 77 million evaluations, I am impressed! Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 21, 2013 Share Posted May 21, 2013 (edited) I gave up at 400,000,000 evaluations using knoll dithering and a small detail mask (bottom of the cat's face). Posting image in a spoiler tag due to NSFW caption. output.xex Edited May 21, 2013 by Stephen Quote Link to comment Share on other sites More sharing options...
bfollett Posted May 21, 2013 Share Posted May 21, 2013 Thanks, that did the trick. I didn't know if there was going to be more than 1 missing dll, but it was just the one. Bob UnZIP and drop this file in the directory where the Rasta exe is running. Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted May 21, 2013 Share Posted May 21, 2013 @phaeron: That makes sense! Thanks for the explanation. I modified abxmovie to rewrite AUDC1 immediately after every segment load and voila - no more buzz. @CharlieChaplin: Thanks for the heads up! I've uploaded fixed versions of all three movies: birds-fixed.zip - 3.3minutes, NTSC epic-fixed.zip - 1.7minutes, NTSC im-fixed.zip - 1.4 minutes, PAL What exactly keeps these animation executables from running on real hardware? They run fine in both Altirra and Atari800win.. But I droped them on a CF card and stuck them in my SIDE cartridge, and FAT32-Loader sees them, but it just freezes with a blank screen if you try to run them. Quote Link to comment Share on other sites More sharing options...
Xuel Posted May 22, 2013 Share Posted May 22, 2013 What exactly keeps these animation executables from running on real hardware? They run fine in both Altirra and Atari800win.. But I droped them on a CF card and stuck them in my SIDE cartridge, and FAT32-Loader sees them, but it just freezes with a blank screen if you try to run them. These executables abuse the fact that segments of any length are loaded instantaneously in emulators, as in it takes zero machine cycles. Real machines take many cycles per byte to load that same segment. Check out my blog post about my ABX hobby project where I attached a Beaglebone to a stock 600XL to enable semi-instantly paging in 24K blocks out of a pool of 140MB of RAM. This allows RastaMovie movies to be played on real hardware. phaeron has since figured out how to display APAC movies with IDE interfaces by telling ANTIC to read bitmap data by hammering the IDE data register but that method wouldn't work with RastaMovies since the CPU display kernel for each image needs to be loaded in addition to bitmap data but you can't get the 6502 to hammer a single IDE data register the same way. Though, mr. atari modified his IDE interface to map D580-D5FF to the data register which might just be enough to do it! You would just have to allocate three cycles of the line kernel for a JMP instruction to keep the 6502 inside that window. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted May 22, 2013 Author Share Posted May 22, 2013 I needed an excuse to learn C++11 threading, so I ported RastaConverter beta 5.1 to Visual Studio Express 2012 and rewrote the evaluation loop to work on multiple threads. Of course, that's when I discovered via the debugger that VS2012's condition_variable is unusably broken, so then I had to strip out the C++11 threading and replace it with pthreads-win32. Updated build and source are attached (VS2010 SSE2 pogo build). It has an improved line cache for better single threaded performance and the core evaluation loop broken out to enable multithreading. Hopefully I haven't added too many bugs. Phaeron, great work! You have really motivated me to merge the beta6 changes to this multithread version :-) Hope to find some time soon. 1 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted May 25, 2013 Share Posted May 25, 2013 Phaeron, great work! You have really motivated me to merge the beta6 changes to this multithread version :-) Hope to find some time soon. If possible, please fix the grey palette output.xex bug (output.png image is grey but output.xex has colored stripes). Quote Link to comment Share on other sites More sharing options...
ilmenit Posted May 27, 2013 Author Share Posted May 27, 2013 (edited) If possible, please fix the grey palette output.xex bug (output.png image is grey but output.xex has colored stripes). Does it still happen in the latest version (those by Phaeron)? I see that he created the multithreaded version on the Beta6 from Github. Edited May 27, 2013 by ilmenit Quote Link to comment Share on other sites More sharing options...
+Philsan Posted May 28, 2013 Share Posted May 28, 2013 If possible, please fix the grey palette output.xex bug (output.png image is grey but output.xex has colored stripes). Does it still happen in the latest version (those by Phaeron)? I see that he created the multithreaded version on the Beta6 from Github. I am not a command line guy (I use RastaConverter with GUI) but I tested Phaeron's new threaded version and it has the same bug. Quote Link to comment Share on other sites More sharing options...
snicklin Posted May 31, 2013 Share Posted May 31, 2013 One thing that I see is that the "Norm. Dist" value goes up and down (but on the whole - down), would it be possible that this is locked to the value of the best solution that is currently available, rather than the latest solution? Ideally I'd only like this value to go down or stay the same. Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 1, 2013 Share Posted June 1, 2013 I might have broken it, but in the multithreaded version I released, it's the score of the last 'accepted' solution. This means that if you have more than one solution, like /s=10000, it'll go up and down as sometimes a solution with a slightly worse score will be taken. This actually does reflect the program that would get saved out since the previous solution isn't actually kept even if it had a lower score. I've since modified my local version to also print out an average of the solution score table so it's easier to see overall progress. Quote Link to comment Share on other sites More sharing options...
snicklin Posted June 1, 2013 Share Posted June 1, 2013 I might have broken it, but in the multithreaded version I released, it's the score of the last 'accepted' solution. This means that if you have more than one solution, like /s=10000, it'll go up and down as sometimes a solution with a slightly worse score will be taken. This actually does reflect the program that would get saved out since the previous solution isn't actually kept even if it had a lower score. I've since modified my local version to also print out an average of the solution score table so it's easier to see overall progress. Ahh, now that explains it! Yes, I think that the more information on the screen, the better. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 1, 2013 Author Share Posted June 1, 2013 I am not a command line guy (I use RastaConverter with GUI) but I tested Phaeron's new threaded version and it has the same bug. I see where the problem is. RastaConverter does not know where the picture will be displayed and you have to decide about it with /pal option. The palette used in the RastaConverter must be the same (or very close) to palette of execution on real Atari (or emulator). For example if you convert a picture with /pal=laoo (which is PAL) and then try to display it on NTSC then colour will be greenish. In the mentioned "bug" you have chosen a gray.act palette which is for simulation of monochrome display in emulators. Therefore RastaConvrter ignored chroma information and worked only on luma. If you display such converted output picture on a monochromatic Atari or emulator using grey.act palette then you will see a corectly converted picture. If you display it on some colorful screen then you'll see random colors on the screen. This is because RC mapped grey colors from the picture to random grey colors from chosen palette. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 2, 2013 Author Share Posted June 2, 2013 RastaConverter Beta7, command line Win32 x86 Binary: http://bintray.com/ilmenit/generic/RastaConverter/Beta7/general Sources: http://github.com/ilmenit/RastaConverter MULTI-THREADED version - many thanks to Phaeron! Fixed bug causing crash with /dither=knoll + /preprocess /onoff option added to control used registers - basic version Optimized version of raster program (.rp) is saved as .opt Changed default options to: /filter=box /pal=laoo /height is automatically assigned to keep proportion of the screen if width:height is higher than 4:3 Fixed screen redraw when switching the application window New dithering types: line and line2 Fixed Jarvis dithering Fix in floyd dithering - should't produce that many vertical stripes /picture_colors was buggy. Removed. 3 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted June 2, 2013 Share Posted June 2, 2013 Thank you very much for the update, Jakub. I see where the problem is. RastaConverter does not know where the picture will be displayed and you have to decide about it with /pal option. The palette used in the RastaConverter must be the same (or very close) to palette of execution on real Atari (or emulator). For example if you convert a picture with /pal=laoo (which is PAL) and then try to display it on NTSC then colour will be greenish. In the mentioned "bug" you have chosen a gray.act palette which is for simulation of monochrome display in emulators. Therefore RastaConvrter ignored chroma information and worked only on luma. If you display such converted output picture on a monochromatic Atari or emulator using grey.act palette then you will see a corectly converted picture. If you display it on some colorful screen then you'll see random colors on the screen. This is because RC mapped grey colors from the picture to random grey colors from chosen palette. I have done this conversion: PC original grey image > Rastaconverter with Altirra standard palette = xex with stripes of colors, on Altirra emulator and real Atari Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 2, 2013 Author Share Posted June 2, 2013 I have done this conversion: PC original grey image > Rastaconverter with Altirra standard palette = xex with stripes of colors, on Altirra emulator and real Atari Could you attach all the output files zipped? Quote Link to comment Share on other sites More sharing options...
+Philsan Posted June 2, 2013 Share Posted June 2, 2013 Could you attach all the output files zipped? PM sent. Thank you. Quote Link to comment Share on other sites More sharing options...
+Philsan Posted June 2, 2013 Share Posted June 2, 2013 Jacub was right. I see where the problem is. RastaConverter does not know where the picture will be displayed and you have to decide about it with /pal option. The palette used in the RastaConverter must be the same (or very close) to palette of execution on real Atari (or emulator). For example if you convert a picture with /pal=laoo (which is PAL) and then try to display it on NTSC then colour will be greenish. In the mentioned "bug" you have chosen a gray.act palette which is for simulation of monochrome display in emulators. Therefore RastaConvrter ignored chroma information and worked only on luma. If you display such converted output picture on a monochromatic Atari or emulator using grey.act palette then you will see a corectly converted picture. If you display it on some colorful screen then you'll see random colors on the screen. This is because RC mapped grey colors from the picture to random grey colors from chosen palette. So, to display a grey scale image on Atari or emulator, first convert a color image to grey scale using a PC program, then convert it to Atari with RastaConverter using a standard palette and not "gray.act" palette. Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted June 17, 2013 Share Posted June 17, 2013 (edited) I love the Quantizator / RastaConverter pic quality of the .xex output on a REAL Atari. My question is: How can I load these pics into a (Compiled and linked) Turbo-BASIC-XL proram I want to write? I want to make a light gun (or joystick) shooter game. I want to display these pics, one pic per level, and have the user shoot at a particular place on each picture. This should be easily possible, if I knew how to load the pictures. Thanks! -Kyle Edited June 17, 2013 by Kyle22 Quote Link to comment Share on other sites More sharing options...
vol Posted December 27, 2023 Share Posted December 27, 2023 This thread is old but still very useful. I got the RastaConveter sources from github, tried to compile them on Linux and failed. I had to apply several patches. Let me share them, it would be great if this helps someone. linux-patch.zip 2 Quote Link to comment Share on other sites More sharing options...
pirx Posted December 27, 2023 Share Posted December 27, 2023 could you put up a github repo with your version? Quote Link to comment Share on other sites More sharing options...
ivop Posted December 27, 2023 Share Posted December 27, 2023 (edited) 2 hours ago, pirx said: could you put up a github repo with your version? I have a fork for Linux for years at https://github.com/ivop/RastaConverter On top of the build fixes it has numerous code fixes, too. See git log for details. Edited December 27, 2023 by ivop 2 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.