Before I start writing my own program, I want to see if something already exists.

I have a very large background (20×256 pixels) for a side scrolling beat'em up game. The background is very detailed with lots of unique tiles (several thousand). I'm using the MMC3 512/256 board so I have ample amounts of memory to burn.

What I need is something that does

1. Extracts the tiles from the background2. Extracts the color paletes from the background3. Organizes the tiles into banks that would allow for smooth horizontal scrolling4. Return the horizontal breakpoints and vertical IRQs were the tile banks and palettes would need to be changed. Note, there shouldn't need to be any hblank palette swap needed.

Regardless... coming up with a palette is part of the development process, and I prefer to do to manually. Which means reducing the image to 4 color black, grey, and white.

When I draw images, I did so using MS Paint and use the dabber on an RGB palette pulled from NESST. I'm pretty good an limiting the palette by the 16 rule, though I do make mistakes, the impacts of which are minimized if I add "slack" points to the image where I can expand or contract the image in a dimension without altering the look too much. The specific challenges here are

1. Identifying where I am off: Not difficult algorithmic-ly because I can sample the colors every 16x16 pixels and make sure that a sliding window of 256 pixels does not contain more than 4 different palettes2. Identifying where I need to change palettes (byproduct of the algorithm from 1)

Kasumi wrote:

If I thought those would be easy to add, I would. But I can't come up with an algorithm that would play nice with how the program already works.

If we ignore hblank IRQ bank switching and assume that no 272 x 240 window contains no more that 256 unique tiles. That gives us a 16 pixel buffer on both ends for when I scroll splits the screen mid-tile.

If NESST could order the tiles in the as they appear horizontally, that would get me really close.

Here is how I was planning the algorithm:

0. Splice the image into 8x8 tiles.1. Start 256 x 240 pixel window at the beginning of the image.2. Populate a tile bank, ordering the tiles based on how they appear horizontally (use vertical placement as a tie-breaker).3. Move the window forward 1 pixel and find all the tiles now in use.4. Highlight ("RED") all the tiles in the bank that are no longer visible.5a. If there is enough empty slots, append any new unique tiles ("GREEN") to the bank.5b. If not, then save a copy of the bank and mark the x-coordinate Remove all RED tiles then add in the GREEN Tiles.6. Repeat 3 until the window has reached the end of the image.

The same technique can be done for the palettes.

If we wanted to include hblank bank switching then it would just be a matter of finding the "optimal" split point. I'd repeat the same algorithm as above by now be managing two active banks at once.

The publicly available one is called savtool, and it works on 256x240-pixel images because it's intended for converting a static PNG to a CHR+NAM pair. It's written in Python and distributed alongside a background graphics editor that runs on the NES.

Lucradan wrote:

assume that no 272 x 240 window contains no more that 256 unique tiles

This is starting to sound a lot like a tool I made for Retrotainment Games during the development of Haunted: Halloween '85. Should I ask if I may release it in a modified form?

I have a couple more questions to think about that may inform the design of data structures for your scrolling engine:

Do you plan to use one-way ratchet scrolling (like Super Mario Bros. and Contra) or allow backtracking two ways (like Mega Man and Castlevania)?

If a group of tiles appear only at the left and right sides of a map, and a bunch of other tiles appear in the middle, do you want to restrict the number of tiles that may appear between them because the tiles are still technically in use? Or do you want to be able to purge a tile from the in-use set and then readd it later?

I have a couple more questions to think about that may inform the design of data structures for your scrolling engine:

Do you plan to use one-way ratchet scrolling (like Super Mario Bros. and Contra) or allow backtracking two ways (like Mega Man and Castlevania)?

If a group of tiles appear only at the left and right sides of a map, and a bunch of other tiles appear in the middle, do you want to restrict the number of tiles that may appear between them because the tiles are still technically in use? Or do you want to be able to purge a tile from the in-use set and then readd it later?

1. Theoretically, with the sliding window algorithm it shouldn't matter. I'd have to prove it to myself, but I think it's good.

2. Purge and replace. If I have more than enough chr banks, might as well.

Who is online

Users browsing this forum: No registered users and 6 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum