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

Reply
 
Thread Tools Display Modes
  #81  
Old 29th January 2015, 11:23 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 687
Default

What I do with my ass is none of your business! *Hahahaha*
I'll have you know I am quite skinny.
Sorry,but the audio issue is also in the main 2.x version and I forgot that it was.
Problem is,the memory search doesn't work in that one,hence the reason I forgot.
The "Fixed Auto Timing" option does indeed work in the main version,but not working in that updated 2.2 build.

Hey zilmar,I got a mean response from using this "No Counter Factor Skips" GS code (80014F4F 0000) with Banjo-Tooie in the main 2.x version when the 1.7.0.50b23 version runs fine with it.
What changed enough to give it more restrictions to codes?
This is the first time I have ever had a code fail on 2.x between these two versions.

Here is the response I get immediately on Banjo-Tooie when enabling it,regardless of where I enabled it.

Code:
Break point found at
.\N64 System\Mips\Memory Virtual Mem.cpp
398

Last edited by retroben; 29th January 2015 at 11:32 PM.
Reply With Quote
  #82  
Old 29th January 2015, 11:31 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

At least you have an ass. I'm fat as fuck and IDK where my ass is. The humans tell me it's behind my tail, but I forgot where tail is.

Well actually when I wear this hat, then I'm not really that fat. Maybe going to the cat gym lost me a couple hundred pounds from that karate pat, not sure.

Also I lol'd uncontrollably while writing this post. I'm not even fat XD
Reply With Quote
  #83  
Old 29th January 2015, 11:46 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by HatCat View Post
LQV and SQV are illegal RSP operations if the element is not a 128-bit-aligned read or write, so if (element != 0) then the operation is invalid. So you could probably just do a cheat function to the RSP interpreter if the opcode is illegal, unless you're finding that it's really that frequently occurring of a case, or that it makes a noticeable difference.
I wonder why they use illegal RSP oeprations ;/ . For instance, they have an instruction where LDV's element = 12. I imagine LLV would basically do the same thing ;/ . I'll have to dig deeper to see if it's worth optimizing those illegal operations.

WDC & Stunt Racer do weird stuff. I was debugging WDC and noticed $v0 seems to always = all 0's. If I can somehow confirm 100% that it's always 0, then that would be one heck of a game specific optimization .

Quote:
Originally Posted by HatCat View Post
Maybe I should tweak the endianness in the RSP compiler and interpreter sharing to make vectorizing easier, but there is a lot of mumbo jumbo about the recompiler which I do not understand, so if I try, I dunno that I'll finish.
I actually recently figured out the endian problem I had. It was me making lazy assumptions ;/ . So now it's up to zilmar whether he cares enough to implement vectorization. Imo, the only potential problem I see with vectorizing PJ64's code, is deciding what to do with the old code.

I have to say, the way you layed out the number format really helped me get a grasp. For some reason the []'s helped me a lot lol. Before, I would just space out the numbers.
Code:
[1 0] [3 2] [5 4] [7 6] [9 8] [B A] [D C] [F E]
looks much better than
1 0 3 2 5 4 7 6 9 8 B A D C F E
Or maybe I'm just weird ;/ .

I just remembered though, I think some of the HLE code in RecompilerSections.c is wrong. In particular, Compile_Section_002 doesn't do all the calculations needed ;/ . Dunno why it just moves 0 to the vector register for the 1st VSAW. I'd love to start applying some of these other ones, if I can confirm they are 100% safe to do. For a long time, I just ignored RecompilerSections, since I use SSE2 instead of MMX anyway ;/ .
Quote:
Originally Posted by HatCat View Post
It's less that he's acting like he can't do anything, more that he's acting like a fatass. Everyone else on this forum is too important to open some text file and save an EXE out of it, when you can download some adware instead. Typical stubborn Winfaggotry for you.
I find that to be quite sad ;/ . I've seen multiple people say they can't do anything. Yet there were tons of tasks I've had to do that just required manual work, rather than knowledge or skill. Like for accumulator & flag analysis, I looked through every vector instruction and wrote down what each instruction did ;/ . Anyone can dump microcode too, but nobody does that either ;/ .
Reply With Quote
  #84  
Old 30th January 2015, 12:25 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 RPGMaster View Post
I wonder why they use illegal RSP oeprations ;/ . For instance, they have an instruction where LDV's element = 12. I imagine LLV would basically do the same thing ;/ . I'll have to dig deeper to see if it's worth optimizing those illegal operations.
They may be illegal, but unlike other cases of invalid RSP instructions (such as reserved opcodes, register specifier overflow, invalid VCF cr selectors, etc.), they do have some extent of documentation on that.

Yes LDV with element == 12 would do probably the same thing as LLV.

I don't think there is a performance difference between the two on actual N64 h/w--while these are scalar op-codes, the vector unit is still used to compute all the elemental moves simultaneously without any performance loss. Maybe they felt like saying LDV with e == 0xC instead of just LLV, simply because they were already writing LDV a bunch of other times throughout nearby parts of the source and felt like keeping consistent.

Last edited by HatCat; 30th January 2015 at 12:27 AM.
Reply With Quote
  #85  
Old 30th January 2015, 08:18 AM
Cybersnuff Cybersnuff is offline
Junior Member
 
Join Date: May 2014
Posts: 1
Default

