 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| User | Post |
| BMF54123 Posts: 353/876 |
Guys, do we really need this bickering in here?  |
| HyperHacker Posts: 1911/5072 |
Sorry, I'm still not seeing it. Let me try to guess which posts you're referring to.
Originally posted by Glyph Phoenix You mean the one I quoted and bolded? Perhaps you need to study English some more. Generally when somebody says "I believe [whatever]" it means they're not entirely sure.
Again, never claiming this information as fact. Actually, this post and LM's help file were the entire basis of said belief. We've already established that this belief was incorrect; all you're doing now is picking at straws, desparately trying to prove invalid points.
Just as I'd stated originally; again, "I believe" != "I'm absolutely sure that".
You asked if I thought it was possible to fit the overworld into 2K. I responded that it could probably be done with simple compression. How exactly is this irrelevant? Perhaps "irrelevant" is another word you should study? |
| Glyphodon Posts: 201/536 |
You made a post about decompressing to SRAM once that didn't make sense, then later you supported it by bringing up the kidnapping message. Then you tried to weasel out of what you said by saying you weren't sure and again bringing up something irrelevant, this time compression.
That is not cool. |
| HyperHacker Posts: 1905/5072 |
Originally posted by Glyph Phoenix Ah, I forgot about that 16x16 layer. 
Originally posted by HyperHacker Care to point out these so-called nonsense statements and support? All I see is "I believe it decompresses the overworld to SRAM" and a single statement supporting this belief ("That's when the game is decompressing the overworld"). Are you referring to my last post in which I stated that even though SMW doesn't do it it may potentially be possible to do? Also, I can't seem to find where I continued to support this belief after your second-last post. |
| Glyphodon Posts: 197/536 |
Decompressing all that information certainly would certainly take more time than simply loading the information straight from ROM. In addition, no valid compression I know could be capable of taking both the 8 x 8 and 16 x 16 layer and forcing it into that save file three times.
Originally posted by HyperHacker You made a specific statement that made no sense and following supporting statements in later posts even after your original point had been shot down. Does the lack of the word 'sure' in your post make this acceptable behavior? |
| HyperHacker Posts: 1898/5072 |
Hey, I never said I was sure.  I guess when it says key portions of the overworld map data are decompressed/loaded from the ROM only once in LM's help file, it means once per session.
Originally posted by Glyph Phoenix Probably if you compressed it. Just use a compression that doesn't take so long to decompress. NES games only had that much RAM to work with (except those that had extra RAM on the cartridge) and they did some amazing things. |
| Glyphodon Posts: 193/536 |
Originally posted by HyperMackerel The reason you're warned against editing the overworld in LM and load an existing save file is because the exit directions and events are saved. Check the size of the .srm file that your emulator creates. Can you load the entire overworld into that space three separate times? [Edit: I see your point involving the allocation, but I doubt memory management systems would be any more compatible with different hacks than the original hacks they were designed to placate.] |
| HyperHacker Posts: 1890/5072 |
Not that I know of, but I wouldn't be too surprised. A lot of things in Nintendo games, especially on NES and SNES, are just to mask load time. The "Mario Start" screen hides the time it takes to render the level. The level name screen does the same on Yoshi's Island, as does the lives screen in Super Mario Bros. They're pretty clever when it comes to making things look faster than they really are. |
| Legendre Posts: 10/12 |
Originally posted by HyperMackerel Hey HyperMackerel  Thank you for posting this, I found this really interesting. I love this board to death, new eye openers every day
The reason I'm replying is to ask: is there a similar explanation for the awkward pauses when you stomp on the big switches in the colored block switch palaces? I always wondered what was up with that! |
| HyperHacker Posts: 1882/5072 |
Originally posted by Glyph Phoenix You know when you start a new game, you do that little intro level with the "Bowser kidnapped Peach again!" message box before you actually get to the overworld? That's when the game is decompressing the overworld to memory. It takes a while, and to do this every time you start the game would be a pain. Then you'd have to step through all the passed events again, updating the map in memory. By keeping it in SRAM you avoid this. The save prompt is just to offer a choice. Saving the events passed and player position only takes a few bytes. This is also why you can't edit the overworld in LM, then load an existing save file.
The problems with this should be obvious already. There are many hacks that use the same RAM/ROM addresses and thus aren't compatible with eachother. In many cases they don't get fixed, because of one or more of the following: 1) The author didn't know of the problem and/or doesn't care. 2) The author stopped hacking SMW ages ago, lost the source code, etc etc. 3) It'd take a lot of work to use different addresses (especially ROM) and nobody's up to it. Especially in cases where other hacks, custom blocks etc interact with these hacks, and to change addresses would make them not work anymore. 4) Both people think the other should be the one to change their hack. |
| MathOnNapkins Posts: 412/1106 |
Mapping the rom into code and data is easy. Many debuggers already do it. It's knowing how it all works together so that it is reassembled that is hard. It's mostly proportional to the amount of indirection your processor is capable of. The more you can hide your program's execution through memory, the harder it is to know the exact structure of the program. |
| Legendre Posts: 9/12 |
Originally posted by Disch Assuming by "any ROM" you mean "any ROM on a fixed system", why is a generic disassembler so hard? In my naive and newbieish mind it seems the hardest thing would be mapping the ROM, dividing it into code and data. Is this anywhere near the truth? |
| Glyphodon Posts: 189/536 |
Hyperhacker, I believe you're thinking of RAM bank 7F. Why would Super Mario's monstrocity of an overworld be loaded into limited SRAM? If the overworld is loaded into SRAM, why would it have to prompt players to save their game? It wouldn't make any sense.
I've done quite a bit of consideration and pages worth of post I won't include because of irrelevance, and I'd say doing any sort of memory allocation with an already assembled ROM just isn't a good idea. Here's why: The most practical course of action is to make a hack that uses any memory it wants and to modify the patch as problems show up. Basically, the best change we should make to our current memory practices is no change. |
| BMF54123 Posts: 343/876 |
Originally posted by DischIt was also the only (?) NES game to feature real-time sprite zooming. No kidding. The white ship in the intro and the spinning 'Toad symbols on the title screen are both scaled in RAM and then copied to VRAM. In fact, a lot of effects in the game (like the vertically-scrolling cavern walls) were achieved by manipulating graphics in RAM. On top of all that, nearly all the graphics are compressed, yet there's virtually no loading time between levels, or when new enemies appear in a level. Overall, it's a truly amazing (if horribly unbalanced and painfully difficult) game.
(okay, I'm done further derailing the topic...) |
| HyperHacker Posts: 1874/5072 |
Originally posted by Disch SMW doesn't save your powerups, Yoshi, or lives. I believe it decompresses the overworld to SRAM too, so that events can simply modify it in memory as they run instead of having to re-apply them all each time (also providing a convenient way to save the passed event status). BTW, some NES games such as Super Mario Bros 3 had on-cartridge RAM that wasn't battery-backed, just to use as work RAM.  |
| Mediocre Ibex? Posts: 9/18 |
1991, so late in its life. |
| Dragonsbrethren Posts: 327/442 |
Originally posted by Disch They sure don't make 'em like they use'd to, do they? Speaking of which, Battletoads was fairly early in the NES's life, wasn't it? I wish developers would push consoles to their limits like that nowadays... |
| Disch Posts: 174/202 |
Originally posted by Legendre Heh... speaking of NES horror stories. Sit down and play Battletoads again sometime. And while you're playing... keep in mind that the NES only has 1 background (only 1 layer, and 64 sprites, no multiple layers or anything), runs at a wimpy 1.79 MHz, and has only 2k of RAM... about 300 bytes of which are more-or-less reserved for Sprite information and stack space (also note that Battletoads has no on-cartridge RAM -- so it does everything with just that 2k). Yet Battletoads manages to pull off full paralax background effects, PCM audio streaming (for some of the sound effects), high scrolling speeds, two player coop, and many simultaeous on-screen sprites... all with no noticable slowdown (at least, I don't remember the game ever slowing down). </offtopic>
Probably not as much as you'd think. How much does SMW actually save anyway? Player position on the map (3 or 4 bytes -- double that if it saves luigi's position too), remaining lives (1 or 2 bytes -- if it even saves this at all, it's been a while), and levels which have been completed (96 paths, right? probably bit-packed, so 96/8 = 12 bytes). Plus maybe the powerups/yoshi you have (maybe 2 or 3 bytes). So clearing out 2 save files will probably only get you about 40 bytes of free RAM. Possibly 64 if it's wasteful.
I doubt many games bother compressing the save RAM. Though most/all of them do some sort of CRC or checksum to make sure the data hasn't gotten corrupted. |
| Legendre Posts: 8/12 |
Ah, very illuminating. I think this sort of thing should be studied by all serious coders just because it really opens your eyes to things you take for granted. I'm very impressed, for example, by these tales of desperate heroic acts of RAM usage by NES developers.
Well, continuing to use SMW as an example. Assuming you are willing to sacrifice two of the three save slots, you could disable them (so the game just has one save slot) and bang, lots of RAM freed up. Do games with savefiles usually use compression of any sort when saving the game? Heh, wouldn't that be novel, incorporate 7z algorithms into games designed over a decade before 7z
Thanks again for all the great responses you guys give a newb like me! |
| Disch Posts: 173/202 |
Linking while working around an already assembled product would be kind of a pain. I'd say if there's such a demand for it -- you'd think it's about time someone sat down and made a re-assembleable disassembly of SMW. This way instead of distributing patches for asm hacks, people could distribute source for them -- allowing people to combine several hacks, giving each their own unique RAM space and what not. It would also make creating those hacks much easier.
Game specific disassembly isn't as hard as people make it out to be. I've done one in the past with Final Fantasy 1 -- and there are several other NES disassemblies out there. It's generic "work on any ROM" disassemblers that are hard. If someone knowledgeable in SMW sat down and dedicated some time to it, I really think something like that could become a reality.
It wouldn't be virtual. Saved games on NES/SNES are stored on actual, real RAM, backed with a battery so it maintains its data after power-off. There wouldn't be any speed issues either. Many games already do this (especially on the NES. Final Fantasy has 8k of battery-backed RAM on the cartridge, only about 2k of which is actually save game stuff -- the rest it just uses as more work RAM since the NES provides so little). |
| This is a long thread. Click here to view it. | |
