Posts for nitsujrehtona


Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
No. AND() is 0xFFFFFFFF (or 0x7FFFFFFF if signedness is too scary); OR() and XOR() are 0. That way rules like AND(list, v) = AND(AND(list), v) hold.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
muxum wrote:
regarding input: it would be nicer to have full joypad access (if you have a joypad with 10 buttons 4 axes...) not only the snes keys because those r usually already used by the game and keyboard input would be nice too
Would a few "script control" hotkeys (and the abuse of, say, controllers #3-#5) be enough for your purposes? That'd be easier to add in a portable way. I'd really like to see CPU registers added to the memory.* functions (or at least the ability to register() PC and read the others). Heh, I'd also like nullary AND()/OR()/XOR(), even though they're useless. (Right now the bitwise math functions go out of their way to fail on zero args.)
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Whew, that's a tricky one. Is the value indicated by 7E:051F of any use?
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Workaround for Shiny: Symlink $HOME/.fceultra/movie/basename.1.fcm (basename being your ROM file's name without the suffix) to the movie file. I'm not sure when I'll be playing with FCEUX... Eventually I'm sure it'll make this easier.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
ShinyDoofy wrote:
Great to see it compiles! :) Yet, the key binding are hardcoded, I guess (src/drivers/pc/input.c) - is there a way of changing them (without having to recompile) or even using a joypad? The rather old Win32 version (0.98.16) I'm running via wine runs relatively well (size multiplier >2 and it's starting to slow down), but not perfect imho.
Hotkeys are hardcoded in that source file. To change the game controls, try "fceu -inputcfg gamepad1 <ROM file>". You should be able to supply one or more keys or joypad buttons to bind to controller #1. (But you can't override the hardcoded hot-keys.) And thanks, swedishmartin. :) Good luck with the scripting; I'm sure you'll have no trouble picking up Lua.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
I like writing scripts, so here's a script. SuperRType.lua.gz I assume it's unhelpful for making a TAS; if I'm wrong, let me know and I'll refine it. Otherwise, I'll leave it as-is because snes9x/Lua doesn't let you read CPU registers (yet), the game's internal design is *crazy*, and it's already drawing me some amusing eye-candy. :) Good luck with this, Dave.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
OK, here's a FCEU 0.98.27 release. W32/Linux x86 Binary Source Changes:
    Include mz's sound-sync & wrong-movie-check fixes Use up-to-date Win32 input code (to fix disabling UD/LR?) Fix the squished movie replay box (Thanks, mz!) Fix graphical overlays during frame-advance. Sacrifice color-blending quality to make transparency and gdoverlay usable. Extend memory functions to support the same addresses as FCEU's cheat search (hopefully correctly!) Stop unloading scripts when a ROM is re-opened Credit DeHackEd in AUTHORS (in case he cares :)) Win32: Pause the emulator's sound before opening message boxes Linux: Don't spam players with "not implemented" messages
If minor problems with memwatch still exist, they'll have to wait for FCEUX. Under Linux, the speedmode stuff only works if you turn sound off. Haven't tested movie sync either... Oh yeah, the sample scripts got updated (partly because I wanted to test more stuff). Poor Mario... the coin ledge is even deadlier than the koopa.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Thanks for catching those problems; next release will fix them. Would you please try editing drivers/win/res.res with Microsoft's tools? I just want the resources from v0.98.26 with this addition to new FCEUMENU -> FILE menu items (preferably keeping these numeric IDs -- *gags in general direction of drivers/win/window.c*)
    MENUITEM SEPARATOR
    MENUITEM "Run Lua Script...", 40036
    MENUITEM "Stop Lua Script", 40037
and a Lua dialog that looks something like this:
"IDD_LUA_ADD" DIALOGEX MOVEABLE PURE DISCARDABLE 0, 0, 186, 76
STYLE 0x80c808c8
CAPTION "Load Lua Script..."
FONT 8, "MS Sans Serif"
BEGIN
  DEFPUSHBUTTON "Load && Run", 1, 70, 55, 50, 14, 0x50010001
  PUSHBUTTON "Cancel", 2, 129, 55, 50, 14, 0x50010000
  EDITTEXT "", 1096, 7, 17, 116, 14, 0x50810880, 0x4, 0
  PUSHBUTTON "Browse...", 1359, 129, 17, 50, 14, 0x50010000
