Dingoonity.org

The following bug reports that existed before this post are now invalid pending re-testing:

• Super Smash Bros. Kirby inhaling attack freeze
• Banjo-Tooie intro freeze
• Mario Kart 64 race retry freeze

Banjo-Tooie no longer freezes on startup, but the screen turns black partway into the opening cutscene. Audio continues, but video doesn't.

The following bug reports that existed before this post are now invalid pending re-testing:

• Super Smash Bros. Kirby inhaling attack freeze

This one is looking good on my Zero! Played a full 5min without any freeze

Banjo-Tooie no longer freezes on startup, but the screen turns black partway into the opening cutscene. Audio continues, but video doesn't.

You mean the part of the opening cutscene where I get control of Banjo and enter his house?

Quote from: Nebuleon on November 16, 2015, 02:23:56 am

You mean the part of the opening cutscene where I get control of Banjo and enter his house?

No, it was towards the end of the opening cutscene when the screen turned black and didn't continue. If you got into the game on JIT, then it could have been a one time graphics issue from the plugin. I wasn't sure if it was a bug or not, so I just tested it again and got into the game, so I guess it had to do with the plugin.

Then, you may have had the same issue I had one time while running Donkey Kong 64.

Here's a paste: http://pastebin.com/kHCFgTPK

Starting at line 47, the screen progressively lost its textures, rendering only colored triangles, and then became fully black. The recompiler, audio and input (and thus probably the game logic itself) kept on rolling even in the face of this lack of video memory.

Etnaviv -- the (reversed) name for the reverse-engineered graphics driver for Vivante graphics cores which is used by the GCW Zero -- is responsible for this line. You may have seen it in the Log Viewer if it was enabled and you took that log before running Mupen64plus again.

The code displaying that message is here: https://github.com/laanwj/etna_viv/blob/fb0d77d/src/driver/etna_resource.c#L234

This was a very odd bug which I encountered only twice during my entire testing. (The other time, it was in Goldeneye; it lost textures for literally 3 seconds and then recovered.) The bug is frustratingly difficult to narrow down due to not being handily reproducible.

Ah, ShadowGate 64 and Castlevania gives a black screen on startup

Shadowgate probably plays at full speed because the gfx are simple and there isnt too much things moving simultaneously on the screen (Like Myst)

Curious question:
- In the current build, is it worth to disable sound ?

Quote from: care16la20 on November 16, 2015, 12:09:19 pm

a) Ah, ShadowGate 64 and Castlevania gives a black screen on startup

Shadowgate probably plays at full speed because the gfx are simple and there isnt too much things moving simultaneously on the screen (Like Myst)

Curious question:
b) - In the current build, is it worth to disable sound ?

a) Does this happen in the JIT and not the interpreter? And did you get the Nov 15 build before (re-)testing?

b) Why would you?

Hi,
a) will try right now; Was using the first JIT

b) Performance reasons.... On old days of emulation (Pentium computers), usually sound eated most of the processor for the emulation so thats why I asked...

Quote from: care16la20 on November 16, 2015, 10:13:17 pm

a) will try right now; Was using the first JIT

b) Performance reasons.... On old days of emulation (Pentium computers), usually sound eated most of the processor for the emulation so thats why I asked...

a) Alright, but in the future, please at least check the opening post (OP) to see if what you're running is still the latest - I put the date in ISO 8601 format in the OPK's name.

b) You're probably right about old emulators for even older systems having more CPU-intensive audio. The SNES, in particular, had 8 independent sample-based channels that could be panned (stereo), echoed, and frequency modulated, and this was very taxing to emulate.

However, the N64 uses relatively simple sound compared to its graphics. On the GCW Zero, time spent in audio emulation (including the emulation itself and the forwarding to audio hardware) is around 5%, and graphics emulation time (including the emulation itself, the preparation for forwarding to graphics hardware, the forwarding itself, and graphics driver code) is 40%-60%.

The graphics are the current bottleneck.

Hi, thanks for the explanation

a) same result on the latest JIT release ; Castlevania Legacy of darkness gives black screen and them kicks back to dingux

b) ah okay, thought it would be something like 20% more performance gain but them its almost useless....
But one thing I noticed is some struggling to play some audios... For example, Mario Kart when passing trough the finish line.... And on some other games I noticed this quick slowdown when loading some samples too.....

My apologies for not getting to this project sooner, I'm just going through your build instructions Nebuleon, nice job!

EDIT looks like I spoke too soon 

I'm getting warnings/errors when compiling core

