(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
05-16-24 03:15 PM
0 users currently in SMW Hacking.
Acmlm's Board - I3 Archive - SMW Hacking - My Project New poll | |
Pages: 1 2Add to favorites | Next newer thread | Next older thread
User Post
bothwingsbroken

Goomba


 





Since: 09-07-06
From: Online

Last post: 6432 days
Last view: 6432 days
Posted on 09-29-06 06:38 PM Link | Quote
Hey again everybody. Just a note: this thread is NOT announcing a new hack; it is simply discussing some different SMW items that could very well benefit the whole community if released in a new base rom.

Basically, I have some ideas, with some logic behind them, and while I develop them I'm hoping to get some feedback so that my work won't collide with other existing simple hacks, or to see if someone has a smarter way to implement the functions in question.


The List : :
SMB3 OW Pipes - A simple concept; all you have to do is have a block in-level that sets mario's X, Y, and current submap values. You can rip these through Snes9x's cheat function when you are at the OW point you want the pipe to lead to, and then write your ripped values with a blocktool block at one side or the other of a pipe level. Now, its a pain in the a$$ because you have to create another blocktool block for each exit point, but at the same time it can set off your hack from everyone else's. And with a base .bin file, it requires almost no asm knowledge, just changing a couple numbers. Now for the bugs: I have this feature working smoothly, but there is a bug. If you have events set up, mario will snap back onto the path when the event is activated. If the events are alraedy completed, and you come out of the pipe and move, you will snap back onto the path. However, in rare cases, if you try to reenter the path without moving, you'll end up in the bonus game level. There is a temporary work-around; just modify the bonus game level to include an exit, maybe even remove the lives game from it so that players can't infinitely profit. Not sure. I'm still working on a permanent fix anyway.

Multiple Exits - Read the above item. This can be applied in near limitless number, allowing one level to have as many exits as you can imagine. One point, your goal point had best have a straight exit with no true "beating the level" or events will activate incorrectly. Of course, your first two exits can have events.

Floating Physics - Basically I'm trying to make mario's run speed, jump height, and fly gain assigned to a RAM address. If this is possible, we can power it up through blocks or custom sprites. So far, I've tried a JSR at different points surrounding the ROM addresses trying to get it to pull a value from RAM, but it appears the values are strung. So I have to better parse that area of the ROM in order to understand how this can be done. But I think it would benefit all of us.

Growing Block - Those of us with a DS who have played the New Super Mario Bros. will recognize what I mean; the "turn blocks" that spawn more blocks on top of them. Not sure how doable it is, but maybe having a "null" sprite interact with custom non-solid blocks on top, you could run a check every frame for a RAM counter, and then adjust the blocks to be solid or not depending on how many times mario hit the base block.

Flying Spring Board - A custom sprite, naturally, that I don't think is hard to do. Haven't started on it yet, but basically I think I will just rip existing springboard code, and give it some basic flying ASM. Could add some very unique challenges.

Larger Intro Screen - The whole "presents" screen. I've managed to modify or disable it, but now I want a full page intro screen loading before the title screen. I don't know if it can be done through DMA or not, I'll give it a brief effort and if I can't; there are tutorials everywhere for writing custom intros to snes roms (commonly seen in group rips). I'll get it to work and not disable the SRAM, then we're good to go.

Time - A true element of time. I'll use PalletteASM to implent a 3-life/3-level time passage from day to night. Depending on the pallete, when night mode is activated, I'll write all the basic colors of the pallete to be darker, and then brighten 3 lives/levels later. And the purpose of this would basically be fore Luna/Sol gates that open corresponding to day or night. Basically a counter would be tripped every time you enter a level, and then load a counter from ram. if the counter is 3-6, color the pallete. If its 6, color the pallete then reset the counter so the next time it will be back at 0, daytime. Also maybe some custom sprites to appear or dissapear at day or night. Koopa and goomba by day, Boo and Anti-Boo by night. Haunted forests, anyone?

8 Switch Blocks - I'll get four more switch blocks. Just for the hell of expansion.

So any ideas, suggestions, "please don'ts", I'll listen.


rubixcuber

Mole








Since: 09-08-06
From: St. Louis, MO

Last post: 6406 days
Last view: 6406 days
Posted on 09-29-06 06:54 PM Link | Quote
Those are some good ideas. I've done the stuff under floating physics if you need some help.
bothwingsbroken

Goomba


 





Since: 09-07-06
From: Online

Last post: 6432 days
Last view: 6432 days
Posted on 09-29-06 07:09 PM Link | Quote
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
Smallhacker

Super Koopa
I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER








Since: 11-17-05
From: Söderhamn, Sweden

Last post: 6298 days
Last view: 6296 days
Skype
Posted on 09-29-06 07:17 PM Link | Quote
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.
Kailieann



 





Since: 11-18-05

Last post: 6296 days
Last view: 6296 days
Posted on 09-29-06 07:44 PM Link | Quote
Originally posted by bothwingsbroken
Time - A true element of time. I'll use PalletteASM to implent a 3-life/3-level time passage from day to night.

Originally posted by Smallhacker
Very interesting idea. An even cooler idea would be to make the time change in levels as well.


There's this thing called levelASM. Have you heard of it?
bothwingsbroken

Goomba


 





Since: 09-07-06
From: Online

Last post: 6432 days
Last view: 6432 days
Posted on 09-29-06 08:08 PM Link | Quote
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.


(edited by bothwingsbroken on 09-29-06 07:21 PM)
(edited by bothwingsbroken on 09-29-06 07:29 PM)
FreeDOS +

Giant Red Koopa
Legion: freedos = fritos








Since: 11-17-05
From: Seattle

Last post: 6296 days
Last view: 6296 days
Posted on 09-29-06 08:51 PM Link | Quote
Originally posted by bothwingsbroken
Larger Intro Screen - The whole "presents" screen. I've managed to modify or disable it, but now I want a full page intro screen loading before the title screen. I don't know if it can be done through DMA or not, I'll give it a brief effort and if I can't; there are tutorials everywhere for writing custom intros to snes roms (commonly seen in group rips). I'll get it to work and not disable the SRAM, then we're good to go.

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

Goomba


 





Since: 09-07-06
From: Online

Last post: 6432 days
Last view: 6432 days
Posted on 09-29-06 09:08 PM Link | Quote
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?


(edited by bothwingsbroken on 09-29-06 09:06 PM)
Kailieann



 





Since: 11-18-05

Last post: 6296 days
Last view: 6296 days
Posted on 09-29-06 10:38 PM Link | Quote
Originally posted by bothwingsbroken
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

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
Another concept. How about a key like the one in SMB2 with a Phanto that follows?

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

Goomba


 





Since: 09-07-06
From: Online

Last post: 6432 days
Last view: 6432 days
Posted on 09-30-06 02:01 AM Link | Quote
: : 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.


(edited by bothwingsbroken on 09-30-06 01:05 AM)
Kailieann



 





Since: 11-18-05

Last post: 6296 days
Last view: 6296 days
Posted on 09-30-06 02:11 AM Link | Quote
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

Goomba


 





Since: 09-07-06
From: Online

Last post: 6432 days
Last view: 6432 days
Posted on 09-30-06 02:58 AM Link | Quote
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


(edited by bothwingsbroken on 09-30-06 03:41 AM)
(edited by bothwingsbroken on 09-30-06 03:43 AM)
(edited by bothwingsbroken on 09-30-06 04:49 AM)
Stephan Reiken

Blipper








Since: 11-17-05

Last post: 6304 days
Last view: 6297 days
Posted on 09-30-06 11:25 AM Link | Quote
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.
Shiryu

Gungun








Since: 02-24-06

Last post: 6298 days
Last view: 6296 days
Posted on 09-30-06 01:12 PM Link | Quote
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)
Ramon

