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 MaxxLevels: 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 MaxxGFX: 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 MaxxSprites: 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 MaxxBlocks: 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 MaxxObjects: 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 MaxxHDMA: 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 MaxxMusic: 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 MaxxBut 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.