News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Tile limitations: How to make 32x32 tile table to a 16x16 table without glitches  (Read 4646 times)

Thanatos-Zero

  • Full Member
  • ***
  • Posts: 220
  • NES Graphic Designer
    • View Profile
Currently I and Kujakiller have to deal with the nasty 32x32 tile table, which would be much more efficient, if it would work like the 16x16 tile table. However trying to editing it, would have horrible side effects on what already existed before, like it would screw up with hitboxes, gravity effects and a lot more.

We need to find a way, how to make it more data efficient. It is ludicrous how the 32x32 table has several 16x16 tiles within repeated like mad. Just a example of Hardman's stage.


We would appreciate, if there is someone who is capable to successfully rewrite the 32x32 table into a 16x16 table without to change what already exists.

Gideon Zhi

  • IRC Staff
  • Hero Member
  • *****
  • Posts: 3500
    • View Profile
    • Aeon Genesis
You do realize that even if you pulled this off you're going to quadruple the size of the level data, right? There are four 16x16 tiles per 32x32 tile.

Thanatos-Zero

  • Full Member
  • ***
  • Posts: 220
  • NES Graphic Designer
    • View Profile
Does that mean we waste space or do we get more space available for more 16x16 tiles?
In any case, the more efficient the useage of tile data, the more space we can use without to rely on copies of the same graphic on the very same table. It just sucks, that we are wasting 32x32 tile space for 16x16 tiles I designed for the level we are working on.
I created the base of the level with just 16x16 pixel blocks in mind.
If it is not possible for what we wish, I will have to redesign the level, but this time with 32x32 pixel blocks in mind.

tomaitheous

  • Hero Member
  • *****
  • Posts: 543
    • View Profile
    • PC Engine Dev
The map data would be 4 times as large, as you need four times the needed data two represent 32x32 area, with 16x16 tiles. You'll have to do some rom expansion and probably relocation of the new map data (won't all fit in the original area). That said, it is doable - with the right amount of time thrown at it (asm re/work).

 I was planning on doing something similar to Megaman 1 (either 16x16 or 8x8 cells for level maps). I have no interest in MM3 at the moment.

Thanatos-Zero

  • Full Member
  • ***
  • Posts: 220
  • NES Graphic Designer
    • View Profile
As you certainly will have no interrest into Megaman Odyssey as well. Anyway I have here a log from the chatroom #rom-hacking from esper.net. It might be helpful for anyone interrested.

http://pastebin.com/gkNBXuic

As I could gain from the conversation, my idea is not a good one in terms of space.
« Last Edit: January 08, 2014, 01:52:35 pm by Thanatos-Zero »

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
You can make a struct called BigTile, containing the four 16x16 tiles needed to compose a big 32x32 tile. This way, you can keep your map data the same size (but you need a table of BigTile, so it will increase the size).

Many games work like this.

tomaitheous

  • Hero Member
  • *****
  • Posts: 543
    • View Profile
    • PC Engine Dev
MM1 had something like a 64 32x32 table setup. It MM3 limited to 64 entries as well? Assuming the map data itself is byte wide entries, are all 8bits used? If not, then you could expand the table with a little bit of code (possible putting the expanded table . If so, then you could have reserve 1 entry as an 'extended' form, that looks for an alt map data corresponding to the current map location; and then access a full byte with an alt table elsewhere in rom (possible expanded rom area). I.e. You only increase the map size by two (with split locations), but you break nothing of the original game map code.

 Is the editor you're using gonna support anything other than what the game already supports? I.e. Make changes to the games format, how is the editor gonna handle that?

Quote
As you certainly will have no interrest into Megaman Odyssey as well. Anyway..
Huh? Did I say something to offend?

kuja killer

  • Full Member
  • ***
  • Posts: 163
    • View Profile
dont worry guys, nevermind. I aint going to dare even think about touching the level format. I knew it would entirly break all megaman/sprites because gravity/wall/hit detection/ground all read the level data. it's way to complex to screw around with anyway.

it's one of the few things i've never touched in all the years i've spent with megaman 3.
And lenophis and others were correct about the concept making level data be 4x bigger. And i cant ever just do something insane like that.

I got other methods im able to do in order to use more than 256 "32x32" structure blocks. (the limit in megaman 3 - 6 was 256, not 64 like megaman 1.

just kinda suck-ish that there could be trillions of "32x32" block patterns. but the 16's table that it's built on, doesnt really have any such problem
« Last Edit: January 08, 2014, 07:06:20 pm by kuja killer »

tomaitheous

  • Hero Member
  • *****
  • Posts: 543
    • View Profile
    • PC Engine Dev
dont worry guys, nevermind. I aint going to dare even think about touching the level format. I knew it would entirly break all megaman/sprites because gravity/wall/hit detection/ground all read the level data. it's way to complex to screw around with anyway.

it's one of the few things i've never touched in all the years i've spent with megaman 3.
And lenophis and others were correct about the concept making level data be 4x bigger. And i cant ever just do something insane like that.

I got other methods im able to do in order to use more than 256 "32x32" structure blocks. (the limit in megaman 3 - 6 was 256, not 64 like megaman 1.

just kinda suck-ish that there could be trillions of "32x32" block patterns. but the 16's table that it's built on, doesnt really have any such problem

For my own curiosity, because I haven't decided which Megaman game to do next for nes2pce (3-6), is the level (collision, sprites, objects, etc) on the upper level structute (32x32) or on the lower level (16x16) after the game engine fetches the data from the decoding table? Sounds like it's inside the 32x32 decode table itself (from the description of "hitboxes, gravity effects and a lot more").

 Just curious about "And i cant ever just do something insane like that." <- As in, you're opposed to expanding PRG space?

 Though even if you solved all these problems, what editor would you use to handle this new format? Old fashion hex editor? Or just a new one?
« Last Edit: January 08, 2014, 09:26:40 pm by tomaitheous »

kuja killer

  • Full Member
  • ***
  • Posts: 163
    • View Profile
no it's not really about PRG space, the rom is already 1 MB right now. -- 512 kb graphics, 512 kb coding space.

It's just that the whole 4x bigger thing would require 100 bytes for 1 single screen, instead of 40. And that would go up to like 2800 bytes of RAM needed for level data. That's WAY too much. My levels are only 1C00 bytes of data per level.

I use megafle, i've personally programmed some things in Visual Basic myself to support extra stuff i've put into megaman 3 over the years, that didnt exist in the game originally, like multi paths, longer levels (how many screens a level is), MMC5 mapper "ex attributes" and stuff.

and i have no idea to the answer of your 1st question, cause i dont honestly understand how the hit detection with level data stuff works :( and that's why i leave it alone.

tomaitheous

  • Hero Member
  • *****
  • Posts: 543
    • View Profile
    • PC Engine Dev
Wow. I see. Yeah, quite the dilemma. Thanks for answering my questions. :)