Author Topic: Mupen64plus technical preview  (Read 28336 times)

codingcampbell

  • *
  • Posts: 25
Re: Mupen64plus technical preview
« Reply #20 on: November 13, 2015, 03:13:22 am »
4. [Super Smash Bros.] Oh, maybe a softlock caused by the JIT. Do you happen to know if it also happens in the interpreter?

Luckily the issue is quite reproducible on the JIT, usually under a minute of play. I gave the interpreter a 5min run and didn't see the issue. I wish I could offer some better debugging info here but GDB isn't showing that the program has stopped anywhere (and the music continues playing, so I guess not)

5. [Yoshi's Story] ...  try editing the file called gles2n64.conf to see if a setting allows you to see anything more than what you're seeing now. I suspect depth-test settings will make it work better, but it'll probably be slower.

Cool, I'll play around with this. I've tried poking the texture depth and disabling clipping, but no luck yet. I'll post an update if I find something.

As it relates to making frontends and per-game button mapping, can button maps actually be passed in as arguments to mupen? I guess, if not, the frontend could make a special config file per game to pass instead.

Anyway, thanks again for your hard work!

zhongtiao1

  • *
  • Posts: 246
Re: Mupen64plus technical preview
« Reply #21 on: November 13, 2015, 04:00:08 am »
Xena, talisman of fate seems to be running full speed except for animation at the beginning. The actual fighting and the menus work perfectly.

Nebuleon (OP)

  • *
  • Posts: 37
Re: Mupen64plus technical preview
« Reply #22 on: November 13, 2015, 08:08:12 am »
4. [Super Smash Bros.] Oh, maybe a softlock caused by the JIT. Do you happen to know if it also happens in the interpreter?

Luckily the issue is quite reproducible on the JIT, usually under a minute of play. I gave the interpreter a 5min run and didn't see the issue. I wish I could offer some better debugging info here but GDB isn't showing that the program has stopped anywhere (and the music continues playing, so I guess not)
ProTip:
Code: [Select]
./mupen64plus --verbose SMSH_PLS.N64 > crash_log.txtThe --verbose switch, combined with the file redirection, will create a huge log, containing the N64 and native address, as well as the opcode mnemonic, of every N64 instruction being recompiled. You may find that the writes to the card will freeze the emulator (and the sound!). Once you have a freeze with sound, you may hit Ctrl+C and it will stop the output. You may then use the 'less' command on the log to scroll back up to the last "Core: compiled ..." line, and look at the last trace that was compiled. If, every run, the freeze is triggered at the same address, or from the same instruction, that is an indication that an instruction on the N64 is consistently being incorrectly recompiled.

As it relates to making frontends and per-game button mapping, can button maps actually be passed in as arguments to mupen? I guess, if not, the frontend could make a special config file per game to pass instead.

Anyway, thanks again for your hard work!
I don't think an input mapping can be passed in via the command-line.

You're welcome btw :)
The Cloud is nice, but not if it decides to rain on your parade.

thefifthgiant

  • *
  • Posts: 108
Re: Mupen64plus technical preview
« Reply #23 on: November 13, 2015, 12:32:59 pm »
F-zero X: Climax (Hack):
Interpreter: A few glitches but pretty much full speed
JIT: same

Unfortunately, I have to take this back. I tested a time trial before (no opponents), but It didn't occur to me to try a GP race (30 racers), because I'm an idiot.

It actually runs about half-speed or so.

lemmywinks

  • ****
  • Posts: 2729
Re: Mupen64plus technical preview
« Reply #24 on: November 13, 2015, 02:10:46 pm »
Yeah, it'd make sense for Star Fox 64, but then other games that need L and R wouldn't get them, and so on. It's why a good frontend with per-game mappings would be better due to the GCW Zero not having enough buttons.

Most games don't use the L button so you are best off mapping it to Z. The only struggle you will have is with games that use the C buttons for aiming or camera controls.
Handhelds:
GPD Win, GPD XD 64gb, Pap KIII-Plus, 3DS XL, DSi XL, GBA SP, GBBC Clone, Gameboy Pocket, PSP Go
PC:
HP Envy M6
Acer 522
Psion 5 & 5MX

joebro88

  • *
  • Posts: 28
Re: Mupen64plus technical preview
« Reply #25 on: November 13, 2015, 02:22:48 pm »
This is so amazing, thanks a ton for all of the work. I'm going going to test this when I get home to see what runs well, can't wait! All I want now is USB controller support  ;)
R.I.P. in peace

