Posts for nitsujrehtona

Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Phil: fceux addresses both. As time allows, I'll update the .98.xx series. Randil: That sucks; I'll change the way it handles those situations. What's actually happening is that the Lua engine is killing your displayer function, unregistering it, and letting the rest of the script continue. If you register it just once, rather than re-registering it every frame, you won't be paralyzed by an army of message boxes.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
No, it's just supposed to use OpenGL for graphics output (so your video card can do the scaling and throw in whatever other fancy effects). Forget the Pitch2 -> Pitch/2 change; it's 1.51-specific. Sorry for not mentioning that. If those bugfixes can't fix osnes9x for you, I give up...
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
We've identified a bug causing this behavior in any game which uses an MMC1 board and tends to VBlank in the middle of a write to the controller. The only released version I know of which fixes the issue is .98.15.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
It's there to look pretty if you let it eat enough hardware. Gocha, if you're interested in fixing the insta-crash that probably bit ShinyDoofy, it's not that hard. In unix/x11.cpp you init the colormap earlier and pass it to XCreateWindow(). In unix/opengl.cpp it's also a good idea to fix the incorrect GL version check. see here (for a patch against v1.51); only the first patch (the one in the second post) is relevant.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Thank you for these bug reports, klmz. Is it reasonably easy for you to check whether these "certain games" used the same mapper (or mmc)?
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
I spotted this game looking for cute titles for submission #20xx. Then I noticed the guns, grapple-ropes, and jumpkicks--this game could make a nice TAS! Unfortunately, I know very little about it. Did you go any farther with this project?
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Why did you spare the ship-segment that was on the screen around frames 30450 and 31350? Bits of level 7 looked a bit iffy too, when enemies escaped off the left edge of the screen. (Ex: frame 61650.) Overall, I liked this, but I want to hear more about how well you met your goals.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
ShinyDoofy wrote:
Will do so, as soon as I run into one. About the sourceforge page: fceultra.sourceforge.net seems to be the page of the original FCEU, not the one discussed here. Do they use the same bug tracker?
The history and nomenclature of all this project's forks can make me dizzy... but the "official" FCEU on that page is ours now! :)
ShinyDoofy wrote:
Here's the problem: I've got a german keyboard layout. I noticed that pressing my "-" key slows gameplay down (should be the slash key on a US keyboard), but I can't seem to speed it up again. Currently the hardcoded keybindings are my biggest problem. If these key bindings are gone, it would be just great.
Configurable hotkeys won't happen right away. The minus key is supposed to slow down the game (and + speeds it back up, as does = (+ without the shift)). If you don't have a backslash key, or the keybindings just make you mad, edit drivers/pc/input.c. Look for the phrase keyonly(BACKSLASH), and change it to something else. If you need a list of legal replacements for the "BACKSLASH", your system should have the file /usr/include/SDL/SDL_keysym.h -- open it up and look for words starting with "SDLK_".
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
If the game's thinking hard enough to lag all the time, why does it let you get away with all these tricks? I generally find this game painful to watch, but I like what you've done to it.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Nice showmanship vs. Cold Man and in Tengu Man's stage! I thought Parrot's handling of the "memory game" in Astro Man's stage was way more amusing... Did your strat save time over doing the same with Forte? The trick after the boss made up for it anyway. :) Clear yes vote, overall.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Hmm, it also fails to identify as 0.98.28 when you open the about box... Because I shipped the wrong damn binary. Sorry for the inconvenience; please re-download. (The source code was current.)
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
If you worry about annoying me, Shiny, you needn't. I hope you'll also be reporting issues with FCEUX/Linux; it'll need testers. If you worry about annoying anyone else, feel free to PM me or submit bug reports to the sourceforge tracker. Anyway, the usual way to get out of frame-advance is to hit the pause button (probably the backslash key for you). Eventually I will want to make those keys configurable and make the frame-advance key autorepeat! Outdated docs are actually a big deal. Adelikat is working really hard on that issue for FCEUX/Win32; once he's done, it should be straightforward to get the Linux port documented properly.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Yeah, that code calls gui.text() (drawing before the .frameadvance()), then passes its output to gui.register(). This is not what you want. Outline of this function's intended use:
local function draw_position()
  xpos = memory.readbyte(...)
  ypos = memory.readbyte(...)
  gui.text(xpos, ypos-8, xpos)
  gui.text(xpos, ypos, ypos)
