mupen64plus / mupen64plus-ui-console Goto Github PK

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.

test_cp1252.zip

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:

https://github.com/mupen64plus/mupen64plus-core/blob/b9765eca453ed46773655c44bc86fbcdeb33ab7c/src/main/main.c#L725

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...

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.

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!

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

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

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...

It was noticed that 7b23651 breaks the build under mingw64:

x86_64-w64-mingw32.shared-gcc: error: unrecognized command line option '-no-pie'

This change was introduced with #65 after #61 was opened.

It fails to build under windows with:

x86_64-w64-mingw32.static-gcc: error: unrecognized command line option '-no-pie'

Please revert 187d3a3

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 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.

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

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.

#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.

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:

• 2.1
  • ConfigSaveSection
• 2.2
  • ConfigHasUnsavedChanges
• 2.3.1
  • ConfigExternalOpen

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.

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?

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.

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.

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.