PDA

View Full Version : Improve Donkey Kong 64 emulation


DKfanatic
17th February 2013, 09:57 PM
Hi... I would suggest that improved support for DK 64, it is a game that never had a remake... :( And as you know, he still has many emulation problems as the screen size (with vertical and horizontal black bars) and other issues.

It would be very nice to play it with HD graphics, Banjo-Kazooie works well, I do not understand why the DK 64 did not, the two games use the same engine and both were developed by Rare.

Other emulators can not even run it, the Project64 is uniquely capable, it would be nice to see him get too run it on the same level of BK.

squall_leonhart
17th February 2013, 10:32 PM
not a valid suggestion.

HatCat
17th February 2013, 11:33 PM
Nope, DK64 uses its own RSP graphics microcode, apart from what Banjo-Kazooie uses.

B-T never (immediately) executes ADD $zero, s1, s2 and tries to overwrite $0 like DK64 does. :D

I have not had a look at DK64 to see if my RSP upgrades maybe have fixed the finite geometry issue etc..

et500
17th February 2013, 11:33 PM
DK64 also has these borders on a real N64, to improve speed. However, of course the video plugin could remove these borders. But the PJ64 video plugin is dead and will not be improved or fixed any further as the developer stopped working on it. Therefore someone has to develop a new or improve an existing video plugin for PJ64.

mudlord_
18th February 2013, 01:22 AM
and who the hell would do that when FatCat and MarathonMan are making it thier mission to make HLE (thus your fancy enhancements) obsolete?

Makes it kinda pointless to continue HLE if everyone will flock to LLE anyway.

HatCat
18th February 2013, 01:27 AM
I still have some interest in HLE.

It is useful for making execution more direct and linear for cases where the hardware operation is too far away from what we can do with Intel ranging over the standard fetch-decode-execute routine.

But yes under the assumption of an infinite variety of graphics ucodes, my objective I feel should be to eliminate the use of HLE as much as possible. I want to assume the worst-case scenario after all.

mudlord_
18th February 2013, 01:29 AM
Indeed, the idea of hires textures must die and pave the way for per pixel/cycle RDP accuracy! :D

ExtremeDude2
18th February 2013, 01:30 AM
B-T never (immediately) executes ADD $zero, s1, s2 and tries to overwrite $0 like DK64 does. :D


Banjo-tooie does :p


I have not had a look at DK64 to see if my RSP upgrades maybe have fixed the finite geometry issue etc..

Last I checked it didn't :p

HatCat
18th February 2013, 01:45 AM
I meant to say B-K cause that was what he was talking about.
B-T I did a typo.

Tooie will overwrite $zero via SPECIAL::ADD or SPECIAL::AND, if unchecked.

HatCat
18th February 2013, 01:50 AM
Last I checked it didn't :p

Most of the test plugins I gave you were speed rewrites, or DMA security rewrites, which would not fix the finite geometry segmentation bugs in DK64.

All of the opcode rewrites I have done since the last time I sent you a stable update on the other hand...

Indeed, the idea of hires textures must die and pave the way for per pixel/cycle RDP accuracy! :D

We get the point.

You like to accuse me of things you know clearly well I have already explained are not true (e.g. me caring to implement cycle-accuracy) because you think it will make me less likely to change my mind about implementing them.

Too bad the opposite is true. If you really don't want me to care about cycle-accuracy so much (currently where I'm at) then learn when to shut up.

mudlord_
19th February 2013, 12:16 AM
Too bad the opposite is true. If you really don't want me to care about cycle-accuracy so much (currently where I'm at) then learn when to shut up.

No, its very good someone gives a damn about cycle accuracy everything.

How else will progress be done? :mad:
Do you honestly think opcode accuracy is adequate? It sure as hell IS NOT!!!!

We must use byuu's method or don't bother trying at all.
Who the hell cares about speed?

Emulation is about preservation, not about playable speeds.

HatCat
19th February 2013, 12:19 AM
learn when to shut up.

Those were the key words, btw. :)

Since you have failed this step I am considering even more to become like byuu, until you learn to shut up. ;)

mudlord_
19th February 2013, 12:21 AM
Which is good.

