Shin_Gouki
New member
Still nothing, but thx anyway and so we wait for the QT UI release 
Still nothing, but thx anyway and so we wait for the QT UI release![]()
Is there a way to increase the size of the game window? In the "Glide64.ini" file I'm able to change scale_x and scale_y to adjust the resolution, but I haven't been able to find a setting to change the window size to match. Am I missing something?
Great job, by the way. The "InputAutoCfg.ini" is an excellent addition to the project, and I look forward to future releases.
./run_arach.sh --resolution (800x600) example.v64
Try removing ( and ) like:
mupen64plus-ui-console.exe --resolution 800x600
Johns-Abacus:Mupen64Plus john$ ./run_rice.sh --resolution 800x600 example.v64
__ __ __ _ _ ____ _
| \/ |_ _ _ __ ___ _ __ / /_ | || | | _ \| |_ _ ___
| |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|
| | | | |_| | |_) | __/ | | | (_) |__ _| __/| | |_| \__ \
|_| |_|\__,_| .__/ \___|_| |_|\___/ |_| |_| |_|\__,_|___/
|_| http://code.google.com/p/mupen64plus/
Mupen64Plus Console User-Interface Version 1.99.3
UI-console: attached to core library 'Mupen64Plus Core' version 1.99.3
Includes support for Dynamic Recompiler.
Error: couldn't open ROM file '--resolution' for reading.
Johns-Abacus:Mupen64Plus john$ ./run_rice.sh Rom\ name\ with\ spaces.N64
__ __ __ _ _ ____ _
| \/ |_ _ _ __ ___ _ __ / /_ | || | | _ \| |_ _ ___
| |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|
| | | | |_| | |_) | __/ | | | (_) |__ _| __/| | |_| \__ \
|_| |_|\__,_| .__/ \___|_| |_|\___/ |_| |_| |_|\__,_|___/
|_| http://code.google.com/p/mupen64plus/
Mupen64Plus Console User-Interface Version 1.99.3
UI-console: attached to core library 'Mupen64Plus Core' version 1.99.3
Includes support for Dynamic Recompiler.
Warning: unrecognized command-line parameter 'Rom'
Warning: unrecognized command-line parameter 'name'
Warning: unrecognized command-line parameter 'with'
Error: couldn't open ROM file 'spaces.N64' for reading.
./mupen64plus.app/Contents/MacOS/mupen64plus
--corelib ./mupen64plus.app/Contents/MacOS/libmupen64plus.dylib
--plugindir ./mupen64plus.app/Contents/MacOS
--gfx mupen64plus-video-rice
--resolution 800x600 example.v64
./run_rice.sh --resolution 800x600 example.v64
EDIT: another way is to edit the .sh file, and replace $1 with $*. Then your line will work.
I'm having some trouble changing the default key mappings for Mupen64Plus. The keys shown at http://code.google.com/p/mupen64plus/wiki/KeyboardSetup don't quite match up with the mappings in the InputAutoCfg.ini file. InputAutoCfg.ini has the d-pad mapped to number pad keys (new Macs don't have these by default) and the analog stick mapped to the arrow keys, but the documentation on the Google Code page shows W, S, A, and D and the arrow keys being used.
I had a similar problem when trying to open rom names with spaces in them, even if they were preceded by a "\":
I guess the command-line UI is searching for a rom so hard that it gets a little huffy when spaces are thrown into the mix.
Also I read about the launcher effort, and I'm thinking about writing one in Qt.
Hopefuly I'll start this week-end, and I'll post first results here.
For sure, the goal is to have a cross-platform launcher, tho I'll only be able to
develop and test on Windows (Vista 32bits) and Ubuntu (9.04 64bits).
Just wanted to let you know so we don't waste time starting 2 (or more ;-) different
projects at the same time.
I guess you can contact me through the forum if need be.
Thanks again, and have a good week-end :flowers:
Vkn, great to hear about your interest in the project. I would encourage you to write a true front-end application using the shared library API, and not just a launcher which runs the command-line front-end through the shell. The reason for this is that a launcher is of limited use - it can only start games and set up some already-known options. A true front-end application is more complicated to write but also more powerful; it can do things like control the emulator while it is running, support rom debugging, set up all configuration parameters, retrieve detailed ROM information for display in the ROM browser, and allow more user-friendly logging/debug information from the core.
Seconded. sadly i didn't knew about the shared api before i started to write the launcher otherwise it would be different by now... anyways i made a quick solution for now until the real one is done... and just as you mentioned you have better control of the whole thing using it which without doubts is the way to go.