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

Reply
 
Thread Tools Display Modes
  #21  
Old 19th February 2013, 03:02 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by haxatax View Post
oh yes, including using Nintendo's manuals for documentation on thier ucodes.
Forgot about that honestly, but I figure if they had to want HLE they would reverse the entire ucode segments which is a shitload of work, effective at wasting one's life away.

But it would be so much more worthwhile if like, there was a smaller variety of RSP microcodes to simulate, and they were all less than a megabyte of RSP instructions. Then they would all be so much simpler to understand and express in a high-level language to simulate them for speed (and more beneficial, in the process...without bloating up code out of desperation for speed).

Quote:
Maybe they find it a challenge, like Gonetz did for finding out the lighting in CBFD? Maybe for speed (like its done currently) ? Maybe for things like hires textures?

I can name plenty of reasons why to do HLE, but I can also see plenty to do LLE (like better compatibility, ability for debugging, etc)
It's just so much frekkin' work to me...however I can sort of understand the perspective Gonetz had on it since he was the last surviving maintainer of a legacy video plugin, so he carried on with the code of those before him which, I'm sure he knew later on had its flaws. So even if it means hacking out more HLE, it makes sense he would correct that code, things UltraHLE devs. etc. didn't know about it.

But from the perspective of starting off scratch man, if there is enough documentation just to do LLE then that would save half of a man's lifetime working on emulation to just do that I think.

I mean, it's like.
If you HLE graphics ucodes for N64 games, why not HLE graphics ucodes that never get used / exist in any known N64 ROMs?
Because they only care about what the games / commercial stuff is doing.
It's still very beneficial for research / concrete understanding, no doubt, but it has so much less focus on the hardware than just making sure the damn system gets emulated without throwing in software dependencies.

I mean any time you remove a constraint, you can make software faster.
Some file I/O reader program can be optimized by reducing it down to main(){return 0} or w/e ; it's making it as fast as possible "while confirming to the constraints specified by the programming goal" that matters; HLE / static recompilers, these are things that are on the edge boundary of violating that goal because the code is so much less practical / maintainable / readable.
Reply With Quote
  #22  
Old 19th February 2013, 03:03 AM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

You said it yourself: emulation is about preservation. Even angrylion and those who have implemented plugins to the lowest level to-date have noted that there are imperfections in their non-cycle accurate methods. By all means, they are few and far between, but inaccuracies nonetheless.

Given that, and the fact that today's hardware has progressed to the point where cycle-accuracy is either possible, or on the brink of possibility for this generation on consoles, why would one not be interested in seeing if cycle-accuracy is a means to an end?

Surely, HLE has provided us with a great run, and zilmar et. others works are invaluable in giving what the community what it has today, but the minor, known holes that remain are solely waiting to be filled... and HLE doesn't seem to be cutting the bill...

Until I see otherwise, I'll keep chugging along, anyways.
Reply With Quote
  #23  
Old 19th February 2013, 03:09 AM
mudlord_ mudlord_ is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2012
Posts: 383
Default

Quote:
You said it yourself: emulation is about preservation.
Yes, I have been FORCED to accept that fact.

Happy?

If cycle accuracy is what the public wants......its what the public must get.
Now if you don't mind, I must completely purge all n64video plugin references of mine from my hd as I know my work is a waste of everyone's time.

Maybe now you know why I am such a cunt to everyone else. Because everyone else has been telling me that they are right and I am wrong, blablabla, and now I am just butthurt about it being all true.

Last edited by mudlord_; 19th February 2013 at 03:11 AM.
Reply With Quote
  #24  
Old 19th February 2013, 03:14 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

lol

Part of me wishes there was another way to make it 100% accurate, without including the slowness of cycle-accuracy. I see it as process of elimination: if there is no other way to patch the missing holes / inaccuracies then ignore the slowness/consequences of the one and only existing available way, and shoot for completeness/thoroughness. (But it would suck major ass if every single emu was cycle-accurate, and this is limited to not just for people who play pirated games all day long either.) If it's the only way I can ever complete a product, well, I should be grateful that I'm able to conclude that logic and know what the way to be perfect is (even if it is not a very favorable road...).

Part of the reason of what the public wants, in my experience.
Is just what they haven't seen yet.

And this is not pertinent namely to emulation.
I go on other projects I help maintain the code.
And any time a new feature gets added to the program, users swell up the suggestions list with new ideas.
You implement an idea, it opens up a whole new dimension of new ideas suggested by users (not to mention confusions and disagreements over what was just done already).

So, I'm not sure if this makes me like byuu or whatever.
But, bah. Just based on that experience I really don't put a whole lot of stock into what people "want" me to do. I'm sure they'll all get their fair share of taking advantage of me at one point in another, gullible and extroverted as I am.
Reply With Quote
  #25  
Old 19th February 2013, 03:21 AM
mudlord_ mudlord_ is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2012
Posts: 383
Default

