<pclass="rvps2"><spanclass="rvts57">Most scripts use this function in their main game loop to advance frames. Note that you can also register functions by various methods that run "dead", returning control to the emulator and letting the emulator advance the frame. For most people, using frame advance in an endless while loop is easier to comprehend so I suggest starting with that. This makes more sense when creating bots. Once you move to creating auxillary libraries, try the register() methods.</span></p>
<pclass="rvps2"><spanclass="rvts57">Calls given function, restricting its working time to given number of lua cycles. Using this method you can ensure that some heavy operation (like Lua bot) won't freeze FCEUX.</span></p>
<pclass="rvps2"><spanclass="rvts57">Windows-only. Calls given function, restricting its working time to given number of milliseconds (approximate). Using this method you can ensure that some heavy operation (like Lua bot) won't freeze FCEUX.</span></p>
<pclass="rvps2"><spanclass="rvts57">Toggles the drawing of the sprites and background planes. Set to false or nil to disable a pane, anything else will draw them.</span></p>
<pclass="rvps2"><spanclass="rvts57">Displays given message on screen in the standard messages position. Use gui.text() when you need to position text.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns the framecount value. The frame counter runs without a movie running so this always returns a value.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns the number of lag frames encountered. Lag frames are frames where the game did not poll for input because it missed the vblank. This happens when it has to compute too much within the frame boundary. This returns the number indicated on the lag counter.</span></p>
<pclass="rvps2"><spanclass="rvts57">Sets current value of lag flag.</span></p>
<pclass="rvps2"><spanclass="rvts57">Some games poll input even in lag frames, so standard way of detecting lag (used by FCEUX and other emulators) does not work for those games, and you have to determine lag frames manually.</span></p>
<pclass="rvps2"><spanclass="rvts57">First, find RAM addresses that help you distinguish between lag and non-lag frames (e.g. an in-game frame counter that only increments in non-lag frames). Then register memory hooks that will change lag flag when needed.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns true if emulation has started, or false otherwise. Certain operations such as using savestates are invalid to attempt before emulation has started. You probably won't need to use this function unless you want to make your script extra-robust to being started too early.</span></p>
<pclass="rvps2"><spanclass="rvts57">While this variable only applies to movies, it is stored as a global variable and can be modified even without a movie loaded. Hence, it is in the emu library rather than the movie library.</span></p>
<pclass="rvps2"><spanclass="rvts57">Sets the read-only status to read-only if argument is true and read+write if false.</span></p>
<pclass="rvps2"><spanclass="rvts57">Note: This might result in an error if the medium of the movie file is not writeable (such as in an archive file).</span></p>
<pclass="rvps2"><spanclass="rvts57">While this variable only applies to movies, it is stored as a global variable and can be modified even without a movie loaded. Hence, it is in the emu library rather than the movie library.</span></p>
<pclass="rvps2"><spanclass="rvts117">Loads the ROM from the directory relative to the lua script or from the absolute path. Hence, the filename parameter can be absolute or relative path.</span></p>
<pclass="rvps2"><spanclass="rvts57">Registers a callback function to run immediately before each frame gets emulated. This runs after the next frame's input is known but before it's used, so this is your only chance to set the next frame's input using the next frame's would-be input. For example, if you want to make a script that filters or modifies ongoing user input, such as making the game think "left" is pressed whenever you press "right", you can do it easily with this.</span></p>
<pclass="rvps2"><spanclass="rvts57">Note that this is not quite the same as code that's placed before a call to emu.frameadvance. This callback runs a little later than that. Also, you cannot safely assume that this will only be called once per frame. Depending on the emulator's options, every frame may be simulated multiple times and your callback will be called once per simulation. If for some reason you need to use this callback to keep track of a stateful linear progression of things across frames then you may need to key your calculations to the results of emu.framecount.</span></p>
<pclass="rvps2"><spanclass="rvts57">Like other callback-registering functions provided by FCEUX, there is only one registered callback at a time per registering function per script. If you register two callbacks, the second one will replace the first, and the call to emu.registerbefore will return the old callback. You may register nil instead of a function to clear a previously-registered callback. If a script returns while it still has registered callbacks, FCEUX will keep it alive to call those callbacks when appropriate, until either the script is stopped by the user or all of the callbacks are de-registered.</span></p>
<pclass="rvps2"><spanclass="rvts57">Registers a callback function to run immediately after each frame gets emulated. It runs at a similar time as (and slightly before) gui.register callbacks, except unlike with gui.register it doesn't also get called again whenever the screen gets redrawn. Similar caveats as those mentioned in emu.registerbefore apply.</span></p>
<pclass="rvps2"><spanclass="rvts57">Registers a callback function that runs when the script stops. Whether the script stops on its own or the user tells it to stop, or even if the script crashes or the user tries to close the emulator, FCEUX will try to run whatever Lua code you put in here first. So if you want to make sure some code runs that cleans up some external resources or saves your progress to a file or just says some last words, you could put it here. (Of course, a forceful termination of the application or a crash from inside the registered exit function will still prevent the code from running.)</span></p>
<pclass="rvps2"><spanclass="rvts57">Suppose you write a script that registers an exit function and then enters an infinite loop. If the user clicks "Stop" your script will be forcefully stopped, but then it will start running its exit function. If your exit function enters an infinite loop too, then the user will have to click "Stop" a second time to really stop your script. That would be annoying. So try to avoid doing too much inside the exit function.</span></p>
<pclass="rvps2"><spanclass="rvts57">Note that restarting a script counts as stopping it and then starting it again, so doing so (either by clicking "Restart" or by editing the script while it is running) will trigger the callback. Note also that returning from a script generally does NOT count as stopping (because your script is still running or waiting to run its callback functions and thus does not stop... see here for more information), even if the exit callback is the only one you have registered. </span></p>
<pclass="rvps2"><spanclass="rvts57">Adds a Game Genie code to the Cheats menu. Returns false and an error message if the code can't be decoded. Returns false if the code couldn't be added. Returns true if the code already existed, or if it was added.</span></p>
<pclass="rvps2"><spanclass="rvts57">Removes a Game Genie code from the Cheats menu. Returns false and an error message if the code can't be decoded. Returns false if the code couldn't be deleted. Returns true if the code didn't exist, or if it was deleted.</span></p>
<pclass="rvps2"><spanclass="rvts57">Puts a message into the Output Console area of the Lua Script control window. Useful for displaying usage instructions to the user when a script gets run.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns the separate RGB components of the given screen pixel, and the palette. Can be 0-255 by 0-239, but NTSC only displays 0-255 x 8-231 of it. If getemuscreen is false, this gets background colors from either the screen pixel or the LUA pixels set, but LUA data may not match the information used to put the data to the screen. If getemuscreen is true, this gets background colors from anything behind an LUA screen element.</span></p>
<pclass="rvps2"><spanclass="rvts57">Usage is local r,g,b,palette = emu.getscreenpixel(5, 5, false) to retrieve the current red/green/blue colors and palette value of the pixel at 5x5.</span></p>
<pclass="rvps2"><spanclass="rvts57">You can avoid getting LUA data by putting the data into a function, and feeding the function name to emu.registerbefore.</span></p>
<pclass="rvps2"><spanclass="rvts57">The FCEU library is the same as the emu library. It is left in for backwards compatibility. However, the emu library is preferred.</span></p>
<pclass="rvps2"><spanclass="rvts118">Get a hash of the ROM loaded, for verification. If type is "md5", returns a hex string of the MD5 hash. If type is "base64", returns a base64 string of the MD5 hash, just like the movie romChecksum value.</span></p>
<pclass="rvps2"><spanclass="rvts57">Write the value to the ROM at the given address. The value is modded with 256 before writing (so writing 257 will actually write 1). Negative values allowed.</span></p>
<pclass="rvps2"><spanclass="rvts57">Get an unsigned byte from the RAM at the given address. Returns a byte regardless of emulator. The byte will always be positive.</span></p>
<pclass="rvps2"><spanclass="rvts57">Get a length bytes starting at the given address and return it as a string. Convert to table to access the individual bytes.</span></p>
<pclass="rvps2"><spanclass="rvts57">Get a signed byte from the RAM at the given address. Returns a byte regardless of emulator. The most significant bit will serve as the sign.</span></p>
<pclass="rvps2"><spanclass="rvts57">Get an unsigned word from the RAM at the given address. Returns a 16-bit value regardless of emulator. The value will always be positive.</span></p>
<pclass="rvps2"><spanclass="rvts57">If you only provide a single parameter (addressLow), the function treats it as address of little-endian word. if you provide two parameters, the function reads the low byte from addressLow and the high byte from addressHigh, so you can use it in games which like to store their variables in separate form (a lot of NES games do).</span></p>
<pclass="rvps2"><spanclass="rvts57">The same as above, except the returned value is signed, i.e. its most significant bit will serve as the sign.</span></p>
<pclass="rvps2"><spanclass="rvts57">Write the value to the RAM at the given address. The value is modded with 256 before writing (so writing 257 will actually write 1). Negative values allowed.</span></p>
<pclass="rvps2"><spanclass="rvts57">Sets the current value of the given hardware register.</span></p>
<pclass="rvps2"><spanclass="rvts57">For example, memory.setregister("pc",0x200) will change the main CPU's current Program Counter to 0x200.</span></p>
<pclass="rvps2"><spanclass="rvts57">You had better know exactly what you're doing or you're probably just going to crash the game if you try to use this function. That applies to the other memory.write functions as well, but to a lesser extent. </span></p>
<pclass="rvps2"><spanclass="rvts57">size is the number of bytes to "watch". For example, if size is 100 and address is 0x0200, then you will register the function across all 100 bytes from 0x0200 to 0x0263. A write to any of those bytes will trigger the function. Having callbacks on a large range of memory addresses can be expensive, so try to use the smallest range that's necessary for whatever it is you're trying to do. If you don't specify any size then it defaults to 1.</span></p>
<pclass="rvps2"><spanclass="rvts57">The callback function will receive three arguments (address, size, value) indicating what write operation triggered the callback. If you don't care about that extra information then you can ignore it and define your callback function to not take any arguments. Since 6502 writes are always single byte, the "size" argument will always be 1.</span></p>
<pclass="rvps2"><spanclass="rvts57">You may use a memory.write function from inside the callback to change the value that just got written. However, keep in mind that doing so will trigger your callback again, so you must have a "base case" such as checking to make sure that the value is not already what you want it to be before writing it. Another, more drastic option is to de-register the current callback before performing the write.</span></p>
<pclass="rvps2"><spanclass="rvts57">If func is nil that means to de-register any memory write callbacks that the current script has already registered on the given range of bytes.</span></p>
<pclass="rvps2"><spanclass="rvts57">Registers a function to be called immediately whenever the emulated system runs code located in the given memory address range.</span></p>
<pclass="rvps2"><spanclass="rvts57">Since "address" is the address in CPU address space (0x0000 - 0xFFFF), this doesn't take ROM banking into account, so the callback will be called for any bank, and in some cases you'll have to check current bank in your callback function.</span></p>
<pclass="rvps2"><spanclass="rvts57">The information about memory.register applies to this function as well. The callback will receive the same three arguments, though the "value" argument will always be 0.</span></p>
<pclass="rvps2"><spanclass="rvts57">Get an unsigned byte from the PPU at the given address. Returns a byte regardless of emulator. The byte will always be positive.</span></p>
<pclass="rvps2"><spanclass="rvts57">Get a length bytes starting at the given address and return it as a string. Convert to table to access the individual bytes.</span></p>
<pclass="rvps2"><spanclass="rvts57">Simulates a breakpoint hit, pauses emulation and brings up the Debugger window. Use this function in your handlers of custom breakpoints.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns an integer value representing the number of CPU cycles elapsed since the poweron or since the last reset of the cycles counter.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns an integer value representing the number of CPU instructions executed since the poweron or since the last reset of the instructions counter.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns a table of every game button, where each entry is true if that button is currently held (as of the last time the emulation checked), or false if it is not held. This takes keyboard inputs, not Lua. The table keys look like this (case sensitive):</span></p>
<pclass="rvps2"><spanclass="rvts57">Where a Lua truthvalue true means that the button is set, false means the button is unset. Note that only "false" and "nil" are considered a false value by Lua. Anything else is true, even the number 0.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns a table of every game button, where each entry is true if that button is held at the moment of calling the function, or false if it is not held. This function polls keyboard input immediately, allowing Lua to interact with user even when emulator is paused.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns a table of only the game buttons that are currently held. Each entry is true if that button is currently held (as of the last time the emulation checked), or nil if it is not held.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns a table of only the game buttons that are not currently held. Each entry is nil if that button is currently held (as of the last time the emulation checked), or false if it is not held.</span></p>
<pclass="rvps2"><spanclass="rvts57">Any string works in place of "invert". It is suggested as a convention to use "invert" for readability, but strings like "inv", "Weird switchy mechanism", "", or "true or false" works as well as "invert".</span></p>
<pclass="rvps2"><spanclass="rvts57">nil and "invert" exists so the script can control individual buttons of the controller without entirely blocking the user from having any control. Perhaps there is a process which can be automated by the script, like an optimal firing pattern, but the user still needs some manual control, such as moving the character around.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns the zapper data</span></p>
<pclass="rvps2"><spanclass="rvts57">When no movie is loaded this input is the same as the internal mouse input (which is used to generate zapper input, as well as the arkanoid paddle).</span></p>
<pclass="rvps2"><spanclass="rvts57">The return table consists of 3 values: x, y, and fire. x and y are the x,y coordinates of the zapper target in terms of pixels. fire represents the zapper firing. 0 = not firing, 1 = firing</span></p>
<pclass="rvps2"><spanclass="rvts57">Reads input from keyboard and mouse. Returns pressed keys and the position of mouse in pixels on game screen. The function returns a table with at least two properties; table.xmouse and table.ymouse. Additionally any of these keys will be set to true if they were held at the time of executing this function:</span></p>
<pclass="rvps2"><spanclass="rvts57">Requests input from the user using a multiple-option message box. See gui.popup for complete usage and returns.</span></p>
<pclass="rvps2"><spanclass="rvts57">Create a new savestate object. Optionally you can save the current state to one of the predefined slots(1-10) using the range 1-9 for slots 1-9, and 10 for 0, QWERTY style. Using no number will create an "anonymous" savestate.</span></p>
<pclass="rvps2"><spanclass="rvts57">Note that this does not actually save the current state! You need to create this value and pass it on to the load and save functions in order to save it.</span></p>
<pclass="rvps2"><spanclass="rvts57">Anonymous savestates are temporary, memory only states. You can make them persistent by calling memory.persistent(state). Persistent anonymous states are deleted from disk once the script exits.</span></p>
<pclass="rvps2"><spanclass="rvts57">savestate.create is identical to savestate.object, except for the numbering for predefined slots(1-10, 1 refers to slot 0, 2-10 refer to 1-9). It's being left in for compatibility with older scripts, and potentially for platforms with different internal predefined slot numbering.</span></p>
<pclass="rvps2"><spanclass="rvts57">Save the current state object to the given savestate. The argument is the result of savestate.create(). You can load this state back up by calling savestate.load(savestate) on the same object.</span></p>
<pclass="rvps2"><spanclass="rvts57">Load the the given state. The argument is the result of savestate.create() and has been passed to savestate.save() at least once.</span></p>
<pclass="rvps2"><spanclass="rvts57">If this savestate is not persistent and not one of the predefined states, the state will be deleted after loading.</span></p>
<pclass="rvps2"><spanclass="rvts57">Set the given savestate to be persistent. It will not be deleted when you load this state but at the exit of this script instead, unless it's one of the predefined states. If it is one of the predefined savestates it will be saved as a file on disk.</span></p>
<pclass="rvps2"><spanclass="rvts57">Registers a callback function that runs whenever the user saves a state. This won't actually be called when the script itself makes a savestate, so none of those endless loops due to a misplaced savestate.save.</span></p>
<pclass="rvps2"><spanclass="rvts57">As with other callback-registering functions provided by FCEUX, there is only one registered callback at a time per registering function per script. Upon registering a second callback, the first is kicked out to make room for the second. In this case, it will return the first function instead of nil, letting you know what was kicked out. Registering nil will clear the previously-registered callback.</span></p>
<pclass="rvps2"><spanclass="rvts57">Registers a callback function that runs whenever the user loads a previously saved state. It's not called when the script itself loads a previous state, so don't worry about your script interrupting itself just because it's loading something.</span></p>
<pclass="rvps2"><spanclass="rvts57">The state's data is loaded before this function runs, so you can read the RAM immediately after the user loads a state, or check the new framecount. Particularly useful if you want to update lua's display right away instead of showing junk from before the loadstate.</span></p>
<pclass="rvps2"><spanclass="rvts57">Intended Function, according to snes9x LUA documentation:</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns the data associated with the given savestate (data that was earlier returned by a registered save callback) without actually loading the rest of that savestate or calling any callbacks. location should be a save slot number.</span></p>
<pclass="rvps2"><spanclass="rvts6">Loads and plays a movie from the directory relative to the Lua script or from the absolute path. If read_only is true, the movie will be loaded in read-only mode. The default is read+write.</span></p>
<pclass="rvps2"><spanclass="rvts6">A pauseframe can be specified, which controls which frame will auto-pause the movie. By default, this is off. A true value is returned if the movie loaded correctly.</span></p>
<pclass="rvps2"><spanclass="rvts118">An optional save_type can be specified. If set to 0 (default), it will record from a power on state, and automatically do so. This is the recommended setting for creating movies. This can also be set to 1 for savestate or 2 for saveram movies.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns true if a movie is currently loaded and false otherwise. (This should be used to guard against Lua errors when attempting to retrieve movie information).</span></p>
<pclass="rvps2"><spanclass="rvts57">Turn the rerecord counter on or off. Allows you to do some brute forcing without inflating the rerecord count.</span></p>
<pclass="rvps2"><spanclass="rvts57">Performs the Play from Beginning function. Movie mode is switched to read-only and the movie loaded will begin playback from frame 1.</span></p>
<pclass="rvps2"><spanclass="rvts57">While this variable only applies to movies, it is stored as a global variable and can be modified even without a movie loaded. Hence, it is in the emu library rather than the movie library.</span></p>
<pclass="rvps2"><spanclass="rvts57">Sets the read-only status to read-only if argument is true and read+write if false.</span></p>
<pclass="rvps2"><spanclass="rvts57">Note: This might result in an error if the medium of the movie file is not writeable (such as in an archive file).</span></p>
<pclass="rvps2"><spanclass="rvts57">While this variable only applies to movies, it is stored as a global variable and can be modified even without a movie loaded. Hence, it is in the emu library rather than the movie library.</span></p>
<pclass="rvps2"><spanclass="rvts57">Draw one pixel of a given color at the given position on the screen. See drawing notes and color notes at the bottom of the page. </span></p>
<pclass="rvps2"><spanclass="rvts57">Returns the separate RGBA components of the given pixel set by gui.pixel. This only gets LUA pixels set, not background colors.</span></p>
<pclass="rvps2"><spanclass="rvts57">Usage is local r,g,b,a = gui.getpixel(5, 5) to retrieve the current red/green/blue/alpha values of the LUA pixel at 5x5.</span></p>
<pclass="rvps2"><spanclass="rvts57">Draws a line between the two points. The x1,y1 coordinate specifies one end of the line segment, and the x2,y2 coordinate specifies the other end. If skipfirst is true then this function will not draw anything at the pixel x1,y1, otherwise it will. skipfirst is optional and defaults to false. The default color for the line is solid white, but you may optionally override that using a color of your choice. See also drawing notes and color notes at the bottom of the page.</span></p>
<pclass="rvps2"><spanclass="rvts57">Draws a rectangle between the given coordinates of the emulator screen for one frame. The x1,y1 coordinate specifies any corner of the rectangle (preferably the top-left corner), and the x2,y2 coordinate specifies the opposite corner.</span></p>
<pclass="rvps2"><spanclass="rvts57">The default color for the box is transparent white with a solid white outline, but you may optionally override those using colors of your choice. Also see drawing notes and color notes.</span></p>
<pclass="rvps2"><spanclass="rvts57">Draws a given string at the given position. textcolor and backcolor are optional. See 'on colors' at the end of this page for information. Using nil as the input or not including an optional field will make it use the default.</span></p>
<pclass="rvps2"><spanclass="rvts57">Returns the separate RGBA components of the given color.</span></p>
<pclass="rvps2"><spanclass="rvts57">For example, you can say local r,g,b,a = gui.parsecolor('orange') to retrieve the red/green/blue values of the preset color orange. (You could also omit the a in cases like this.) This uses the same conversion method that FCEUX uses internally to support the different representations of colors that the GUI library uses. Overriding this function will not change how FCEUX interprets color values, however.</span></p>
<pclass="rvps2"><spanclass="rvts57">Makes a screenshot of the FCEUX emulated screen, and saves it to the appropriate folder. Performs identically to pressing the Screenshot hotkey.</span></p>
<pclass="rvps2"><spanclass="rvts57">Makes a screenshot of the FCEUX emulated screen, and saves it to the appropriate folder. However, this one receives a file name for the screenshot.</span></p>
<pclass="rvps2"><spanclass="rvts57">Takes a screen shot of the image and returns it in the form of a string which can be imported by the gd library using the gd.createFromGdStr() function.</span></p>
<pclass="rvps2"><spanclass="rvts57">This function is provided so as to allow FCEUX to not carry a copy of the gd library itself. If you want raw RGB32 access, skip the first 11 bytes (header) and then read pixels as Alpha (always 0), Red, Green, Blue, left to right then top to bottom, range is 0-255 for all colors.</span></p>
<pclass="rvps2"><spanclass="rvts57">If getemuscreen is false, this gets background colors from either the screen pixel or the Lua pixels set, but Lua data may not match the information used to put the data to the screen. If getemuscreen is true, this gets background colors from anything behind a Lua screen element.</span></p>
<pclass="rvps2"><spanclass="rvts108">Warning:</span><spanclass="rvts57"> Storing screen shots in memory is not recommended. Memory usage will blow up pretty quick. One screen shot string eats around 230 KB of RAM.</span></p>
<pclass="rvps2"><spanclass="rvts57">Transparency is fully supported. Also, if alphamul is specified then it will modulate the transparency of the image even if it's originally fully opaque. (alphamul=1.0 is normal, alphamul=0.5 is doubly transparent, alphamul=3.0 is triply opaque, etc.)</span></p>
<pclass="rvps2"><spanclass="rvts57">dx,dy determines the top-left corner of where the image should draw. If they are omitted, the image will draw starting at the top-left corner of the screen.</span></p>
<pclass="rvps2"><spanclass="rvts57">gui.gdoverlay is an actual drawing function (like gui.box and friends) and thus must be called every frame, preferably inside a gui.register'd function, if you want it to appear as a persistent image onscreen.</span></p>
<pclass="rvps2"><spanclass="rvts57">Here is an example that loads a PNG from file, converts it to gd string format, and draws it once on the screen:</span></p>
<pclass="rvps2"><spanclass="rvts57">Scales the transparency of subsequent draw calls. An alpha of 0.0 means completely transparent, and an alpha of 1.0 means completely unchanged (opaque). Non-integer values are supported and meaningful, as are values greater than 1.0. It is not necessary to use this function (or the less-recommended gui.transparency) to perform drawing with transparency, because you can provide an alpha value in the color argument of each draw call. However, it can sometimes be convenient to be able to globally modify the drawing transparency. </span></p>
<pclass="rvps2"><spanclass="rvts57">Scales the transparency of subsequent draw calls. Exactly the same as gui.opacity, except the range is different: A trans of 4.0 means completely transparent, and a trans of 0.0 means completely unchanged (opaque). </span></p>
<pclass="rvps2"><spanclass="rvts57">Register a function to be called between a frame being prepared for displaying on your screen and it actually happening. Used when that 1 frame delay for rendering is not acceptable.</span></p>
<pclass="rvps2"><spanclass="rvts57">Brings up a modal popup dialog box (everything stops until the user dismisses it). The box displays the message tostring(msg). This function returns the name of the button the user clicked on (as a string).</span></p>
<pclass="rvps2"><spanclass="rvts57">type determines which buttons are on the dialog box, and it can be one of the following: 'ok', 'yesno', 'yesnocancel', 'okcancel', 'abortretryignore'.</span></p>
<pclass="rvps2"><spanclass="rvts57">type defaults to 'ok' for gui.popup, or to 'yesno' for input.popup.</span></p>
<pclass="rvps2"><spanclass="rvts57">icon indicates the purpose of the dialog box (or more specifically it dictates which title and icon is displayed in the box), and it can be one of the following: 'message', 'question', 'warning', 'error'.</span></p>
<pclass="rvps2"><spanclass="rvts57">icon defaults to 'message' for gui.popup, or to 'question' for input.popup.</span></p>
<pclass="rvps2"><spanclass="rvts57">Linux users might want to install xmessage to perform the work. Otherwise the dialog will appear on the shell and that's less noticeable.</span></p>
<pclass="rvps2"><spanclass="rvts57">The following bit functions were added to FCEUX internally to compensate for Lua's lack of them. But it also supports all operations from </span><aclass="rvts110"href="http://bitop.luajit.org/api.html">LuaBitOp</a><spanclass="rvts57"> module, since it is also embedded in FCEUX.</span></p>
<pclass="rvps2"><spanclass="rvts57">A general warning about drawing is that it is always one frame behind unless you use gui.register. This is because you tell the emulator to paint something but it will actually paint it when generating the image for the next frame. So you see your painting, except it will be on the image of the next frame. You can prevent this with gui.register because it gives you a quick chance to paint before blitting.</span></p>
<pclass="rvps4"style="clear: both;"><spanclass="rvts18">Created with the Personal Edition of HelpNDoc: </span><aclass="rvts19"href="https://www.helpndoc.com/create-epub-ebooks">Generate EPub eBooks with ease</a></p>
