Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #601  
Old 7th December 2013, 10:35 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,136
Default

Quote:
Originally Posted by BatCat View Post
Then you could at least explain where you were confused, because I am not seeing it. :/
I didn't see the dates on the files on the first post is all, just the names, no biggie. And for EmuCR, lol, I don't trust those files as far as I can throw a football. They leaked an Snes emulator on there all the time against author's wishes, so I called them out on it

Anyways, I didn't see the "click here to get the latest version", I only saw the attached files on the OP, so it was PEBKAC on my part. Sorry about that.
__________________
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
  #602  
Old 7th December 2013, 10:57 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

ya , release dates are all in the manual

But since there is no "pr6" or higher, only "pr5", I was incredibly confused why anyone wouldn't be certain that "pr5" had to have been the latest version. No offense--it sounds like you had your reasons.

Funny thing, at emuCR they got impatient waiting for me to update this plugin again, so they started compiling off my GitHub repository. So I broke Microsoft Visual Studio's ability to compile my code, and they haven't been able to update their builds of my plugin since. That's why I thought you were judging by the code on my GitHub repository, instead of the version numbers here.

Quote:
Originally Posted by nintendo1889 View Post
Anyways, I didn't see the "click here to get the latest version",
Only one reason why I put that there.
I see lots of people are still downloading "rsp.7z" and not the latest version (pr4 and, now, pr5), possibly cause they thought "pr" meant "parts of the multi-part download" or something, or just looked for the very first attachment they could find and only downloaded that.

It was to help make sure they didn't download the oldest version thinking it was the latest.
But, I'm out of attachment upload slots, anyway. This forum only permits a maximum of 5 attachments per post.
Reply With Quote
  #603  
Old 8th December 2013, 05:30 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,136
Default

Quote:
Originally Posted by BatCat View Post
ya , release dates are all in the manual

But since there is no "pr6" or higher, only "pr5", I was incredibly confused why anyone wouldn't be certain that "pr5" had to have been the latest version. No offense--it sounds like you had your reasons.

Funny thing, at emuCR they got impatient waiting for me to update this plugin again, so they started compiling off my GitHub repository. So I broke Microsoft Visual Studio's ability to compile my code, and they haven't been able to update their builds of my plugin since. That's why I thought you were judging by the code on my GitHub repository, instead of the version numbers here.



Only one reason why I put that there.
I see lots of people are still downloading "rsp.7z" and not the latest version (pr4 and, now, pr5), possibly cause they thought "pr" meant "parts of the multi-part download" or something, or just looked for the very first attachment they could find and only downloaded that.

It was to help make sure they didn't download the oldest version thinking it was the latest.
But, I'm out of attachment upload slots, anyway. This forum only permits a maximum of 5 attachments per post.

Aaaaaand I feel like a jackass But at least I know why now.
__________________
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
  #604  
Old 10th December 2013, 10:23 AM
e2118289's Avatar
e2118289 e2118289 is offline
Junior Member
 
Join Date: Apr 2013
Posts: 6
Exclamation In other news: nobody pays attention to posts titles

Hi there, thanks for the new release catdude, your RSP is really neat.
But there is a problem. The new semaphore/sync stuff it's not working in PJ64 2.1!
With both options set any game just freezes with 60 VI/s and keeps doing nothing, tried toggling the options separately without luck, also tried HLE audio/video etc etc, the only thing that works is having both options disabled, and that way Mario no Photopie doesn't boot so can you please check this out?
Reply With Quote
  #605  
Old 12th December 2013, 03:12 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by oddMLan View Post
I found a bug in Conker's Bad Fur Day using the latest release. Some SFX and voices sound "muffy" (as if there were no interpolation applied). Easily noticeable in the intro with Conker cutting the "N" logo with a chainsaw.
Jabo's RSP and your RSP Public Release 4 don't suffer from this bug.
I could upload some audio comparing the affected audio and the desired result if it is necessary. FWIW, this game compresses voices and SFX using some custom MP3 codec.

Using Project64 2.1 and Jabo's DirectSound 1.7.
Ah, this was no bug in the vector operations. I seem to remain voided of those.
It actually turned out to be a surviving "typo", if you could call it that, in the 128-bit quadword stores if the address was unaligned. I put the lines in the wrong order a few months ago.

Easily enough fixed, as well as the issue mentioned in the post directly above this one, but in a sudden turn of events it seems I won't be releasing this next version straight away because it looks like I might have an opportunity to first pull in and merge some 64-bit portability fixes based on the Mupen64Plus take on the situation. It won't matter for non-zilmar-spec afaik, but more portability is more success at any rate.

The issue about SP_SEMAPHORE cycle-accuracy fakes not working in Project64 2.1 was actually because I moved the CPU memory map of the PC register to a local segment instead of writing it back. I had no idea, but the emu needed to remember the PC on a global scale in this case.
Reply With Quote
  #606  
Old 12th December 2013, 05:03 AM
oddMLan's Avatar
oddMLan oddMLan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2009
Location: Parappa Town
Posts: 210
Default

Yay Glad you fixed it. I wonder if that "typo" affected other games.
Oh, and BTW, I experienced a black screen if I enabled the SP_Semaphore option, too. But at first it seemed to work, then the next day it didn't D: I thought I screwed up something lol