END
Or else PM me if you know how to get wrc or *-mingw32-windres to behave sensibly.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Ewww... can you just compile with -m32 as a workaround?
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Here's a WIP version FCEU 0.98.26 + sound-hack + Lua API v0.05 (with snes9x.* renamed to FCEU.*). The WIP includes a source folder and a bin folder containing a few test scripts, Linux & Win32 builds, and a lua51.dll. In the Linux version you can hit "L" to load a script. click Boring caveats: I intentionally limited memory watching/writing to addresses in main RAM (0x0000..0x07FF), for now. I suspect the "maximum" speedmode isn't aggressive enough yet. None of the speedmodes work right in the Linux build. (I also suspect frame-skipping could cause desyncs because it's implemented very differently than under Windows.) I think I "squished" the movie-replay dialog. (Can someone confirm?) If so, this is tough to fix, because mingw's windres and Wine's wrc are inadequate for editing .res files. If you pass an integer as a color, it's treated as a palette index rather than an RGB565 color. Finally, I don't know whether any of the functions work right while you're recording a movie. On my computer, starting to record will make FCEU seize up within a second or two... go figure.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Gradius 3, on the other hand, was exactly as hard as Warp made it sound. But part of the problem was that the player's hitbox didn't vary in that game. In most platformers it's probably feasible to find your own hitbox with cheat search, and then convince the emulator to trace through the game and flag relevant subtract/compare instructions...
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
I second this request -- it could get to be a pain if I port this to FCEU and fix certain old bugs in a different way than you did. (I figure the setup will be refactored once it becomes clear how the code can be shoehorned into all the supported emulators,. That'll be easier if the code doesn't diverge first...)
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
ShinyDoofy wrote:
I can't seem to ./configure the current version: Hints, anyone? :)
It's because of DOS-style line termination in various shell scripts. (bash reads the embedded carriage returns and vomits forth weird error messages.) You can try deleting a bunch of shit first, then running aclocal; autoconf; automake -a -c --foreign. I'm working on hacking basic Lua support into the emulator now (goal is to get something that is useful and works like a subset of what's in snes9x, to make it easier to synchronize with DeHackEd's newer unreleased s9x+lua source code...) Currently I'm writing test scripts to see whether I've created exactly that or just some program that compiles. :) If everything goes well I'll release my patches, and they'll include fixes for Linux compiles and Linux->Win32 cross-compiles...
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
ShinyDoofy wrote:
I copied them using my still existing XP installation and I still get the same errors.
That's odd. It worked for me if those DLLs are placed in either the same directory as "vba-rerecording-19 3.exe" or the current directory from which you run wine.
ShinyDoofy wrote:
Now I didn't even seem to get a binary.
The patch didn't include the Makefile changes you'd already made--that's all.
ShinyDoofy wrote:
I do get a binary and now was even able to watch submission #1975, up to the third level of the tree zone. On that very first run, the game was running at perfectly normal speed (fluctuating between 98% and 103%). After it desynced (after getting the mushroom in that particular level), I restarted VBA and bam, fast-forward again. :(
I also get the desync (no idea...) but not the fast-forward problem. Don't suppose you have a VisualBoyAdvance.cfg that it's reading? Or that passing "--throttle=0" helps?
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Hilarious. Loved it.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Saturn wrote:
Yeah, I obviously had to add a few frames to my real accomplishments in this rooms to not spoil the tricks I used in them before the final run.
Yeah, obviously! Well, to avoid being forced in the direction of modesty like that, you could try talking shit about entertainment techs rather than just time-saver techs. It's easier to talk about those without actually talking *about* them.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Right idea; wrong link. OS X binary, 1.43-WIP1 ; OS X port source, 1.43-WIP1 It won't work with every smv on the site: desync is guaranteed if a movie hits L+R/U+D or uses resets. The portable CPU cores and lack of sound-related sync options will cause less predictable desyncs. Fireside, the Windows version will probably run at full speed (under wine, for instance). If you know how, you can also compile the source code linked above into an Intel-native version of what you're using now. Michiganbusiness, let me know if you have a PPC Mac and need more help.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
The main problem here is that "WIP1 Timing" (which virtually all non-1.51 movies on this site use) actually means the timing used in snes9x-1.43-wip1 (a "work in progress" release that predates 1.43). You will get a lot of movies to sync if you can get a port of this version. The other options you mention won't be in that official release either, though; so you might need to fool around a bit with the source in order to get an OS X native app that can play all the movies you want. If you have a PowerPC Mac, rather than an Intel Mac, also keep in mind that this site's builds of snes9x use "[x86] ASM CPU cores", which are not entirely sync-compatible with the portable versions written in C that you'd be using. So you might get stuck with desyncs you can never fix. On the other hand, if you have an Intel Mac, you can probably get the Windows binary version to run at full speed. Watch out for the "sync sound" option, which may cause the emulator to seize up and eat up all your CPU time for up to a few minutes at a time (because it expects your OS to handle threading exactly as Windows does). Aside from that problem, this solution is likely to be *much* easier for you.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
mfc71.dll and msvcp71.dll are standard MS runtime libraries. Google them and you'll get safe download links; I'm pretty sure that's perfectly legal. The last string of errors you got was for building TestEmu, not VisualBoyAdvance itself. No idea about the fast-forward issue... that sucks. You need all of the code changes I mentioned for VBA to (a) not crash and (b) accept a movie's input when you supply the --watchmovie switch. Sorry about assuming C++ knowledge you didn't have. I threw a crappy patch on this crappy file host: http://www.fileden.com/files/2007/9/22/1451488/vba-rerecording-19-sdl-cpp_changes_only.patch. It contains the changes I made to the C++ source (not makefiles). DeHackEd or somebody might have a more complete solution for Linux, BTW. Chances are that nobody's ported the TAS-making features that Nitsuja added, though.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Here's a way to make it compile. To make it work, build for Windows and run under Wine. I haven't run into any unbearable bugs. (I'm half-kidding: these steps made at least one movie play correctly.) Yeah, just alter src/sdl/Makefile.* to include movie.cpp as well. (Just searching for an existing source file like bios\. and mimicking what you see is a quick&dirty solution.) Then fix the Windowsisms in src/movie.cpp: _MAX_PATH -> PATH_MAX ... err... actually, 260. Trust me. stricmp -> strcasecmp Kill the line with MOVIE_SETTING_REMOVEINTROS (it doesn't matter what you do to it -- the flag is unused because in v19.3 this isn't a per-movie setting anyway.) Then add new features to src/sdl/SDL.cpp that appeared in the Windows port: Make systemFrame() take an int param. Declare sensorOn ("bool sensorOn = false;" at global scope) and make systemReadJoypad() update it ("sensorOn = sensor;"). Make systemReadJoypad() also call VBAMovieUpdate(which). Finally, throw in the checksumBIOS() function defined in src/win32/MovieOpen.cpp. (Change theApp.useBiosFile to useBios, theApp.biosFileName to biosFileName.) This will fix the build errors, but in movie.cpp you'll see that a key bit of HardResetAndSRAMClear() isn't implemented for the SDL build. So throw the ROM loading code into a function. (Make szFile global in src/sdl/SDL.cpp and rip out the rest of the "if (optind < argc)" clause, and the "emulating = 1" line later on.) Call it from HardResetAndSRAMClear(). Now build as usual. Ignore the TestEmu build failure.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Your rolling and platforming are always a pleasure to watch. The game's pace just looks qualitatively faster since you manage your momentum so well...
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Awesome movie! The margin of improvement over the previous one is just ridiculous. It's a bummer that the ceiling rocks can't be killed in time. (The game developers even made them immune to the blue insta-kill capsules.): Some trivia: Some enemies survived by spawning off-screen: one rock in the volcano level and five bubbles in the final level. Exactly one meteorite sneaked past you in level 5. On the other hand, over 3300 enemies weren't so lucky. No wonder the final boss just committed suicide when you showed up. :-P
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Sorry for making noise, but I updated the Gradius III script because it sometimes got hitboxes wrong for your shots or missiles. Added the level height, too, since vertical wrap-around apparently confuses everybody. Cpadolf, your run is the reason I made the script, but it took me a while to figure out how collisions and enemy lists worked. Hope it helps.
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Here's a script for Gradius 3, heavily based on smetroid.lua. You get differently colored hitboxes for the player, shields, missiles, projectiles, and enemies (killable or otherwise). Enemies have HP counters. Finally, some address at the bottom gives an indicator of progress through the auto-scrolling level (to estimate lag?) and the vertical size of the level (256 = 1 screenful). I think it looks pretty awesome. :)
local playerX, playerY
local cameraX, cameraY


gui.transparency(0)

while true do

	playerX = memory.readword(0x7e020a)
	playerY = memory.readword(0x7e020e)

	-- Camera abuse: This might be wrong, but it looks right.
	cameraX = 0
	cameraY = 16

	local radiusX, radiusY = memory.readword(0x7e0228), memory.readword(0x7e022a)

	-- Draw player's hitbox
	do
		-- Use of tables wastes some memory, but I don't really care.

		local topleft = {playerX - cameraX - radiusX, playerY - cameraY - radiusY}
		if topleft[1] < 0 then
			topleft[1] = 0
		elseif topleft[1] >= 256 then
			topleft[1] = 255
		end
		if topleft[2] < 0 then
			topleft[2] = 0
		elseif topleft[2] >= 239 then
			topleft[2] = 238
		end

		local bottomright = {playerX - cameraX + radiusX, playerY - cameraY + radiusY}
		if bottomright[1] < 0 then
			bottomright[1] = 0
		elseif bottomright[1] >= 256 then
			bottomright[1] = 255
		end
		if bottomright[2] < 0 then
			bottomright[2] = 0
		elseif bottomright[2] >= 239 then
			bottomright[2] = 238
		end

		-- Render
		gui.drawbox(topleft[1],topleft[2], bottomright[1],bottomright[2], "#808080")

	end


	-- Check out interesting hit-boxes
	for i=0,58 do
	
	-- Much to my annoyance, lua has no "continue" construct. So
	-- I'm wrapping the whole thing in a "loop" which I can break out of
	-- and force the for loop to start its next iteration
	 while true do
		local boxColor
		local monActive = memory.readword(0x7e0350 + 64*i)
		local monHP = memory.readword(0x7e0346 + 64*i)
		local monX, monY = memory.readword(0x7e034a + 64*i), memory.readword(0x7e034e + 64*i)
		local monRadX, monRadY = memory.readword(0x7e0368 + 64*i), memory.readword(0x7e036a + 64*i)

		-- Skip inactive monsters
		if monActive == 0 then
			break
		end

		if i < 2 then -- shield
			boxColor = "#800080" -- purple
		elseif i < 12 then -- projectile
                	if monHP <= 0 then
				monRadX = 3
				monRadY = 3
                        end
			boxColor = "blue"
		elseif i < 22 then -- missile
                	if monHP <= 0 then
				monRadX = 3
				monRadY = 3
                        end
			boxColor = "#800080" -- maroon
		elseif monHP == 0 or monHP >= 32767 then -- not alive
			boxColor = "#808080" -- grey
		elseif AND(memory.readword(0x7e036e + 64*i), 0x0100) ~= 0 then -- killable enemy
			boxColor = "green"
		elseif AND(memory.readword(0x7e036e + 64*i), 0x0040) ~= 0 then -- enemy fire
			boxColor = "red"
		else -- other enemy
			boxColor = "#ffff00" -- yellow
		end

		-- Constrain coordinates to viewable area
		local topleft = {monX - cameraX - monRadX, monY - cameraY - monRadY}
		if topleft[1] < 0 then
			topleft[1] = 0
		elseif topleft[1] >= 256 then
			topleft[1] = 255
		end
		if topleft[2] < 0 then
			topleft[2] = 0
		elseif topleft[2] >= 239 then
			topleft[2] = 238
		end

		local bottomright = {monX - cameraX + monRadX, monY - cameraY + monRadY}
		if bottomright[1] < 0 then
			bottomright[1] = 0
		elseif bottomright[1] >= 256 then
			bottomright[1] = 255
		end
		if bottomright[2] < 0 then
			bottomright[2] = 0
		elseif bottomright[2] >= 239 then
			bottomright[2] = 238
		end

		-- If we determine that it's off the screen, screw it.
		if topleft[1] == bottomright[1] or topleft[2] == bottomright[2] then
			break
		end

		-- Draw the hitbox
		gui.drawbox(topleft[1],topleft[2], bottomright[1],bottomright[2], boxColor)
	
		-- Render the monster's HP right there
		if (boxColor == "green") then
			local textX, textY = topleft[1] + (bottomright[1]-topleft[1])/2, bottomright[2]
			
			if textY > (224-8) then
				textY = 224-8
			end
			gui.text(textX, textY, tostring(monHP))
		end

		
		break -- out of fake while loop
	 end -- Of false fake loop	
	end

	-- Lastly, player's progress
        local progress = memory.readword(0x7e128a)
        local height = memory.readword(0x7e0090) + 1
	gui.text(0,215,string.format("Progress=%05d Height=%05d", progress, height))

	-- Continue emulation
	snes9x.frameadvance()

	-- io.write(collectgarbage("count")  io.write("\r")  io.flush()

end
IRC nick: UncombedCoconut
Experienced Forum User
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Heavens, that final boss had a lot of trouble finishing you off after mupen's early input termination bug immobilized you... :)
IRC nick: UncombedCoconut