Fluxchar

  • *
  • Posts: 127
Re: Mupen64plus technical preview
« Reply #26 on: November 13, 2015, 03:15:41 pm »
lol this thread is blowing up! this emulator will be complete in no time :p keep up the good work everyone.

pcercuei

  • ***
  • Posts: 1424
    • My devblog
Re: Mupen64plus technical preview
« Reply #27 on: November 13, 2015, 04:46:37 pm »
For the record, this alpha is the result of two years of almost uninterrupted work by Nebuleon - the fruit of many endless nights. The JIT has been rewritten from scratch six or seven times, everytime with new ideas.
It was a pleasure to follow its development, dirty-talk jit internals until the morning, discuss optimizations, laugh at the n64 games' very unoptimized code, debug funky bugs, etc.
So a well deserved round of applause for him.

Surkow

  • * Administrator
  • Posts: 573
Re: Mupen64plus technical preview
« Reply #28 on: November 13, 2015, 04:50:47 pm »
For Nebuleon, the main focus is the new MIPS JIT compiler - not the graphics. If you want to see graphical issues being solved, you can contribute by testing out different GLES based Mupen64Plus video plugins (like GlidenN64) or you can try to attract developers who are experienced writing GLES graphics code for embedded systems.

onthebridge

  • *
  • Posts: 108
Re: Mupen64plus technical preview
« Reply #29 on: November 13, 2015, 04:53:45 pm »
For the record, this alpha is the result of two years of almost uninterrupted work by Nebuleon - the fruit of many endless nights. The JIT has been rewritten from scratch six or seven times, everytime with new ideas.
It was a pleasure to follow its development, dirty-talk jit internals until the morning, discuss optimizations, laugh at the n64 games' very unoptimized code, debug funky bugs, etc.
So a well deserved round of applause for him.
Can this JIT  be reused in a play station emulator?

Quickman

  • *
  • Posts: 220
Re: Mupen64plus technical preview
« Reply #30 on: November 13, 2015, 05:06:19 pm »
Yeah, it'd make sense for Star Fox 64, but then other games that need L and R wouldn't get them, and so on. It's why a good frontend with per-game mappings would be better due to the GCW Zero not having enough buttons.

Most games don't use the L button so you are best off mapping it to Z. The only struggle you will have is with games that use the C buttons for aiming or camera controls.
Curious...
 If/when the analog control stick becomes active/usable, could the D pad be key-mapped as C- buttons? When playing nintendo 64, I remember rarely using the D pad because of the analog.  Not sure if this is possible nor how comfortable it would be, but just an idea.

thefifthgiant

  • *
  • Posts: 108
Re: Mupen64plus technical preview
« Reply #31 on: November 13, 2015, 06:06:25 pm »
Yeah, it'd make sense for Star Fox 64, but then other games that need L and R wouldn't get them, and so on. It's why a good frontend with per-game mappings would be better due to the GCW Zero not having enough buttons.

Most games don't use the L button so you are best off mapping it to Z. The only struggle you will have is with games that use the C buttons for aiming or camera controls.
Curious...
 If/when the analog control stick becomes active/usable, could the D pad be key-mapped as C- buttons? When playing nintendo 64, I remember rarely using the D pad because of the analog.  Not sure if this is possible nor how comfortable it would be, but just an idea.

There are a few great games that need the d-pad. As suggested before, per-game bindings is the solution. You can map them however you want then  ;)

Quickman

  • *
  • Posts: 220
Re: Mupen64plus technical preview
« Reply #32 on: November 13, 2015, 06:41:28 pm »



((---There are a few great games that need the d-pad. As suggested before, per-game bindings is the solution. You can map them however you want then  ;) ---))


Ah, gotcha. Thanks.
 I guess I was just more curious if it were possible. But, definitely what you said sounds way better :D

Nebuleon (OP)

  • *
  • Posts: 37
