IYO: How do you feel about the future of N64 emulation?

[Ambient_Malice]

GLideN64 has suffered from poor priorities and management. For example, GLideN64 does not need bloom. GLideN64 does not need Dolphin's shader system. The only shader it truly needs is a post-processing AA method, preferably SMAA.

GLideN64 needs:
Broken LLE to be fixed. (Muh Turok. Muh Indiana Jones.)
An HLE software renderer/alternate fix for Snap/Body Harvest/etc.

LLE is an absolute mess. As a side effect, low level polygon stuff such as skies are broken in HLE, too.

[p_025]

Like I said, in practice, GLideN64 didn't quite turn out the way it ought to have. And I agree that postprocessing shaders are very unnecessary. That being said, I'm glad it's as good as it is, and I'm glad it's open source. Perhaps there will be enough interest to help development.

[Ambient_Malice]

I'm vaguely annoyed that the HLE dynamic lighting problems in Turok 2, Turok 3, and Armorines have been known for basically over a decade, yet basically zero effort has gone into fixing them.

This is what happens, I suppose, when HLE emulation relies on wonky reverse engineered ucodes that almost nobody can be bothered studying. (I suspect the missing lighting is ucode related, since it works perfectly in all LLE renderers.)

[RPGMaster]

I think some end users have unrealistic expectations. It's like people want a cycle accurate + pixel accurate + hd graphics + full speed !

Originally Posted by p_025

That's all well and good, the problem (for me) is when a pixel accurate plugin is the only option, which means I can't use a certain enhancement I enjoy. For example, until very recently Jabo's video was the only one I knew of that had a widescreen hack. Wanna play this game that only works on Rice (for example)? TOO BAD SUCKAH, you either get big black bars on both sides of the screen, or stretchy graphics.

Wanna play this game that needs a pixel accurate plugin? I hope you like playing games in 240i.

There's always a price to pay, can't have everything. I feel like the demands are too heavy these days, hence why I believe some devs have poor priorities. I admit I do prefer high-res graphics. At the same time, in some cases, it's best to use a software render, due to the many challenges. For instance, I get better performance with Angrylion's plugin in some games, than I do with z64gl ;/ . It's nice to have a plugin where you don't have to deal with any known accuracy issues.

Someone just needs to optimize it.

Originally Posted by p_025

Much of my interest in N64 emulation lately is due to netplay (so I am quite interested in fixing Fixed Audio Timing (or watching the progress of it anyway)). I liked GLideN64's approach. Shoot to be as accurate as you can and add complicated hacks and enhancements later. Though in practice I don't think he spent long enough on accuracy/compatibility. Still, it's good work.

Feel free to compile latest source, or download binary from emucr or someone.

Originally Posted by Ambient_Malice

GLideN64 has suffered from poor priorities and management. For example, GLideN64 does not need bloom. GLideN64 does not need Dolphin's shader system. The only shader it truly needs is a post-processing AA method, preferably SMAA.

I have to agree with this. I'd much rather see the remaining unsupported games get implemented in HLE.

Originally Posted by Ambient_Malice

GLideN64 needs:
Broken LLE to be fixed. (Muh Turok. Muh Indiana Jones.)

It needs to be more optimized too .

Originally Posted by Ambient_Malice

An HLE software renderer/alternate fix for Snap/Body Harvest/etc.

Would be cool to see an accurate HLE software renderer, but aint nobody got the time for that . It's too much.

Originally Posted by Ambient_Malice

I'm vaguely annoyed that the HLE dynamic lighting problems in Turok 2, Turok 3, and Armorines have been known for basically over a decade, yet basically zero effort has gone into fixing them.

This is what happens, I suppose, when HLE emulation relies on wonky reverse engineered ucodes that almost nobody can be bothered studying. (I suspect the missing lighting is ucode related, since it works perfectly in all LLE renderers.)

Much to my surprise, Gonetz doesn't really know the RSP too well. He was looking for an RSP expert, due to problems with Zelda MM.

[N64man]

cycle accurate + pixel accurate + hd graphics + full speed

I can imagine only several variants of it as possible: cycle accurate + full speed, cycle accurate + pixel accurate(for 2D) + full speed. Something like it.

- cycle accurate: dont sure right, but if it means work as on real console so, it will be good to emulate in reasonable limits(not like DICE for example or byuu's thoughts - http://arstechnica.com/gaming/2011/0...snes-emulator/ ).

- pixel accurate: I think it have point for 2D games and 2D elements. Plus text, probably.

- hd graphics: I see the point in high resolutions(more 640x480) only. HD packs in my opinion dont needed. Something like Doom source ports(Zandronum, for example), higan and DOSBox without any upscales except hardware2x, hardware3x.

- full speed: I think, the reason is obvious.

And agree with code optimization(and probably not code only).

[p_025]

Originally Posted by RPGMaster

Feel free to compile latest source, or download binary from emucr or someone.

Well I did compile the PJ64 source from a fresh Github checkout, not sure what I was thinking I could do with it, but there it is. I could do the same for the GLideN64 plugin, but same problem.

Not sure why you brought it up, really, does the source at the moment have fixes not included in the public release update? I was under the impression he was prioritizing GLES 2.0 support.

[RPGMaster]

Originally Posted by p_025

Well I did compile the PJ64 source from a fresh Github checkout, not sure what I was thinking I could do with it, but there it is. I could do the same for the GLideN64 plugin, but same problem.

Not sure why you brought it up, really, does the source at the moment have fixes not included in the public release update? I was under the impression he was prioritizing GLES 2.0 support.

I actually just meant PJ64 . There have been some good improvements, since the release in April 1st .

[HatCat]

Originally Posted by RPGMaster

For instance, I get better performance with Angrylion's plugin in some games, than I do with z64gl ;/ .

Got any examples of this?

[RPGMaster]

Originally Posted by HatCat

Got any examples of this?

With z64gl, some menus are ridiculously slow, like in SD Hiryuu no Ken. Regular gameplay is still a bit faster on my end with Angrylion's with filters off. I'm sure at least part of the problem is my hardware.

In games like Rogue Squadron, z64gl has a higher max VI/s, but it dips below 60 more often than Angrylions for some reason ;/ . Of course I'm using 4MB and not 8MB though.

[p_025]

Originally Posted by RPGMaster

I actually just meant PJ64 . There have been some good improvements, since the release in April 1st .

Oh, well in that case I may pull the latest changes and check it out. I've avoided using the builds I've produced since using the same core is so important to netplay, and I haven't been sending new builds to my friends.

Netplay is finnicky enough as it is right now, with a quirky input plugin workaround. I'm surprised it works at all. But it's a pleasant surprise.