Language…
19 users online: Alex No, ben15420, DanMario24YT, gcrackaaa, GiraffeKiller, Gmario37, Gorry, Green, Hidincuzimsmokin, JudithPrietht, Maw, Metal-Yoshi94, MorrieTheMagpie, rafaelfutbal, Ray Hamilton, ShoopDaWhoop, Sniwott, VoidCrypt, wayht - Guests: 292 - Bots: 463
Users: 64,795 (2,371 active)
Latest user: mathew

what 'big' issues remain in SMW hacking?

This is NOT a request thread. I want this to be discussion with the more capable hackers (I hate how elitist that sounds but I don't know how else to put it).

In the past couple years there's been a huge amount of enhancements made to the game and plenty of options made available to enhance a hack. Is there any part of the game or any category that could really use some work in your opinion, though?

This is more of a discussion thread. If you post something resembling:
"yeah it would be great if you could ____________ thanks"
you'll probably be banned. Let's talk about limitations you'd like to see lifted and how we might do that.

It's the most overhacked game in the entire scene so we may aswell try to make it as good as it could possible be.

My only big issue is limitations with space and shit. If you expand the rom, the music space, for example, doesn´t expand. That is kind of annyoing.
It would be great if you did something about that!



I might put some sort of signature here once. I guess.
These are my thoughts:

I guess the only limitations are the powerups, and extended sprites. No tool has been made for them. ...Well, actually some japanese made Extended Spritetool which I doubt it may be released here, and Bio was working on Poweruptool but it got lost due to his harddrive crash. Right now I'm working on an Extended Spritetool too but I'm not sure if I'll ever finish it soon due to school. About powerup tool I heard someone was working on a $19 expansion patch so that should solve those 2 limitations if all goes as planned.

Another thing which sometimes bothers me is how NMI always has limited time. Yes I know it's SNES' fault, but I wonder if we could optimize the NMI so a few more cycles can be freed up. We could probably make use of the direct page register during the RAM->SNES register writes; SMAS does that too.

Talking about cycles, I was wondering if we could speed up the LZ2 thing decompression by either using an enhancement chip (SA-1 or SuperFX since they're practically programmable), or just optimizing the original SMW routine. Then again, SuperFX requires a major overhaul of the ROM (transferring NMI and IRQ to RAM, freeing up RAM around $0100 etc and I'm sure nobody likes a 2MB Max ROM).

Those are my thoughts. Threads like these always interest me because you're going advanced, and deal with limitations which is pretty challenging.

Originally posted by Jerry
My only big issue is limitations with space and shit. If you expand the rom, the music space, for example, doesn´t expand. That is kind of annyoing.

Do you mean the free space Romi's addmusic automatically searches for? I think it grabs the first RATS-free freespace possible after bank $10.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
With these graphics and the latest LM, we're really hitting the roof in terms of just what the SNES could do.

Levels: HUGE amount of space.
GFX: HUGE. Only thing we need is good rippers now.
Sprites: Pretty fully hacked. Extended sprites?
Blocks: Fully hacked.
Objects: Fully hacked.
HDMA: Could use a decent HDMA tool, but this suffices because HDMA doesn't really have to be fancy.
Music: This is like the last substanial thing left. The music engine that SMW uses is... inconvenient. (4 tracks to load per level.) Also, the engine is fairly picky and we could use some new commands implemented (I'm fairly sure we can..?) But with addmusicM we've solved most problems here too.

But all in all this will suffice. We've come really far- the rest of it is either implementation of the hacking or expanding the hacking. Nothing 'big' remains.

Originally posted by Ersanio
Originally posted by Jerry
My only big issue is limitations with space and shit. If you expand the rom, the music space, for example, doesn´t expand. That is kind of annyoing.

Do you mean the free space Romi's addmusic automatically searches for? I think it grabs the first RATS-free freespace possible after bank $10.

I use addmusic_e, and i am not sure how that one works with free space.
(sorry if I am derailing the thread here, it's not my interntion of doing so)



I might put some sort of signature here once. I guess.
Pretty much what Ersanio said - not much has been done in terms of powerups and extended sprites. The few things that have modified it aren't too standardized, and I have the feeling that all information about them is widely spread.

Mario's GFX space could also be something one could improve on. I think Jagfillit made a patch to add a second page of GFX to Mario just a few days, but I remember him saying that method wasn't quite perfected yet.
(...Now that I think of it, Mario's hitbox hasn't really been messed with either.)

Apart from that, I think everything that can be done has been done.


 
Physical level space. The current level modes require stages to be too linear for certain design types; there should be a way to, say, "double up" a vertical or horizontal level, so that half of the length is sacrificed for double width.
Originally posted by JVyrn
Physical level space. The current level modes require stages to be too linear for certain design types; there should be a way to, say, "double up" a vertical or horizontal level, so that half of the length is sacrificed for double width.



That would be awesome for puzzles!
Your layout has been removed.
All I know is that the Overworld is mostly unknown, and has much potential...

World Community Grid: Thread | Team
 
Quote - (...Now that I think of it, Mario's hitbox hasn't really been messed with either.)


Except that I just submitted a patch this c3 that allows you to easily control it, and made a fix for it to work with the $19 expand.

Smoke images should be fixed to not appear offscreen.
I own a community of TF2 servers!

ASMT - A new revolutionary ASM system, aka 65c816 ASseMbly Thing
SMWCP - SMW Central Presents a Product- tion long name

frog

http://esolangs.org/wiki/MarioLANG
The overworld is in definite need of hacking.

- Palettes are too limited currently. The path reveal animation is the cause of this, and I believe it can be preserved by using layer 1 and 2 with color math for the same effect without using palette space. This would also allow 4bpp graphics instead of 3bpp currently.
- The path transition between submaps should really run the OW loading routine again like pipes and stars do. This would allow music banks, exgfx, ect to be changed when using path transitions.
- Custom paths.
- Custom special events (like switch palaces spewing blocks, or the earthquake).
- Additional levels and events. Honestly shouldn't be much more than expanding a few tables.


Most if not all of that is on my long term to-do list. Some should be rather easy (fixing path transitions), some will be rather hard (fixing palettes), some might require making a tool to be remotely user friendly (custom paths).
Our music.

The addmusic hacks everyone uses only function due to bad emulation. The two most popular ones both store data in the echo buffer. This is incredibly shitty practice.

SMW needs to start doing what many other games did. Load one song into ARAM at a time. When you need another song, load it, don't use the buffer to try and fit a bunch of songs in. Everything stops while you do this (unless you do something crazy like an HDMA upload) but who cares? In just about every game I can think of there's a noticeable pause when the next song loads. I never found it to be bad. It feels dramatic if anything.

Originally posted by Kil
Our music.

The addmusic hacks everyone uses only function due to bad emulation. The two most popular ones both store data in the echo buffer. This is incredibly shitty practice.

SMW needs to start doing what many other games did. Load one song into ARAM at a time. When you need another song, load it, don't use the buffer to try and fit a bunch of songs in. Everything stops while you do this (unless you do something crazy like an HDMA upload) but who cares? In just about every game I can think of there's a noticeable pause when the next song loads. I never found it to be bad. It feels dramatic if anything.



I also want to expand on the music topic. most of the addmusic commands are still shrouded in mystery. I recently was messing with $E4 (believed to be global fine tuning). I tweaked the variable by an unnoticeable amount with it's equivalent $EE (channel fine tuning) and I came out with these.

http://bin.smwcentral.net/19088/E4FF.spc
http://bin.smwcentral.net/19089/E4FB.spc

We really need to understand our music commands and functions more.
Well, there was one thing that immediately came to my mind when I saw this thread: the overworld. Sure, we can use ExGFX and custom music for it, and even HDMA and stuff via OWASM, but we know a heck of a lot less about the overworld than we do about most other stuff in SMW, especially the levels. We don't have very good resources for overworld custom sprites (they shouldn't be too difficult to insert manually, but we're still limited to 13 for the entire overworld), and the palette limitations are a regular pain in the butt. Somebody made a patch that allows custom palettes on the overworld; why hasn't FuSoYa integrated it into Lunar Magic yet? (I could say the same for Roy's Layer 3 ExGFX and Player/Animated Tile ExGFX patches.) And why only 0x77 events? Of all the numbers to end on, they pick 77? 7F might have been understandable...but it could be useful to have it go up to, say, BF or even FF. Then there's the matter of expanding the total size of the overworld. I've heard quite a few people talk about it and an equal number say how difficult it would be, but I can't talk about overworld limitations without at least bringing it up.

I also really wish we knew more about enhancement chips. I still want to figure out enough of the SA-1 to get it into a SMW ROM. Yeah, I know, the SNES Dev manual covers it *coughpedanticcough*, but its examples are...uh, what examples? This isn't really very high priority, though.

Now, Maxx, since you made an actual list, I shall horribly misquote you and screw up everything check off each item on it via quotes.

Originally posted by Maxx
Levels: HUGE amount of space.


I may have to respectfully disagree there. Ninety-six overworld levels and 512 sublevels isn't that many...I can use up 96 overworld levels in a flash, and if you divided the sublevels equally among the overworld levels, each overworld level would get 5.3 sublevels counting the main level. Not bad, but for those of us who like to make more complex levels, it could add up pretty quickly. Also, what if you wanted to have intro cutscenes or something, like in SMB1? That 5.3 instantly goes down to 4.3. Four and a third sublevels per level isn't that many. If we had 0x400 total sublevels instead of 0x200, and $13BF could go up to 7F or even FF instead of 5F...of course, that would require drastically altering the level loading routine and whatnot.

As far as level data space goes, well, suffice it to say that individual Map16 tiles are brutal on ROM space. I once made an entire level out of Tunnel Rhino's foreground, placing nearly every Map16 tile individually. The level only went up to screen 15, too. The end result, however, was that the Layer 1 data for that level took up over half a ROM bank. Fortunately, not every level would be like that, or an 8 MB ROM wouldn't be big enough to hold it all. But I think that's a big enough problem that it should be brought up. I think FuSoYa may already have a solution for this, but...we'll have to wait and see.

Originally posted by Maxx
GFX: HUGE. Only thing we need is good rippers now.


And good non-clashing tilesets...and for me to work on my attention span so I can actually stand to rip foregrounds with edit1754's BG Ripper.

Originally posted by Maxx
Sprites: Pretty fully hacked. Extended sprites?


Pretty well hacked, but not fully. For one thing, there are all those unused sprites that don't have pointers (E7, EB, EC, EE, F0, F1, and F6-FF), and of sprites 00-E6, the only one that uses extra bit setting 1 is sprite 7B, the goal tape. Noobish and I are working on a way to make these usable (or, at least, we're supposed to be...it would be nice to have help from a third person who both isn't busy all the time and knows C#), at least. Yes, I am one of those people who considers 0xC0, or 192, sprite slots a limitation, but honestly, this is more a case of me being anal than needing more sprite slots. (I could fit everything into 00-BF, although it would mean combining some code.) It just kind of bugs me that I can't use sprite F0, for example.

I also sometimes find it a bit limiting to have only 2 pages for sprite graphics. The fact that it's a limitation of the SNES doesn't make it any less annoying. Of course, I don't know how one would get around this, except by making a bunch of sprites dynamic and expanding the capacity of dsx.asm. (Then there are sprite subroutines...ones that aren't very well documented and that very few people know how to do, such as circular movement and wall-following, and ones that need to be more customizable, such as the object and sprite interaction routines, but I don't know if those fall under this category.)

Originally posted by Maxx
Blocks: Fully hacked.


Except for one thing I can think of: custom "acts like" behavior. You know how you can make a movement block act like tile 130 so that it moves you and is solid on all sides, or make a hurt block act like tile 0 so it hurts you and can be swum through? With custom "acts like" codes, if you had a breakable brick on, say, tile 300, and you put a block that gives you a cape in as tile 500 and made it act like 300, when hit, it would give you a cape and shatter. Beyond that, I can't really think of much else we haven't already done with custom blocks.

Originally posted by Maxx
Objects: Fully hacked.


Not really. Extended objects, yes, although FuSoYa hasn't implemented custom object tooltips yet. But no one's made custom normal objects (except FuSoYa...direct Map16 tiles are one example) yet.

Originally posted by Maxx
HDMA: Could use a decent HDMA tool, but this suffices because HDMA doesn't really have to be fancy.


Yeah...just about everything you can do with HDMA has been done by at least one person. Gradients, windowing, parallax, wavy effects, Mode 7 effects...much of it just isn't very common knowledge.

Originally posted by Maxx
Music: This is like the last substanial thing left. The music engine that SMW uses is... inconvenient. (4 tracks to load per level.) Also, the engine is fairly picky and we could use some new commands implemented (I'm fairly sure we can..?) But with addmusicM we've solved most problems here too.


AddmusicM, though, is kind of buggy and not very user-friendly. That's what I've heard, anyway. There isn't yet a program to rip individual .brrs, either. AddmusicM sounds great, but if it were that easy, then there would be submitted ports that work only on it, which I'm pretty sure there aren't. I have to agree with you on the 4-track thing...but couldn't the SPC data be reloaded mid-level? Like, say you're making a sound/music-test room for every song in a hack. What if the blocks or whatever caused the music to play simply reloaded SPC data from wherever necessary? It's been proven that it is possible to reload level data mid-level, so why not music data as well? I've also wondered how useful it would be to learn SPC-700 assembly...it can't be much harder to learn than the normal 65816 assembly, and I did okay with that.

Originally posted by Maxx
But all in all this will suffice. We've come really far- the rest of it is either implementation of the hacking or expanding the hacking. Nothing 'big' remains.


Nothing big, but I still say there are a few things that are at least medium. If I had to choose, in order...

1) The overworld. We don't have enough knowledge or documentation of it, we need to do more with it (Kaijyuu, you are SO right...I didn't even think about custom paths and the like), and there are some things, such as palette limitations, that are really quite annoying.
2) The player(s). I didn't mention this earlier in the post, but really, most of us know next to nothing about the player's physics, graphics, interaction, and a lot more.
3) Music. Look at the paragraph I wrote, then look at the previous two posts. Need I say more? (Fun fact: I recently discovered why Slash Man used to use echo delays of $A0 or more...luckily, that song was only 6 channels originally and only 2 of them were strongly echoed.)
4) The Map16/level data problem. There's an inverse relationship between how cool a tileset looks, on average, and how forgiving it is with ROM space, on average. If we're going to have crazy complicated graphics, especially foregrounds, we need to address this.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by Ersanio
extended sprites