Think the new Glide64 Plugin for Project64 would be awesome
But Sergey Lipskiy must port it and think he will after making the mupen64 plus release....

64DD Support would be also great in the future
Reply With Quote
  #86  
Old 1st February 2015, 02:47 PM
NameBound NameBound is offline
Junior Member
 
Join Date: Aug 2014
Posts: 14
Default

I was pretty impressed with v2.1.. though was a wee bit skeptical at first due to previous builds. A lot of broken roms seemed to have better support or at least the ability to run without heavy laggins - making it possible to work around issues by playing with plugins and assigning individually. I know a few: Gauntlet Legends, Vigilante 8, and Body Harvest still have issues and run pretty unstable - although doesn't damp my hopes for future releases of PJ64.. I use to have v1.6 and v1.7 back to back to be able to play all the roms. Many times being a failed effort..

I've known many to complain about the unsteady framerate and jaggedness of speed within the current build, though I rather have it speedy then run like a mule stuck in the mud. It makes such a much better work around then feeling like your defeating the purpose of fiddling with plugins and settings.

This previous topic also helped with some of the minor fixes as well (a possibility of updating them w/ 2.2): http://forum.pj64-emu.com/showthread.php?t=4647 - At least some roms getting smother and I've found a work around with Star Wars Episode 1 Racer and WCW vs. NWO..

2.1 works great on older PCs as well, almost too perfect - just needing to change Jabo's plugin back a version because of the missing/unsupported pixel shading from older on-board PC cards.. hopingly the new version would be including these plugins as well.
Reply With Quote
  #87  
Old 5th February 2015, 03:09 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

So on my quest to study microcode, I tried looking at Zelda OOT's microcode and I can't isolate the other task ;/ . Basically, when I want to focus on LLE audio, I select HLE gfx and LLE audio and vice versa. So I figured I could set both to HLE, so that I can focus on the other task type (i think JPEG?). The debugger doesn't work when I select HLE for both audio and gfx.

Another minor issue is the fact that the text boxes aren't long enough sometimes, for the vector registers.

Quote:
Originally Posted by HatCat View Post
I don't think there is a performance difference between the two on actual N64 h/w--while these are scalar op-codes, the vector unit is still used to compute all the elemental moves simultaneously without any performance loss. Maybe they felt like saying LDV with e == 0xC instead of just LLV, simply because they were already writing LDV a bunch of other times throughout nearby parts of the source and felt like keeping consistent.
After spending some time analyzing the microcode, it does look like the purpose was to be consistent. I think that game has some good potential for game specific optimizations in a recompiler .
Reply With Quote
  #88  
Old 5th February 2015, 03:27 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 RPGMaster View Post
So on my quest to study microcode, I tried looking at Zelda OOT's microcode and I can't isolate the other task ;/ .
Actually there are 2 other task types in Zelda OOT besides graphics and audio. There's a RSP task DMA'd to the instruction cache by the NUS-CIC-6105 bootcode and also many JPEG tasks throughout the game.

Quote:
Originally Posted by RPGMaster View Post
So I figured I could set both to HLE, so that I can focus on the other task type (i think JPEG?). The debugger doesn't work when I select HLE for both audio and gfx.
Works for me. Maybe you're not breaking out the commands stepper early enough for either of the other two tasks. They tend to happen pretty soon after boot.

Try Debugger > RSP > Settings > Break on start of task, enabled before loading ROM.

Quote:
Originally Posted by RPGMaster View Post
Another minor issue is the fact that the text boxes aren't long enough sometimes, for the vector registers.
Can I get a picture of this? I was thinking of reformatting the register display slightly anyway. If it's not too far off the edge, I might have a better clue how far I can go with the restyle.
Reply With Quote
  #89  
Old 5th February 2015, 04:06 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by HatCat View Post
Actually there are 2 other task types in Zelda OOT besides graphics and audio. There's a RSP task DMA'd to the instruction cache by the NUS-CIC-6105 bootcode and also many JPEG tasks throughout the game.

Works for me. Maybe you're not breaking out the commands stepper early enough for either of the other two tasks. They tend to happen pretty soon after boot.

Try Debugger > RSP > Settings > Break on start of task, enabled before loading ROM.
Thanks, that did the trick. I didn't know you had to set a breakpoint that early . Sounds interesting, didn't know it had more than 3 task types.

Quote:
Originally Posted by HatCat View Post
Can I get a picture of this? I was thinking of reformatting the register display slightly anyway. If it's not too far off the edge, I might have a better clue how far I can go with the restyle.
I went in cheat engine and set $v0 to all D's

I should probably do my own experimentation with the debugger. I think it should show 2 bytes at a time, not 4, and I'll probably rename the flags too, so that I know what is what. I'll probably split the accumulators too. It's been fun debugging the RSP.

I'm starting to like cheat engine more. It's been useful for me, since memory view in PJ64 doesn't work with IMEM or DMEM. Plus it's cool being able to change data .

Last edited by RPGMaster; 5th February 2015 at 04:36 AM.
Reply With Quote
  #90  
Old 6th February 2015, 03:57 PM
weinerschnitzel weinerschnitzel is offline
Junior Member
 
Join Date: Dec 2010
Posts: 14
Default

Timing regressions would be great to see fixed. I think it would be way cool to see 64DD support since so much has been reverse engineered recently. What about CIC NUS 7105 support?
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 09:47 AM.


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