Posts for nitsuja


Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Why not do it on hard mode? I think you should... Also, are you going to be doing "highest score without slowing down", or just "highest score"? It might get pretty boring if you slow down all the way at every single group of enemies just so you can kill a few more of them before running by. (Hitting something doesn't count as "slowing down", only letting go of the Up button while running does.)
qFox wrote:
with a sloppy start (my keyboard is unable to press 4 buttons at once so I cant hold up+left+start+frameadvance, so I just wasted a 100 or so frames at the beginning)
There are several ways of working around that, such as reassigning your Start button or the frame advance hotkey, or using auto-hold.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Wouter Jansen wrote:
I'd like to friendly request if you (or someone else) could also make/post savestates for each wip that starts where the wip before it ended. I tried to do it myself, but it didn't work.
What, making savestates doesn't work on your computer or something? It should be fine as long as you keep at least one savestate before any part that's going to be redone.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Rising Tempest wrote:
(turn around = lose speed)
That's the main downside of the control scheme you're using, I take it?
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
It wouldn't use the accelerator table. The configurable ones already don't. If they don't use WM_COMMAND they probably use WM_KEYDOWN or check the input some other way, it shouldn't make too much of a difference how the message gets there.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Hard Mode B (4x), hold Up + Left, press Start (at screen before game begins)
Other
Increased luck: Press B(4), then hold Left/Up and press Start to begin game play.
I wonder if they've actually gotten it to work...
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
But aren't some of the hotkeys already configurable, such as the quicksave and quickload keys? It might not be pretty, but if you're looking to avoid coding a new input checking routing, you could simply duplicate the code those use, and delete the corresponding keys from the accelerator table. (It should be rewritten to be better, though.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Sorry, I didn't see that post before. If you're still looking for an answer... it actually uses Bloodshed Dev-C++, although that uses MinGW so both should work. The error you posted looks like it can be fixed by making sure vcr.h is included. That should contain:
#define MOVIE_AUTHOR_DATA_SIZE (222)
#define MOVIE_DESCRIPTION_DATA_SIZE (256)
#define MOVIE_MAX_METADATA_SIZE (MOVIE_DESCRIPTION_DATA_SIZE > MOVIE_AUTHOR_DATA_SIZE ? MOVIE_DESCRIPTION_DATA_SIZE : MOVIE_AUTHOR_DATA_SIZE)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Check.
EXPORT void CALL ReadController ( int Control, BYTE * Command ) {}

...

for (BYTE i = 0; i < NUMBER_OF_CONTROLS; i++)
	ControlDef[i]->RawData = FALSE;
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
It's been mentioned a few times that people want an input plugin that's better for making TASes. I realized this should be pretty easy to do since some existing input plugins have source available that's free to use for anything. So what features do people want, again? UPDATE: Here [adelikat]: Updated link with a current one. Everything but the combo system is functional. So far it has only been tested with Mupen64 0.5 running on Windows XP. It's based on Def's DirectInput plugin. To use, move or copy "TASDI.dll" into the "plugin" folder where your emulator is, then open the emulator and choose "TAS Input Plugin 0.6" in the Input Plugin part of the Settings. Then you'll want to configure the buttons before using it, like any other input plugin. When you start a ROM, a control panel should appear for each active controller. If the main emulator window doesn't get focus when you click on the panel, click on the emulator once first, then on the input panel, and it should remember it after that. You might want to turn off the "Pause when inactive" option in the emulator, if you don't want it to pause whenever you are dragging the panel around or clicking on a button. The "Instant / Relative / Radial" buttons change how the keyboard (or joystick) controls the analog stick. You can also left-click and drag on the analog stick circle to set the stick position, or right click once if you don't want to drag the mouse to keep controlling it. The sliders on the right are multipliers for X and Y analog stick intensity from the keyboard. To reset the multiplier to 100%, right-click-drag on the slider bar. "Ang. Disp" stands for "Angular Display", which changes the X/Y display into Angle/Distance. You can manually edit the numbers for X/Y or Angle/Distance, but if you do so, remember that other input is disabled while you're editing it, until you hit Enter or Escape to return focus to the emulator. The game buttons (A,B,L,R,Start,etc.) can be left-clicked on for auto-hold, or right-clicked on for auto-fire. Known bugs:
  • If you're using a joystick, you'll need to set the max range to 127 instead of 128 in the settings.
  • Sometimes the X and Y range sliders start at 1, so you'll have to set them higher before you can move with the keyboard/joystick.
  • Autofire doesn't work in many games yet (timing issues, since the plugin has no reliable way to tell what frame it is)
  • It doesn't show movie playback input (not really a bug because it is the plugin specification that lacks any way of supporting this)
  • Combos don't work yet (because they haven't been implemented)
  • If you spastically click the show/hide buttons the panel may eventually stop working.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
I'd start out more like this, with less jittering and more diagonal movement. Somehow I'm 18 frames faster, I don't know where those came from. [Although the main differences are a much higher score and more trick-jumping.]
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
comicalflop wrote:
I'm also playing by turning mute on, will this solve desynch problems?
Check your PMs. I sent you one a couple of days ago.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Did you copy your saved game file to where PJ64 can see it? You should find it at someplace like "mupen64\save\BANJO TOOIE (USA).eep", which probably isn't the same place as your PJ64 saves directory.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Sami: Did you test if it's faster to leave the 5th jiggy you took until later, so you can take a detour to get it with the termite to avoid the dance animation?
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
It'd make a good speedrun for sure, but for a TAS would be pretty boring. You can run diagonally as much as possible to make it seem faster, and do double-jumps on top of columns, but it wouldn't make the run any faster than just holding up most of the time and jumping when necessary.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
TSA: I agree it could have / should have been better. But I disagree that it would have taken "just a bit more time" to do it. I'm amazed that it was finished at all and that it was published. Getting a run out there makes it easier for other people to improve it in the future, and some people found it entertaining to watch, so I don't see how it's hurting anyone to have it published.
TSA wrote:
Seriously, some of you guys need to check your damn attitudes at the door, and stop having this damn "mental" hate against me for whatever reason.
I'm sorry, but there's more attitude showing in that post than in everyone else's [earlier] responses combined, which is really only aggravating the situation. Just ignore it if someone is flaming you or whatever.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
A camhack for an N64 game should actually be easier to do, since you could simply tell the graphics plugin to turn its camera around (when it gives it to OpenGL/whatever) to get a different viewpoint . Of course, that requires having the source to the graphics plugin, and a run that doesn't desync when using it normally. But, I don't know why so many people think the backwards view makes it boring. I think it makes it more entertaining to see things appear next to Link as he runs by, instead of seeing them in the distance as he approaches them, and it adds another thing to distinguish it from normal playing.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Randil wrote:
But I don't understand what you mean when you say that it "works in both directions", you can only run right with the left+right glitch.
I guess I misread this sentence: "if you press down when running with left+right, you will surprisingly enough dash left"
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Randil wrote:
I personally think that the left+right glitch makes a run of this game more interesting and fun to watch. It is my opinion that this should either obsolete the current movie, or get published individually.
I think the only reason to not consider that would be that the left+right glitch seems an awful lot like a debug/testing feature, since it's so convenient and works in works in both directions. (But, I thought the same thing about the latest TMNT2 movie, looking at the range of things in the "Glitches" section of that description...)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
OmnipotentEntity wrote:
However, v1.1 has the changed Fire Temple music and the less stabbity ending, and more green blood. :(
Aren't those changes only in v1.2? Or, supposedly there are different versions called 1.1:
Wikipedia wrote:
Version 1.1 is known to have two variations, one with green blood, and one with red blood.
EDIT (off-topic): funny video, (nevermind the ending) if you've never seen an Arwing in a Zelda game. Too bad there's no way to make it appear without using a cheat code.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Already have, more than once. I won't be able to do it.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Although there's no such emulator, there has already been a TAS of a GameCube game.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
I think it affects the Game Over screen too, although obviously that happens less often than the pause screen. It's likely that the "fix" in Project64 is a hack, applying a cheat code to that game to reduce the time the pause screen takes to come up... not that these emulators don't have a lot of hacks already, but it's just a myth that modern N64 emulators don't use low-level emulation at their cores.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Ash Williams wrote:
I know windows has functions to send keys to a process, but I really would like to find a better way, and still not modify source code.
I doubt you'll find anything closer to what you're looking for (for Windows) than the SendInput function. That won't work for some cases though (for instance, if the emulator uses DirectInput to check keys). What about the problem of synchronizing with the emulation? You could make it use frame advance to control how many frames go by, but this is sounding extremely inefficient, for minimal benefit...
L4yer wrote:
Humans can make intelligent decision independently, a program can not.
Not to go into too much detail, since that's not the point of this discussion, but that's highly debatable...
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
What's so bad about correcting someone's spelling? It's not a personal insult, it's just pointing something out for future reference. (And for all I can tell, Xkeeper was just joking about being really angry; it's not as if emotions come through very well in text.) Anyway... what sort of runs are being done again? Fastest time is probably the tornado-heavy one, so what are the goals of the hammer-using one? "Fastest time without using Tornado"? Or is that one being scrapped in favor of a no-powers run? (Hmm, what about not using Mix as a limitation, if there needs to be one?)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
AzHP wrote:
Turbo shouldn't affect anything...
It shouldn't, but when a game waits for a sound to finish playing before continuing (or otherwise reads the sound output and uses it), it does matter because Snes9x (unfortunately) plays the sounds separately from the emulation. So if you're fast-forwarding at one of those times, or have a different enough CPU, the game ends up waiting a different number of frames before continuing, causing a desync. That's what the "fake mute" fix is supposed to prevent. In the case of this particular game, it has desyncs for another reason, which happen if you load a savestate that was made on certain frames. So fast-forward shouldn't matter for that. What could matter is whether you save on odd or even frames, if the "bad frames" to save on follow such a simple pattern...
comicalflop wrote:
Gangplank Galley: None
What about the very start of the level? You roll under the barrel for no apparent reason before jumping onto it. And using Dixie might speed up the part after getting the DK coin.