Bullet Bill


 





Since: 11-25-05

Last post: 6296 days
Last view: 6296 days
Posted on 09-30-06 02:54 PM Link | Quote
Wow

If that all works, it's awesome!!!!
I didn't even think such things would work...

Keep up the good work...!
bothwingsbroken

Goomba


 





Since: 09-07-06
From: Online

Last post: 6432 days
Last view: 6432 days
Posted on 09-30-06 07:39 PM Link | Quote
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.


(edited by bothwingsbroken on 09-30-06 06:43 PM)
(edited by bothwingsbroken on 09-30-06 06:56 PM)
Stephan Reiken

Blipper








Since: 11-17-05

Last post: 6304 days
Last view: 6297 days
Posted on 09-30-06 11:37 PM Link | Quote
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

Goomba


 





Since: 09-07-06
From: Online

Last post: 6432 days
Last view: 6432 days
Posted on 10-01-06 04:32 AM Link | Quote
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?
Glyphodon



 





Since: 11-18-05

Last post: 6337 days
Last view: 6318 days
Posted on 10-02-06 02:31 AM Link | Quote
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.)
Shiryu

Gungun








Since: 02-24-06

Last post: 6298 days
Last view: 6296 days
Posted on 10-02-06 12:30 PM Link | Quote
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.
Pages: 1 2Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - SMW Hacking - My Project |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.044 seconds; used 481.24 kB (max 617.43 kB)