Dingoonity.org
GCW Zero => Development => Topic started by: Nebuleon on November 12, 2015, 08:26:15 am
-
Hey guys!
Now that I have your attention... I'd like you guys to test Mupen64plus. (No, this wasn't a bait-and-switch topic.)
Before reading further, please heed Surkow's warnings about this thread in posts #3 (http://boards.dingoonity.org/gcw-development/mupen64plus-technical-preview/msg133815/#msg133815) and #28 (http://boards.dingoonity.org/gcw-development/mupen64plus-technical-preview/msg133879/#msg133879). tl;dr Support of games is not guaranteed. Full-speed gameplay is not guaranteed.
It's the result of 2 years of trying things with JIT compilation and finally arriving at a result I like. I'll spare you guys the technical details, but the JIT is much faster than the interpreter at doing its job. There are other jobs to do in an N64 emulator, like emulating the RSP and RDP, and handling video and audio, so while the task of emulating the CPU is much faster, all the other tasks are still running at the same speed, which may not be enough. I'm in the process of cleaning up the one massive commit that I wrote everything into, and writing documentation about the technical details so that interested people may read about everything.
So, while I'm fairly certain the JIT should be compatible with all the games the interpreter is compatible with (which is quite a lot of them), I'm not really able to test all games, so I'd like you guys' help on this, as well as a few more requests at the end of this post.
Here are two builds of Mupen64plus. The first is the highly compatible, but slow, interpreter build. It is the reference implementation that the JIT compiler should run like. The second is the faster JIT compiler build. If it doesn't run a game like the interpreter does, that's a bug.
Interpreter build: https://dl.dropboxusercontent.com/u/106475413/gcw-zero/preview/mupen64plus-interp.opk
JIT build (updated 2015-11-15): https://dl.dropboxusercontent.com/u/106475413/gcw-zero/preview/mupen64plus-alpha-20151115.opk
Source code is at the end of this post.
These are bare emulator builds. The usual gmenu2x file selector allows you to select uncompressed .n64, .v64 or .z64 format ROMs. There is no frontend with which to rewind, save states, modify configuration, or any of that.
When launching a ROM, especially one that is 16 MiB in size or more, please note that the GCW Zero will need to read, hash (for lookups in the ROM database, keyed on the MD5 hash) and byte-swap (the Nintendo 64 is big-endian, and the GCW Zero is little-endian) the ROM. It is a time-consuming task, which contributes to high startup time.
-- Controls --
You should be able to use the following controls to play N64 games:
(GCW Zero button = N64 button)
D-pad, A, B, Start, L Trigger, R Trigger = Same
D-pad = Analog
D-pad = D-pad
Analog = Nothing
Y = Z Trigger
X = C Button Left
Select = (Exit emulator)
The lack of analog nub mapping in this test version is due to mupen64plus-input-sdl not allowing a keyboard and a joystick to be used for the same player, as well as my lack of interest to investigate that due to my test GCW Zero having an analog nub that constantly reads fully up and to the left as soon as it's a little bit off-center, which makes using the analog nub aggravating.
As for the C Buttons, only C Button Left is mapped, because the GCW Zero has insufficient inputs, and A and B are pretty important.
-- My requests to everyone --
- I'm no good when it comes to frontends. I'd like it if a frontend better than a bare emulator could be built. I would then include the frontend in the OPK if its license allows for that.
- I'm no good when it comes to 3D and OpenGL (desktop or embedded). The graphics look odd in some games, but if they look as odd on the JIT as they do on the interpreter, I can't do much about that. Perhaps one of you could build gonetz's GlideN64 plugin and see if it's fast enough and compatible with OpenGL ES 2, or help fix it or report bugs if not. And then I could also include that in the OPK.
- The input mapping may need adjustment per game to fit with the GCW Zero's buttons, of which there are fewer than on a Nintendo 64 controller. That would require per-game configuration in a frontend, similar to how ReGBA does it.
- With that in mind, please report bugs in the JIT and I'll be happy to investigate them.
Improvements, praise and hate mail all go here! GitHub will be better for JIT bug reports, but they may go here too. Post away!
-- Source code that went into this release --
https://github.com/mupen64plus/mupen64plus-ui-console
https://github.com/Nebuleon/mupen64plus-core/commits/trace-jit-experimental
https://github.com/mupen64plus/mupen64plus-input-sdl
https://github.com/mupen64plus/mupen64plus-audio-sdl
https://github.com/mupen64plus/mupen64plus-rsp-hle
https://github.com/Nebuleon/mupen64plus-video-gles2n64 (this is based on a gles2n64 source dump, itself based on the GLN64 source code)
-
Glad to see you back on the boards, you were sorely missed
-
Glad to see you back on the boards, you were sorely missed
First of all, this. It's good to see you again nebuleon!
Secondly, wow! I thought that the possibility of an n64 emulator being worked on was killed off already. This thread will be swarming with posts soon I bet ;)
I'll do some testing when I get home later tonight and report back!
-
Just as a reminder, although the Mupen64Plus technical preview work is impressive and exciting, end-users should not arrive here with the wrong expectations. Do not ask for support of specific games or if or when games become "faster". It is a work in progress and there is no guarantee of games being playable whatsoever.
Posting about game compatibility is fine, including any bugs you might encounter.
-
Awesome stuff Neb!
Looking forward to test and play around with later.
-
Good to see you back!
Tested F-Zero X and Paper Mario, apart from some graphical glitches and weird textures, is impressive how well they run.
Screenshots for the curious:
(http://i68.tinypic.com/beyqmo.png)
(http://i64.tinypic.com/15i2t0z.png)
(http://i63.tinypic.com/29wonqf.png)
(http://i68.tinypic.com/6i5krl.png)
(http://i68.tinypic.com/35ipvnn.png)
-
wow... will do testing when I get home. great to see nebu again
-
WOW. Great job Nebuleon! And thanks for coming back :)
Will test later today
-
This post made me squeal like a 13-year-old girl !!!
It's amazing to see the possibility still remains! So exciting, I can't say it enough, this is just so exciting!
Thank you
for all of your incredible work Neb!
if no one thanks you enough, allow me to do so at this exact moment,
thank you x 100,000,000,000,000,000,000,000,000,000 !!!
(I cannot remember how many zeros are in a Googolplex...I think 100, but just know that's what I was going for)
Can't wait to test :) :) :D
THANK YOU!!
-
Also if anyone would like to post YouTube video/quick clips of Nintendo 64 working emulation for comparison reasons and speed, I'd love to test and compare with others. Video footage always helps me greatly with bugs and glitches. Either way I'm very excited
And this is huge.
@Greetdeath how would you say your speed was (in percentage %) on the game photos you posted? Which emu build did you go with?
-
-- My requests to everyone --
- I'm no good when it comes to frontends. I'd like it if a frontend better than a bare emulator could be built. I would then include the frontend in the OPK if its license allows for that.
- I'm no good when it comes to 3D and OpenGL (desktop or embedded). The graphics look odd in some games, but if they look as odd on the JIT as they do on the interpreter, I can't do much about that. Perhaps one of you could build gonetz's GlideN64 plugin and see if it's fast enough and compatible with OpenGL ES 2, or help fix it or report bugs if not. And then I could also include that in the OPK.
- The input mapping may need adjustment per game to fit with the GCW Zero's buttons, of which there are fewer than on a Nintendo 64 controller. That would require per-game configuration in a frontend, similar to how ReGBA does it.
- With that in mind, please report bugs in the JIT and I'll be happy to investigate them.
I'll happy help out with coding the frontend, although I'd need help with any graphics assets.
-
Nice to see you again and thank you very much for your work!!
-
Thank you nebuleon for your support, im glad you come back here :3
-
Hi, for an alpha version: SUPERB RELEASE
Tried the JIT only with some games and:
- Mario Kart is FULL SPEED on time attack on most of the tracks
- Mario 64 is almost full speed but playable as I saw so far
- Harvest Moon 64 is almost full speed; Totally playable
- Quest 64 seems to be good speed but lacks the analog control so you cant move
- Yoshi Story is full speed but gfx is not good at all
- Cruisin USA stucks on a msg about mem card on the beginning
- Some games like Blast Corps only show the Nintendo logo and dont go further
- Banjo Kazzoie is FULL SPEED on not so large open areas (i was not going to try that one to not being disappointed and BANG !)
Again, superb alpha release Thanksssss
-
Hi, for an alpha version: SUPERB RELEASE
Tried the JIT only with some games and:
- Mario Kart is FULL SPEED on time attack on most of the tracks
- Mario 64 is almost full speed but playable as I saw so far
- Harvest Moon 64 is almost full speed; Totally playable
- Quest 64 seems to be good speed but lacks the analog control so you cant move
- Yoshi Story is full speed but gfx is not good at all
- Cruisin USA stucks on a msg about mem card on the beginning
- Some games like Blast Corps only show the Nintendo logo and dont go further
- Banjo Kazzoie is FULL SPEED on not so large open areas (i was not going to try that one to not being disappointed and BANG !)
Again, superb alpha release Thanksssss
@care16la20
This is so exciting! Thanks for all the feedback! I'll definitely be comparing notes to what I see on this thread.
You guys are the best, thank you so much for all your hard work!
Again, THIS IS SO EXCITING :)
-
Ok, here we go, I tested a few games after work. Note that I wasn't able to have my volume on so I can't comment on sound.
Conkers Bad Fur Day:
Interpreter: Very slow, graphical glitches
JIT: same, but slightly faster
F-zero X: Climax (Hack):
Interpreter: A few glitches but pretty much full speed
JIT: same
Majora's Mask:
Interpreter: Very slow
JIT: slightly faster, still unplayable
Megaman 64:
Interpreter: Slow, but graphics looked good
JIT: not much different
The New Tetris:
Interpreter: reasonable speed, lots of graphical glitches (the pieces don't even show up!)
JIT: same
Ogre Battle 64:
Interpreter: graphics good, super slow intro (I was too impatient to wait for gameplay :P)
JIT: Same, perhaps a little faster
Pokemon Stadium 2:
Interpreter: reasonable speed, a few graphics issues
JIT: same
Super Smash Bros.:
Interpreter: very slow
JIT: Same
Turok 2:
Interpreter: slow, graphics pretty good
JIT: Same, but somewhat faster
And because I was curious/optimistic/naive about the possibilities...
World Driver Championship
Interpreter: crash on boot (no surprise there)
JIT: crash on boot
-
Hi, for an alpha version: SUPERB RELEASE
Tried the JIT only with some games and:
- Mario Kart is FULL SPEED on time attack on most of the tracks
- Mario 64 is almost full speed but playable as I saw so far
- Harvest Moon 64 is almost full speed; Totally playable
a) - Quest 64 seems to be good speed but lacks the analog control so you cant move
- Yoshi Story is full speed but gfx is not good at all
- Cruisin USA stucks on a msg about mem card on the beginning
b) - Some games like Blast Corps only show the Nintendo logo and dont go further
- Banjo Kazzoie is FULL SPEED on not so large open areas (i was not going to try that one to not being disappointed and BANG !)
Again, superb alpha release Thanksssss
a) The directional cross on the GCW Zero should be mapped to the analog stick on player 1's N64 controller. I'll investigate the input mapping using X-OD-NeedsJoystick and separate the N64 d-pad from its analog stick.
b) Even the interpreter gets stuck on Blast Corps. I see the JIT compiling plenty of code after the Rare logo, but then it gets stuck in an emulated idle loop and redraws the same frame over and over. This is odd. It must require a feature that the main Mupen64plus code repository doesn't handle.
-
Ok, here we go, I tested a few games after work. Note that I wasn't able to have my volume on so I can't comment on sound.
Conkers Bad Fur Day:
Interpreter: Very slow, graphical glitches
a) JIT: same, but slightly faster
F-zero X: Climax (Hack):
Interpreter: A few glitches but pretty much full speed
JIT: same
Majora's Mask:
Interpreter: Very slow
JIT: slightly faster, still unplayable
Megaman 64:
Interpreter: Slow, but graphics looked good
JIT: not much different
The New Tetris:
b) Interpreter: reasonable speed, lots of graphical glitches (the pieces don't even show up!)
JIT: same
Ogre Battle 64:
Interpreter: graphics good, super slow intro (I was too impatient to wait for gameplay :P)
JIT: Same, perhaps a little faster
Pokemon Stadium 2:
Interpreter: reasonable speed, a few graphics issues
JIT: same
Super Smash Bros.:
Interpreter: very slow
c) JIT: Same
Turok 2:
Interpreter: slow, graphics pretty good
JIT: Same, but somewhat faster
And because I was curious/optimistic/naive about the possibilities...
World Driver Championship
d) Interpreter: crash on boot (no surprise there)
JIT: crash on boot
a) I'll disagree here. Because Conker's Bad Fur Day is one of those games that give emulators trouble, due to the way it uses interrupts, exceptions, and virtual memory, I tested it extensively during the creation of the JIT, and in places, it's 4x faster than the interpreter. Though, in the others, the time taken by the GCW Zero on graphics alone is over 50%...
b) Ouch. I don't know what to do here. If you know how to unpack the OPK, mark 'mupen64plus' as executable and run it through SSH or gmenu2x, try editing the file called gles2n64.conf to see if a setting allows you to see the pieces.
c) Yep. Smash runs at 60 FPS; it's one of the few N64 games to do that. Graphics time is over 60% in that game.
d) Core: Compiling LUI at native 702C7F94
Core: Compiling B at native 702C7F98
Core: Compiling B/[cycle count update] at native 702C7F9C
Core: Compiling B/SW at native 702C7FA8
Core: compiled 80001584+ 3 at 702C7F84+ 184
Segmentation fault
The interpreter crashes too, though? That SW (Nintendo 64) instruction must be doing some really nasty stuff!
edit:
Program received signal SIGSEGV, Segmentation fault.
0x74f0acac in gDPLoadTLUT(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) () from ./mupen64plus-video-n64.so
Comes from the video plugin trying to access address 77C525A7 (for me) using a 16-bit load, but the address is both unaligned by 1 (which is somewhat bad) and not even referring to allocated memory (which is very bad).
Thanks for your testing :)
-
Thank you Nebuleon and others involved! I figured the GCW just didn't have the power for this, but this is a very impressive alpha release. Not knowing anything about emulators, my inclination is that audio processing is holding a lot of games back. I'd be interested in seeing a build without audio processing just to see if that's true. And hey, I'd play a muted full-speed Smash ;)
It'd also be great to have a L->Z and R->R shoulder mapping for games like Star Fox.
Here's a video for those interested in seeing it in action. Sorry for crappy focus, I'm not a video-making person really:
https://www.youtube.com/watch?v=j-0RtQHvItQ
edit: I'm wrong about the button mapping (here and in the video), though shoulder buttons weren't working for me.
Quick summary:
Using the JIT build only. The interpreter seems to work the same, just slower.
1. Diddy Kong Racing - major graphical glitches, pretty trippy effect though
2. Star Fox 64 (1:50, gameplay at 4:10) - slow cutscenes and audio, first stage playable with some various graphical glitches
3. Super Mario 64 (5:50) - very playable, just slow
4. Super Smash Bros (10:30) - playable but slow, graphical glitches (e.g no eyes on pikachu, hah). Also there's a freeze (not a crash) you can see in the video at 12:00
5. Yoshi's Story (12:30) - 2D sprites seem to be working but none of the polygons really
-
Thank you Nebuleon and others involved! I figured the GCW just didn't have the power for this, but this is a very impressive alpha release. Not knowing anything about emulators, my inclination is that audio processing is holding a lot of games back. I'd be interested in seeing a build without audio processing just to see if that's true. And hey, I'd play a muted full-speed Smash ;)
It'd also be great to have a L->Z and R->R shoulder mapping for games like Star Fox.
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.
Here's a video for those interested in seeing it in action. Sorry for crappy focus, I'm not a video-making person really:
YOUTUBE OBJECT
edit: I'm wrong about the button mapping (here and in the video), though shoulder buttons weren't working for me.
Quick summary:
Using the JIT build only. The interpreter seems to work the same, just slower.
1. Diddy Kong Racing - major graphical glitches, pretty trippy effect though
2. Star Fox 64 (1:50, gameplay at 4:10) - slow cutscenes and audio, first stage playable with some various graphical glitches
3. Super Mario 64 (5:50) - very playable, just slow
4. Super Smash Bros (10:30) - playable but slow, graphical glitches (e.g no eyes on pikachu, hah). Also there's a freeze (not a crash) you can see in the video at 12:00
5. Yoshi's Story (12:30) - 2D sprites seem to be working but none of the polygons really
1. [Diddy Kong Racing] Wow, that looks so bad!
2. The weird letter offsetting in Star Fox 64 is an issue with texture index numbers in the video plugin; it's not your ROM. You'll notice that, within a single "text cutscene", every instance of one letter is always the next or previous letter in the alphabet. You can see a lot of them in the voice-acted cutscene before entering Corneria.
3. [Super Mario 64] Yeah, this one runs pretty well! Note that the cake cutscene is fullspeed, or close to fullspeed, as Lakitu appears, but then as Peach's Castle also appears, the frame rate drops considerably, and in the Bob-Omb Battlefield, it sounds like it runs about 50% as fast as an N64.
4. [Super Smash Bros.] Oh, maybe a softlock caused by the JIT. Do you happen to know if it also happens in the interpreter?
5. [Yoshi's Story] Well, that's disappointing; you don't see anything...
If you know how to unpack the OPK, mark 'mupen64plus' as executable and run it through SSH or gmenu2x, 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.
-
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!
-
Xena, talisman of fate seems to be running full speed except for animation at the beginning. The actual fighting and the menus work perfectly.
-
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:
./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 :)
-
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.
-
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.
-
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 ;)
-
lol this thread is blowing up! this emulator will be complete in no time :p keep up the good work everyone.
-
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.
-
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.
-
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?
-
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.
-
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 ;)
-
((---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
-
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 :)
-
Wow truly amazing... Thanks Nebuleon nice to see you back on the boards :D
P.S I need to try goldeneye at some point :)
-
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!
-
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!
-
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?
-
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.
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.
-
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!
-
When I first saw this, I didn't think it was really you, Nebuleon. I remember you looking at N64 on the Zero on your github, but never thought it would come this far. This is incredible!
Welcome back to the forums, and excellent progress on this so far! :D
As far as C buttons go, you could try combinations, like SELECT+A = Right C. The C buttons in many games are used for the camera, or to select an item (Ocarina of Time), so that's a possibility.
P.S. Tested games on the JIT build so far.
For Banjo Kazooie, the opening cutscene runs full speed except for very rare frameskips as the camera goes up the stairs into Grunty's Lair. Game itself runs at... mostly full speed. I'd have to say around 40, maybe even 50 FPS by the looks of it. Slight sound skipping. Haven't tried the interpreter build yet. Graphics look perfect, I haven't found any graphical issues other than the sky flashed green for a second in the opening cutscene.
Kirby 64 runs fullspeed, but I can't get past the tutorial video because of the lack of mapped C buttons and/or the analog stick. There's a lot of screwed up graphics though. The text is bundled up in the corner of the screen.
Super Mario 64 runs the same as Banjo Kazooie. Slight slow down, no graphical issues so far.
Bomberman Hero seems to be full speed, but the screen is black. No video.
Ocarina of Time is maybe 20 FPS at the moment. No graphical issues so far.
-
Welcome back Nebuleon !
-
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)
Congratulations. You've found a bug that exposes a problem that the Intel JIT, which only recompiles the arithmetic and bitwise operations and leaves the rest of the work to the interpreter, also has. My PC doesn't handle a fight with Kirby as Player 1 using the inhaling attack either; it freezes in the exact same way at the exact same place.
If I generate code, for Intel or MIPS, that consists solely of calls to the interpreter, the freeze occurs too.
Because the interpreter's functions are known to be good, this indicates a fundamental fault in the JIT, which means I have to reverify the basic code supporting the MIPS and Intel JITs before reverifying the emitters for N64 memory stores, branches, exceptions and interrupts on MIPS.
-
Ocarina of Time is maybe 20 FPS at the moment. No graphical issues so far.
It runs at 20fps natively, the PAL version is around 17fps.
-
shoulder buttons weren't working for me.
Neglected to mention this as well, L and R don't seem to be doing anything for me
-
It runs at 20fps natively, the PAL version is around 17fps.
Right, I don't know why I was thinking out of 60 FPS.
As far as controls go, what if a control layout like this was used:
Dpad = dpad
Analog = analog (Analog sensitivity is used in some games like Super Mario 64)
A = A
B = B
Start = start
L = L and Z (Since games used one or the other)
R = R
Menu = Power switch up
Select+A = Right C
Select+B = Bottom C
Select+X = Left C
Select+Y = Top C
Since C buttons were only used for camera and items. I mean, in Perfect Dark you could use them to move, but that's one of the few games I believe where they were used for something else. I think this would be a pretty nice layout. For pretty much every game, you do need all of the controls mapped, after all.
I just downloaded the Interpreter for some testing with the JIT. Time to try out Pokemon Snap. :D
Also, would you be willing to keep the gmenu2x selector? I do prefer that over built-in selectors like FCEUX used to have.
-
On Zelda you will need to map at least one C button to a face button for selecting the bow/slingshot as you need to hold it and aim with the analog stick. Same with Goldeneye you will need all four face buttons mapping to C buttons.
-
On Zelda you will need to map at least one C button to a face button for selecting the bow/slingshot as you need to hold it and aim with the analog stick. Same with Goldeneye you will need all four face buttons mapping to C buttons.
True. I have no idea then, other than mapping the C buttons to the dpad and having the analog stick as both the analog and dpad, which was mentioned earlier.
On a side note, I tested Banjo-Tooie. On the interpreter it runs fine (minus the extreme lag), but on the JIT build, it runs full speed, but freezes at the N64 logo every time. Audio continues, but video freezes.
-
For most games you would be fine mapping them to corresponding dpad buttons and also mapping certain C buttons to X and Y. For N64 you would need to map them to the face buttons, that game hasn't aged well at all though and the control scheme is horrible to begin with.
-
For N64 you would need to map them to the face buttons, that game hasn't aged well at all though and the control scheme is horrible to begin with.
You mean map them to the face buttons for Goldeneye?
-
Also, would you be willing to keep the gmenu2x selector? I do prefer that over built-in selectors like FCEUX used to have.
I agree with this. I like being able to restrict to a single folder, as well as the uniformity it lends to the emulators that do this.
As far as controls go, the N64 suffers for all sorts of weird control schemes, and I think that the aforementioned idea of allowing for complete per-game mapping by the end user is the best way to accommodate everyone's tastes. I have played several games where the c-buttons are used as normal buttons so flexibility will be key. (there is no way I will want to press a multiple button combo to jump in smash bros. for instance, and I still refuse jump with the analog stick) ;)
-
(there is no way I will want to press a multiple button combo to jump in smash bros. for instance, and I still refuse jump with the analog stick) ;)
Right, I forgot about that, too. Haha.
I'm all for the per game configurations, as long as analog is supported. In time, though. Right now I'm just speechless seeing Banjo Kazooie running on my GCW-Zero... at near full speed, too. ;)
-
Also, would you be willing to keep the gmenu2x selector? I do prefer that over built-in selectors like FCEUX used to have.
I agree with this. I like being able to restrict to a single folder, as well as the uniformity it lends to the emulators that do this.
Y'all know me, everything I port uses the gmenu2x file selector :) If anything, the frontend would just be an in-game options menu.
As far as controls go, the N64 suffers for all sorts of weird control schemes, and I think that the aforementioned idea of allowing for complete per-game mapping by the end user is the best way to accommodate everyone's tastes. I have played several games where the c-buttons are used as normal buttons so flexibility will be key. (there is no way I will want to press a multiple button combo to jump in smash bros. for instance, and I still refuse jump with the analog stick) ;)
There's no way I'm going to accept Select+ABXY for C Buttons; I don't even think mupen64plus-input-sdl allows configuration files to declare button combinations like that. Maybe in SM64, where you have some time to think about your button inputs and switch the camera around with the C Buttons, but that's the exception, rather than the rule.
-
There's no way I'm going to accept Select+ABXY for C Buttons; I don't even think mupen64plus-input-sdl allows configuration files to declare button combinations like that. Maybe in SM64, where you have some time to think about your button inputs and switch the camera around with the C Buttons, but that's the exception, rather than the rule.
Yeah, I admit it was a bad idea. Bottom line, per game configs are the best idea.
Neb, would that issue with Banjo-Tooie be a bug?
-
I've just found a workaround for the Kirby inhaling attack freeze in Super Smash Bros. It is caused by the interpreter functions for N64 conditional branches, used if the delay slot of a branch is not in the same 4 KiB page as the branch itself, not bothering to revalidate the fallthrough code if the branch condition is false.
Sure enough, Kirby's inhaling attack has a branch at 8013_4FFC (N64 memory address, hex) which falls through to 8013_5004, in the next 4 KiB page, if the condition fails. The game had written new code at 8013_5004, but the new code was not properly revalidated. So I end up running the code that was previously at that address, which the game does not expect, and it continues in a limbo state.
I will have to reverify many parts of the MIPS JIT now. In the meantime, please do keep reporting bugs, except for the one in Super Smash Bros. I will appreciate any other work done in parallel with me. :)
-
Hi if it helps:
Mario Kart time trial: in the end of a race if you select retry, the swlock happens and requires an reset on the gcw
-
Just curious Nebuleon,
how do you build the source ?
'Cause i can see that you have pushed some commits today and i would like to test them out
but there are lots of git repos and stuff...
-
Mario Kart time trial: in the end of a race if you select retry, the swlock happens and requires an reset on the gcw
Power + select or an actual power cut with the reset button?
-
Just curious Nebuleon,
how do you build the source ?
'Cause i can see that you have pushed some commits today and i would like to test them out
but there are lots of git repos and stuff...
Nebuleon/mupen64plus-build
make -f Makefile.gcw0
I'm still reverifying the code though.
-
The original post has been updated with a new alpha build. Controls are unmodified.
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
The following bug report that existed before this post is still valid, but it also exists in the interpreter:
The following bug report that existed before this post is still valid, but it is a bug in the video plugin, gles2n64:
- World Driver Championship, Segmentation fault during intro
-
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.
-
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 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
-
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.
-
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?
(https://dl.dropboxusercontent.com/u/106475413/dingoonity/mupen64plus-banjo-tooei-freeze2.png)
-
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.
-
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.
-
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
-
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 ?
-
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?
-
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...
-
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.
-
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.....
-
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.
-
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 :)
-
Checking out the controller design for the N64 (I have no experience of using this controller so I looked here (https://en.wikipedia.org/wiki/Nintendo_64_controller)) 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?
-
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.
-
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.
-
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.
-
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.
-
This information was taken directly from the Wikipedia entry. Apparently it was possible to play Perfect Dark with two controllers using both analogue sticks and Z buttons.
In any case clearly it's the hardest control option to configure and given it's rare use I don't think it'll make the cut, it was really only there for completeness.
I haven't studied the mupen64 code base in any detail yet but I would like to get an idea on what people want before I invest more hours of my life coding features that may not be necessary ;)
If anyone has any ideas or artwork they wish to contribute then please let me know.
Eg Given the long load times necessary a loading screen would be nice, preferably with space for a progress bar at the bottom. If anyone fancies designing one and developers (mainly Nebuleon of course!) approve then it will be included as long as they use a suitable license.
-
This information was taken directly from the Wikipedia entry. Apparently it was possible to play Perfect Dark with two controllers using both analogue sticks and Z buttons.
I've tried it, and it is actually quite fun, expect for the weird looks you get trying to play!
-
This information was taken directly from the Wikipedia entry. Apparently it was possible to play Perfect Dark with two controllers using both analogue sticks and Z buttons.
I've tried it, and it is actually quite fun, expect for the weird looks you get trying to play!
If you Google search dual analog Nintendo 64 controller, you will see that somebody actually made one of their own! It looks hilarious in size, but I'm sure it's functional. Ha ha
I think eventually it got a third-party controller that had dual analog as well. Just in case anyone's curious.
Also, Love the visual @thefifthgiant !! Hahaha
-
This control scheme is available in Star Wars Episode I Racer as well, and lets you control each of the two engines independently. Pretty cool stuff if you ask me 8)
-
Here's an alternate icon if you'd like to use it. Let me know if I need to upload it in a different format.
-
Here's an alternate icon if you'd like to use it. Let me know if I need to upload it in a different format.
Love it!!!
-
Here's an alternate icon if you'd like to use it. Let me know if I need to upload it in a different format.
I'll use it for sure, for consistency with the other emulators which use icons representing the hardware of the original console. Thanks! :)
But I want to use it only for a good release; for any release before that, where the performance, compatibility or user-friendliness (or some, or all) is not acceptable, I'll keep using the current icon.
-
But I want to use it only for a good release; for any release before that, where the performance, compatibility or user-friendliness (or some, or all) is not acceptable, I'll keep using the current icon.
Sounds good! :)
-
Out of curiosity, do you plan to implement the N64's rumble pak? That way you can use rumble in games that support it?
In the emulator's menu, you could have the option to enable or disable the rumble pak, for example.
-
Out of curiosity, do you plan to implement the N64's rumble pak? That way you can use rumble in games that support it?
In the emulator's menu, you could have the option to enable or disable the rumble pak, for example.
The input plugin from the emulator already supports rumble for games that support it.
-
The input plugin from the emulator already supports rumble for games that support it.
So it would already work then? I haven't tried it yet, but good to know it's supported.
-
I tested Perfect Dark today, and I think I found a bug.
The JIT build loads the game, but freezes after the Perfect Dark logo at a black screen.
The interpreter build gets to the main menu, but then shows an error message that says "ERROR: Controller Pak 1 the save data has been erased due to corruption or damage".
-
Great work so far, Nebuleon! ;D
-
Thanks, jxv.
I've done my best, but it's diminishing returns until the graphics are better and faster, because they take the most time right now. Even speeding up the JIT by 2x (+100%), which would be another full year of effort to chase enough optimisations to get there, would provide only a global speedup of ~10%.
So until then, I intend to do absolutely nothing on the JIT. I'd only continue if the CPU time spent on graphics, as reported by Oprofile, is less than 25%, or the time spent on the JIT is more than 60%, whichever occurs first.
Let's see who can build off of what I've done.
-
(lack of) Progress update.
Unfortunately I'm still at the code analysis stage. I just haven't got much time right now to dedicate towards this project. If anyone else can spare the time to help build a frontend please let me know, otherwise you'll have to be patient, I've got loads of ideas but no time to implement them :(
-
Just to say I downloaded this today and had a quick play of Mario 64 (possibly my all time favorite game!) and was pleasantly surprised! The speed is certainly playable, and although I found the sound irritating it's easy enough to turn off.
One thing I think would be worth doing is integrating the analogue stick. David Knight, I've been using your Pocket Snes (thanks for the work here BTW!) and really enjoyed being able to use the little nub if I felt like it. It would also presumably free up the dpad for other uses.
Anyway, a bit of a ramble but thanks to all those who put hard work into this - very impressive!
-
I still can't wait to try this, thank you for all of your hard work Neb! It seems the puck stops here for now, but I truly hope somebody picks up where you left off. Either way I'm extremely thankful for all of the hard work that you and anyone else who helped make it happen. You guys are the best, Merry Christmas!
-
I've not gone anywhere, I'm just super-busy right now. When I can I'll get back to coding, I've got loads of plans for Genesis-plus and other part-finished projects.
-
AWESOME!!!! :o
Really good to see you again, nebuleon! ;)
I can't wait to try this emulator! Only a few hours.
Thanks for your work!
-
Thanks Nebuleon for all your work on this! Running Mupen64 on a GCW is like a dream come true!
I will take a closer look into the JIT port soon, just stumbled upon this (best late xmas present). ;) Keep up the great work!
-
have there been any updates to this gentlemen?
-
have there been any updates to this gentlemen?
Nope.
Which implies that either:
a) there are no knowledgeable people to take over
b) there is no interest in this platform/emulator among skilled developers
-
have there been any updates to this gentlemen?
Nope.
Which implies that either:
a) there are no knowledgeable people to take over
b) there is no interest in this platform/emulator among skilled developers
:(
Crossing my fingers that those implications are incorrect!
@David Knight to your knowledge was there any chance at getting analog to work? (for further testing purposes)
-
@David Knight to your knowledge was there any chance at getting analog to work? (for further testing purposes)
This is merely a matter of repacking the OPK with X-OD-NeedsJoystick=true and a new input config. No need to recompile anything.
-
@David Knight to your knowledge was there any chance at getting analog to work? (for further testing purposes)
This is merely a matter of repacking the OPK with X-OD-NeedsJoystick=true and a new input config. No need to recompile anything.
@zear thank you for the replies! Just curious, because I know It had been mentioned before, but then I never heard anything after. Hopefully someone will get around to doing it eventually. All of you work so incredibly hard. THANK U
-
have there been any updates to this gentlemen?
Nope.
Which implies that either:
a) there are no knowledgeable people to take over
b) there is no interest in this platform/emulator among skilled developers
c) people interested in developing do not have time to dedicate to this project.
-
Some games, such as Super Smash Bros. drop about half in frame rate, though most run well on the hardware. Perhaps doing some resolution downscaling might increase the overall framerate, though I may not be the person to ask. Love the idea and love the way most games run. :)
-
have there been any updates to this gentlemen?
Nope.
Which implies that either:
a) there are no knowledgeable people to take over
b) there is no interest in this platform/emulator among skilled developers
c) people interested in developing do not have time to dedicate to this project.
d) i'm dedicated to you @David Knight 8)
-
Hey! This is so awesome! Thank you!
For further testing I would love to see:
- analog support added
- trigger buttons mapped (maybe right to right/left to Z button)
- Basic menu for save states (since games run slower, would make it easier to save progress and keep testing further)
Hope things can be further optimized! Thank you guys so much for the hard work! So gorgeous on the GCW LCD :)
Edit: tested a few games with similar results to other people I've seen, here are a couple of new games tested w/JIT.
-Goemon's adventure: runs. Gets to the main screen fine. Choosing characters is fine. Once characters chosen game goes black in what seems to be a freeze but not a crash.
-Mischief Makers: runs. Gets to main screen fine. Start game fine. Dialog box comes up, notifies you to use the L/R triggers? No longer able to progress because these buttons are not mapped.
-
Thanks so much to OP for sharing this with us all. Are there any new developments on this project I can see there hasn't been much info for awhile?
Thanks
-
Thanks so much to OP for sharing this with us all. Are there any new developments on this project I can see there hasn't been much info for awhile?
Thanks
@SilentRunner, from what i'm seeing from the last commit on github, he hasn't worked on it since last version.
Maybe the reason why is because the CPU part is mostly done and due to the fact it's the GPU plugin that's taking most of the time
and slowing down the GCW0.
The next firmware should fix this, if it ever comes with the new etnaviv driver.
If not well a faster plugin needs to be made available, as Nebuleon himself said he wasn't interested fixing graphical glitches and the speed of it
-
The OPK files need to be uploaded and linked again they don't work anymore
-
Maybe this year we will get some N64 ?
-
Anyone can fix the download links?
-
Hi the community!
Here is my contribution:
https://mega.nz/#!bQpF1SBa!CgANq02XkIrroVcM0NwcUbOT5pV0JaR3fulHwtDGGq0 (https://mega.nz/#!bQpF1SBa!CgANq02XkIrroVcM0NwcUbOT5pV0JaR3fulHwtDGGq0)
Have fun!