Sonic and Sega Retro Message Board: flamewing - Viewing Profile - Sonic and Sega Retro Message Board

In a record-setting quintuple post, I have an announcement and a bugfix.

The announcement is that the improved DMA queue (and instructions for its use) can now be obtained on GitHub. I will no longer update the OP with new developments, but I will post new things in the thread.

The bugfix: this is actually an issue only with S&K's Perform_DPLC function and 128kB-safe DMA. If you don't have the option enabled, or you are not using Perform_DPLC, then you are not affected.

The issue is that Perform_DPLC expects the high word of d3 to be unchanged by a call to the DMA function; and this was not true in the case where the DMA was split in two if 128kB-safe option was enabled. The fix is here if you want to apply it manually.

Been awaiting a release now for some time; now to play around with it.

sega16, on 09 July 2015 - 03:06 AM, said:

You may want to look into the color selection algorithms used in this project; I had some success in converting and scaling art with it, although it does need some hand-tweaking for best results. It selects colors one color at a time, executing multiple iterations until everything converges. Another approach would be to use k-means segmentation using the color metric you already define in color_compare.cpp; here is a summary of several techniques. You probably can lift several of these from OpenCV.

sega16, on 09 July 2015 - 03:06 AM, said:

What I would do is try rendering the tile in all rows, then use the row with the smallest total distance (= sums of the distances of all pixels) to the original tile. But that can get slow.

I think your best bet is to pass the word you get from the chunk table (solidity bits + flip bits + block ID) to the AI and let it learn what the each combination means on its own. The block IDs are used in indices to the collision arrays, which depend on the zone; and the solidity + flip bits will affect how the collision arrays are applied (if at all). But each block ID + solidity + flip bits will always act the same way in the same zone, meaning it can be thought of as a denser way to feed data to the AI than breaking everything up all the way down to the collision arrays. The drawback is that you will have to evolve the AI for a specific zone, and probably for a longer period of time until it learns how all relevant blocks work.

If you do it another way, you will run the risk of the AI not being able to pass the simplest of levels because it gets stuck holding right on sloped ground where you need speed.

Oh, and a pitfall: some chunks in the level layout in S1 have bit 7 set (that is, ID >= 128). This is a bit flag; it is used by loops to mark that the chunk with ID+1 holds the collision data when you are going through the loop. You may want to feed that bit to the AI too, if it is to have a hope of getting through GHZ1.

Out of curiosity, what will you be passing as inputs for the AI? The solidity bits of each 16x16 or also the 16x16 ID and maybe solidity data?

It will, yes, unless you push the updates offscreen like S3&K does for Angel Island's waterline. It is one of the reasons I prefer the first option.