May 13th, 2015, 17:21
I thought about a key press (like keys 0-9) to act like slots. That would definitely work, I'm just not sure it's a perfect solution. It'd work great if you switch levels or areas that use a solid color to represent different things (a forest, or a mountain, like Kirby's Dreamland). But what if you wanted the sky and the ground to be separate graphics? In the picture you posted, GBE would take the first row 8x8 tiles underneath the HUD and make them the same tiles as the ground. I think I have a decent solution, but I haven't exactly tested it out yet.
May 13th, 2015, 21:16
Yeah that is quite restricting, in that pic you see the grey blocks for the ground is also the same as under the score. I did read a bit with what the hdnes author and ideas on how he would tackle the problem, with the use of scripts. Whether the same ideas could apply here i don't know.
Originally Posted by Shonumi
the topic discussing that is here.
May 13th, 2015, 22:44
In that specific case, that there are tiles aways on floor and always on the sky its possible to program the emulator to show diferent tiles according to their coordinates at emulator screen?
Originally Posted by Shonumi
original tile with solid color is xxx.png
if originaltile is in upper half of the screen show substitutetile x
else if originaltile is in botton half of the screen show substitutetile y
Maybe associate with the percentage of y axis so it can adapt to any resolution of the screen and we can have different options of solid tiles for different parts of the screen.
May 14th, 2015, 01:03
@chiburunga - That would work as well, but only some of the time. Imagine you have the ground being a solid color and the sky is that same color. Say you did replace them both based on their Y coordinates so that the sky is blue, and the ground is brown. Now imagine the player falls into a pit, and the screen scrolls down too. Eventually the "ground" tiles scroll up to the top of the screen (imagine the walls of the pit take up the full vertical length of the screen). Some of the topmost "ground" tiles would accidentally be replaced with "sky" tiles, even though in the game you're in a pit, away from the sky.
The best solution I've come up with yet works like this:
The emulator chooses one tile to act as a sort of "anchor". It looks at the "anchor", then if any tiles above, below, left, or right of it match a solid color (gray in this example), it replaces them accordingly. You'd be able to specify which tiles above it are for the ground and which tiles below it are for the sky. Left and right seem less useful than up and down, but it's no trouble to implement them all. When a new anchor comes on-screen, then it can switch to something else, so making different graphics for different levels is possible. The tricky thing is making this easy for the user. I don't want them to spend more than a few seconds on it, and no head scratching, screaming at the computer, or pounding on the keyboard
Last edited by Shonumi; May 14th, 2015 at 01:05.
May 14th, 2015, 22:06
Thanks shonumi! I Think that a easy way to select a tile as anchor is to put a flag in the name file... example:
Originally Posted by Shonumi
To make this tile the anchor just rename to actualtilename_anchor0001.png and the solid tiles to actualfilename_above0001.png or actualfilename_bellow0001.png
Could also use the HUD tiles to make anchors... for example if tile corresponding to 1 - 1 (in world 1 -1 in mario hud) use tile x to substitute solid tile y
Last edited by chiburunga; May 15th, 2015 at 01:23.
May 15th, 2015, 15:56
The fact is that, although both tiles are identical, they are not the same tile.
If you look at the tilemap from that part of the game, you find the following tiles loaded in memory (see attached pic).
The ones highlighted in red (tile 232 and tile 339 in this case) are the ones used for the ground (232) and the sky (339).
So if you find a way to identify where in the tilemap is that particular tile, then depending on that, you can replace it with different tiles.
May 15th, 2015, 16:53
The thing is, while this works for SML (using tile numbers to differentiate tiles with the same pixel data) it's not a global solution. Other games will use the exact same tile with the exact same pixel data to draw different parts of the BG. The problem isn't getting it to work with one game in one instance; it's about getting to work for every game under every reasonable circumstance. The solution you've brought up has been mentioned before (just look at the tilemap entry numbers to add to the hash) but it will still mess up other games.
What's worse about relying on tile numbers (for both OAM and BG VRAM data) is that there is always the possibility for things to get reshuffled whenever the screen scrolls. It's not a problem in SML (you can clearly see all of the data for World 1-1 is loaded) but other games constantly swap out stuff and rearrange the tiles.
Last edited by Shonumi; May 15th, 2015 at 16:56.
May 15th, 2015, 17:40
Yes, i'm not telling to replace the detection method. But for those special cases where there are identical (but separate) tiles, you could do:
IF (Your actual tile detection method) AND (tile position is 339) THEN use tile "sky". For all other cases, then it would use tile "ground".
It could be done as additional conditions, so the user can "add" this condition in the cases where he needs it.
May 15th, 2015, 23:38
Maybe it is impossible to have a universal type of tile anchor... maybe the way is to have multple anchor logics, so the remaker could select the most apropriate for each game.
May 16th, 2015, 01:42
@hi-ban - See, but there's no guarantee at all that tile numbers will be consistent while playing the game. Even if using tile numbers were an extra condition, imagine you have a GB game that shuffles VRAM around when it scrolls to load new sections of a level. Looking for tile position 339 might be suitable for the first few screens, but as soon as the player starts moving, the game logic shifts everything around. The tile at tile position 339 is now somewhere else (225, 181, 5, anything really). Not every game is like that (SML is not one), but in many games tile numbers are quite arbitrary. That's one of the reasons I've been against looking at tile numbers/positions from the start; they can change at any moment, potentially. I prefer anchor tiles because they're independent of everything else except the actual 8x8 pixel data.
@chiburunga - Yes, just using one anchor tile (for the whole game, or even a single level) is actually impractical. The system would allow for multiple anchor tiles. Naturally, if two have regions that overlap, the one processed last will take priority. As long as users know how to use anchor tiles, they should be able to avoid conflicts where one tile "fights" to be shown over the other.