Become more like byuu, then I have more motivation to treat you like byuu. :D

Which means pissing on your current work, which I haven't done ONCE.

Sure its illogical, but byuu is illogical XD

HatCat
19th February 2013, 12:23 AM
Silly liar. You piss on everyone else's site + work.

I don't care what you think about mine. You insult basically everyone else here; why should just one person make me not ban you at VBA-M? :p

mudlord_
19th February 2013, 12:27 AM
ic what you did thar

why should just one person make me not ban you at VBA-M?

go ahead :D

ok, I should insult your work for not being SSE, and MarathonMan's for being SSE, happy?

HatCat
19th February 2013, 12:30 AM
Meh.

Look, I'm speaking the truth when I say that I'm not concerned with your opinions about my work (though, part of that is contributed by the impression I'm getting that you never seem to have any, just psychological mid-subtle statements attempting to shift my intentions or whatever).
Anyone is free to think what they will (as long as it's not something fucking retarded).

The only thing that's ever bothered me is how I see you treat everyone else on sites like this.
How you treat me? :D You seem more like a generous, perhaps midway insane person, compared to a mentally abusive parent raising a child.

In either case, I have little involvement. :D

HatCat
19th February 2013, 12:42 AM
Hmmm oh yeah,

No, its very good someone gives a damn about cycle accuracy everything.

How else will progress be done? :mad:
Do you honestly think opcode accuracy is adequate?

Well, I don't really see HLE as "emulation progress", but it is useful for learning how to make target hardware behavior more direct on the native environment, studying the algorithms more closely.

Similarly, a simple RSP interpreter without cycle-accuracy is a much smaller base to work with, before forward-extending it with certain aspects or types of accuracy (like cycle-) that a N64 executable could in theory command use of.

I do wish to account for all possibilities (or else I would not be beginning from LLE first); I just don't think it's a good strategy to maintain that adherence from the very first line of code I type. :)
As I said in the thread before this one, solutions to programming should at least start out simple and direct, not desperate. An interpreter can become a cycle-accurate, static recompiler.

mudlord_
19th February 2013, 01:44 AM
I'll bite.

Well, I don't really see HLE as "emulation progress", but it is useful for learning how to make target hardware behavior more direct on the native environment, studying the algorithms more closely.

That I agree with. And I also personally don't see the harm in learning how a game's graphics work on a low software level. And reimplementing said processes. Sure you can have fun while reversing for LLE, don't see how thats different for HLE either. Just different means, and goals.

As I said in the thread before this one, solutions to programming should at least start out simple and direct, not desperate. An interpreter can become a cycle-accurate, static recompiler.

Agreed. Better to have a clean base to start from before experiments are made. I guess that can apply to LLE RDP emulators to HLE implementations, too.

HatCat
19th February 2013, 02:22 AM
Well I try to reverse whenever possible, with what little resources I have (a real N64 no longer being one of them, I'm hoping to RE the memory pak reserved bits on the hardware somehow...sometimes I can disassemble libraries in the OS reference to RE things without having a real N64).
But reversing LLE usually takes less work than hacking out HLE microcodes, from what I understand.
My microcode logger generates like, hundreds of megabytes of RSP instructions for some graphics ucodes...I'm like, WTF? Who in their right mind would go through so much trouble just for HLE'ing specific (not to mention copyrighted) games?

Not that it's at all without admiration, but LLE I believe is the key to passionate, hardware preservation -- not that HLE cannot preserve some of the more direct flow of how tasks are supposed to work natively, but this always ends up including someone else's code indirectly. If you emulate absolutely nothing about the software and only the hardware system itself then morally speaking it becomes a lot more legal and universal (hardware isn't copyrighted).

Agreed. Better to have a clean base to start from before experiments are made. I guess that can apply to LLE RDP emulators to HLE implementations, too.

This was the goal of Project Unreality at first, from the beginning day that people only just started to know a N64 emulator could be made do with...but the rarity of one with the skill to use the information properly, is not unique apart from the rarity of one who can implement the information in a readable, accurate layout (an interpreter base...in the RSP's case, much like zilmar had to do before Jabo could make a recompiler out of it). Start out by including the least amount of information as possible, and there is less things to be broken / stand a chance of being inaccurate (missing information is better than misinformation).

I'm more-or-less following behind MarathonMan's lead since I know little of cycle-accuracy, but if it's the only way to guarantee every single thing will work as the N64 may require then it's not something I can just ignore. I'm certainly willing to accept help off of the example he applies with it, but for now, my efforts are independent of anyone else's. If need be I am happy if my work ends without cycle-accuracy in it, but somewhere out there we definitely should have at least one demonstration. There are lots of other things like this I don't know for sure I'll finish adding, hence why I'm defaulting to open-source in case nobody else takes an interest in the RSP by the time I get back to it (hate focusing on the same project for too long).

mudlord_
19th February 2013, 02:46 AM
Not that it's at all without admiration, but LLE I believe is the key to passionate, hardware preservation -- not that HLE cannot preserve some of the more direct flow of how tasks are supposed to work natively, but this always ends up including someone else's code indirectly.

oh yes, including using Nintendo's manuals for documentation on thier ucodes.

My microcode logger generates like, hundreds of megabytes of RSP instructions for some graphics ucodes...I'm like, WTF? Who in their right mind would go through so much trouble just for HLE'ing specific (not to mention copyrighted) games?

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)

HatCat
19th February 2013, 03:02 AM
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).


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 :D; 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.

MarathonMan
19th February 2013, 03:03 AM
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. :)

mudlord_
19th February 2013, 03:09 AM
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.

HatCat
19th February 2013, 03:14 AM
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.

mudlord_
19th February 2013, 03:21 AM
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.)

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.