Quote:
Part of me wishes there was another way to make it 100% accurate, without including the slowness of cycle-accuracy. I see it as process of elimination: if there is no other way to patch the missing holes / inaccuracies then ignore the slowness/consequences of the one and only existing available way, and shoot for completeness/thoroughness. (But it would suck major ass if every single emu was cycle-accurate, and this is limited to not just for people who play pirated games all day long either.) If it's the only way I can ever complete a product, well, I should be grateful that I'm able to conclude that logic and know what the way to be perfect is (even if it is not a very favorable road...).
In that case, would be very interesting to see what MarathonMan can accomplish, even if it means upgrading a CPU to support SSSE3 and such vector extensions.

I seen cases where cycle accurate can also mean fast, just take certain NES/GBC emulators for instance...I fail to see how it can't apply to N64, too. (especially when MM made efforts to SSE-ize the whole RSP interpreter.)

Quote:
Part of the reason of what the public wants, in my experience.
Is just what they haven't seen yet.
Yes, and now that they seen what happens (like cycle accuracy on a mass scale with byuu's stuff), they want it on EVERYTHING. At least thats how I seen the mass shift to cycle accuracy, all because of one developer.
Reply With Quote
  #26  
Old 19th February 2013, 03:28 AM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Quote:
Originally Posted by haxatax View Post
I seen cases where cycle accurate can also mean fast, just take certain NES/GBC emulators for instance...I fail to see how it can't apply to N64, too. (especially when MM made efforts to SSE-ize the whole RSP interpreter.)
The problem with cycle-accuracy on this generation of console isn't as much as per-core emulation speed as it is keeping everything in sync, while still meeting all requirements of cycle accuracy. The latter is far more difficult in the grand scheme of things.

Quote:
Originally Posted by haxatax View Post
Yes, and now that they seen what happens (like cycle accuracy on a mass scale with byuu's stuff), they want it on EVERYTHING. At least thats how I seen the mass shift to cycle accuracy, all because of one developer.
We're the developers. Ultimately, we get to control what gets churned out.
Reply With Quote
  #27  
Old 19th February 2013, 03:30 AM
mudlord_ mudlord_ is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2012
Posts: 383
Default

Quote:
We're the developers. Ultimately, we get to control what gets churned out.
Not 100% true. You get demands from pathetic end users like wanting accurate aspect ratio settings to preserve "square pixels" and shit.

All in all, I hate end users, I find that they are vermin.
Reply With Quote
  #28  
Old 19th February 2013, 03:33 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

EVERYTHING lawlz...
gimme CA for ALL!11!1

If I had to pick, I would say, do CA only for the well-engineered, educational/scientifically interesting systems.

But for anything totally designed for gaming and nothing else.
Not for homebrew/educational programming, only for playing t3h commercial g4m3z.
Then eh...I would rather do a static recompiler with HLE.

But with a well-known processor like MIPS and a standard vector system not necessarily pertinent for a game, hopefully there is some way to maintain an optimized use for CA...

Quote:
Originally Posted by haxatax View Post
I seen cases where cycle accurate can also mean fast, just take certain NES/GBC emulators for instance...I fail to see how it can't apply to N64, too. (especially when MM made efforts to SSE-ize the whole RSP interpreter.)
Good to know, because I would love for the possibility to exist, that I can make a fast, modern-speed CA.

I know from what I learned in Hacktarux's progress there is not a whole lot of reservoires for speed to start out with...wow and that I believe was without an implementation of the RSP. I would hate if a complete emulator has to be confined to that, but for every logical reason contradicting that conclusion, there seems to be another reason for forcing an insistency on re-impementing SSE stuffs to match their vector unit as much as possible.

For this reason, voiding my solution in the long run of SSE2, just so Win95 / MS-DOS could run it (lmao), is sort of like emulating the N64 on a NES: no one cares. (except, a subset of the emulator which has no RCP support and does all gfx on the CPU, then maybe someone might care)

So assuming even a SSSE3 requirement even if almost nobody can use it without upgrading their machines, sort of seems logical enough if it's the only way to make the RSP emulation even more accurate. Fight fire with fire, target machine vector instructions with [S]16-bit MS-DOS shit[/S] native machine vector SSE set.
Reply With Quote
  #29  
Old 19th February 2013, 02:34 PM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

I had no qualms with making SSSE3 baseline for x86 because, really, if you don't have it, you'll probably just be barely meeting the minimum specs for running the game anyways. SSSE3 is on my 2.4GHz dual core laptop from early '08...

I imagine that I'm leaving out a handful of AMD users, but such is life...
Reply With Quote
  #30  
Old 19th February 2013, 08:07 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

I mean to do it for accuracy, not speed necessarily.

Many times, changes for accuracy go hand-in-hand with changes for speed.
SSE is such an example because why decline enhancements to the instruction set when they entirely replicate some of the vector operations?

Speed is a coincidence. If that was really the goal then people would not have issues with minimum system requirements as such if the emulator were non-CA.
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:26 AM.


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