ilmenit

sure, I will add the command line to a window title. I will return to previous naming (without 32) so the 32bit version will work with the Larek's GUI. There is also this super simple GUI library for SDL2 https://github.com/rxi/microui/tree/master that could allow to make a proper UI (not just a launcher) for the RC. Will consider trying it, but if we have C++ developers here, any help is welcome! Since the release C++ also added a multi-threading to the language natively, so dependency on pthreads could be removed, but I think it's not a priority for now. Generally the code got super optimized for speed by @phaeronwith caching of intermediate results for reuse which now makes it harder to introduce changes (like addition of 5 color char-mode instead of 4 color bitmap). To make it possible the code will need to be significantly reorganized. Oh, I also forgot to add a Generator folder to the release on Github, will add it in the next release.

FYI, I just implemented proposed previously Diversified Late Acceptance Search https://arxiv.org/pdf/1806.09328.pdf and to my surprise it works worse than LAHC in case of RC. The reason is that with multi-threading in LAHC all threads modify the same "best picture", while in DLAS each thread modify a own "non-best picture" (Diversified part of the algorithm). However, because of diversity the CACHE_SIZE_LIMIT kicks leading to mitigation of performance gain. I then tried to reorganize the code in a way that all threads will modify a shared "non-best picture", however this requires extra synchronization of threads to use common array of past solutions, which again leads to mitigation of gain. Additionally, the multi-threading code for it is even more hard to read and would probably prevent further improvements. There are some new algorithms like https://www.uni-due.de/mvmo/ that should work better in multi-threaded optimization, so are to be tested in the future. On the other hand I found out that the cache can be reduced to 1/4 (16MB from 64MB per thread) without speed decrease, and even could lead to increase if /s number of solutions is small. For big ones (over 5K, 10K) the bigger cache could be more beneficial. I'll make it configurable from the command line, but by default lowered to 16MB.

Yes, you can set /save=0 to turn it off or set it to preferred value. I will change the default auto-save to be time-based (like each 30 seconds) to avoid SSD burning. @MrFish - I have tried also setting 1280 x 960 but it does not work well on my screen. I use high-resolution one and the SDL2 window is automatically scaled for me, so the 1280x960 leads to a huge out-of-screen window. In the current version of RC you can resize the window and make it full-screen. Can it solve the small window size problem for you?

Yes, you can set /save=0 to turn it off or set it to preferred value. I will change the default auto-save to be time-based (like each 30 seconds) to avoid SSD burning. I have tried also setting 1280 x 960 but it does not work well on my screen. I use high-resolution one and the SDL2 window is automatically scaled for me, so the 1280x960 leads to a huge out-of-screen window. In the current version of RC you can resize the window and make it full-screen. Can it solve the small window size problem for you?

Dear friends and users of Rasta Converter, After almost 11 years I am thrilled to announce a new official release or Rasta Converter - Beta 9, available now on GitHub. https://github.com/ilmenit/RastaConverter/releases/tag/Beta9 This update has been made possible thanks to the incredible contributions of our community, particularly the significant efforts of @Sheddy who successfully convinced me to revive this project. This release includes a number of exciting new features and improvements, including: - A fix for the sprite repositioning bug, thanks to the hard work of @Sheddyand @phaeron. - The removal of the dependency on the Allegro 4 library, replaced by the more modern SDL2. This allowed to prepare a 64-bit version of the software for improved performance and memory space. - The use of the LLVM compiler for extra speed and efficiency, thanks to @Sheddy. - The removal of the thread limit for the /threads parameter, allowing for even more parallel processing. - The addition of default auto-save functionality, which will save your work every 100K iterations. - Improved build processes for Linux, thanks to the efforts of @dmsc and @polluks. - An updated help file, courtesy of @snicklin. - Conditional compilation with NO_GUI directive that removes dependency on SDL2 (for developers who want to run RC on GUI-less devices). Thank you for your continued support of Rasta Converter. I hope you enjoy these new features and improvements, and I look forward to hearing your feedback. Please note that the code for this release has undergone a significant rewrite, so it is possible that some bugs may have been introduced. If you encounter any issues while using Rasta Converter Beta 9, please let us know by reporting them on GitHub so we can address them as soon as possible. Enjoy!

Yup, it should optimize faster. With how LAHC is done now (with multi threading) I couldn't make the DLAS work properly yet. I will probably need to implement it first to solve some easier optimization problem, to have a reference implementation.

Thanks to @Sheddy I have a working build environment for Rasta Converter on a new Visual Studio. This allowed me to merge and test the pull requests that were added by the others. The binary build Beta8 done by Sheddy here is the one to use now, the fixes are very good. Having some free time I'll make an official release to download from Github directly. Now I'm trying to understand the highly optimized code introduced by @phaeron with the multi-threading and caching that he added. While the code is of good quality, it's lacking the general comments about concepts used. Also I did not program in C++ for more than 10 years now and never used it for multi-threading so the task is not easy. I have some ideas to check and implement, but first I need to do more code cleanup to make it easier to work with the code in the future.

can you share the code?

Is it only a graphical overhaul or also the seed for pseudorandom level generation is different and we have "a new level pack"?

True, but even if you can, doesn't mean that you should (especially in a thread for a newbie)

Amazing, this is what I was looking for!

It was a great community and a pleasure to be here. I'm not optimistic knowing how corporations work. What often starts as idea for non-direct monetization, sooner or later brings questions about ROI, profitability and how to improve some KPIs like Average Revenue Per Active User. Time to create an alternative non-commercial international community?

it's crazy amazing how well it looks, how fluent the game is and how good the gameplay is preserved! I would say the non-transparent enemies are totally fine, and maybe even better in the limited resolution and color space, because the tiny black border makes them better visible on the screen. The game runs really fast now but "faster sprite drawing" indicates that you know how to improve it further 🙂

https://ekranownia.atari8.info/ http://www.atarimania.com/pgegallerysoft.awp?system=8&type=G&screenshot=1&step=200

Looking forward for the progress. At least for me it's one of the most interesting projects from recent years (as I love Dungeon Crawlers).