What would you like to see in Project64 2.2?

[the_randomizer]

Nice, 2.2, eh?

- Timing issues resolved, games like Clay Fighter 63 1/3 drop to 45 VI/s when sync game to audio is enabled with default audio plugins (several other games suffer from this as well), games like Hybrid Heaven have micro stuttering as every 10-15 seconds on 2.1.0.1.

- Emulator crashing in between ROM swapping. I don't know if it's just me, but every time I press F12 to stop the emulator and change ROMs, it always crashes.

[=X= Smasherx74 =X=]

Originally Posted by zilmar

What would you like to see in 2.2?

- Real 60FPS F-Zero X
- AQZ Netplay without input dependencies, where he couldn't handle the mempacks or auto-cheat sending through the client.
- Faster Load/Save states
- Fixed fixed audio timing
- Overclocking, like with that 1964 version
- Full emulation control, Speed Up/Speed Down extremely, rewind emulation and reemulate previous emulation? With most noobs they use Savestates with Nemu64 during/before a breakpoint. Having the ability to rewind/fastfoward memory would be useful especially for Majoras Mask.

If none of these suggestions are done, I will continue to hate on N64 emulation.

[HatCat]

Originally Posted by =X= Smasherx74 =X=

- Faster Load/Save states

Saved states are not fast enough?

Well I use them just every so often, but on my 1.90 GHz CPU they didn't seem to take a second to finish writing/reading (except on my worn-out flash drive, where it takes like, 1 minute >.<)

I should be able to optimize something like that, though. I just don't know where in PJ64 source saved states are handled.

Originally Posted by =X= Smasherx74 =X=

- AQZ Netplay without input dependencies, where he couldn't handle the mempacks or auto-cheat sending through the client.

AQZ NetPlay is like Kaillera but without the UDP implementation (uses TCP/IP I think) but with the IRC chat interface.

I don't mind that it was an input plugin. It could have handled the mempak file system if he had knowledge about it, but the plugin is closed-source and basically just an experiment for testing NetPlay on Project64 1.7's level of sync.

[oddMLan]

The ability to overclock/underclock N64 CPU would be a nice feature, don't know how hard would be to implement on Project64 tho.

But the most important things I think would be:
-Make the recompiler more stable/less hazard prone (ex. complex games like Conker's BFD crash on the recompiler on certain circumstances)
-Make timings more accurate/closer to the N64, so things like the DK64 intro (ultimate timing challenge on N64 emus IMO) stay on sync
-Disable Fixed Audio Timing by default (force enable on netplay only)
-Implement latest changes to the RDB by Nekobabu and DSX

Maybe:
-Emulate the console more accurately autodetecting some parameters like VI refresh rate, AI counter per byte, Self-Mod methods, etc... so we depend less on a RDB.
-Deprecate rarely used/not used at all settings, to make the UI less cluttered.

[RPGMaster]

Originally Posted by HatCat

That's another thing I forgot about.

Supposedly pj64 dumps memory but...I had to write my own RDRAM export feature in angrylion gfx plugin (with endian fixing)? Because pj64 just dumps the RAM in CPU disassembly text view. I don't want a text file; I want a binary file of the 4 or 8 MB dumped so I can navigate through it via a pixel map viewer to look at texture/frame buffer memory in the RDRAM. Can't do that with text files.

I already wrote a program to open binary files as bitmaps and scroll through the pixels/pitch under various color decoding modes, and plus there's LemAsm. But none of the n64 emulators except Nemu64 actually dump the RDRAM to a binary file?!

I actually only used Nemu for memory dumping. Binary dumps should definitely be added in! Maybe I could implement binary dumping for PJ64 after zilmar adds the other debugging stuff in.

I'll have to check out your program .

Originally Posted by HatCat

Gfx issue with Factor 5 games on PJ64 are caused by incorrect VI registers, or the timing when VI_X_SCALE_REG and things like that get set. That's why they have a black screen a lot of the time. Also, interlaced frame buffer video timing doesn't work on pj64, so games with a 640x480 frame buffer only come out with a 320x240 one.

Good to know. Perhaps that's why high-res doesn't look right in Rogue Squadron? Although m64p(old zilmar spec version) seems to have the same problem.

Originally Posted by the_randomizer

- Timing issues resolved, games like Clay Fighter 63 1/3 drop to 45 VI/s when sync game to audio is enabled with default audio plugins (several other games suffer from this as well), games like Hybrid Heaven have micro stuttering as every 10-15 seconds on 2.1.0.1.

These are some of the issues I was talking about. I wonder how Mupen64 0.5 fixes these issues. I'm going to have to learn how audio works.

Originally Posted by the_randomizer

- Emulator crashing in between ROM swapping. I don't know if it's just me, but every time I press F12 to stop the emulator and change ROMs, it always crashes.

I bet you're using Azimer's XA2 plugin . Pretty sure it's a plugin issue, since it happens on multiple emulators.

Originally Posted by =X= Smasherx74 =X=

- Real 60FPS F-Zero X
- AQZ Netplay without input dependencies, where he couldn't handle the mempacks or auto-cheat sending through the client.
- Faster Load/Save states
- Fixed fixed audio timing
- Overclocking, like with that 1964 version
- Full emulation control, Speed Up/Speed Down extremely, rewind emulation and reemulate previous emulation? With most noobs they use Savestates with Nemu64 during/before a breakpoint. Having the ability to rewind/fastfoward memory would be useful especially for Majoras Mask.

If none of these suggestions are done, I will continue to hate on N64 emulation.

F-Zero already runs 60fps. Netplay will be time consuming to implement ;/ . I'd just use a different emulator in the meantime for netplay. Not sure if you can speed up save states, but speeding up load states is possible. I know Apollo loads states really fast. Probably because it doesn't pause when loading a save state.

[retroben]

I second on that overclocking feature.

I have decent savestate speeds since they are faster when not compressed because there's nothing to compress and decompress between saving and loading,though savestates will take more space.
I guess my great speeds could be from several tweaks and hacks for the fastest read and write speeds.

Can't F-zero X already reach 60fps when counter factor is set to 1?

AFAIK,You can already increase/decrease speed in PJ64 with "+" and"-" keys,or other keys if you remap the options.

[HatCat]

Uh. I like my clocks like I like my ass: on time not over it.

I guess overclocking's useful for those games that were too slow on 1964's recompiler CPU to begin with like Perfect Dark or w/e, those high system req. titles.

Originally Posted by RPGMaster

I'll have to check out your program .

It's called "PixD". I wanted to experiment with a pixel disassembler...basically just drag and drop any file via Windows Explorer, and it opens the file as a pixel map in 256-color mode by def. (Press 0 for 1 bit per pixel, 1 for 2 bits, 2 for 4-bit Windows VGA color decoding...etc., you press 4 and 5 for N64 R5G5B5 and R8G8B8A8 frame buffer formats to see N64 textures and other goodies.) And obviously drag the window like you would LemAsm. (I also added a window capture hotkey with alpha transparency saving, similar to PNG, since Alt+PrintScreen doesn't copy transparency levels.)

