New update! Hooray!
Here's a list of major changes in version 0.6:
A large portion of the code has been rewritten to actually be manageable. This will make updates a lot less painful on my end.
There is now a line tool for all your line-y needs.
Both the ellipse tools have been implemented.
There is a working fill tool implemented.
Bug fixes and better handled exceptions.
As a side note, the fill tool is admittedly not very helpful since trying to fill a background color will likely bleed into other tiles, since SNESTile doesn't use the two-pane view of YY-CHR, but this should be remedied with the implementation of the marquee/selection tool.
Sorry for the long update delay. I'm rather busy, but I managed to find some time to work on this, so here you go. I'll try to be a bit more responsive in the future.
Sorta makes me think of this. Shame we can't track ZSNES usage the same way.
Going with the IE6 analogy, I think it's time to keep in mind what happened to people who refused to upgrade. At first, people kept backwards-compatibility. Conditional comments and CSS hacks were used to attempt to salvage the IE6 population. IE7 maintained a quirks mode to help render pages designed for IE6 properly.
Degrade Gracefully – Basically, this is a policy to let web pages still work in older browsers, though they may lose some more complex animations, styles, and interactions when viewed in them.
Abandon and Move On – This is the simplest and least graceful method. Simply put, these developers will either block access to or display warnings on their websites to upgrade users' browsers, or they might just silently crash and burn. The lowest maintenance method, this leaves the responsibility of upgrading to the user.
Let's face it, we can think of similarities for ZSNES. Obviously, some things can degrade gracefully in ZSNES, like less accurate music, fewer effects, and simple inaccurate emulation. However, due to the error-prone nature of such a limitation, it's hard to write complex code that will both take advantage of accuracy and still allow emulation on ZSNES.
While providing two different ROMs is always a possibility, this could easily become a real pain for hack developers, since the current state of SMW hacking is really only designed for a one-ROM per hack basis.
The question is, do we go with the final option? Can we move on, or is the ZSNES user base large enough to maintain.
The bottom line is that, well, ZSNES is not a problem when it's just a users' choice. If someone doesn't need perfect emulation, that person can make that decision. But when the users' choice of an outdated emulator starts inhibiting modern technology development, we have a problem. Should we design anything to run on just ZSNES or just bsnes just because we want to spite the emulators? No, but at some point, maintaining compatibility is no longer an easy task.
Sorry if this is a bit inflammatory, but I felt the need to post it. I'm done now.
Another update! Version 0.7 adds the following features:
The marquee tool now exists! This can be used to make selections. Click and drag to select, or click once anywhere to clear your selection.
Currently, the only real function of the marquee tool is to ask as a "mask". Basically, once a selection is created, drawing tools will only work inside the selection. This makes editing tiles somewhat simpler.
Speedier and more consistent internals.
Definitely download and check it out. With the inclusion of a selection system, I'll now be able to actually start implementing things like color replace, flip, and rotation. Hopefully I'll be able to get those in soon.
Well, considering it is as close to being done as it is...
The first update is a complete overhaul of the file sections. Everything has been united under a single system, a demo section has been set up over here. Feel free to mess around and upload garbage (actually that would help testing). As you can probably see, there are still a few lose ends, but it's almost ready at this point.
Ooh, pretty. And the test file names are almost as insane as mine usually are! Hooray!
Oh, y'know one thing I think would be cool to have would be the option to have multiple downloads for a single file. The main reason I suggest this is so that tool makers could include multiple platforms for their applications. As it is now, I have to manually compile xkas or Asar to work on Mac OS X, which seems a bit silly since the source is basically compatible.
Additionally, it'd be awesome if authors of a submission could just click a link to upload a new version of a file, instead of creating a duplicate and having a mod remove the old one. Just a thought.
I'm having a little bit of trouble understanding the game modes that relate to the level loading routines, specifically about switching between levels and sublevels. From what I've gathered by looking through all.log, this is the process:
Mario is in a level (GM 14).
Mario enters a door or pipe, which freezes all sprites and triggers the Fade to Level game mode (GM 0F).
The Fade to Level game mode triggers the mosaic effect and then increments the game mode counter to the so-called "Fade to Level (black)" mode (GM 10). I'm not exactly sure what that mode does, but then it transitions into Load Level (GM 11).
I would assume that this actually loads the level data into RAM, though I'm not exactly sure about the specifics, but it seems relatively straightforward.
The next mode is Prepare Level (GM 12), which I believe just sets things up and loads sprites, etc. Pretty obvious.
Finally, there's Level: Fade In (GM 13) which actually fades into the level and starts it up.
Given this information, I wanted to see how quickly I could make a the level transition occur. Basically, which of these steps are required, and which are optional? The first thing I tried was cutting out the Fade to Level game mode and jumping straight to GM 10. This worked, but interestingly enough, it entered the level with the mosaic effect still in play. I assumed this occurs because the next mode was attempting to undo the effect that was no longer being applied, so I tried skipping Fade to Level (black) as well, just to see what would happen. Interestingly enough, I still saw no difference between skipping GM 0F and skipping GM 10. Still not sure what Fade to Level (black) actually does.
Obviously, skipping subsequent modes causes the game to glitch out a little bit, even if you're reloading the same level. However, I'm interested in that latter case, the case in which you're simply reloading the same level.
Why does Load Level need to be called again if the target level is the same as the one you're currently in? The game appears to fail to reset sprites' positions if Load Level is skipped, which means my earlier analysis was partially wrong, and the background graphics get garbled as well, which I don't really understand.