Go Back   Project64 Forums > Public Version > Project 64 - v2.x - Suggestions

Reply
 
Thread Tools Display Modes
  #11  
Old 22nd January 2015, 05:48 PM
the_randomizer's Avatar
the_randomizer the_randomizer is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Sep 2008
Location: USA
Posts: 1,134
Default

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.
__________________
My rig:
CPU: Intel Core i7 4470 3.4 GHz to 3.9 GHz
Video card:: MSI nVidia GTX 970 4 GB GDDR5
OS: Windows 7 Professional 64-bit
RAM: 16 GB DDR3 SDRAM 10600
HDD: 2 x Western Digital 1 TB HDDs
Monitor: 23" Asus Full HD LED

Oh, and Snes9x > Zsnes in every way
Reply With Quote
  #12  
Old 22nd January 2015, 06:34 PM
=X= Smasherx74 =X= =X= Smasherx74 =X= is offline
Senior Member
 
Join Date: Jun 2011
Posts: 149
Default

Quote:
Originally Posted by zilmar View Post
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.
Reply With Quote
  #13  
Old 22nd January 2015, 07:18 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

Quote:
Originally Posted by =X= Smasherx74 =X= View Post
- 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.

Quote:
Originally Posted by =X= Smasherx74 =X= View Post
- 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.
Reply With Quote
  #14  
Old 22nd January 2015, 07:36 PM
oddMLan's Avatar
oddMLan oddMLan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2009
Location: Parappa Town
Posts: 210
Default

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.
Reply With Quote
  #15  
Old 22nd January 2015, 07:37 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,004
Default

Quote:
Originally Posted by HatCat View Post
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 .

Quote:
Originally Posted by HatCat View Post
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.

Quote:
Originally Posted by the_randomizer View Post
- 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.
Quote:
Originally Posted by the_randomizer View Post
- 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.

Quote:
Originally Posted by =X= Smasherx74 =X= View Post
- 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.
Reply With Quote
  #16  
Old 22nd January 2015, 07:42 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 681
Default

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.
Reply With Quote
  #17  
Old 22nd January 2015, 08:06 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

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.

Quote:
Originally Posted by RPGMaster View Post
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.)

Quote:
Originally Posted by RPGMaster View Post
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.
Reply With Quote
  #18  
Old 22nd January 2015, 08:41 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,004
Default

Quote:
Originally Posted by HatCat View Post
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.

Quote:
Originally Posted by HatCat View Post
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.
Reply With Quote
  #19  
Old 22nd January 2015, 09:08 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

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.
Reply With Quote
  #20  
Old 22nd January 2015, 09:44 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,004
Default

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 .
Reply With Quote
Reply

Tags
2.2, project64

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 01:56 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.