Page 1 of 1

Background Splicer

Posted: Tue Mar 20, 2018 5:18 am
by Lucradan
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 background
2. Extracts the color paletes from the background
3. Organizes the tiles into banks that would allow for smooth horizontal scrolling
4. 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.

Re: Background Splicer

Posted: Tue Mar 20, 2018 7:24 am
by dougeff
very large background (20×256 pixels)
This seems like a typo of some sort. Did you mean 20x256 TILES?
Extracts the color paletes from the background
Didn't tepples have a tool that does exactly this?

Regardless... coming up with a palette is part of the development process, and I prefer to do ot manually.

Which means reducing the image to 4 color black, grey, and white.

Re: Background Splicer

Posted: Tue Mar 20, 2018 7:29 am
by tepples
My tool assigns attributes and extracts tiles given an image and a 32-digit palette string. But it doesn't try to guess an optimal palette by itself.

Re: Background Splicer

Posted: Tue Mar 20, 2018 7:59 am
by tokumaru
dougeff wrote:
very large background (20×256 pixels)
This seems like a typo of some sort. Did you mean 20x256 TILES?
It looks to me like he meant 20 screens, each 256 pixels wide.

Re: Background Splicer

Posted: Tue Mar 20, 2018 8:23 am
by Kasumi
My tool does 1 and 2, but not 3 and 4.

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.

Re: Background Splicer

Posted: Tue Mar 20, 2018 11:17 am
by Lucradan
tokumaru wrote:It looks to me like he meant 20 screens, each 256 pixels wide.
Yes, at least 20 screens if not more.
dougeff wrote: Didn't tepples have a tool that does exactly this?
Is it available somewhere to try? What is it called?
dougeff wrote: 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 palettes
2. 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.

Re: Background Splicer

Posted: Tue Mar 20, 2018 2:49 pm
by tepples
Lucradan wrote:
dougeff wrote: Didn't tepples have a tool that does exactly this?
Is it available somewhere to try? What is it called?
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?

Re: Background Splicer

Posted: Tue Mar 20, 2018 4:20 pm
by Lucradan
tepples wrote:
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.