[email protected]:~/Projects/mupen64plus-build$ make -f Makefile.gcw0
sed "s/DATE/2015-11-17 10:04:28 UTC/g" default.gcw0.desktop > out/default.gcw0.desktop
make -C ../mupen64plus-core/projects/unix PKG_CONFIG="env PKG_CONFIG_SYSROOT_DIR=/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot PKG_CONFIG_LIBDIR=/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot/usr/lib/pkgconfig pkg-config" SDL_CONFIG="/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot/usr/bin/sdl2-config" USE_GLES=1 all
make[1]: Entering directory `/home/david/Projects/mupen64plus-core/projects/unix'
Makefile:124: Architecture "mips" not officially supported.'
    CC  _obj/main/sra_file.o
    CC  _obj/main/workqueue.o
    CC  _obj/memory/memory.o
    CC  _obj/pi/cart_rom.o
    CC  _obj/pi/flashram.o
    CC  _obj/pi/pi_controller.o
    CC  _obj/pi/sram.o
    CC  _obj/plugin/emulate_game_controller_via_input_plugin.o
    CC  _obj/plugin/emulate_speaker_via_audio_plugin.o
    CC  _obj/plugin/get_time_using_C_localtime.o
    CC  _obj/plugin/rumble_via_input_plugin.o
    CC  _obj/plugin/plugin.o
    CC  _obj/plugin/dummy_video.o
    CC  _obj/plugin/dummy_audio.o
    CC  _obj/plugin/dummy_input.o
    CC  _obj/plugin/dummy_rsp.o
    CC  _obj/r4300/r4300.o
    CC  _obj/r4300/cached_interp.o
    CC  _obj/r4300/cp0.o
    CC  _obj/r4300/cp1.o
    CC  _obj/r4300/exception.o
    CC  _obj/r4300/instr_counters.o
    CC  _obj/r4300/interupt.o
    CC  _obj/r4300/mi_controller.o
    CC  _obj/r4300/pure_interp.o
    CC  _obj/r4300/r4300_core.o
    CC  _obj/r4300/recomp.o
    CC  _obj/r4300/reset.o
    CC  _obj/r4300/tlb.o
    CC  _obj/rdp/fb.o
    CC  _obj/rdp/rdp_core.o
    CC  _obj/ri/rdram.o
    CC  _obj/ri/rdram_detection_hack.o
    CC  _obj/ri/ri_controller.o
    CC  _obj/rsp/rsp_core.o
    CC  _obj/si/af_rtc.o
    CC  _obj/si/cic.o
    CC  _obj/si/eeprom.o
    CC  _obj/si/game_controller.o
    CC  _obj/si/mempak.o
    CC  _obj/si/n64_cic_nus_6105.o
    CC  _obj/si/pif.o
    CC  _obj/si/rumblepak.o
    CC  _obj/si/si_controller.o
    CC  _obj/vi/vi_controller.o
    CC  _obj/osal/dynamiclib_unix.o
    CC  _obj/osal/files_unix.o
    CC  _obj/r4300/empty_dynarec.o
    CC  _obj/main/zip/ioapi.o
    CC  _obj/main/zip/zip.o
    CC  _obj/main/zip/unzip.o
    CXX _obj/osd/screenshot.o
    LD  libmupen64plus.so.2.0.0
if [ "libmupen64plus.so.2" != "" ]; then ln -sf libmupen64plus.so.2.0.0 libmupen64plus.so.2; fi
make[1]: Leaving directory `/home/david/Projects/mupen64plus-core/projects/unix'
cp ../mupen64plus-core/projects/unix/libmupen64plus.so.2.0.0 out/libmupen64plus.so.2.0.0
ln -sf libmupen64plus.so.2.0.0 out/libmupen64plus.so.2
make -C ../mupen64plus-input-sdl/projects/unix PKG_CONFIG="env PKG_CONFIG_SYSROOT_DIR=/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot PKG_CONFIG_LIBDIR=/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot/usr/lib/pkgconfig pkg-config" SDL_CONFIG="/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot/usr/bin/sdl2-config" USE_GLES=1 all
make[1]: Entering directory `/home/david/Projects/mupen64plus-input-sdl/projects/unix'
Makefile:114: *** CPU type "mips" not supported.  Please file bug report at 'http://code.google.com/p/mupen64plus/issues'.  Stop.
make[1]: Leaving directory `/home/david/Projects/mupen64plus-input-sdl/projects/unix'
make: *** [input-sdl] Error 2

I'm using the 'gcw0' branches of core and input-sdl from Nebuleons git repo.

[email protected]:~/Projects/mupen64plus-core$ git checkout gcw0
Already on 'gcw0'

EDIT 2

I was using Nebuleons repo instead of the mupen64 repo, it compiles fine now

Yes. The "FPS style" is the one used by 99% of the games. Most of them didn't even use the L button, or they used them for a very minor feature (hide the map on OOT, reduce the music volume on Mario Kart...).

What I used for testing Mupen for the last 2 years:
GCW0 -> N64
analog -> analog
d-pad  -> C buttons
L          -> Z
R         -> R
start    -> START
select -> L
B         -> A
X         -> B (to match the position of the buttons on the N64)
Y         -> C up
A         -> C right

This worked fine for all the games I used to test Mupen.

3)Dual controller
Dual analogue, Z, Z

There is no 2nd analog on the N64, this is why Goldeneye and Perfect Dark are pretty horrible to play these days, they use the analog for turning (not strafing) and moving backwards/forwards and the C buttons for strafing and looking up and down.

It also only has one Z trigger (behind the analog stick prong) so this would replace L when using the analog stick and the right trigger would be used with the other hand.