Originally Posted by RPGMaster

Good to know. Perhaps that's why high-res doesn't look right in Rogue Squadron? Although m64p(old zilmar spec version) seems to have the same problem.

Are you a Mupen64Plus tester?

I have never tried Mupen64Plus, just the core ported to libretro (which I contribute to portability and design fixes on GitHub under RetroArch). I was wondering if the original, current Mupen64Plus has issues with booting up games in LLE gfx--Zelda Majora's Mask, Castlevania (*NOT* LoD, just regular), 007 TWINE.

[RPGMaster]

Originally Posted by HatCat

It's called "PixD". I wanted to experiment with a pixel disassembler...basically just drag and drop any file via Windows Explorer, and it opens the file as a pixel map in 256-color mode by def. (Press 0 for 1 bit per pixel, 1 for 2 bits, 2 for 4-bit Windows VGA color decoding...etc., you press 4 and 5 for N64 R5G5B5 and R8G8B8A8 frame buffer formats to see N64 textures and other goodies.) And obviously drag the window like you would LemAsm. (I also added a window capture hotkey with alpha transparency saving, similar to PNG, since Alt+PrintScreen doesn't copy transparency levels.)

Nice. Will probably test it out later today.

Originally Posted by HatCat

Are you a Mupen64Plus tester?

I have never tried Mupen64Plus, just the core ported to libretro (which I contribute to portability and design fixes on GitHub under RetroArch). I was wondering if the original, current Mupen64Plus has issues with booting up games in LLE gfx--Zelda Majora's Mask, Castlevania (*NOT* LoD, just regular), 007 TWINE.

I rarely use Mupen64Plus. Was never even able to compile it myself. I should try out the libretro one . I could still test out Mupen64Plus. I probably need to download latest version, since it's been a few months. The problem with M64p is that there's only 1 LLE gfx plugin, which has many issues on my hardware ;/ . Like in F-Zero, I get a black screen with z64gl. I know you ported the pixel accurate plugin to the libretro one though.

[HatCat]

Sort of.
I never really ported angrylion plugin to Mupen64Plus libretro, nor do I understand anything at all about this "M64P API"; I just helped get it drawing pixels in the RetroArch integration of it and fix some segfaults in the Linux build.

"Like in F-Zero, I get a black screen with z64gl."
sounds like it's Mupen64Plus's fault then.

Man they really need to either find someone to fix that or undo some carefree commits that broke it. LLE gfx worked great in Mupen64 0.5 so why break it.

[RPGMaster]

Wow, it's time for me to try and learn about the emulator core!

Mupen64 0.5 is the only emulator I've seen that actually displays something for F-Zero with z64gl. It still crashes, but so does every other emulator. Probably some hardware issue of mine, although I think the plugin is at least partly to blame.

I really would like to experiment with Mupen64 0.5's source and learn from it, but never got it to compile with MSVC ;/ . I wonder how I'd be able to fix the RDRAM issue in games like Rogue Squadron though ;/ .

Once I learn a decent amount, I'd be able to help improve PJ64's emulator core .