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.
Background Splicer
Moderator: Moderators
Re: Background Splicer
This seems like a typo of some sort. Did you mean 20x256 TILES?very large background (20×256 pixels)
Didn't tepples have a tool that does exactly this?Extracts the color paletes from the background
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.
Last edited by dougeff on Tue Mar 20, 2018 7:29 am, edited 1 time in total.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Background Splicer
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
It looks to me like he meant 20 screens, each 256 pixels wide.dougeff wrote:This seems like a typo of some sort. Did you mean 20x256 TILES?very large background (20×256 pixels)
Re: Background Splicer
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.
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
Yes, at least 20 screens if not more.tokumaru wrote:It looks to me like he meant 20 screens, each 256 pixels wide.
Is it available somewhere to try? What is it called?dougeff wrote: Didn't tepples have a tool that does exactly this?
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 aredougeff 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.
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)
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.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 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
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:Is it available somewhere to try? What is it called?dougeff wrote: Didn't tepples have a tool that does exactly this?
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?Lucradan wrote:assume that no 272 x 240 window contains no more that 256 unique tiles
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
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.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?
2. Purge and replace. If I have more than enough chr banks, might as well.