This.

(Not really trying to make a small post, but that pretty much sums it up for me. Extended sprite documentation would be awesome.)

Give Mario some love?~
I don't know if it exactly fits this thread but what I feel like should be made is LM with all the additional tools (Addmusic, Blocktool SD etc.) implemented and made easy to use.

I know you can use them separately and there's nothing wrong with that (especially when they are made easier to use every day) but IMO it should be made some day.
I really mostly just have to echo what other people have said already.

1. Power-Up Tool/Extended Sprite Tool
Jagfillit is currently working on a new power-up system, and I have faith in him, but I am sure he wouldn't mind some help. An expanded power-up system is something I've wanted to see developed since I first got into this three years ago, and there has been little to no progress with that until just recently. Major obstacles with this include:
- implementing new Extended Sprites
- loading custom sprites into the Item Box (or some new item-storing system)
- a good way of handling player graphics
- a good way of handling graphics for the power-ups and their effects

2. Overworld
Very few people have really messed with the overworld much. Of all the aspects of the game, it seems to be one of the least investigated. Besides what Kaijyuu mentioned (which are all worthwhile things to look into), I would still love to see something done that would expand the number of levels accessible from the overworld, but this is a pretty advanced task and one that I don't expect to see anytime soon, if ever.

3. Recreations Of Things In Past Games
There are still a lot of things from the classic 2D Super Mario Bros. games (SMB 1-3, YI, SML 1+2, etc.) that could be recreated in Super Mario World. For instance, there are still several sprites that haven't been recreated due to their need for custom Extended Sprites to avoid slowdown (e.g. the SMB3 Paragoomba that drops Mini-Goombas), or because they were unusual (Tweester from SMB3 for example), or because no one cares (Ostro from SMB2, for example). In the meantime, though, some of the most-requested sprites, like SMB3's Bowser or Boom-Boom or Koopalings can only be found in private collections, if at all. Those are just some thoughts off the top of my head, though, an not necessarily the best examples (nor the biggest, most adventurous projects for highly-skilled hackers).