end
gui.register(draw_position)
So you pass just the name of the function into gui.register(), and you make sure the function updates the values of xpos & ypos before drawing stuff. Hope that's helpful.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
The FCEU Lua API is almost identical to that of snes9x-lua v0.05. You test for equality with the == operator. Dealing with the one-frame delay is the purpose of the gui.register() function: pass it a function that does the drawing you want to show up with *no* delay. It should behave exactly according to DeHackEd's description, but I haven't tested it thoroughly and have no useful sample code. Happy hacking! :)
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Please re-download and pretend I never made that mistake. =)
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
FCEU-rerecording 0.98 & source CHANGES bug: movies of script-generated input desync'd bug: dead scripts' graphics overlays persisted bug: argument order for memory.writebyte didn't match API docs bug: Lua's memory functions couldn't read from ROM bug: bot.html was missing from the binary release bug: diagnostics were suppressed when loading a script failed bug: memwatch crashed when given addresses before any ROM was loaded enh: memwatch allows longer labels. (If you save a text file with long labels, don't open it in an earlier version.) enh: HUD font altered by Zeromus so digits are fixed-width. (No old font though--sorry.) enh: hotkey to reload a Lua script (defaults to Shift+L) enh: dumps have their own folder enh: Linux version recognizes the command-line options -playmovie <file>, -loadstate <file>, -readonly <0>, -stopframe <#>, -muteframeadvance <0>. If you need a larger address limit in FCEU .98, I can help you, but I'm not doing it for this version...
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
You're missing his point. Of course there's a maximum which can't be exceeded, but that doesn't mean repeatedly adding a near-constant acceleration will cause overflow. Instead, the exponent would get so big that the acceleration would round down to zero when you added it in...
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Alden: The bots are progressively relying less on savestates and more on the heuristics. UraniumAnchor's doing some great work on synthesizing all this info and using it for game play! The scripts track enemy locations but currently don't have accurate hitboxes; I hope to fix that, but it's nearly irrelevant for decision making... uh, except with platforms. :)
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
.98.27-compatible version of the SMB tile scanning script: here.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Neat! :) I was just thinking that SNES Tetris Attack (vs. mode) could be a good target as well, especially since a bot could equally well control either player -- it'd be trivial to have a driver script set up a bot-vs.-bot contest. Playing (and menu navigation) could be tough, but all the information that's essential for gameplay is easily obtained: Display-script (It'd be nice to know the VScroll offset / time 'til next line arrives. Or what the next line is.) I'd better get back to work on FCEU/Mario. :-P Anyone want to see this taken farther after that?
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Agreed; let's take the bots here.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Continuing discussion of SMB-bots written in Lua (around here): Wall-ejection to the left apparently kills the current "has Mario stopped?" logic. Warp zones would be worse. But for now, let's get the script past a castle: $35 is nonzero only when the sequence with Toad starts. It gets reset pretty quickly, but the script could watch $075F (world #) to figure out when it should resume playing.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
I'll look into the misbehaviors reported on this page, especially that last one. A bugfix release is already in the works because of other mistakes I made. (I won't fix all the new issues though; sorry in advance.) Shiny: FCEU "remembers" past command-line arguments; is the problem fixed simply by passing "-sound 1"? Anyway, you'll find movies easier to play once I merge (parts of) Bisqwit's patch. UraniumAnchor, thanks for playing with Mario. I'm also working on the SMB scripts, but my new stuff is broken with .27 (because it reads some pointers out of ROM). It can detect and draw (but not react to) tile data:
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Yeah, require() is magically easy! I'm working on a demo of using it and coroutines to run several scripts at once (but for FCEU). And I know what you _asked_ for regarding input... the less powerful alternatives I suggested would require less invasive changes to the emulator, which is kind of important for an out-of-tree patch to an actively developed program maintained by one person with finite time... (This is also why I'd be satisfied if something like memory.register("X", func) was never supported...)
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Close. XOR(n) is also n -- the result of XORing a bunch of bits (1-bit #'s) is 1 if there are an odd number of 1's. (Sorry for derailing the topic :-P)
IRC nick: UncombedCoconut