Re: Mupen64plus technical preview
« Reply #33 on: November 13, 2015, 07:26:14 pm »
For the record, this alpha is the result of two years of almost uninterrupted work by Nebuleon - the fruit of many endless nights. The JIT has been rewritten from scratch six or seven times, everytime with new ideas.
It was a pleasure to follow its development, dirty-talk jit internals until the morning, discuss optimizations, laugh at the n64 games' very unoptimized code, debug funky bugs, etc.
So a well deserved round of applause for him.
Yep. I didn't forget about you, pcercuei! I just didn't want people to jump on you too about this JIT.

But I do remember the first 4 attempts, and how you would help by implementing opcodes (both a few on the N64, as well as the native instruction emitters) for the first two of them, even though the design of the JIT itself was crap and not allowing the generated code to be much faster than the interpreter. And then, for the next attempts, you were there to give feedback on ideas, and yet more ideas to implement. The "daily Conker breakage", the really bad code in N64 games. That was really fun!

Thank you for your support during all this time :)
The Cloud is nice, but not if it decides to rain on your parade.

ruffnutts

  • ****
  • Posts: 2667
Re: Mupen64plus technical preview
« Reply #34 on: November 13, 2015, 07:47:39 pm »
Wow truly amazing... Thanks Nebuleon nice to see you back on the boards :D

P.S I need to try goldeneye at some point :)
« Last Edit: November 13, 2015, 08:49:20 pm by ruffnutts »

toto

  • *
  • Posts: 147
Re: Mupen64plus technical preview
« Reply #35 on: November 13, 2015, 09:31:30 pm »
Couldn't believe it when I saw it  :o . Thanks nebuleon! I tried Zelda ocarina of time with not so much hope but guess what, runs slow but it's not that bad. I just ran a little bit in kokiri village and It's pretty good. Guys your are genuis! Thanks!

Quickman

  • *
  • Posts: 220
Re: Mupen64plus technical preview
« Reply #36 on: November 13, 2015, 10:16:35 pm »
Wow truly amazing... Thanks Nebuleon nice to see you back on the boards :D

P.S I need to try goldeneye at some point :)

 Goldeneye!  Need to see this in action :D
capture & share if you can!

superfenix2020

  • *
  • Posts: 222
Re: Mupen64plus technical preview
« Reply #37 on: November 13, 2015, 10:37:34 pm »
Nebuleon, great job.
thank you very much for giving us a new emulator for our Zeros.  :)


edit:
I have a question for you:
is it possible ports emulators of Sharp X6800 and Sega Saturn in GCW-Zero?
« Last Edit: November 13, 2015, 10:41:09 pm by superfenix2020 »

gameblabla

  • **
  • Posts: 759
Re: Mupen64plus technical preview
« Reply #38 on: November 13, 2015, 11:18:52 pm »
I'm speechless, congrats Nebuleon !
I honestly didn't know you worked that hard on it, i thought you just gave up working on it.

Anyway, now i can sleep easy tonight without worrying about gcw0's owners asking for a n64 emulator.
Might give it a try on my zero too.

Quote
is it possible ports emulators of Sharp X6800 and Sega Saturn in GCW-Zero?
Damnit,
this has already been answered :
There's Px86 but it's a buggy piece of shit and yabause do not officially have a SDL port. (though one could port it to gcw0 using ptitseb's fork)
If Yabause ever gets ported to zero, it will be too slow anyway.

thefifthgiant

  • *
  • Posts: 108
Re: Mupen64plus technical preview
« Reply #39 on: November 14, 2015, 03:16:44 am »
Ok, a few more games tested:

Bangaioh
Interpreter: black screen
JIT: black screen

Beetle Adventure Racing
Interpreter: very slow
JIT: slightly faster but not playable, graphic ok too

Doom 64
Interpreter: Super slow, crazy graphics
JIT: little faster, graphics still bad (can't play)

Pokemon snap
Interpreter: slow but ok
JIT: faster, almost playable

Rayman 2
Interpreter: super slow, missing some missing effects in menus and cinematics
JIT: same issues, slightly faster, but still unplayable

Tetrispere
Interpreter: slow, graphics ok
JIT: much faster/smoother, quite playable

Turok
Interpreter: not bad overall, still sluggish
JIT: looks good, plays good so far! (controls are lacking, cant get far into the level to test further)

It's interesting because some of the games I expect to run well don't, and some ran better than expected. So far I haven't found any cases where the JIT performed worse than the interpreter, so good news I guess. I'll keep testing!

 

Post a new topic