Windows 10 and Project 64

[HatCat]

Originally Posted by Dekki64

...especially in this forum, where a few of the plugin developers find that "M$"-centric APIs are worthless anyway in the face of software emulation, or OpenGL.

It's interesting that you should call yourself an "observer", in the face of the tens of times we've re-iterated actual reasons that have nothing to do with what you just said.

[NUK3 TH3 WHAL35]

Originally Posted by Dekki64

To be fair, it may provide a good few fixes to a few longstanding problems that DirectX11 could have fixed as well.

Not that any N64 emulation developer ever had any inclination to design a plugin surrounding it, especially in this forum, where a few of the plugin developers find that "M$"-centric APIs are worthless anyway in the face of software emulation, or OpenGL.

In addition, it's not like anyone was in a hurry to support anything considered "modern" anyway. GlideN64 was probably the latest of the efforts to support HLE-related emulation, while Dolphin (among others) have been running circles around N64 emulation for quite some time now.

There may be problems with emulating the N64 that may not be as cut and dry, (and I'm certainly no expert, but an observer over the years) so correct me if I'm wrong.

I think the larger issue with development is complacency. Sure, the emulator is "fine" the way that it is, but why go out of your way to fix larger issues when they can be "fixed" with a series of already existing setting changes and plugin combinations. Now, as to not rattle any supporter or tester's barn, I say this with complete appreciation that all of this (for the most part) is FREE! Granted, they could start a donation page again like they had for 1.7, but it WAS head turning when seemingly ONE guy fixed many MANY issues and ran games "that will NEVER run" (Indiana Jones) with the release of GLideN64. Granted it took him TIME and donations, BUT he pulled it off. Imagine what the Project 64 "TEAM" could do...

[Ambient_Malice]

Originally Posted by Dekki64

In addition, it's not like anyone was in a hurry to support anything considered "modern" anyway. GlideN64 was probably the latest of the efforts to support HLE-related emulation

GLideN64 is LLE, too. Still kinda broken, but it's coming along. Assuming Gonetz can balance his IRL responsibilities with casual coding, the project has quite a promising future.

Originally Posted by NUK3 TH3 WHAL35

it WAS head turning when seemingly ONE guy fixed many MANY issues and ran games "that will NEVER run" (Indiana Jones) with the release of GLideN64. Granted it took him TIME and donations, BUT he pulled it off. Imagine what the Project 64 "TEAM" could do...

For the record, Gonetz was just pairing GLideN64 with mupen64plus for Indiana Jones. GLideN64 handles stuff like pause menus and screen shrinking and all that way better than Ziggy's LLE, but GLideN64 has a bug that prevents any 2D bitmap objects from rendering in Indy. Stuff like water particles and shrapnel and dirt and smoke and lens flares and such. See, GLideN64 actually uses code from Ziggy's LLE, which was a 2007 hardware accelerated fork of Angrylion's. But Ziggy's is a dead project and GLideN64 isn't dead.

[RPGMaster]

Originally Posted by V1del

Of course it is a thing, it has to be a thing, it isn't a thing if you have to synchronize (might've been the wrong word in the other post) millions of calls per second (and PJ64 doesn't use .Net btw)

Because N64 emulation is so reliant on previously computed results you can't just throw more cores at the problem, as they'd have to wait for the result of the previous core anyway. (It depends on the machine to be emulated if you can feasibly multithread it, N64 is not one of them )

Multithreading is useful If you can do it for stuff that's independent e.g. if you compress multiple files to a zip or whatever each file can be compressed in a seperate thread because they are different files the only thing that has to be synchronized is "when is everyone finished?" so that the final file can be written

If we're only concerned about performance, multithreading can certainly be useful. It just depends on what the bottlenecks are. If the RDP is using up 90% of runtime, then obviously it won't help much, but when the ratios are better, it makes enough of a difference. I see a significant difference in performance when using multithreading in D3D9 plugins.

Basically, it's not that useful for most games that actually need extra speed, due to the terrible ratios.

Originally Posted by Dekki64

To be fair, it may provide a good few fixes to a few longstanding problems that DirectX11 could have fixed as well.

Perhaps.

Originally Posted by Dekki64

Not that any N64 emulation developer ever had any inclination to design a plugin surrounding it, especially in this forum, where a few of the plugin developers find that "M$"-centric APIs are worthless anyway in the face of software emulation, or OpenGL.

Name 2 active developers on this forum who think this.

Originally Posted by Dekki64

In addition, it's not like anyone was in a hurry to support anything considered "modern" anyway. GlideN64 was probably the latest of the efforts to support HLE-related emulation, while Dolphin (among others) have been running circles around N64 emulation for quite some time now.

If you're refering to fixing graphical issues in a few games like Pokemon Snap, I wouldn't consider that "running circles around N64 emulation". What else have they done for N64 emulation?

Originally Posted by Ambient_Malice

See, GLideN64 actually uses code from Ziggy's LLE, which was a 2007 hardware accelerated fork of Angrylion's.

Z64gl came out before Angrylion's. Pretty sure ziggy's was based off of MAME's.

[HatCat]

He said "plugin" developers, not experimentalist contributors using an emulator or two to teach themselves code.

Originally Posted by NUK3 TH3 WHAL35

I think the larger issue with development is complacency. Sure, the emulator is "fine" the way that it is, but why go out of your way to fix larger issues when they can be "fixed" with a series of already existing setting changes and plugin combinations. Now, as to not rattle any supporter or tester's barn, I say this with complete appreciation that all of this (for the most part) is FREE! Granted, they could start a donation page again like they had for 1.7, but it WAS head turning when seemingly ONE guy fixed many MANY issues and ran games "that will NEVER run" (Indiana Jones) with the release of GLideN64. Granted it took him TIME and donations, BUT he pulled it off. Imagine what the Project 64 "TEAM" could do...

...Wait, what?

Was that meant as a reply or are you just botting / a bot?

[NUK3 TH3 WHAL35]

"You're right HatCat,

My cousin earned $2,500 at home last week just by doing everyday things!"

Jokes and botting examples aside. Breathe my friend. Sit back and take a DEEP breath. No need to get defensive. Sure this thread is veering slightly from the Windows 10 topic, but we're all friends here sharing tips, tricks, and various viewpoints and opinions on various aspects and functions of this great great emulator. You not only have my respect, but also admiration for your insight and contributions lent to the project.

[RPGMaster]

Originally Posted by NUK3 TH3 WHAL35

Breathe my friend. Sit back and take a DEEP breath. No need to get defensive. Sure this thread is veering slightly from the Windows 10 topic, but we're all friends here sharing tips, tricks, and various viewpoints and opinions on various aspects and functions of this great great emulator.

Agreed

[HatCat]

Originally Posted by "NUK3 TH3 WHAL35

"Sure this thread is veering slightly from the Windows 10 topic,

Cool .

It wasn't that sorry; it just appeared hard to find what post you were replying.
Kind of seemed like Dekki something's but kind of seemed like its own thread, so I just making sure.

[MELERIX]

the BSOD throw the following Bug Check codes: 0x0000001e (0xc0000005, 0x9413cc59, 0x00000000, 0x000000ac).

0x0000001e = KMODE_EXCEPTION_NOT_HANDLED

0xc0000005 = STATUS_ACCESS_VIOLATION
0x9413cc59 = ?
0x00000000 = ?
0x000000ac = HAL_MEMORY_ALLOCATION

[kfdz277]

Found a solution.
Delete the Project64.exe.manifest file and it works. Compatibility mode actually never worked, but as soon as that file was gone, my PJ64 loaded up and didn't crash upon selecting a- well, upon selecting anything.