Author Topic: Mupen64plus technical preview  (Read 37596 times)

xXFrostXx

  • * Former Staff
  • Posts: 234
Re: Mupen64plus technical preview
« Reply #60 on: November 16, 2015, 12:55:41 am »
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.
Dingoonity is the place to be!

Nebuleon (OP)

  • Posts: 37
Re: Mupen64plus technical preview
« Reply #61 on: November 16, 2015, 12:57:29 am »
Banjo-Tooie no longer freezes on startup, but the screen turns black partway into the opening cutscene. Audio continues, but video doesn't.
Does this occur with the JIT, and not with the interpreter?
The Cloud is nice, but not if it decides to rain on your parade.

codingcampbell

  • Posts: 25
Re: Mupen64plus technical preview
« Reply #62 on: November 16, 2015, 01:08:18 am »
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

xXFrostXx

  • * Former Staff
  • Posts: 234
Re: Mupen64plus technical preview
« Reply #63 on: November 16, 2015, 01:33:51 am »
Does this occur with the JIT, and not with the interpreter?

It happens with the JIT. I just tested it with the interpreter (due to lag it took awhile to get through the opening cutscene), but I did get into the game. So, it only happens with the JIT.

Once you get into the game, everything besides Bottles and Banjo has no textures, but that likely has to do with the current video plugin.
« Last Edit: November 16, 2015, 01:38:44 am by xXFrostXx »
Dingoonity is the place to be!

Nebuleon (OP)

  • Posts: 37
Re: Mupen64plus technical preview
« Reply #64 on: November 16, 2015, 02:23:56 am »
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?

The Cloud is nice, but not if it decides to rain on your parade.

xXFrostXx

  • * Former Staff
  • Posts: 234
Re: Mupen64plus technical preview
« Reply #65 on: November 16, 2015, 02:43:01 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.
Dingoonity is the place to be!

Nebuleon (OP)

  • Posts: 37
Re: Mupen64plus technical preview
« Reply #66 on: November 16, 2015, 03:01:43 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.
The Cloud is nice, but not if it decides to rain on your parade.

xXFrostXx

  • * Former Staff
  • Posts: 234
Re: Mupen64plus technical preview
« Reply #67 on: November 16, 2015, 03:18:51 am »
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.

That was probably what happened, then. At least it's an extremely rare occurrence. :D
Dingoonity is the place to be!

care16la20

  • Posts: 178
Re: Mupen64plus technical preview
« Reply #68 on: November 16, 2015, 12:09:19 pm »
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 ?

Nebuleon (OP)

  • Posts: 37
Re: Mupen64plus technical preview
« Reply #69 on: November 16, 2015, 07:21:49 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?
The Cloud is nice, but not if it decides to rain on your parade.

care16la20

  • Posts: 178
Re: Mupen64plus technical preview
« Reply #70 on: November 16, 2015, 10:13:17 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...

Nebuleon (OP)

  • Posts: 37
Re: Mupen64plus technical preview
« Reply #71 on: November 16, 2015, 10:25:51 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.
The Cloud is nice, but not if it decides to rain on your parade.

care16la20

  • Posts: 178
Re: Mupen64plus technical preview
« Reply #72 on: November 17, 2015, 01:54:11 am »
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.....

Nebuleon (OP)

  • Posts: 37
Re: Mupen64plus technical preview
« Reply #73 on: November 17, 2015, 02:07:29 am »
b) Whenever the audio is silence, it's not because audio is having trouble. It's because the steps required to get the emulated N64 in a state where it can emit sound are not done by the time the GCW Zero's sound hardware requests more sound. The N64 CPU and graphics are not done, so the audio doesn't get done, either.
The Cloud is nice, but not if it decides to rain on your parade.

David Knight

  • Posts: 577
Re: Mupen64plus technical preview
« Reply #74 on: November 17, 2015, 09:25:56 am »
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

Code: [Select]
[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.

Code: [Select]
[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 :)
« Last Edit: November 17, 2015, 10:31:25 am by David Knight »

David Knight

  • Posts: 577
Re: Mupen64plus technical preview
« Reply #75 on: November 17, 2015, 10:21:41 am »
Checking out the controller design for the N64 (I have no experience of using this controller so I looked here) it seems there are three methods of usage:

1) Traditional "2D"
D-pad, A, B, L, R, C1-4
2)FPS style "3D"
Analogue, Z, A, B, L, R, C1-4
3)Dual controller
Dual analogue, Z, Z

Is this correct?

pcercuei

  • Posts: 1643
    • My devblog
Re: Mupen64plus technical preview
« Reply #76 on: November 17, 2015, 10:45:40 am »
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.

David Knight

  • Posts: 577
Re: Mupen64plus technical preview
« Reply #77 on: November 17, 2015, 02:24:05 pm »
However some users have non-functioning analogue controls so it is preferable to have analogue off by default but easily toggled from the menu.

My thoughts on control configuration is that there should be a number of pre-defined control settings which can then be further refined on a case by case basis. Current configuration should be easily accessible from the menu (perhaps forming the menu background?).

Most apps use a combination of START + SELECT or pushing the power switch up to access the menu so I propose both are implemented.

Apart for sound and graphics/performance setting tweaks and save states are there are any other requirements?

EDIT
Perhaps during setup it can check the analogue values to see if they are registering maximum values and toggle off?

Also a progress bar during file loading/conversion would be useful.
« Last Edit: November 17, 2015, 03:45:24 pm by David Knight »

lemmywinks

  • Posts: 2834
Re: Mupen64plus technical preview
« Reply #78 on: November 17, 2015, 06:11:22 pm »
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.
Handhelds:
GPD Win, GPD XD 64gb, PlayGo, RS-90, 3DS XL, DSi XL, GBA SP, GBBC Clone, Gameboy Pocket, PSP Go
PC:
Medion Erazer, Toshiba Z20t, Dell Mini 9, Psion 5MX
Tons of other old laptops and tablets.....

Quickman

  • Posts: 220
Re: Mupen64plus technical preview
« Reply #79 on: November 17, 2015, 06:44:38 pm »
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.

 With certain games you were able to enter codes and/or modify settings in order to use 2 separate controllers at once functioning as one,  for the purpose of.. as he stated,
 "dual controller:
2-analog
&
2 Z-buttons. "

I think that's all that he meant. I do not think he was trying to say that the Nintendo 64 controller had two analog sticks.