 |
| 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 SMW Hacking. |
| User | Post | ||||||||||||||||||
| bothwingsbroken Posts: 16/23 |
I see your point, Glyph. As for opening and closing things by how long was waited; this is why I wanted to make it turn-based rather than time-based. Turn-based, when used to reach alternate or secret OW locations, I personally don't see as a bad thing, considering I plan on changing a LOT of things in level besides just opening and closing areas (like show/hide sprites, etc.). Basically the level will have two very different forms, one for day, and one for night. For me its about expanding capabilities. As we all know, you don't have to use day/night blocks in your hack. Just if I code it, and you so desire, you have that capability. If nothing else you could use day and night for a pretty pallete change. To let you in on a little secret, I'm using it to swap levels for a "ghost mode" where loose ghosts come out at night. So basically all it would do is double the amount of levels, pretty much. And hopefully increase replay value.
As for expanding the SRAM for lives, yoshi status, etc. I do, in some form agree, that some hackers won't like this, so I will release a hack with and without that particular function. But the purpose of the SRAM expansion is to near triple the amount of addresses saved, mostly unused addresses, to spped up the process for future hacks when they need a ram address to be saved, they won't hjave to modify new/load game, and savegame routines themselves, which might deter some really good ideas from ever being born. I ust thought that while I was at it, I woul like my hard-earned Red Yoshi to stay with me when I have to save and come back later. You could always throw it off a cliff if you wanted to go back and get it again. See I like rare items. I'm an RPG fan. So I want the legendary blue yoshi to be near impossible to get. But what fun is that if he ditches you when you go to bed for the night? Yoshi's life has no value now because we all "go get him again". But if you had to actually work for it, and had the ability to save him to sram, he'd have a more important role than the springboard; he'd actually be a character. But per request, I don't mind making a version that just increases blank addresses and doesn't save any existing values other than originals. | ||||||||||||||||||
| Shiryu Posts: 216/275 |
actually, I would prefer to have lives, yoshi, and powerups saved in GOOD hacks. The purpose of replaying levels is to have fun again with them or to find secrets, not to go and do the same things again and again... It can make the whole hack boring.
If yoshi is in a level per world and is very hard to get I wouldn't like to lose it only by stopping playing... and having to replay a level everytime I start playing or else I don't get what I had back... It's annoying. Also, if you could go where you wanted when you wanted... then why even stages? the day and night actually adds more posibility to secrets and puzzles. And about the multiple stories, the last one is supposed to be what you win by doing the other 3. | ||||||||||||||||||
| Glyphodon Posts: 372/536 |
Day and night sounds like a bad idea. Opening and closing things to the player simply based on how long they've waited is not a good idea. The same goes for past, present, and future. Wouldn't it be more fun if you could go where you wanted, when you wanted?
Expanding the SRAM for lives, yoshi status, and such sounds pretty pointless, too. Finding Yoshi, lives, or powerups, or such in a game where you can visit old levels is little more than a fetch quest. (No, I'll never, ever, stop complaining about that. Ever.) | ||||||||||||||||||
| bothwingsbroken Posts: 11/23 |
Good point mentioning BTO. Hadn't really thought about that. And yeah, the Mario/Luigi hack, I already have it and in hwe32.430 i've done a simple compare operation and listed changes in red. I just haven't had time to intrepret all of it yet as right now this save thing is my main priority. Expanding the save function increases value for all of us. Hey, attention sprite specialists- Does anyone know a way to *add* overworld sprites? I want to enable setting starting points right in LM. Also if anyone has offsets for existing sprite ASM I could always just rewrite the "fish" sprites which are already supported by LM to load player start points. Or something. Good ideas welcome. It looks like it's gonna be one more day on this save thing though. Leaving it half done would result in glitches. It works, though! Slots four and five are coded but not operational until I get the menu stuff. I just have to finish adding the excess SRAM stuff and then set up my status save flags to save mario's powerup, state, and yoshi color for each of five files. Should be done by tommorow I imagine. Just a quick question, when I get it working, should we keep this here or start a new thread for the expanded SRAM hack? | ||||||||||||||||||
| Stephan Reiken Posts: 165/200 |
Request: Create a Verison that is barren of all Custom Blocks. This is on the hopeful part that BlockTool Omega will be released, and it would be much simpler to not have them around.
Helpful bit I hope: Look into the patch that modifies the Mario/Luigi Graphics routine so that Luigi has different graphics... SMW Central is an easy place to find it. That might give you some insight on that part if you want to look it up. | ||||||||||||||||||
| bothwingsbroken Posts: 10/23 |
While I'm at it, does anyone know the level load subroutine address range? BTW I don't know enough about GFX routines to split the graphics out. I can look into it, but for now all I'm doing is setting up the new SRAM functions. I do like the unlockable file idea, but again I don't know the menus yet either. I'll look into it when I finish the new SRAM routine.
Also, so none of you get confused; what I'm making is NOT a hack, persay, but an expanded baserom for others hacks that does two things: comes preloaded with custom blocks/sprites and GFX and ExGFX setups (I'm actually working on expanding for two .bins of ExGFX as well...) and also expands the current capabilities of the rom itself, such as expanding save areas for future hacks, adding game slots, and hopefully even enabling a character select, eventually. I don't waste time making hacks that will be outdated in a month. I want to give others something to base their new hacks off of, something that can be as immortalized as Demo World once was. Just thought I'd make that clear so you all don't get your hopes up. The past, present, future, was just an example that you could have three seperate quests (soon to be five), and if you wanted even allow them to merge or share some parts. This would be good for RPG type games, as well; I'll add a placer address to remember where each file saved at and maybe you can meet them in the level. But that RPG or that game is not what I'm developing, just an advanced base rom that can support it. So if you want, get your brain boiling, just if your thumbs are what's swelling, put them on ice. It'll be cool, but far from fun for a while. | ||||||||||||||||||
| Ramon Posts: 75/503 |
Wow 
If that all works, it's awesome!!!! 
I didn't even think such things would work... Keep up the good work...! | ||||||||||||||||||
| Shiryu Posts: 211/275 |
the idea of past, present and future seems nice... what about that when you get all the exits from one, it increases a vaule in a common save data, when it's 3, it unlocks the 4th file, which uses the main overworld ^^ it would be like the "Last" story seen in some Sonic games...
It would be a good use for this. About the day/night thing... I think it would be better to have in the overworld some sort of counter, that constantly increases (until it hits 255, then it would decrease to 0 again), depending of this, the stages would be at day or night (and maybe afternoon and evening, for both blocks activated and no blocks) | ||||||||||||||||||
| Stephan Reiken Posts: 163/200 |
Say, to truly get a Past, Present, and Future Mario... Could you force each save to load different Mario Graphics?
Past - SMB3 Present - SMW Future - New Mario Bros I believe that would help with your depth, and make it more believable that all three represent different timelines. | ||||||||||||||||||
| bothwingsbroken Posts: 9/23 |
Wow. As of this exact moment, the rest of my project is on hold. I've got a plan that could well revolutionize the depth of Mario gameplay.
Summary: There are six submaps and an overworld. I'm going to split this into three sets of two, and give two to each mario save file. The overworld, through an updated save routine, will be a common map to three files. And if I designate an area of the SRAM for "common" data, it opens doors to hacks not yet concieved. For example: Original: Mario A Mario B Mario C Mine: Past Mario Present Mario Future Mario And each mario starts in his own submap; after their two subworlds, they merge onto the overworld; the levels will be common to all three, and file-specific solid blocks can allow each mario into different areas, while sharing some areas; maybe the level before bowsers castle has to be beaten by all three marios, past present, and future. This overworld can serve as a time vortex or something. And then team all three up to kick some bowser behind. Just a thought. So my main priority is rewriting the savegame and loadgame subroutine completely; I want to save more data to each file, and i want to designate about 30 extra blank ram addresses to each file, for expansion; and also range about 100 ram addresses for common data. Common data opens tons of new possibilities. So yes, this save, load, and erase subroutines have just become my project's greatest priority; that and splitting the three files. Sorry, I think it's cool. ~bothwingsbroken Update - I've got a good idea of how to approach this. I'm basically appending a JSL to the end of the save game subroutine, which I've found works a good deal differently then I believed. However, while I'm at it, it doesn't look to hard to clone the existing routine to another location in the rom where I have a bit more room, and even possibly add two more slots while I'm at it. The only part on this that I'm not sure of, is if it's possible to add two more items to the menu. Load game settings are actually unbelievably more simply to add this; so the only hard part would be saving them. And even that, I guarantee is possible. So if any of you can shed some light on the menu, I'm proceeding to code support for the two extra files. As long as I'm reworking, might as well go all out, right? The only catch I see with my savegame method is that loading and saving will be significantly more processor-intense, and probably cause some lagging, rather than the near instantaneous save seen before. But its a small price, and I'm only guessing it will be slower, it might not. Anyway, I should have some type of demo in the next couple hours. Had another thought, I know that mario and luigi's GFX have been split through an existing ASM hack. Is anyone here familiar enough to split the GXF routine for the three (or soon to be five?) game slots? This would enable a "character select" form of gameplay, even possibly giving each character their own quest. Alright, I'll get my head back in the damn hex editor lol. ~bothwingsbroken Update 2 - - - I fell asleep on the keyboard. Yeah. I'll be back tommorow with your playable. Here's what I got done: SRAM assignment: 70:3961-3992 - Extra SRAM slot 1 70:3993-39C4 - Extra SRAM slot 2 70:39C5-39F6 - Extra SRAM slot 3 70:39F7-3B75 - Save Slot 4 + bonus data 70:3B76-3CC2 - Save Slot 5 + bonus data 70:3D00-3D32 - Common Save Data (loaded regardless of current file) New things to save: Mario's Status Yoshi Flags Coins Score Note that the extra save slots are not quite funtional yet. I don't really have a way to test them, and the whole "grouping" routine is slow progress. *Yawn* Tommorow's another day. ~bwb | ||||||||||||||||||
| Kailieann Posts: 421/808 |
The part that does the actual loading is from 00:9DB5 to 00:9DF9.
Note that this is also used for new games, but, of course, if it's a new game then all the SRAM values will be 00 anyways. Also -- one thing I initially overlooked, myself, so I'll pass it along as a courtesy, DON'T FORGET TO MODIFY THE ERASE GAME ROUTINE. And, no, I haven't gotten around to looking for that quite yet <.< Maybe tomorrow. As for the SRAM values: Save 1 uses 70:0000 - 70:008D and 70:01AD - 70:023A Save 2 uses 70:008F - 70:011C and 70:023C - 70:02C9 Save 3 uses 70:011E - 70:01AB and 70:02CB - 70:0358 Which means 70:0359-70:FFFF are open season. | ||||||||||||||||||
| bothwingsbroken Posts: 8/23 |
: : The Checklist :  /b]
SMB3 OW Pipes - Debugging Multiple Level Exits - In Progress Physics Float - In Progress Speed Powerup (to demonstrate physics) - Not Yet Started "Bump" Block (growing block was the wrong name) - Not Yet Started Flying Spring Board - Not Yet Started Larger Intro Screen - Not Yet Started Time Progression - In Progress Lunar/Solar Blocks - Not Yet Started OW Time Progression - In Progress OW Flag-check Path Enabling - In Progress Additional Switch Blocks - Not Yet Started Additional Switch Palaces - Not Yet Started Multiple Same-Screen Exits - Not Yet Started Title Screen Secret Game - Debugging Phanto - Done by MikeyK Keyhole Block - Not Yet Started Block Pokey - Not Yet Started Savegame Block - In Progress Savegame Update - Not Yet Started Loadgame Update - Not Yet Started Kailieann, do you by chance have a byte range for load game subroutine? As long as I'm at it, I want to add some more data to the save game variables, and possibly leave a couple blanks for others hacks. Also does anyone know the capacity of the SRAM? Does SMW currently fill that capacity or do we have room to grow on the load/save game data? This could expand the possibilities of custom ASM by a significant amount. I'll edit this post for updates and .ips links when they are ready. Kailieann |
Posts: 419/808 Originally posted by bothwingsbroken I've done a reasonable amount of work on the savegame routine. It starts at 00:9BC9 and ends at 00:9C12. The problem -- or, I should say, relatively minor inconvenience, is that the routine listed is only half the equation. It takes the values to be saved from a big chunk of RAM and stores it to SRAM. The issue here is that those values aren't updated regularly. When you beat a saveable level, the game copies all the important values from other parts of the RAM into said chunk, before it pops up the save game window. And I haven't gotten around to narrowing down that part just yet. Though if you really wanted to, it wouldn't be difficult to do. I found it the first time when I was looking for something unrelated -- a write breakpoint at 7E1F49 should do the trick. Originally posted by bothwingsbroken MikeyK has already added a Phanto to Sprite Tool, if I'm not mistaken. And making a block that breaks if you're holding a key, then deletes the key, would be fairly simple. Touching the actual code for the key would be unnecessary. bothwingsbroken |
Posts: 7/23 It does mask this but by changing the gfx and sound routine to skip bytes, it loads the solid color as the background (which I leave black) and then loads the game. It speeds it up, technically, by skipping like 12 bytes, but, again, this notice is so unnoticeable that its not exactly practical. Not to mention that it makes your rom appear broken to the impatient user taht won't wait the 2 seconds to see it load. And I agree that the pirate intro is a bit lame; but if its done... creatively... as well as being easily editable, would give that one hair more control over the ROM's function. And there is a practical... "excuse" for it. It gives you some extra work-room to preload custom values to a ram address before even the engine loads. Not sure if its a needed ability, but; just brainstorming.
| Also, another note I found while screwing around with some things: On the title screen, if mario dies, the player gets to play. Make this level beatable, and it returns you to 0,0 on the overworld map. If you use a custom block before the goal point that writes mario to a new overworld coordinate, and if you have some extra space, or even, say, an extra submap, you could have a hidden minigame (mini as in you can't save it) only reachable by playing and beating the title level screen. And expanding on this a little, if you set the current file flag in RAM, you could possibly enable saving to a slot of the players choice, and this could function as a secret "intro world", or even a shortcut world, the possibilities are vast. And one more custom feature idea; how about a savegame block? On the ROM map at SMW central, people have narrowed down the savegame ASM routine; if we could isolate it, we could make a savegame block, that could add a new challenge to the game: with no level-passed savepoints, a player would have to find savepoints, and they could be easily reached, or the most sacred, hard to find places in the game. Either way. If nothing else, a Save Point House could be a convenience for the easier hacks. Edit - - Another concept. How about a key like the one in SMB2 with a Phanto that follows? The key would destroy a keyhole block when mario, holding the key, collides with it. The key would also self-destruct at this point. Phanto could be a simplified version that basically sits idle, and then while mario is holding the key, he changes palletes to a brighter color, then acts like a high-speed boo. Then when mario dropsthe key, he turns back into an inactive state. He can only hurt mario in an active state. Doesn't have to be phanto, persay, could be a new baddie. And also, perhaps a block Pokey? Basically a Pokey made from like, turn blocks, that you can stand on, and of course stand on and adjust (lower) the height. An interesting twist would be to make it non-aggresive, and solid; so it won't hurt mario, but it also acts like a solid block, that mario can't walk through. He'd either have to lure it out of a path, run jump over it in the open, or eat it with a yoshi. Alright, well, I'm off to work on these all. I'll post .ips files feature-by-feature with coded support and an in-game example of each. But seriously, is there a reason that I should use LevelASM over pallete ASM for the time passing hack? And does anyone know offsets for any OW sprite asm? FreeDOS + |
Posts: 887/1312 Originally posted by bothwingsbroken The -Nintendo- Presents screen? I don't even know if it'd be realistic to remove it; most likely, it just masks loading the game engine into the SNES. As for a pre-intro like lame pirates, They usually append it onto the end of a ROM, modify some starting assembly to load that, which then returns back to the real game. I'd recommend against this method, it's quite annoying. bothwingsbroken |
Posts: 6/23 LevelASM vs. PalleteASM:
| I want the time-transition to be pallete-specific, so that cave tilesets dont turn a darker green, while forests do turn a darker green. Now, I could use LevelASM to run a current pallete check, but I just seem to think PalleteASM would be easier for a pallete-based hack. I could be wrong, that's just my logic. Would LevelASM really be easier? Also, about the sprite pos. for classic pipes; Good idea, but in one way, contricting: A single sprite, with a single set of coordinates, would only work on a one way pipe. I mean, using two different levels for the two tiles would allow travel back and forth, but it just lacks the freedom of exiting a pipe from inside the pipe, at either end. If you make the player proceed all the way through the pipe, this works. But *true* classic pipes, need to be exitable at either end. Oh and one other item for the list, shouldn't be extremely hard; Multiple Same-screen exits - I imagine if there was a way to write to the "current screen exit number" we could use a sprite, or a block, or a combination of the two like smallhackr mentioned, to redirect the player to a different exit. Basically I'm trying to remove the limitations set up by the existing structure for the ROM, or at least work around them. Creativity is 80% of a hack; when it's hindered, it limits the capabilities of the hacks in question. Also, about the switch block expansion: a cheater way to do it would be to have an invisible "trigger sprite" that activate the blocktool code and then self-terminates; the blocktool code would basically function like a change block, sprite activated, that would only change if the flag was true. Eventually I definately want a more permanent solution, but this would be a doable start. Then all we'd need would be four more switch sprites. I'm thinking the graphics are already there so an existing switch sprite code with a modified flag pointer, should work. Oh and another thought on the sprite position for the classic pipes, that might not really work because have you looked at those values? They seem to function in a near random order, and run from 00 to ff. levels don't really have the range to store that large of a coordinate array, and I'm not sure theres a simple algorithym to do the math... It's an awesome idea though, if we can make it work. Anyway, I'll keep digging, and keep you posted. Please keep feedback coming in, it's really helping. Edit - - - - Overworld time passage: doable, I just have to locate any unused (or unwanted) sprite code, and hopefully just place that sprite on the map. what I would like but don't know if its possible, is flag-based passable points. I imagine this would be very difficult, but if we could engage and reverse a "enable direction" flag, we could have luigi-only, mario-only, day-only, night-only, etc. paths on the overworld. Any ideas? As for the multiple exits; you can use the pipe technique to exit the level at another point on the map. Enter the woods on one side, exit and one of maybe 8 different points, for example. Not neccesarily direct path exits, you see. Kailieann |
Posts: 418/808 Originally posted by bothwingsbroken Originally posted by Smallhacker There's this thing called levelASM. Have you heard of it? Smallhacker |
Posts: 735/832 SMB3 OW Pipes:
| Very possible to do. Also, instead of one block per pipe, one could make an invisible sprite and place it in the level. This sprite gets it's own X and Y coordinates and stores them at an unused RAM location. Then, the pipe block reads this data and sends Mario to coordinates based on it. To move Mario's destination, all you would have to do is to move the sprite. Multiple Exits: Mario can only move in four directions. Also, Mario has to arrive from one of those, meaning that increasing the amount of exits to four or above would be useless. Floating Physics: Should be pretty easy to do. Use a tracer to find the opcodes that reads the physics data, replace them with a jump to a subroutine and make a subroutine that reads the data from RAM instead. Growing Block: Possible. However, correct me if I'm wrong, but didn't those blocks shrink back to their original size after a while? If so, it would have to be a sprite. Flying Spring Board: Copy spring ASM, make it move forwards and backwards and draw wings on the screen (or find flying subroutine), possibly disable Mario from picking it up. Larger Intro Screen: Ask BMF. Time: Very interesting idea. An even cooler idea would be to make the time change in levels as well (and possibly on the overworld). 8 Switch Blocks: Requires patching the level loading routine. bothwingsbroken |
Posts: 5/23 Awesome! Was I close with the whole JSR routine around the ROM address, or was it a different method altogether? I'm basically working towards a new base rom, like an up-to-date demo world, a prepared starting point for new hacks, unprotected. If you have like an ASM ips or something to enable just this, I'd be glad to include it, and of course you would recieve full credit. Or if you could just set me in the right direction (or confim that I'm in the right direction?) I'd be ready to do the dirty work myself.
| Thanks! ~bothwingsbroken rubixcuber |
Posts: 95/356 Those are some good ideas. I've done the stuff under floating physics if you need some help. | This is a long thread. Click here to view it. | | ||||
