Guest User

About Tiles

a guest
Jan 8th, 2014
142
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. [<@Drag> To operate the TV, I usually just press the buttons]
  2. [18:03] == Thanatos-Zero [webchat@p57909506.dip0.t-ipconnect.de] has joined #rom-hacking
  3. [18:03] bbitmaster [~bbitmaste@c-50-142-3-0.hsd1.tn.comcast.net] requested CTCP VERSION from Thanatos-Zero:
  4. [18:03] <Thanatos-Zero> Greetings!
  5. [18:03] <Thanatos-Zero> Is Ghideon Zhi present?
  6. [18:03] <Thanatos-Zero> Hm...
  7. [18:04] == Sanae [~Magneto@178-78-252-118.customers.ownit.se] has quit [Remote host closed the connection]
  8. [18:04] <Thanatos-Zero> It doesn't appear that this is the case, anyway... Is here anyone mentally present.
  9. [18:04] <Thanatos-Zero> ?
  10. [18:05] <PJBoy> quite
  11. [18:05] <Thanatos-Zero> That is good....
  12. [18:05] <Thanatos-Zero> http://www.romhacking.net/forum/index.php/topic,17532.0.html
  13. [18:05] <Thanatos-Zero> I and my pal Kujakiller have a problem with tile space.
  14. [18:06] <Alantas> Gideon Zhi = Lakmir, who's present. Or at least his IRC program is.
  15. [18:06] <Thanatos-Zero> To come to the point I designed the level with 16x16 tiles in mind, but not with 32x32 tiles...
  16. [18:07] == Lakmir [~Lakmir@c-24-143-80-222.customer.broadstripe.net] has quit [Ping timeout: 380 seconds]
  17. [18:07] <Thanatos-Zero> *** SECRET ***
  18. [18:07] <furrykef> I actually didn't know Lakmir = Gideon Zhi for a long time, leading to much embarrassment when I found this out
  19. [18:08] <PJBoy> changing something like tilesize sounds like an overhaul
  20. [18:08] <Thanatos-Zero> That is the level I designed.
  21. [18:08] == Lenophis [~Lenophis@67-7-237-213.dlth.qwest.net] has joined #rom-hacking
  22. [18:08] == mode/#rom-hacking [+o Lenophis] by ChanServ
  23. [18:08] <Alantas> Well, you have to design your level to fit the constraints of the game.
  24. [18:09] <Thanatos-Zero> But wouldn't it make things easier PJBoy.
  25. [18:09] <Alantas> Changing the tilesize would indeed call for a complete overhaul of most of the game's level-handling code. Rendering, storage, all that.
  26. [18:09] <Alantas> Existing MM game levels, and hacks, already work with its 32x32 cell layout. So can yours.
  27. [18:09] <PJBoy> I wouldn't say anything would be easier
  28. [18:10] <Alantas> It might make things easier for you, but not for the game. Like Lakmir said in that thread, it would quadruple the size of the level data in-ROM.
  29. [18:10] <PJBoy> and there's a reason so many games use that 2x2 16x16 tile mapping trick
  30. [18:10] <Alantas> Unless you implemented some form of compression, which itself would be a major overhaul.
  31. [18:10] <Thanatos-Zero> Well Atlantas... I wasn't aware of a 32x32 table a month ago.
  32. [18:10] <Thanatos-Zero> ehm...
  33. [18:11] <Thanatos-Zero> what I am saying? I meant a day ago.
  34. [18:11] <Alantas> Well, now you are. And now you have to adapt your level design to it.
  35. [18:12] <Alantas> Now, what are these "horrible side effects" you talk about in the thread? Hitboxes, gravity effects. What were you expecting to get, what are you actually getting, and how do they differ?
  36. [18:14] <Thanatos-Zero> Well, Kujakiller never touched the data of the tables themselves, because he expects things how they were, would stop to work and in turn he would need to program everything by scratch again.
  37. [18:15] <DahrkDaiz> whoa
  38. [18:15] <DahrkDaiz> actual conversation
  39. [18:15] <Alantas> Exactly. And you would have to do the same, if you wanted to change the underlying level format.
  40. [18:16] <Alantas> So, don't. Maybe you just need to adapt your thinking to the 32x32 method. Maybe you drew up your map assuming you could lay it out down to 16x16, but now you find that assumption wasn't right.
  41. [18:16] <Thanatos-Zero> Yes.
  42. [18:18] <Alantas> Play around with the editor, get a feel for how the layout mechanism works. Adapt your layout to work with it, where needed.
  43. [18:20] <Alantas> Heh, that level looks like a Metroid map in some places. I'm looking at it, trying to see the flow of it, on a design level.
  44. [18:22] <Thanatos-Zero> the area below was meant for the revisiting of the stage, after aquatic geothermal plant goes boom after the two stages.
  45. [18:22] <Thanatos-Zero> the*
  46. [18:22] <Thanatos-Zero> Let me show you what we got so far.
  47. [18:22] <Thanatos-Zero> Per PM of course.
  48. [18:23] <Alantas> Is this for Kuja's hack?
  49. [18:23] <Thanatos-Zero> Yep.
  50. [18:33] <bbitmaster> It should be possible to reprogram the game to be 16x16. It would require ExRAM (0x6000-0x7FFF) to store the tiles, and some decompression algorithm to put them there. That would be a whole lot of work though.
  51. [18:33] <Alantas> That's PRG RAM; ExRAM is MMC5-specific and is at like 5C00-5FFF or so.
  52. [18:33] <bbitmaster> Kirby Adventure (and I think) SMB3 both do that. They store raw 16x16 tilemaps in 6000-7FFF
  53. [18:34] <Alantas> But yeah, it's *feasable*, FF1 practically already does it, but you'd have to overhaul a lot of the game code in order to do it.
  54. [18:34] <bbitmaster> It's also SRAM In some games too :-)
  55. [18:35] <Alantas> Like, a lot. Almost everything that deals with level loading and so on. If it doesn't already expand it to 16x16 in memory, but keeps it in 32x32 and does lookups as necessary, you'd probably have to update all hitbox, etc code too.
  56. [18:35] <bbitmaster> It would probably require rewriting all of the scrolling code, and all of the sprite->hit->bg code that is littered throughout the game
  57. [18:35] <Alantas> If it does already expand it to 16x16 in memory (it's only a page), then that makes things simpler.
  58. [18:35] <Alantas> Definitely, the scrolling code.
  59. [18:36] <Alantas> You're basically rebuilding much of the game engine in order to do that.
  60. [18:36] <bbitmaster> it would be a TON of work... I think many different sprites sometimes look up whether they are behind solid blocks or not, with their own custom code.
  61. [18:36] <Alantas> Like I said, all existing MM games, and hacks thereof, are already built on the 32x32 foundation, so 32x32 should be *at least* as useful for your hack.
  62. [18:37] <Alantas> Imagine trying to rebuild it to run 8x8. A fool's errand.
  63. [18:40] <bbitmaster> Most of the existing game levels have a lot of space left in the table that builds the 32x32 structures
  64. [18:40] <bbitmaster> So, I don't think that's a serious limitation. It can be worked around.
  65. [18:41] <Alantas> Indeed. Just a question of getting familiar with how it works and how to work with it.
  66. [18:42] <Alantas> Point being, converting it to 16x16 isn't just a question of checking a box in an editor; you seemed to assume it'd be that straightforward. It'd require a major tear-down and rebuild of the game engine.
  67. [18:42] <bbitmaster> I remember once, I was going to try to make an editor that lets you edit 16x16 blocks directly, and it transparently rebuilds things in structure format (at least until it runs out of space).
  68. [18:43] <Alantas> Could be interesting for sketching levels out.
  69. [18:43] <bbitmaster> It would make for a more user friendly editor -- until it ran out of space.
  70. [18:44] <Alantas> Perhaps: Don't think of the level as 16x16 with a quirky engine that makes you lay them out 2x2 at a time. Think of it in terms of 32x32 first.
  71. [18:44] <Alantas> Like, this 32x32 block represents a corridor, this is a wall, this is the bottom of a spike pit, etc.
  72. [18:45] <Alantas> And it's broken down into 16x16, then 8x8, for internal reasons.
  73. [18:46] <bbitmaster> It's much more natural to think of it in terms of 16x16 blocks
  74. [18:46] <Alantas> Like, this 32x32 represents the bottom of a spike pit. One of its component 16x16s represents an individual spike.
  75. [18:46] <Alantas> Think, "spike pit" rather than "spike".
  76. [18:48] <Alantas> I hope you don't get into Metroid hacking. It takes a completely different approach. On one level, it's 16x16-based, but it builds levels in terms of structures (of assorted sizes), not blocks.
  77. [18:49] <Alantas> So like, an entire platform might be "one thing" to the game engine. But if you want a slightly different platform, you need another structure.
  78. [18:49] <Alantas> But you can move that platform to any 16x16 location without needing to regenerate 32x32 structures or the like.
  79. [18:50] <DahrkDaiz> heh SMB3 does something similiar
  80. [18:50] <DahrkDaiz> with the object system
  81. [18:50] == Linkandzeld has changed nick to Linkandzelda
  82. [18:51] <DahrkDaiz> which is why I switched to a compressed tile map
  83. [18:51] <Alantas> Yeah, that's what FF1 does. Though its levels have a fixed size (64x64 cells of 16x16 pixels).
  84. [18:51] <DahrkDaiz> ah
  85. [18:53] <Alantas> Uses simple RLE. For my own homebrew (should I ever actually make it), I have a simple LZ-based approach that produces better compression.
  86. [18:53] <DahrkDaiz> heh I looked into LZ compression but it required more RAM than what I had available
  87. [18:53] <Alantas> But, it's a top-down view game, not a platformer. How would that work for a side-scrolling platformer? Does it define it by columns first?
  88. [18:53] <DahrkDaiz> it actually defines it by rows
  89. [18:54] == itsblah [~messt@c-71-224-28-28.hsd1.pa.comcast.net] has quit [Ping timeout: 380 seconds]
  90. [18:54] <Alantas> Well, FF1 (and my own design) expands the entire level to memory (somewhere in 6000-7FFF), so LZ is a non-issue for that, it just expands it right into place, and the output is its own memory.
  91. [18:54] <DahrkDaiz> there's 4 commands: skip, repeat tile, repeat pattern, write raw
  92. [18:55] <DahrkDaiz> the most common tile in the level is first written to the tile memory, then the skip command will skip that many columns, write byte writes the given byte a given number of times, write pattern writes a repeated pattern, write raw writes so many bytes for more complicated patterns
  93. [18:56] <DahrkDaiz> it's not the best by any means
  94. [18:56] <DahrkDaiz> but I can compress roughly 7.5K of tile memory into ~2.1Kb on average
  95. [18:56] <DahrkDaiz> KB*
  96. [18:56] <Alantas> Ah, yeah, kinda LZ-like. "skip" basically is shorthand for "repeat tile, using the defined most-common tile"?
  97. [18:56] <DahrkDaiz> yeha
  98. [18:57] * Lenophis just saw the thread at RHDN
  99. [18:58] <Alantas> My own approach just has "write raw" and "reachback". I figure, the most common tile ("blank space", by far the most common) will simply compress better as it is, without needing to single it out.
  100. [18:58] <Alantas> "reachback" / "copy forward", whatever you want to call it.
  101. [18:59] <Alantas> Makes patterns doable in a simple and natural way. Like if you want a checkerboard pattern. You don't say "take these two tiles and repeat this pattern N times", you simply write it out raw, then copy forward from 2 tiles back for N tiles on, and it'll simply repeat itself naturally.
  102. [19:00] <Alantas> Or like, a vertical hallway, you write it out raw (however wide it is), then you can simply reach back to the previous row and copy it again, without having to define a "pattern" per se.
  103. [19:00] <Alantas> Even so, it still needs a lot of memory, at least as much as how far it can "reach back". In my case, the whole thing is expanded to memory, so it just operates on that directly, no problem.
  104. [19:01] <Alantas> To work out of onboard RAM, you'd probably have to limit how far it can "reach back".
  105. [19:02] <Thanatos-Zero> Do you mind, if I copy your conversation into my next post?
  106. [19:02] <Thanatos-Zero> It might be helpful,
  107. [19:02] <Alantas> Fine by me. Whether it'll be fine by them to dump a big chat log in it, I dunno, though.
  108. [19:03] <Lenophis> make sure you use code tags, quote tags, or whatever
  109. [19:03] <Lenophis> IRC chat and forum posts don't mix well together
  110. [19:03] <Thanatos-Zero> Ok
  111. [19:03] <Alantas> Or just summarize it yourself. "Okay, I talked to people in #rom-hacking and they say herp derpty dee".
  112. [19:04] <DahrkDaiz> lol
  113. [19:04] <Lenophis> hey, I say "Herp-a-doola"
  114. [19:04] <DahrkDaiz> I say "I have a bad case of the derpes"
  115. [19:04] <Alantas> "And they said I can't hack Metroid! :("
  116. [19:05] <Alantas> Well, insinuated.
  117. [19:10] <Alantas> Pretty much everyone in that thread, and here, is telling you the same thing: converting it to 16x16 is not feasable.
  118. [19:11] <Alantas> You did mention some problems aside from that, such as something about hitboxes and gravity effects. What are you experiencing?
  119. [19:11] <Alantas> ...Ah, you said in the context of trying to edit it, which I'm guessing means you're editing the graphics but not the functional data, like what's solid and what isn't, so it only changes the appearance.
  120. [19:12] <Lenophis> I get the gripe about the 32x32 data not being the most efficient, however, the grand scheme, it is overall more efficient than 16x16 data, since you need 4x it as mentioned
  121. [19:13] <Lenophis> unless you want to make level sizes dynamic and compress them down to nothing
  122. [19:13] <DahrkDaiz> yeah it really depends heavily on what your tiles are used for
  123. [19:13] <DahrkDaiz> MM is prett simplistic isn't it? I mean you have solid tiles, water, background, spikes, not much else
  124. [19:13] <Alantas> It's a tradeoff of storage and handling ability (32x32 is better) versus precise editability (16x16 is better).
  125. [19:14] <DahrkDaiz> everything else is just graphical
  126. [19:14] == Sanae [~Magneto@178-78-252-118.customers.ownit.se] has joined #rom-hacking
  127. [19:15] <Alantas> Yeah, and it sounds to me like he's editing only the graphics, but not the rest, so maybe he changed something that was originally solid, giving it the graphics of something he expects to be nonsolid, and finds it's still solid.
  128. [19:15] <Alantas> Or things like that. If so, that might explain the problems he's having, and the solution is just to figure out where you can change that information in the editor.
  129. [19:16] <Lenophis> I would also caution you about this potentially breaking the editor
  130. [19:17] <DahrkDaiz> yeah
  131. [19:17] <Alantas> Changing the structure table might break the editor? Some editor.
  132. [19:17] <Lenophis> well, if he successfully changes the 32x32 to be 16x16, the level format is already done. The editor will only recognize the sizes based on the 32x32 format
  133. [19:17] <Alantas> Oh, right.
  134. [19:18] <Alantas> Yeah, you'd have to rewrite practically the whole editor too.
  135. [19:18] <Alantas> Not just to tweak it, but to rebuild it with an entirely different structure in mind.
  136. [19:18] == Sanae [~Magneto@178-78-252-118.customers.ownit.se] has quit [Ping timeout: 194 seconds]
  137. [19:19] <Alantas> Better hope it's open-source! </callback>
  138. [19:20] <Lenophis> it looks like it was built with Visual Basic
  139. [19:20] <Alantas> Having to move mountains because you missed a dialogue somewhere. No doubt quite a learning experience! But massive overkill for the problems you're having.
  140. [19:23] <DahrkDaiz> heh
  141. [19:24] <DahrkDaiz> that's the attitude I had when I did Reuben
  142. [19:24] <DahrkDaiz> it started out as something to just modify the level format
  143. [19:24] <DahrkDaiz> but I was like you know...
  144. [19:24] <DahrkDaiz> if I'm going to go all out I might as well make this thing seriously do things differently
  145. [19:24] <Alantas> One thing led to another...
  146. [19:24] <DahrkDaiz> yeah
  147. [19:24] <DahrkDaiz> now it's not even a rom hack, it's a new game based off the SMB3 engine
  148. [19:25] <Alantas> He's not even Mario anymore, but now more like, Sebastian.
  149. [19:25] <DahrkDaiz> yeah I'm calling it Super Sebastian Brother
  150. [19:25] <Alantas> Sebastian and Fernando.
  151. [19:26] <DahrkDaiz> nah just one brother
  152. [19:26] <Alantas> Luigi/Fernando never gets any respect.
  153. [19:26] <DahrkDaiz> heh I went to a thing on NES homebrew at magfest
  154. [19:26] <DahrkDaiz> it was interesting to see someone else's approach
  155. [19:26] <DahrkDaiz> barely anyone was interested in the panel so I started pitching the tough questions
  156. [19:27] <DahrkDaiz> like
  157. [19:27] <Alantas> There was a thing on NES homebrew?
  158. [19:27] <DahrkDaiz> yeah a 1 hr panel on NES Homebrew in 2014
  159. [19:27] <DahrkDaiz> I wasn't aware of who the guy was, his name was Derek, I forgot his screen name
  160. [19:27] <Alantas> What the hell. That needs to be, like, here.
  161. [19:27] <DahrkDaiz> he hadn't really heard of me
  162. [19:28] <Alantas> Hacking is hardly even a thing anymore. You'd think neither would NESdev, or maybe all the hackers are graduating to that? That's kinda where I'm going with this, to the extent I'm going anywhere.
  163. [19:28] <DahrkDaiz> yeah well it was enough to get a panel
  164. [19:28] <DahrkDaiz> I think the rom hacking panel I woulda held would have gained more attention
  165. [19:29] <DahrkDaiz> emphasis on "remixing old classics"
  166. [19:29] <DahrkDaiz> it's not as big as it used to be, but we were never that big to begin with, not in the grand scheme of the internet
  167. [19:29] <Alantas> I hope it wasn't just about "retro" stuff like MM9/MM10, which aren't actual NES games, they just look like they are.
  168. [19:29] <Alantas> But real NES dev, like the "you know the difference between LSR and ROR, right?" kind.
  169. [19:30] <DahrkDaiz> nah he covered nesasm, fceuxd sp, 6502, etc
  170. [19:30] <DahrkDaiz> it was a very borad and shallow approaach
  171. [19:30] <DahrkDaiz> he wasn't that great as a presenter
  172. [19:30] <DahrkDaiz> but still, I appreciate the fact he was up there presenting
  173. [19:31] <Alantas> Yeah, I wouldn't have seen that sort of thing coming.
  174. [19:31] <Alantas> To me, NESdev/hacking lives in places like this very chatroom, message boards, and the like. In geekspace.
  175. [19:31] == Sanae [~Magneto@178-78-252-118.customers.ownit.se] has joined #rom-hacking
  176. [19:31] <DahrkDaiz> yeah well magfest is full of geeks
  177. [19:31] <DahrkDaiz> it's music and gaming
  178. [19:32] <DahrkDaiz> and by gaming I mean D&D, scrabble, Magic the Gathering, pinball, classic arcade, modern consoles, ddr
  179. [19:32] <DahrkDaiz> the whole real of "games"
  180. [19:32] <DahrkDaiz> realm*
  181. [19:33] <Alantas> Huh. Sounds like it could be pretty cool.
  182. [19:33] <DahrkDaiz> oh it was amazing
  183. [19:33] <Alantas> And they had a panel on NES development. That's about as close as it'll ever get to mainstream. And closer than I thought it ever would!
  184. [19:34] <DahrkDaiz> I saw Machinae Supremacy live, never heard of them untl them but they were awesome to hear
  185. [19:34] <Alantas> Outside of like the actual 1980s or something.
  186. [19:34] <Thanatos-Zero> ehm... the titled tileset contains about 90% original content, which cannot be found in other games.
  187. [19:34] <Alantas> I heard of them many years ago, and got some of their music, but that's it.
  188. [19:35] <Alantas> Thanatos-Zero: Alright, so you've got the graphics in place, right? Have you edited their properties? Like, defining what's solid and what isn't?
  189. [19:35] <Alantas> Making ladders actually work as ladders, that sort of thing? There should be some options for that somewhere.
  190. [19:35] <Thanatos-Zero> yeah.
  191. [19:36] <DahrkDaiz> heh it may not be options, it might be hardcoded
  192. [19:36] <Thanatos-Zero> Kuja takes care of the rest once the map is complete.
  193. [19:36] <Thanatos-Zero> he assigns the tiles data for the right purposes.
  194. [19:38] <Alantas> Well, sounds like he's the one you should be talking to about all this.
  195. [19:39] <Alantas> Assuming there's anything *to* talk about, beyond you simply getting the hang of working with 32x32 format.
  196. [19:40] == Sanae [~Magneto@178-78-252-118.customers.ownit.se] has quit [Quit: OKAY COOL]
RAW Paste Data