Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
I think its main use would be in places where you would need to wall-jump 2 or more times. You could substitute the first one (or every other one?) with a double-jump, which gets you immediately ready to do another wall-jump from the same wall.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
I said "is" possible, not "is not" possible. I was trying to wall-jump from a wall on the left side of the screen and accidentally did a double-jump instead.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Has anybody else noticed that the old-style wall-jumping (glitch) from the early Mario games is still possible in NSMB? It would be funny to see someone ignore the intentional wall-jump move to save time by jumping straight up at a wall.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
That's already done, but cheats aren't implemented (only searching/viewing, and viewing could be more convenient), and there seems to be some bug in the way Gens handles all RAM addresses that Upthorn has been working on fixing.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
It rips the currently-loaded 3D world, which you can render from overhead in a 3D program if you want to make a map out of it. I believe it comes from the emulator (after it has put the scene into a standard format for drawing), not directly from the ROM. It shouldn't matter how big the objects are.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
You could play using a renamed duplicate of the ROM (similar to what FractalFusion suggested) and/or make a savestate whenever you make an in-game save.
The emulator feature closest to what you're looking for would be an option to prevent the SRAM stored in savestates from being loaded at all. That leads to an inconsistent state when you load a savestate, where saved game data will persist into a game that didn't save that data, but presumably you're willing to accept that if you use that option. You're in luck if you use Gens, because it always does that (it forgets to save or load SRAM in savestates, much to my annoyance when I actually want to recover a saved game from a savestate).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Depends on the emulator, but I think that is what Snes9x and VBA do, whenever any of those 3 things happens (including loading another ROM or playing a movie, not including crashing). If you want to edit/replace/inspect the SRAM file, generally you should exit the emulator first and leave it closed until you're done.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
It overwrites the SRAM in the emulator's RAM immediately, and sometime later (could be in a few minutes or the next time you reset or exit) it writes that back out to the SRAM file, which is only loaded when starting or resetting the game.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
I haven't heard anything from Hacktarux lately, but supposedly he's been working on Mupen64 on and off, and I already let him know that compatibility with this game is one of the most desired improvements for the next version. If there is any news about it, it's likely to show up here first.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
N64 emulation is very CPU-intensive, and the fast-forward button doesn't skip very much except for the final rendering stage of some frames, so it will only make it go faster if your CPU is already powerful enough to run N64 games at higher than 100% speed.
However, it's possible that your sound plugin is preventing it from speeding up. Some sound plugins purposely slow down the gameplay to keep the sound synchronized, which will stop fast forward from working even when it should work.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Wouter Jansen wrote:
[snip]
Then, I agree. I'm being lazy by not fixing it, but a workaround exists and it looked (before) like you were ignoring that.
EDIT: comicalflop posted a savestate at the bottom of the previous page, for anyone that missed that post.
Bag of Magic Food wrote:
Hmm... How does the angle get less precise if you're a greater distance away from center?
At least in Banjo Kazooie, a lot of the "out of range" area is interpreted as 100% diagonal tilt (45 degree angle). So if you try fine-tuning your diagonal movement by moving it a little out of the far corner, it will have almost no effect until you get close to a cardinal direction, where the movement angle changes more rapidly. Most of the same angles are there, but they are spread out more evenly along the circle.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
comicalflop wrote:
What happens when that red dot goes outside the circle? is that outside the N64 range? because I've been adhering to within the circle using the GUI, and I've noticed the analog stick of the gamepad goes beyond it, have I been going at angles not at the optimal speed?
Approximately. I don't know exactly what the range is but it made sense to draw a circle there to give a rough idea. If the character seems to move faster than normal when you go outside of the range, you could use that to your advantage. Otherwise, it doesn't really matter.
In some games (like Banjo-Kazooie), you will actually get worse angular precision, for no speed benefit, if you play outside of the normal range. So it might be better to stay inside it. You can adjust the sensitivity bars in the input panel or the "range" settings in the input plugin options if you want to prevent the joystick from going outside of that range.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
I would think jumping when you touch the ground would be bad in general, because being near the peak of a jump slows you down a lot compared to being on the ground without pressing any directions. And in Sonic games after Sonic 2, they fixed the problem where holding in the direction you want to go will slow you down.
Finding the first frame to stop holding left is easy because if you let go too early then Sonic will still be in the wall. Maybe the hardest part to optimize is that the speed you leave the wall at can vary depending on the position (and probably subpixel position) before starting to zip, so even if you test all possible input while zipping you could still miss the optimal speed you could have gotten if you had entered the wall a little differently. Obviously a speed display or memory viewer makes it a lot easier to tell.
In this particular run, there isn't a lot of zipping because spindashing is usually faster. Sometimes (such as in act 1-2) I stop to zip through a wall to purposely slow down, otherwise the game would forget to load the collision for the rest of the level and Sonic would die shortly thereafter.
AKA wrote:
Could you elaborate on the ejection algortithm a little more
There is a little more information about it here, but it's probably incomplete.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Wouter Jansen wrote:
so I finally figured out why I couldn't make save states that worked.. I use the Save As.. option
nitsuja wrote:
use the savestate hotkeys, not "save as"
Wouter Jansen wrote:
I've never successfully saved my own states so far
It sounds like you are just being lazy... Not that it isn't convenient to have a savestate available for those who lost theirs or don't want to watch the intro, but it shouldn't be a requirement. They are very large compared to a movie file (especially a compressed one), and most people can figure out how to hit the savestate button.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Does the emulator's menu still work, or is Mupen64 frozen too? If it works then you should be able to go to the input options and set controller 1 to not active. But, judging from your AVI, whatever is breaking is at a lower level (in Windows) than what the plugin has direct control over, so that might not work either. What kind of CPU do you have, by the way?
Yeah, who am I kidding? But I highly doubt I'll find any game that's better-suited for TASing than this one. The amount of things that worked out perfectly is astonishing...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
The only time I didn't use the camera hack was on the first act, which I already know is optimal because getting to the goal faster won't make the goal sprite load sooner. And I usually turned it off when Sonic was onscreen.
AKA wrote:
I seriously doubt we'll ever see a cam hack of the full version
At least one person has already captured it, and if that doesn't work out soon then I think Nach is able to encode it as well.
AKA wrote:
trying to optimize zipping glitches in any Sonic game is a nightmare
How do you mean? The ejection algorithm is simple and it usually doesn't put Sonic offscreen for very long. Of course it's easier when you can see what you're doing at all times, but it's not something that can't be tested methodically.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
moozooh wrote:
I take it no-one has interest in porting the camera hack for Linux
That's mainly because Bisqwit already did that and posted it on page 3. I think Nach missed that post, but I PM'ed him about it recently so maybe he'll have time for this sometime soon.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
It will still run at 60 FPS and be in English, so... why not E ROM? However... Zefiris should also provide a from-start movie that creates the SRAM he uses, even an unoptimized one, if he wants this to have a better chance of being published. Either that, or use the same SRAM made by the published MMZ4 movie (which I think will work despite being a slightly different ROM).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
NecroVMX wrote:
However runs that break the game to this extent should not "obsolete" runs that play the game perfectly, flawlessly and ARTISTICALLY.
...
Since I can see thsi problem is much worse than I thought, I'm no longer abstaining. I'm voting no.
But the run this would obsolete is almost identical for most of it. All this does is add a few more glitches and optimizations on top of a zillion others that are already in the published run. You're not going to unpublish the last 3 or so versions by voting no on this new one. Also, what is "artistic" is entirely a matter of opinion, and I'm sure this run is full of things that some people here would consider "artistic".
Warp wrote:
The point of a TAS is to produce results as close to possible as what a robot built to play games optimally would make.
Entertainment is also a big factor on top of that. I forgot to mention it as well, but I was making the assumption that if you can get the results as close as possible to optimal, then it shouldn't be too hard to also make sure it's entertaining whenever that can be done without losing time.
NecroVMX wrote:
One example of what I feel is the lessening artistry in TASes is the motto of "if it's faster to just ram into the enemy and take the damage than it is to skillfully dodge it, then do that" It's fast yes, but it looks bad.
It's up to the author to decide if it looks bad. Several published runs are in the "take no damage" category and were published despite being a little slower for doing that.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Dasrik wrote:
There's a jump in one of the levels that seems to be impossible.
If that's a problem you need help with, then you should be more specific so other people might take a look. (And if it's not a problem, then I don't know why you'd post that...)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Nibelung: Codes like that aren't enough to keep it out of the main section. Hard mode is usually preferred even if it takes an in-game code to activate it, and several normal published runs already use codes (suitless Samus, turbo mode, hard mode...)
JXQ wrote:
Hmm, actually, it has a negative connotation to me because of the way people treat the category. It seems that runs that are borderline accept/reject get the "publish as a concept demo!" suggestion, as if we're saying "Nice try, Billy. Everyone gets a trophy!"
If it's borderline accept/reject simply because it's a poor to mediocre run, not many people would suggest it be a concept demo.
Really, that section seems to be where movies belong that don't follow the normal goals of movies on this site, but are entertaining enough to be published anyway. That decision is made on a case-by-case basis by the publishers, so I don't see why it would need to be defined more clearly than that. (The only possible benefit I could think of would be to reduce the amount of arguing over whether a given movie should be a concept demo, but maybe that argument is a form of useful input in deciding where the movie should go.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Bag of Magic Food wrote:
Access Violation
While processing graphics data an exception occurred
you may need to restart the emulator
With what game and graphics plugins does that happen? It sounds like a plugin-specific problem so I would think you could find a combination of plugins that prevents it from crashing like that. There are some emulation options in the settings you could try fiddling with as well (things like recompiler mode or alternate handling of jump instructions) but I've never seen anything besides worse performance come out of changing those.
comicalflop wrote:
the expansion pak, which I'm not 100% sure if it's nescessary to play the game, but someone suggested that the desynchs myself and everyone is getting while I'm making it are caused by this pack...
The expansion pak simply extends the capabilities of the N64 by giving it more RAM. Thus there is no need to emulate it specifically, it happens automatically by simply giving the N64 enough memory, and there's no way to turn it off that I know of. It's possible that the bigger the game is and the more RAM it uses, the more likely the game is to desync, in which case there's not much you can do to keep a particular game from desyncing. (Unless you're capable of finding and fixing bugs in the emulator's savestate code.)
