Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
OgreSlayeR: I don't think the save file could be relevant; Mupen64 clears all .sra, .eep, and .mpk files corresponding with the ROM being loaded when it is about to play a movie. If it didn't do that, you wouldn't even be able to watch a Mario 64 movie twice, because the second time would load a saved game instead of starting a new one.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I agree with Baxter about the decimals. I'm not sure what to vote when either category is almost perfect, better than a 9 but not a 10. I round it, but I would give ratings like 9.4 if I could. When something has a 9, then someone improves it and makes it know that it could be improved further, it obviously shouldn't go to a 10 but it deserves higher than it had before.
Warp wrote:
Perhaps a page could be written outlining the basic ideas behind the two rating categories? If there's any interest, I could write some kind of draft and post it here.
It couldn't hurt, but keep in mind that so far all (3) of the responses to your previous post have been disagreeing with [part of] what you said your basic idea of the technical rating is. If a run is really framewise perfect, then it deserves a 10 for technical rating by definition. If it required so little ingenuity to make it perfect, then that would show in the movie getting a low entertainment rating. I know most people aren't qualified to judge how perfect any given movie is with any accuracy, but I think it's more important for them to pay attention to the movie than to what its author says about the movie's creation.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Isn't that completely different from the intended use of the technical rating? I've wondered why some runs that most likely can't be significantly improved have a low technical rating, and why some runs that have large known improvements have an average technical rating higher than 9. I assumed the cause was category cross-contamination, but maybe it's really because of the technical rating being interpreted differently from its stated definition.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Neither do I. You seemed to be running this without problems before. Is it happening at a certain place in the game? Have you tried it with different plugins?
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
The Game Gear would choke on Sonic 1 without some huge sacrifices (like the ones they already made when they made the 8-bit Sonic games). Though the physics in this "port" do remind me of those a bit.
Huh... Disabling music in the options makes a bigger difference than I first thought it did. Green Hill 1 became over 4 seconds faster, and the act still took 12 seconds by the in-game clock. It looks much smoother, and the background stopped glitching out, as well, but as subpar as the music was, it sounds rather empty now.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Wow. They obviously didn't finish this before releasing it. It would make a fast and funny TAS because the physics are so different and broken this way, but the lag is just awful.
Here is my attempt, until I stopped somewhere in Marble Garden 3. It could be more optimized, but whatever. Even with the spindash and all of the other changes that cause Sonic to move faster and the ability to skip bonus countdowns, it would still probably be slower in real-time than a run of the original.
EDIT: Turning off the music seems to help a little, but not much.
To add to what JXQ said is different:
speed shoes don't let you go any faster
loop jumping doesn't work at all
Sonic jumps higher
jumping no longer reduces your speed at all
jumping on upward slopes to jump higher barely works
jumping out of a roll leaves you in full control of movement during the jump
you don't stop moving when you land after taking damage
damage always knocks in the direction you're not facing
you can't bounce high off of item monitors or enemies
you can't push blocks during a jump
bosses don't reverse your speed when you hit them, instead it matters where you hit them
bosses push you away when you hit them even if they're still invincible
zipping doesn't work anymore
if you press in the direction you're already moving while running backwards, you instantly stop
in general, when moving at a high speed, the only effective way to slow down is to press forward (in the wrong direction)
you can jump into and out of lava or fire without taking damage
if you beat Labyrinth 3 too fast, the game freezes
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
petrie911 wrote:
Incidentally, how DO you quickspin on emu?
How to quickspin (reposting from other thread):
- Hold in each of 3 directions for 1 frame each, then press B + the 4th direction on the next frame.
- By 1 frame I really mean 3 input frames. So it will take ~12 frame advances.
Example of keypresses: Hold left and press \ 3 times. Then hold down and press \ 3 times. Then hold right and press \ 3 times. Then hold up and hold the key for the B button and press \ 3 times. Then unpause and watch Link spin. Repeat until dizzy.
to return them to the default. And of course you can change those values manually if for some reason you can't set them in the emulator. You should probably close Mupen64 first whenever you edit that file.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Hmm, this thing with including the movie name in savestate filenames is really annoying in some cases. While I'm watching a movie, I make a few savestates, then I close the movie because I don't want to screw up the movie while I'm experimenting, and then when I try loading those savestates it instead loads some completely different savestates from the ones I just made.
EDIT: It's not so bad that it can't be worked around when it gets in the way, but perhaps there should be an option for it.
EDIT2: Oh, and it's not a new bug, but look what happens if you choose "Screen Shot" from the menu instead of pressing the hotkey for it.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
CBright wrote:
... I've done some tests timing how much faster emulators run ...
It matters which emulator(s) you use. They are programmed independantly and thus can (and do) have different timing. However, the CPU is emulated as closely as possible to the original (at a low level, based on how the original behaves), and Mario 64 is probably the most accurately emulated commercial N64 game overall. On the other hand, even SNES emulation isn't perfect yet, and N64 emulation certainly isn't.
CBright wrote:
I suspect that the upcoming virtual console emulator will also remove some lag
I doubt it would. That constitutes innacurate emulation, and similar things in the past (such as PS2 emulating PSX games) have not attempted to reduce lag that was present in the original, despite adding other optional features.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Did you know you can hold R to turn faster while flying? Also, did it save time to punch those crabs inside the shell before getting the jiggy?
WR = world record console time. The fastest 100% record I can find for that level is 9'36'' (here).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
It seems that loading a savestate now blacks out the already-drawn graphics (either by clearing the pixels or by setting the palette to black, I don't know which), which is a problem in places where a game shows a static image or playing field instead of something that can scroll, because the game doesn't update it and it stays black until the next scene change.
EDIT: this has been fixed
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Vidar wrote:
Whenever I tap my frame-advance key (R) it will advance a frame for the most part, but sometimes mupen will register a tap as "hold the button down for 30 frames or so" which makes the game play at 100%< speed which is odd.
That sounds like intentional behavior; if the game isn't checking input for 30 frames then frame advance will zoom past those 30 frames for you because they don't matter.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Baxter wrote:
I'd say lag is very noticable when using frame advance. Lag is way harder to detect when using low speeds.
I guess you haven't tried minimizing lag in an N64 TAS. Frame advance skips over lag frames, so you can only notice it on playback or by watching the frame counter. Maybe frame advance should be given a configurable framerate, because there's no way for the emulator to tell the difference between a frame of lag that is supposed to happen (which is every other frame when the game runs at 30 FPS) and an additional frame of lag that could be avoided.
laughing_gas wrote:
That makes sense, but when you do the BLJ in BOB, do you press A every frame the elevator goes up or every other frame? If you press A every frame, the game thinks you're holding A so the BLJ doesn't work.
Right. The fastest you can possibly press a button is every other frame. Although BLJ requires even slower than that sometimes, because Mario can't jump again while his feet are still in the air from the last jump.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Truncated wrote:
Probably because Ctrl-T was not documented anywhere, and/or doesn't show up in the hotkeys dialog where people could have found it by accident. I heard about it only by word of mouth and this seems to be the case for most people.
Well, it was in the post of the version of Gens that added it, and it's in the readme file which apparently nobody reads, and I think it's somewhere on the emulator features page (it should be added if it isn't already).
Truncated wrote:
upthorn wrote:
When Automatic Close Movie is unchecked, and a movie is open read-write, resetting will rerecord movie from start (even if movie had finished playing)
This behaviour sounds very dangerous, and not something you would ever want to do -- you would just start a new movie file instead.
I don't think this feature is useful either, but it's probably not as dangerous as it sounds. You can clearly see that the game has reset, and if you don't intend to start over your recording then you'll load a savestate when you see that. It's only dangerous if you panic and overwrite all of your savestates, or if you weren't using savestates.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
AKA wrote:
all the input seems to be stored in a m64 permanently so you can't erase parts and hex edit stuff in
Again: what? These are the only tricky parts about hex editing an M64, most of which aren't really tricky:
The frame counter in the emulator shows 2 types of frame counts (video, and input). You have to use the right one or you'll be editing in the completely wrong part of the file.
You should do the editing while the movie is not open in the emulator, otherwise the emulator will keep using the unedited copy of the movie that's in memory, like with SMV or VBM.
Each 'frame' of input is 4 bytes, you have to know that. But that's easier than GMV's 3 bytes, because most hex editors can group by 1, 2, or 4 bytes at a time, but not 3. You also have to add in the header size, of course.
If you increase the length of the movie, you have to increase the frame counts in the movie (see above link), like for SMV. But presumably this won't be a problem since you're trying to make the movie shorter, not longer.
EDIT: Sorry; I misread your post. Well, I hope the above info is useful to someone. Leaving the input at the end of the movie file is sometimes helpful, sometimes not. In this case it means you need to convert from VIs to bytes one extra time to know where you should paste the input at.
AKA wrote:
but the game should be good because there is almost no randomess in terms of the setup of the paint worlds.
I think FODA explained what would desync, but I can't remember it out of these 100 pages. You're right that it shouldn't be a lot in this game, but I wouldn't be surprised if it would mean he has to redo 20 stars (and go through a bunch of hex editing sessions) just to change one star early on.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Hex editors can edit anything, why does everyone keep saying M64 movies can't be edited? I think it's possible to fix previous stars, based on the way I've seen this game run with Spezzafer's movie until near the end of Bowser 3 without desync when a small change was introduced at the start. But this game seems to have some randomness with (at the least) enemy movement, so you would need to redo a few other stars in addition to the ones you change, probably more than you would think.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Minor bug that I somehow didn't notice before: Changing the "Data Type" in the RAM search window doesn't update the displayed values accordingly, although you can click on something in the "Data Size" section to make them update. (I am posting this here in case someone wonders why changing it to Unsigned or Hexadecimal appears to do nothing.)
Also, the title of the "Changes" column no longer fits, presumably because of a widened address field, so something else should be adjusted to let it fit.
And the Edit Watch button has some problems:
- It duplicates the address being edited, which can cause other problems later.
- It doesn't update if you only change the address' notes.
- It doesn't allow you to enter lowercase characters in the notes, unlike the one from the RAM search dialog. New Watch does the same thing.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
xoinx wrote:
Just curious, would it be possible to add a 'movie preview' function? For example, after playing maybe 100 frames, I can set the movie to play back the last 100 frames in real time so I can see how it looks?
You can already do this by hitting Ctrl-T to switch to read-only and then loading a savestate you made before the part you want to watch. I suppose it could be further automated if it constantly made savestates for you...
JXQ wrote:
And frame advance becomes continuous immediately (or near-immediately)
I mentioned that in the post above yours, but at least that confirms it's not only happening for me.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Will the source be available somewhere? Also,
upthorn wrote:
[*]Tweaked the timing of continuous frame advance (courtesy of Nitusja)
I think this change didn't get into that executable or was further changed from the last time I saw it, because it is behaving quite differently (much too fast) in that gens_movie_9Z.exe, whereas it has a longer delay in the executables built from what's currently on SVN.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
bkDJ wrote:
easy to implement? Wouldn't that be a video plugin thing and not an emulator thing?
The emulator has to updates the counter of rendered frames somewhere, so it knows when a new frame is being drawn. It's possible that the easy implementation will cause you to miss a frame or two whenever the framerate increases, and of course you will miss any single-VI opportunities that don't correspond with a new frame being rendered, but in practice I don't know if either of those will be a problem. N64 games almost always make you wait for some menu animation before you can use menus, and every game I've tried that runs below 60 FPS either queues up or ignores your input until the next visible frame anyway.
Fixing synchronization issues, of course, is quite difficult. Especially in a relatively slow emulator that lacks debugging features.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
upthorn wrote:
Now all that's left to do before the release of Gens_Movie_9.5 is to compile a list of the new features...
No 9k and onward? Let me check something first though, one of the RAM search features just struck me as wrong (and easy to fix, if you haven't already changed it).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Bisqwit wrote:
I have reopened the category changing to editors.
Something seems to be wrong with the link for editing anything about movies. Right now the link says "Edit text" and prompts to create a new page titled with the movie number.