[?] Miscellaneous Helpful Hints
If I moderated your hack, there was apparently a 90 percent chance it was rejected.
Originally posted by imamelia
Also, what if you wanted to have intro cutscenes or something, like in SMB1? That 5.3 instantly goes down to 4.3.

Seems like something that a dynamic level intro could use, somehow making each level start run code to display such a screen, pulling info to display. I'm speaking out of my ass of course, I don't know how feasible it is.

World Community Grid: Thread | Team
 
The first thing I say should first be investigated and expanded on knowledge wise and hacking wise is the overworld, because as much as the others have said, not a lot is known really about the overworld and submaps besides OW ASM and HDMA on the overworld. Sure those are great, very, but It would be really nice to know more about them and to be able to expand them further or have more palettes, etc etc.
meh
I have just about no experience with adding custom features to SMW, but there are a few SMW glitches that it would be nice to have a fix for. These seem pretty minor in comparison to what's already listed, but they occur in just about every hack...

For one thing, the timer bonuses. It shouldn't be that difficult to make 400+ multiply by 50 accurately, right?

Also, correctly displaying a 3-digit exit count on the title screen. (This certainly is possible-- it was done in SDWTLC and a few VIP hacks, after all.)


By the way, I certainly agree that expanding overworld hacking is important, especially increasing the number of events and the number of overworld levels. (I've heard FuSoYa increased the number of events from 0x70 to 0x78... Why not have 0x7F events? And why can't the overworld levels include any level, or at least more than 0x60 (which besides not being a power of 2, is 3 more than the original SMW anyway)? (And yes, I know I'm repeating something said earlier here.))

Also, increasing the space for overworld maps to more than 1 main map and 6 submaps (though it would probably be extremely complicated) would be useful for almost everyone.

(In my opinion, being able to modify the original SMW's features more extensively is more important than expanding features such as custom sprites.)

(Though I have heard that many recent custom music tracks only work correctly on ZSNES due to its lower-quality emulation... Now that's something that shouldn't be done. What will happen if ZSNES is updated? Would people need to be told to go find an outdated version of ZSNES to play certain hacks?)

–=–=–=–=–=–=–
Advynia: a Yoshi's Island editor - Alyssa's Unlikely Trap demo 3