Unused Tile Slot

Franco92

New member
Hello guys!
does anyone know if it is possible use this blank Tile slot?


31174541_1409122602527703_5250142735149745070_n.jpg
 

RadJunk

Administrator
Staff member
Hey friend - it's actually set up for FOUR paths - that's the design of that path slot. :)
 

Franco92

New member
thank you :)!
With the next updates will it be possible for the user to dedicate those slots to expand the Main Tiles one?
 

Rob Burrito

New member
is it possible to switch off the pathing script for these and use them as a 8x8 tile set? or is this more a function that uses layout data to make a metatile out of the 8x8's?
 

RadJunk

Administrator
Staff member
In the future, we're hoping to make it possible how the tilesets are arranged.

Here is the challenge. Only so many graphics can fit inside a bank. So once we start playing with user control, we need to start playing with different distribution of memory. Once we start dealing with different distribution of memory, we need to figure out ways for the game to declare which bank is paired with a screen. But since there is only a limited amount of data per screen, we don' t the bytes to allocate to that...so we need to re-factor something like how we handle collision tables, reducing the number of collision bytes (by having each be a nibble rather than a whole byte)...which means less tile types, and no *solid/ignore pathing* bits (which is why we've abandoned their use for this beta, anticipating that move coming soon), which then gives us more space per screen bank to potentially store more data, some of which could be bank for each portion of the graphic load...

This is why developing for the NES and its constraints is so crazy. It's not the graphical limitations or even the ASM language. It's the memory management that one just takes for granted in a modern development tool. It's the part we're most trying to keep users from having to think about.

So yes, it's planned for future to be able to not use path tiles, and even not use hud tiles...but we're still working on where to stuff the extra data needed to facilitate this.
 

Rob Burrito

New member
sounds awesome, and challenging! keep up the hard work, still having fun learning the tool. any questions are completely inquisitive, as we all try to wrap our heads around it's limitations as well. definitely appreciate the quick but thorough answers!
 

Mihoshi20

Member
I noted in the Graphics Bank 1 folder a strip for Animated Tiles, is that going to be part of the screen tiles block or will it be left out entirely for mapper 2 compatibility? I imagine those using mapper 30 would still like tile animation. I plan only to use mapper 2 to test on my power pack but still build my final project for mapper 30.
 

RadJunk

Administrator
Staff member
Animated tiles are a whole other beast...they don't take up any additional space in the tileset. Only their frame0 tile does, which would be so whether it was animating or not (if you had static water versus animated water...that first frame is what will show up in the tileset either way)
 

Mihoshi20

Member
Ah cool, and very space efficient. Something very precious when it comes to the NES. Also sounds like it won't be implementing the bankswitching method common to NES games like for instance the way SMB3 animated stage select map tiles.
 

Kasumi

New member
It will be using bank switching, that's why only their frame 0 takes up space in the tileset. When frame 1 is displayed, the tiles for frame 1 will occupy the space where the tiles for frame 0 were due to the bank switch. That's also why tiles can't be animated when exported to Mapper 2. Mapper 2 doesn't have bank switching.
 

Mihoshi20

Member
Which makes me curious as to if it'll use the screen tiles slot for it or uses the main tiles slot, as all other tiles will need to be the same for the set aside from the tiles that are changing for animations as it cycles through the banks limiting overall diversity. Assuming their implementation allows the screen tiles portion to be loaded separately from all other tiles when a screen is switched/loaded.
 

RadJunk

Administrator
Staff member
Mihoshi - that is correct, but we have an interface that will handle that with you. The real catch, to keep consistent timing between screens, is that that little *blip* between screen loads is multiplied by 4.

This interface would exist now, but it will be reworked when we rework the collision / screen data (and hopefully allow for more possibilities, btw)
 

Mihoshi20

Member
TheNew8bitHeroes said:
Mihoshi - that is correct, but we have an interface that will handle that with you. The real catch, to keep consistent timing between screens, is that that little *blip* between screen loads is multiplied by 4.

This interface would exist now, but it will be reworked when we rework the collision / screen data (and hopefully allow for more possibilities, btw)

I'm not too overly anxious for it, just mostly curious as to how it'll be implemented compared to other NES games. It will be fun to play with however once it is implemented and give some motion to background objects and seeing other creative ways people use it in their games.
 
Top Bottom