Post subject: PSXjin Lua scripting.
Editor, Skilled player (1172)
Joined: 9/27/2008
Posts: 1085
Strange. I didn't see any thread about general purpose lua stuff here. I figure I'd create one. In creation of this thread, I will start off by posting a quick script to help with handling the analog input using the main PSXjin window, instead of that clunky analog control window. Download analog.lua
Language: lua

-- Simplify handling analog input. 1 player only. -- FatRatKnight local keys, lastkeys= input.get(),input.get() --***************************************************************************** local function UpdateKeys() lastkeys= keys; keys= input.get() end --***************************************************************************** local function Press(k) return keys[k] and (not lastkeys[k]) end --***************************************************************************** local function Limits(v,l,h) return math.max(math.min(v,h),l) end --***************************************************************************** --***************************************************************************** local function GuiTextRight(x,y,t,c) --***************************************************************************** x= x - #tostring(t)*4 gui.text(x,y,t,c) end local CA= { xleft= 128, xright= 128, yleft= 128, yright= 128 } --***************************************************************************** local function ResetAnalog() --***************************************************************************** -- Should be obvious: Restore defaults. CA.xleft= 128; CA.xright= 128 CA.yleft= 128; CA.yright= 128 end local StickyAnalog= true --***************************************************************************** local function HandleAnalog() --***************************************************************************** -- Apply the input each frame. Reset it too, depending on mode. joypad.setanalog(1,CA) if not StickyAnalog then ResetAnalog() end end emu.registerbefore(HandleAnalog) --***************************************************************************** local function ControlAnalog() --***************************************************************************** -- Handle user input through main window UpdateKeys() -- Analog handler and display if keys.leftclick then CA.xleft= Limits(CA.xleft + keys.xmouse - lastkeys.xmouse, 0,255) CA.yleft= Limits(CA.yleft + keys.ymouse - lastkeys.ymouse, 0,255) gui.line(keys.xmouse, keys.ymouse, keys.xmouse - CA.xleft + 128, keys.ymouse - CA.yleft + 128, 0x0040FFFF) -- Blue end if keys.rightclick then CA.xright= Limits(CA.xright + keys.xmouse - lastkeys.xmouse, 0,255) CA.yright= Limits(CA.yright + keys.ymouse - lastkeys.ymouse, 0,255) gui.line(keys.xmouse, keys.ymouse, keys.xmouse - CA.xright + 128, keys.ymouse - CA.yright + 128, -0x00BFFF01) -- Red; 80Red bug end -- Option and reset switches. if Press("insert") then StickyAnalog = not StickyAnalog end if Press("delete") then ResetAnalog() end -- Handle displaying the coordinates. local color= -0x00000001 -- White. 80Red glitch bypass if StickyAnalog then color= 0x00FF80FF end -- Mostly Green GuiTextRight(70, 5,CA.xleft, color) GuiTextRight(70,13,CA.yleft, color) GuiTextRight(90, 5,CA.xright,color) GuiTextRight(90,13,CA.yright,color) end gui.register(ControlAnalog) --***************************************************************************** while true do --***************************************************************************** -- I have observed glitches without this in place. emu.frameadvance() end
Well... That was the main point of my creating this thread, to share this code. But an entire thread dedicated to this one thing felt out of place, so I'll make it a general-purpose thread instead. So, uh... Someone find something to discuss...? I mainly wanted to share that code.
Editor, Skilled player (1172)
Joined: 9/27/2008
Posts: 1085
In my above code, I make references to two bugs. The 80Red glitch, as I call it, is a bug that fails to draw any color for any numeric representation of a number greater than or equal to 0x80000000. As the upper two digits represent the red portion of the colors (0x80000000), this means that any red in the range of 0x80 to 0xFF will produce an invalid color, and will not paint anything in most cases. This bug is common in several emulators, which I've spotted in FCEUX and VBA, but Snes9x isn't hit with this bug. The bug, furthermore, allows using negative numbers, which you can use to get the red components of 0x80 or higher. However, you need to know the mechanics of Twos Complement in order to understand what in the world it's doing to get the color you need. But by and large, subtract the normal color you want by (0xFFFFFFFF + 1) and it'll work as long as the red is 0x80 or higher. The bug does not apply when you use tables ( {r=0x80, g=0x00, b=0x00, a=0xFF} ) or strings ( "#800000FF" ) as your color. It only affects numeric representation ( 0x800000FF ). You can safely call the gui functions using 0x7FFFFFFF, but not 0x800000FF; However, -0x7FFFFF01 will get you the nice, half-brightness red you desire. Another glitch is the Enforced frameadvance bug, another arbitrary name I came up with. Basically, the bug does not exist as long as you have while true do [...] emu.frameadvance() end somewhere in your code, or at least the script doesn't exit with registers still running. An observed effect: joypad.set should normally affect only one frame. If it's not called for the next frame, it should default to simply passing the user's input through. With the emu.frameadvance() loop being absent, this reset does not take place -- the input from the joypad.set sticks permanently until joypad.set is called again or the script is closed by user. Usually not a problem for those making bots, however, as they tend to call joypad.set every frame, but this would affect those who make a macro script. I suspect there might be other effects that "forget" to be reset with an absent emu.frameadvance() loop, but regardless of the problems that crop up from it, sticking in that loop, even without any meaningful content in it, gets you safely around this bug. I have not observed this bug in any other emulator.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
what exactly does this script do?