mupen64plus / mupen64plus-ui-console Goto Github PK
View Code? Open in Web Editor NEWConsole (command-line) front-end user interface for Mupen64Plus v2.0 project
Console (command-line) front-end user interface for Mupen64Plus v2.0 project
=============================================================================== ------------------------------------------------------------------------------- Mupen64plus-ui-console README v2.5 ------------------------------------------------------------------------------- =============================================================================== The latest documentation for this plugin can be found at: https://mupen64plus.org/wiki/index.php/UIConsoleUsage ------------------------------------------------------------------------------- Console Options ------------------------------------------------------------------------------- At startup, the mupen64plus program will look for a user configuration file called 'mupen64plus.cfg'. If this file does not exist, it will be created and default settings will be written. If desired, an alternate config directory can be specified using the --configdir commandline option. Run 'mupen64plus --help' for a complete list of commandline options: $ mupen64plus --help Usage: mupen64plus [parameter(s)] [romfile] Parameters: --noosd : disable onscreen display --osd : enable onscreen display --fullscreen : use fullscreen display mode --windowed : use windowed display mode --resolution (res) : display resolution (640x480, 800x600, 1024x768, etc) --nospeedlimit : disable core speed limiter (should be used with dummy audio plugin) --cheats (cheat-spec) : enable or list cheat codes for the given rom file --corelib (filepath) : use core library (filepath) (can be only filename or full path) --configdir (dir) : force configation directory to (dir); should contain mupen64plus.cfg --datadir (dir) : search for shared data files (.ini files, languages, etc) in (dir) --debug : launch console-based debugger (requires core lib built for debugging) --plugindir (dir) : search for plugins in (dir) --sshotdir (dir) : set screenshot directory to (dir) --gfx (plugin-spec) : use gfx plugin given by (plugin-spec) --audio (plugin-spec) : use audio plugin given by (plugin-spec) --input (plugin-spec) : use input plugin given by (plugin-spec) --rsp (plugin-spec) : use rsp plugin given by (plugin-spec) --emumode (mode) : set emu mode to: 0=Pure Interpreter 1=Interpreter 2=DynaRec --savestate (filepath) : savestate loaded at startup --testshots (list) : take screenshots at frames given in comma-separated (list), then quit --set (param-spec) : set a configuration variable, format: ParamSection[ParamName]=Value --gb-rom-{1,2,3,4} : define GB cart rom to load inside transferpak {1,2,3,4} --gb-ram-{1,2,3,4} : define GB cart ram to load inside transferpak {1,2,3,4} --dd-ipl-rom : define 64DD IPL rom --dd-disk : define disk to load into the disk drive --core-compare-send : use the Core Comparison debugging feature, in data sending mode --core-compare-recv : use the Core Comparison debugging feature, in data receiving mode --nosaveoptions : do not save the given command-line options in configuration file --pif (filepath) : use a binary PIF ROM (filepath) instead of HLE PIF --verbose : print lots of information --help : see this help message (plugin-spec): (pluginname) : filename (without path) of plugin to find in plugin directory (pluginpath) : full path and filename of plugin 'dummy' : use dummy plugin (cheat-spec): 'list' : show all of the available cheat codes 'all' : enable all of the available cheat codes (codelist) : a comma-separated list of cheat code numbers to enable, with dashes to use code variables (ex 1-2 to use cheat 1 option 2) ------------------------------------------------------------------------------- Cheats ------------------------------------------------------------------------------- To list the available cheats in the rom: mupen64plus --cheats list "/path/to/my/rom.v64" If there are cheats in the rom, you will get (in the output console): UI-Console: 3 cheat code(s) found for ROM 'MY ROM' 0: [Enable All Levels] (This is needed to be able to Play all Levels of the Game) 1: [Enable All Weapons] (This is needed to be able to Play with all Weapons of the Game) 2: etc... All you have to do to use this cheats is: mupen64plus --cheats 0,1,2 "/path/to/my/rom.v64" ------------------------------------------------------------------------------- Debugger ------------------------------------------------------------------------------- Setup ===== You must use a mupen64plus core library which was built with the DEBUGGER flag set. Running ======= Use the --debug command-line option to enable the console debugger. The emulator mode should be set to "interpreter", as the dynarec seems to cause issues when interacting with the debugging API. This can be done with the R4300Emulator config setting or with the --emumode flag. Usage ===== Once the emulator boots, it will be paused by default. You will be presented with a prompt as follows: (dbg) The following commands can be entered: run Unpauses the game. pause Pauses the game. step <num-steps> When paused, instructs the emulator to make a single step, or a series of steps if num-steps is provided. regs Prints out general purpose register values. pc Print current value of Program Counter register pc-1 Print previous value of Program Counter register asm Print assembly language instructions. Several forms are supported: asm Print one instruction at the Program Counter register asm <addr> Print one instruction at <addr> asm <addr> <n> Print <n> instructions starting at <addr> asm <addr> <n> <flags> Print <n> instructions starting at <addr> with flags - If flags bit-3 is set (i.e. & 0x04): also print binary instruction data - If flags bit-2 is set: prefix each instruction with its memory address - If flags bit-1 is set: prefix each instruction with a counter from <addr> mem Print memory values. Several forms are supported: mem <addr> Print one 32-bit word at <addr> mem /N <addr> Print <N> 32-bit words at <addr> mem /Nb <addr> Print <N> 8-bit bytes at <addr> mem /Nh <addr> Print <N> 16-bit half-words at <addr> mem /Nw <addr> Print <N> 32-bit words at <addr> mem /Nd <addr> Print <N> 64-bit double-words at <addr> mem /NxM <addr> Print <N> rows of <M> 32-bit words at <addr> mem /NxMb <addr> Print <N> rows of <M> 8-bit bytes at <addr> mem /NxMh <addr> Print <N> rows of <M> 16-bit half-words at <addr> mem /NxMw <addr> Print <N> rows of <M> 32-bit words at <addr> mem /NxMd <addr> Print <N> rows of <M> 64-bit double-words at <addr> write Write values to memory. Several forms are supported: write <addr> <value> Write a (1) byte value to <addr> write <addr> b <value> Write a (1) byte value to <addr> write <addr> h <value> Write a half-word value (2 bytes) to <addr> write <addr> w <value> Write a word value (4 bytes) to <addr> write <addr> d <value> Write a double-word value (8 bytes) to <addr> translate Translates virtual memory addresses to physical memory addresses. Memory read/write breakpoints must operate on physical addresses, in contrast to the memory read/write commands and execution breakpoints that operate on virtual addresses. translate <virtual address> Print the 32-bit physical address for the provided <virtual address> argument. bp add Adds a breakpoint at a given address. Several forms are supported: bp add pc Add a breakpoint at the Program Counter, triggered on EXEC, READ, and WRITE. bp add <addr> Add a breakpoint at <addr>, triggered on EXEC, READ, and WRITE. bp add <addr> <n> Add a breakpoint starting at <addr>, extending <n> bytes, triggered on EXEC, READ, and WRITE. bp add <addr> <n> <flags> Add a breakpoint starting at <addr>, extending <n> bytes, with specified trigger flags. - M64P_BKP_FLAG_READ = 0x02 - M64P_BKP_FLAG_WRITE = 0x04 - M64P_BKP_FLAG_EXEC = 0x08 bp trig Prints the reason for the most recently activated breakpoint trigger. Memory read/write breakpoints will indicate the hit address. bp rm <addr|index> Removes a breakpoint by address or number. bp list Lists all breakpoints. exit|quit Stop emulator and quit debugger ------------------------------------------------------------------------------- 64DD Support ------------------------------------------------------------------------------- Some compatibility with the 64DD disk drive unit has been implemented, but there are a few small usability issues of which users should be aware. When using the 64DD, you need to pass a path to a cartridge rom, even if none is strictly required. The IPL boot rom will execute first and select the disk if you have one inserted, or just show the boot menu otherwise. We can remove this requirement at a later time. For now all we need to remember is to use a Japanese ROM (otherwise some region check will fail) with same features as the 64DD game you want to play (think RumblePak, TransferPak, otherwise, they won't be available). There is a sibling issue also with 64DD games in that there are no entries in the game db (mupen64plus.ini) for them, and the core currently only relies on the cart ROM loaded to fetch the ROM infos.
It seems 87ef789 from pull request #14 broke the SDL1.2 initialization. On parts of the platforms the main function must be replaced and instead the private SDL-main (parachute) function has to be called first. This is the only use of this SDL_main.h include. The programs main function is redefined as SDL_main and the main function is included using a special static library. The normal startup will therefore be main(SDLmain.a) -> SDL_main(previously known called main in the actual program source code). Of course, main() is not always called main() but I just use it here as placeholder for the real name.
This special indirection is required to initialize the internal state of SDL before the actual program calls any SDL function.
A similar problem already caused the windows builds to break (in a very hard to debug way) in the past.
Hello everyone! I have noticed that some string arguments of the --set parameter are not working properly. The pre-release 2.5.9 build works fine, but not the latest nightly-builds.
I'll explain better... I use several mupen64plus.cfg (to be exact, one for each game), and I try to keep them in the same directory as the emulator. That way I can make each game run with a unique configuration for it.
Going to my Mupen directory "C:\mupen64plus" through the Prompt, I run, for example, San Francisco Rush 2049:
mupen64plus-ui-console.exe --configdir "romconfig\San Francisco Rush 2049 (U) [!]" "roms\San Francisco Rush 2049 (U) [!].z64"
It's all right...
1st: My mupen64plus.cfg will be created in the folder "C:\mupen64plus\romconfig\San Francisco Rush 2049 (U) [!]", and no longer in default "C:\Users\ (User) \AppData\Roaming\Mupen64Plus".
2nd: I close the game
3rd: I change my new mupen64plus.cfg as I want
4th: I run exactly the same command mentioned above so that the emulator continues reading my new mupen64plus.cfg when I want to play again.
The problem I reported happens when I want to quickly configure some parameters of my new mupen64plus.cfg using the prompt. I could do this by editing my new mupen64plus.cfg with a text editor (as I've explained), but I can speed things up like this.
For example: to define a new path for my screenshots, I would do:
mupen64plus-ui-console.exe --configdir "romconfig\San Francisco Rush 2049 (U) [!]" --set core[ScreenshotPath]="romconfig\San Francisco Rush 2049 (U) [!]\screenshot" "roms\San Francisco Rush 2049 (U) [!].z64"
As a result, in my mupen64plus.cfg:
[Core]
(...)
ScreenshotPath = "romconfig\San Francisco Rush 2049 (U) [!]\screenshot"
(...)
But this is what I get now :(
ScreenshotPath = ""romconfig\San" (It's three quotes, I wasn't wrong)
And I still get a pile of unrecognized commands that I get later:
UI-Console Warning: unrecognized command-line parameter 'Francisco'
UI-Console Warning: unrecognized command-line parameter 'Rush'
UI-Console Warning: unrecognized command-line parameter '2049'
UI-Console Warning: unrecognized command-line parameter '(U)'
Etc.....
I'll avoid theories here so this text doesn't get too long.
Goodbye!
Debian Stretch 9.0 (1.9) ASUS Tinkerboard RK3288 ARMv7 Mali T764
make NEON=1 VFP_HARD=1 all
CC _obj/cheat.o
CC _obj/compare_core.o
CC _obj/core_interface.o
CC _obj/main.o
CC _obj/plugin.o
CC _obj/osal_dynamiclib_unix.o
CC _obj/osal_files_unix.o
LD mupen64plus
/usr/bin/ld: /tmp/ccSs1UeW.ltrans0.ltrans.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/tmp/ccSs1UeW.ltrans0.ltrans.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:315: recipe for target 'mupen64plus' failed
make: *** [mupen64plus] Error 1
LD mupen64plus
/usr/bin/ld: /tmp/ccBHpyWe.ltrans0.ltrans.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/tmp/ccBHpyWe.ltrans0.ltrans.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:315: recipe for target 'mupen64plus' failed
make: *** [mupen64plus] Error 1
-fPIC seems to be required during compilation of ld.
I tried with setting the PIC option during make
make NEON=1 VFP_HARD=1 PIC=1 all
make NEON=1 VFP_HARD=1 PIC=0 all
but still the same error
Finding the line in projects/unix/Makefile
ifeq ($(OS), LINUX)
LDLIBS += -ldl
endif
and adding
ifeq ($(OS), LINUX)
LDLIBS += -ldl
CFLAGS += -fPIC #THIS LINE
endif
used to fix the problem, it's not working now
Adding PIE=1 to make fixed the problem. thanks loganmc10.
Hi guys,
When I try to install mupen64plus:
sudo apt-get install mupen64plus
from my BananaPi (using Raspbian for BananaPi), I have the following error:
Depends: mupen64plus-ui-console but it is not installable or
mupen64plus-ui but it is not installable
Any idea how I can solve it?
#61 seems to cause a building error on ubuntu 20.04.
/usr/bin/ld: /tmp/mupen64plus.7qvaaK.ltrans0.ltrans.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE collect2: error: ld returned 1 exit status
If I revert this commit, the error has gone.
High DPI awareness is missing for the windows version of the ui console. I had problems using it on Windows 10 and setting to my native 1920x1080 desktop resolution in fullscreen mode...
OS: gentoo
compiler: gcc-9.3.0
mupen64plus-ui-console: ae2d353
The build fails with gcc-9.3.0
on gentoo.
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/cheat.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/compare_core.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/core_interface.o: relocation R_X86_64_32 against symbol `CoreHandle' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/debugger.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/main.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/plugin.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/osal_dynamiclib_unix.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/osal_files_unix.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE
collect2: error: ld returned 1 exit status
Full log: mupen64plus-ui-console.txt
I tried this both with and without OPTFLAGS=-fPIE
without any differences. The build does succeed with clang-11.0.0
and the gcc-9.3.0
shipped with Slackware64-current, I am not sure what is different about gentoo in this case? I was also not able to reproduce this problem with any other mupen64plus plugin.
When using the --configdir
option with mupen64plus-ui-console, only the config file is read in. The save folder (which is in the original config folder) is doesn't use the new custom path.
I have been trying to figure out where the position of the WM gets set (centered, it seems), but have not gotten much further than adding a dummy --position argument to the console/config.
I do not really know which of the many Glide plugins is being used (only that it is Glide64mk2), but whether this is the module responsible for setting the position of the physical window, I have no idea.
Where should I be looking?
Glide64?
Glitch64/OGLES?
Glitch64/OGL?
my use case is programmatically spawning several instances spread out rather than all in one centered pile
there already is a window size parameter, so initially I thought finding the position would be straightforward but apparently not
using Linux
The ui is currently depending on config api 2.0
src/version.h:#define CONFIG_API_VERSION 0x020000
The ui-console program is using following new functions from newer API versions:
When users run mupen64plus for the first time or if they delete their mupen64plus.cfg file then mupen64plus will auto-generate a new cfg file. This cfg file may not have default values that are compatible with some unofficial ports.
Users can of course change these, either on the command line, manually editing the file or copying in a good cfg file.
However for inexperienced users, perhaps a method to set these defaults at build time should be considered.
I would like to suggest that such a method used is similar to how COREDIR and PLUGINDIR are used within the makefile system. Then maintainers of unofficial ports could customize official plugin defaults from within their build scripts. (This would remove the need to fork and maintain updates where only these defaults are changed).
Note: This change would have to be applied to all mupen64plus repositories else an inexperienced user may still need to do something with the cfg file.
As a side note I would like to add that I have not seen many comments/questions about how to change the mupen64plus configuration on the raspberry Pi forums, given the aims of the device is to be educational and so has a higher proportion of inexperienced users of linux, I feel this 'Issue' is of low importance and more of an enhancement.
As a new user, I only set PREFIX for all the mupen64 builds. This placed everything in the right paths, but I needed to put full plugin paths to the .cfg file, and start the console ui with a --corelib arg. It would be useful if the core and plugin paths had defaults derived from PREFIX, the same defaults that the parts get placed in.
It fails to build under windows with:
x86_64-w64-mingw32.static-gcc: error: unrecognized command line option '-no-pie'
Please revert 187d3a3
I'm user of Debian I'm not sure if it's a problem only on Debian or maybe mupen64plus could have a way to fix it...
I only write: sudo apt-get install mupen64plus-qt and the list of roms it's impossible to show any rom
there anyone know some steps to fix it,I'd like to try some textures in those games and without a list of roms it cannot be done
Thanks in advance
Running mupen64plus-2.5.9 on OpenBSD -current.
I have a dual screen setup. If I run a game fullscreen or windowed, it generally plays just fine.
In fullscreen mode, if I move the mouse to the other (non‐mupen64plus) screen, mupen64plus’s graphics output disappears completely, and I can see and interact with the windows behind it. The game continues to play in the background (evidenced by the audio, anyway). I can’t find any way to get the window back. There’s no additional output in the terminal window, except for normal gameplay messages (“Initializing SDL audio subsystem,” etc.).
Nothing of the sort happens in windowed mode; I can move the cursor anywhere with no repercussions.
Tested with both glide64mk2 and rice, with identical results.
I'm doing some Ocarina of Time development and Mupen is the only emulator I can get on NixOS.
How can I view the various calls to osSyncPrint
in the game, and the ones I've added?
Thanks.
Commit 5b9eba4 (as I write, current master) is missing definitions for m64p_media_loader
and M64CMD_SET_MEDIA_LOADER
, resulting in build errors.
CC _obj/main.o
../../src/main.c:830:8: error: unknown type name ‘m64p_media_loader’
static m64p_media_loader l_media_loader =
^~~~~~~~~~~~~~~~~
../../src/main.c: In function ‘main’:
../../src/main.c:1028:26: error: ‘M64CMD_SET_MEDIA_LOADER’ undeclared (first use in this function)
if ((*CoreDoCommand)(M64CMD_SET_MEDIA_LOADER, sizeof(l_media_loader), &l_media_loader) != M64ERR_SUCCESS)
^~~~~~~~~~~~~~~~~~~~~~~
../../src/main.c:1028:26: note: each undeclared identifier is reported only once for each function it appears in
Makefile:321: recipe for target '_obj/main.o' failed
make: *** [_obj/main.o] Error 1
I create this ticket to continue the discussion from here: 334db80#commitcomment-24502858
Don't investigate now as I will try to isolate the bug more carefully.
I realize, in some situation, every requested screenshots (argument --testshots
) are not all generated.
I have a test suite that open a rom with a save state and save some screenshots. Generated command line looks like this:
./mupen64plus --resolution 640x480 --audio dummy --configdir ./ --nosaveoptions --testshots 2,5 --savestate mupen64plus-regression-test/save_state/1080sb-charselect.st0 --sshotdir mupen64plus-regression-test/screenshot /home/narann/code/repo/mupen64plus/mupen64plus-regression-test/rom/1080sb.z64
The second screenshot is never generated. Interestingly, I have around hundred tests and only 4-6 have this problem. It's not game related, maybe more save state related.
Looking at the code where the console ask for the screen shot:
https://github.com/mupen64plus/mupen64plus-ui-console/blob/master/src/main.c#L141
And how the core handle it:
As I understand the code, the core ask for a screenshot "next time" the video plugin reach video_plugin_render_callback
. But the console ask for M64CMD_STOP
as soon the last frame+1 is reached. This mean, the frame callback M64CMD_SET_FRAME_CALLBACK
is executed before the video plugin reach video_plugin_render_callback
and take its screenshot.
I will do some test to know if wait few frames after the latest screenshot before close the emulator could help...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.