MarathonMan
19th February 2013, 03:28 AM
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.

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. ;)

mudlord_
19th February 2013, 03:30 AM
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.

HatCat
19th February 2013, 03:33 AM
EVERYTHING lawlz...
gimme CA for ALL!11!1 :eek:

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. :D

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...

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. :D (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 16-bit MS-DOS shit native machine vector SSE set.

MarathonMan
19th February 2013, 02:34 PM
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...

HatCat
19th February 2013, 08:07 PM
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.

mudlord_
21st February 2013, 02:03 AM
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...

Yes, hapless AMD users like myself need to rot in hell for poor CPU choices. but when you think about it, $300 for a Ivy Bridge CPU aint that bad.

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.

Yes, nothing wrong with zilmar's approach (non CA LLE). Has benefits.

DKfanatic
24th February 2013, 02:05 AM
I'd just like to see that this is one of the best N64 games be emulated as close to real console... Banjo Kazooie and Banjo-Tooie has HD remakes on Xbox 360's XBLA, but the DK 64, by having characters belong to Nintendo, never had this remake... the only way you can play it in an similar experiment to the Banjo titles would be through emulation

I know it's hard but also know it's not impossible, because as already mentioned, the Banjo games run very close to the real N64

Please PJ64 developers, work on improving the emulation of this game :(

squall_leonhart
24th February 2013, 02:30 AM
we refuse.

JulianSK
1st March 2013, 05:36 PM
I also like DK64, I hope the day he can run closer to real N64.
If the video plugin was updated...

et500
1st March 2013, 07:16 PM
I do not see any use in a pixel accurate emulator since I want to play my games with massively enhanced graphics in 1080p, which is the only reason for me to use an emulator instead of the real system. It just looks so much better when played on a modern TV and is therefore much more fun compared to the ugly original ultra-low res graphics.

I also think that the goal of 100% perfect emulation is much easier to achieve with the HLE approach, since the number of games to emulate is very small and limited.

mudlord_
3rd March 2013, 04:28 AM
people have different goals.

Some like to masturbate to 1080p visuals, increased internal res and hires textures, others masturbate to raw unfiltered/unaltered pixels.

HatCat
6th April 2013, 08:22 PM
I also think that the goal of 100% perfect emulation is much easier to achieve with the HLE approach, since the number of games to emulate is very small and limited.

Come on! This again?

HLE means it can be perfect based on the software that's running.

You can port a game from N64 to Win32 native executable and it will run like a perfect replica of just one of the N64's softwares.

That is far from saying HLE allows perfect emulation of the hardware system.
It's very nice, but not necessarily fundamentally academic.

Honestly, how can you manage to be wrong about at least one thing every single time you make a post here?
You're a nice guy and all that, patient and generous and all that other side stuff.
But, I think you can do better.

daninthemix
10th April 2013, 09:52 AM
Come on! This again?

HLE means it can be perfect based on the software that's running.

You can port a game from N64 to Win32 native executable and it will run like a perfect replica of just one of the N64's softwares.

That is far from saying HLE allows perfect emulation of the hardware system.
It's very nice, but not necessarily fundamentally academic.

Honestly, how can you manage to be wrong about at least one thing every single time you make a post here?
You're a nice guy and all that, patient and generous and all that other side stuff.
But, I think you can do better.

Sorry to bring the thread back on topic but what are these RSP upgrades you speak of? Can I give them a try?

HatCat
10th April 2013, 12:54 PM
lulz ^

Last night, I just rewrote the entire RSP divide system from the legacy controlled FP method zilmar/MAME was using (as of z64gl), to the official divide techniques installed to the most recent version of MAME (after z64gl was created to install what was the MAME RSP at that time). This improved Mario64 gfx flickering and fixed hardware T&L illumination effects in F3DZEX Zelda64 ucodes.

Lots of CP0 rewrites, controlled RSP CPU loop directly with SP_STATUS_HALT rather than relying on a BREAK to quit the task and nothing else (but, no games exploit this, so zilmar's RSP was safe from the bug).

Plus destroying and rewriting code several times over again every time I think of a structural improvement that benefitted the directness of R/W for some ops or other speed/accuracy gains.

Had to fix a bug making Zelda MM unplayable on the z64 RSP ... z64gl is not playable with ZeldaMM due to a missing opcode (BLTZAL, extreme rarely used and only in F3DZEX 2), unless you either use my RSP or zilmar's, but not ziggy's interpreter port.

Plus like, 20-800 other things, depending what makes sense to people / what they find worth caring.

A few people have helped me privately test the RSP, but I think there is so much information I might want to find out about what some games will exploit to help test the corner cases, I'm actually nearing the end of my infinite mindset of always having something to do to the RSP, meaning it's near a finishing point that I can release a test version.
I could probably try to give you a deadline but I don't see the point in that. It's closing in. :p

Pau
14th April 2013, 04:48 PM
Other emulators can not even run it, the Project64 is uniquely capable, it would be nice to see him get too run it on the same level of BK.


Why is PJ64 uniquely capable? Even these sellouts on Android are claiming to be able to run DK64

Raz
2nd June 2013, 08:55 PM
The issue i'm having with this game is that the intro is too slow.these are my computer specs.
http://i.imgur.com/M9PwJIl.jpg

RPGMaster
5th August 2014, 06:23 PM
Dat cpu 2 weak. The only plugins I can see you running at decent speed is 1964 Video and Jabo 1.52.

Let me know if you can get full speed with Jabo_DirectD3D6 1.52 .

ExtremeDude2
5th August 2014, 06:41 PM
lol vista (wait why don't you have SP2)

HatCat
5th August 2014, 07:27 PM
lol chrome (wait why don't you have a browser)

ExtremeDude2
6th August 2014, 05:36 PM
what is a browser?

HatCat
6th August 2014, 08:31 PM
something thru which you browse, rather than being browsed on by a company of molesterers like Google

GeneralGiantPanda
14th August 2014, 03:34 AM
something thru which you browse, rather than being browsed on by a company of molesterers like Google

Fair enough, but damn it if they don't give a fine reach-around.

Rodimus Primal
22nd August 2014, 12:51 AM
I applaud any effort to making N64 emulation as playable as possible. Both cycle accuarate and the current N64 emulators are doing what is necessary. And they truly can learn from each other. I long for the day I can play Donkey Kong 64 and Majora's Mask with no slowdowns or major issues (if any at all). Now its a matter of tweaking settings for each game. The end users, while some of you developers don't like them, would like the simplicity of just playing the game. Personally I don't care about HD filters that alter the graphics on the game. I much rather have the game run without it looking out of foucs like my actual N64 does on my HDTV.