Views: 843,391,537
21 users online: Arcten, ASSATAKKU, Counterfeit, Daizo Dee Von, FelterBr, FlamesBoom5628, Green Jerry, Infinity, Isikoro, msi810, Narcologer, NerDose, NewPointless, Nint,  patcdr, Rilla Roo, Rykon-V73, Snessy The Duck, Sweetdude, Synergic, ZeldaVerde - Guests: 42 - Bots: 69 Users: 46,333 (2,850 active)
Latest: Lush_50
Tip: Press F2 on the level editor to see sub-screen boundaries. This will help you avoid glitching Dragon Coins by putting them on the sub-screen boundaries.Not logged in.
Posts by Lexi
Lexi's Profile - Posts by Lexi
Pages: « 1 224 25 26 27 »
Originally posted by millieman76
ZSNES, its more accurate and compatible with a majority of hacks that snes9x can emulate..

But it depended on what computer..

...ZSNES is not accurate. I guess you're trying to say that it's better at playing older hacks without bugs, but that's because the games are inaccurate, not that Snes9x is.

I'm not saying ZSNES is bad, but it's anything but accurate.
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.

Then, web developers just sort of... gave up. People realized that if users refused to upgrade their browsers, it was no longer the developers' problem to provide support for complex JavaScript, CSS3, and HTML5 interaction. There are three primary strategies modern developers use to handle users with outdated browsers:
  1. 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.
  2. Alternative Content – Through a system of conditional comments, CSS hacks, and other methods, developers serve slightly different CSS, HTML, or JavaScript content to older browsers. This makes maintenance more difficult, but it allows outdated clients to still receive a usable experience while letting new users reap the full benefits of new technologies.
  3. 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.
Originally posted by Kieran Menor
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.
Originally posted by Alcaro
Okay, here's Asar 2.00 then. It's absolutely not tested or debugged in any way.

Today is April 1, right?

I really want to know what that does for some reason, but I'm way too lazy to even begin to test it.
Originally posted by Alcaro
Originally posted by imjake9
I really want to know what that does

Originally posted by source code
mov eax, [0]

Oh. Well, then.
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:
  1. Mario is in a level (GM 14).
  2. Mario enters a door or pipe, which freezes all sprites and triggers the Fade to Level game mode (GM 0F).
  3. 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).
  4. 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.
  5. The next mode is Prepare Level (GM 12), which I believe just sets things up and loads sprites, etc. Pretty obvious.
  6. 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.

Any ideas? Are any of these at all documented?
Bump? I don't remember if bumps are condoned or not here, but since I've had no reply after nine days, I figured I'd ask once more before diving into this myself.

Is there really no documentation on how these work? Does anyone have any idea what the process is? Really, anyone willing to point me in the right direction would be appreciated.
Pages: « 1 224 25 26 27 »
Lexi's Profile - Posts by Lexi

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Follow Us On

  • YouTube
  • Twitch
  • Twitter


  • Super Mario Bros. X Community
  • Mario Fan Games Galaxy