Now that we're talking about bug squashing, I want to inform you that changing the RSP settings from the Config Menu in Project64 2.1 crashes the emu. Open the RSP config dialog, and as soon you try to save the settings the emulator closes immediately, creating some interesting files in the config directory (rcpcache.dhex... etc). I don't think those files should be created neither the emulator should close abruptly so it seems to be a unintended crash after all. But maybe I could be wrong...


Also I could compare speeds in some games using different RSPs. But unfortunately I can't test the SSSE3 version because my AMD CPU doesn't support that (it supports SSE3 and SSE4A but not SSSE3 u_u).
Maybe this weekend.

Last edited by oddMLan; 12th December 2013 at 05:11 AM.
Reply With Quote
  #607  
Old 12th December 2013, 05:32 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by oddMLan View Post
Yay Glad you fixed it. I wonder if that "typo" affected other games.
Come to think of it, most likely.

If I wasn't too lazy to put a debugger back in to prove when and for what games that bug just got fixed for, I would check it.

But the bug was basically a mis-ordered SQV operation if, and only if, the address isn't 128-bit aligned.

The vast majority of the time however it is aligned, which would explain why the bug was so hard to stumble upon without testing games with whacky/custom RSP ucode like Rareware/Conker's BFD etc.

I'm positive it could only have affected audio tho, not video...SQV with 3-D graphics tasks is unheard of.

Quote:
Originally Posted by oddMLan View Post
Oh, and BTW, I experienced a black screen if I enabled the SP_Semaphore option, too. But at first it seemed to work, then the next day it didn't D: I thought I screwed up something lol
Yeah it WAS working up until very soon just before I uploaded the pr5 release, where I snuck in a local I-cache counter optimization that broke it on accident. The fix is on the repo now; I just hope I'll be able to get enough answers on the Mupen64Plus merge and then I can release the fixed binary.

It was random/hard to reproduce most likely because the PC stopped at variable offsets and kept being forgotten by the RSP-CPU primary thread.

Quote:
Originally Posted by oddMLan View Post
Now that we're talking about bug squashing, I want to inform you that changing the RSP settings from the Config Menu in Project64 2.1 crashes the emu. Open the RSP config dialog, and as soon you try to save the settings the emulator closes immediately,
Same here, yeah.
I can't really control it though since I don't have the C# source to Garteal's Win32 GUI. I'll see about asking him for another quick update to fix that tomorrow.

It DOES however work if you click Configure RSP, while a game is running in Project64 2.1, just not with Project64 2.1 opened straight up and with no game currently loaded to the emulation thread. (At least that's what I'm observing.) Also it seems to work in 1964, Mupen64 and pj64 1.6 without crashing. But yeah, still, it's worth asking for that sp_cfgui.exe module to get a small update...

Quote:
Originally Posted by oddMLan View Post
creating some interesting files in the config directory (rcpcache.dhex... etc). I don't think those files should be created neither the emulator should close abruptly so it seems to be a unintended crash after all. But maybe I could be wrong...
Those aren't really needed I guess but I felt like always generating them to show off fancy RSP stuff.
It's partly just to be l33t, partly to make it easier for end users to debug the RSP machine code being executed and send these additional data files to me if I have to ask for them to troubleshoot something.

But it's mostly just for showing off RSP stuff for no apparent reason.
Hm, though I suppose it can get a bit annoying...maybe I should move it into the config system?

Quote:
Originally Posted by oddMLan View Post
Also I could compare speeds in some games using different RSPs. But unfortunately I can't test the SSSE3 version because my AMD CPU doesn't support that (it supports SSE3 and SSE4A but not SSSE3 u_u).
Maybe this weekend.
Man, it's like nobody on this entire board has a SSSE3 CPU.

Not ExtremeDude2, not me...well MarathonMan did and actually he's helping to provide me one sometime.

I wish Intel didn't waste time delaying more important standardization by adding those trivial SSE3 things, and SSE4A doesn't really contribute anything towards RSP emulation either.

Not to ramble on, but I know if my SSE2 build is almost as fast as the RSP recompiler for pj64, the SSSE3 build is going to be nothing short of a close call...gah, need access to test it though.
Reply With Quote
  #608  
Old 12th December 2013, 10:49 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

nvm about the pj64 2.1 crash!

That wasn't anything about the EXE it was calling; that was due to logging the RCP system control registers shared with the RDP before the emulation thread was even initialized.

Even though it only seems to crash pj64 2.x and nothing else, I guess the info is mostly useless to look at if you have no bug to report to me for troubleshooting. So I compromised by removing this feature from DllConfig only.

M64+ ABI fixes were also merged, so a new release should be up shortly.
Reply With Quote
  #609  
Old 13th December 2013, 01:25 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

May as well mention that I could not get the plugin to boot up Gauntlet Legends or World Championship Driving, despite setting the relevant option and using LLE graphics.
Reply With Quote
  #610  
Old 13th December 2013, 03:13 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

New release is posted to the thread.

I'm out of attachment upload slots though. Sure I could just use another post or something, but I don't really care. Plus there's no benefit for me in making people register/log in to this forum to download it anyway, so see the OP for the download link.

Quote:
Originally Posted by GPDP View Post
May as well mention that I could not get the plugin to boot up Gauntlet Legends or World Championship Driving, despite setting the relevant option and using LLE graphics.
Yeah, this was just reported earlier on the previous page.
It is one of the things that got fixed in the sixth public release.
Reply With Quote
Reply

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 05:57 AM.


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