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
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 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...
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.
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!
#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.
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.
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.
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?
It fails to build under windows with:
x86_64-w64-mingw32.static-gcc: error: unrecognized command line option '-no-pie'
Please revert 187d3a3
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.
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 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 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'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.
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
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...
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.