In response to N64 emulation threads on byuu.org

mudlord · Post by **mudlord** » Tue Jul 28, 2009 11:25 pm

Since byuu added a dictatorship, I am forced to post my responses here. Thank you byuu. Even though I was wanting to be civil in the sections beside the bsnes section, which I completely avoid: I have to post here.

I am somewhat glad it happened that a seperate forum exists: It seperates the riffraff which is prone to flame wars over something as pathetic as ideologies or scene politics.

Now then.

ShadowFX wrote:one argument against it is that these wrappers have slight issues (off-by-one on rounding, missing blending effects, etc)

How so. All blending effects are done by shaders. They all work. Only thing that doesn't work is depth buffer copies with FBOs, but thats a OpenGL issue. Not ours. To fix it will involve using gl_framebuffer_blit, which will increase the system requirements to OGL2.1-3.0 level!

If you use the graphics card for pixel shading and other 3D work (as I believe PCSX2 does) or, more radically, as a co-processor, then it would be involved in the emulation. If you use it simply to blit the result of emulation to the screen, then no.

Correct Ver. Glide64's wrapper uses shaders to emulate how the pixel pipeline in the Voodoo 5 operates.

Panzer88 wrote:A cleanly written emulator but doesn't have to be PERFECT replication of the system in all it's glory. I think it just takes the right person to want to take it on and that just hasn't happened yet.

People will only bitch about what I did.

IST wrote:I'm not sure how good the wrapper is. I do know it was specifically built for the plugin... You'll have to ask mudlord, he wrote it(Or most of it).

Yes.

1) Its made ONLY for the plugin
2) It emulates a Voodoo 5 only to the extent it requires
3) It uses fragment shaders. And framebuffer objects.
4) It works well for all games atm. The only thing that is left to fix is depth copies with framebuffer objects, and thats not a easy fix. Apparently Dolphin does depth with FBOs fine: I want to know how it does it. o.o

And it doesn't support AA due to point 3 regarding FBOs. Adding AA will drastically increase the system requirements for the vid card.

I think the Glide64 plug-in is designed for use on Voodoo3 or newer Glide hardware. You can try anyway, though.

It even works on Banshees. Only issue is: the Banshees and Voodoo 2's will only support a limited number of HWFBE based effects.

So the wrapper is capable of doing everything that the plugin does, accurately? I wonder if Glide wrappers have developed beyond what they were during the UltraHLE era, which was pretty good but not perfect. Maybe if a wrapper works well someone can do a source code level wrapper to avoid some of this.

Yes Exo, the wrapper does almost everything fine, apart from the issues described about.

And yes, source code level wrapper is possible. The Linux version uses a *.so, Windows; a DLL, so its not used atm. And its not gonna happen since I don't work on that wrapper anymore: I got sick of politics.

Deathlike2 · Post by **Deathlike2** » Wed Jul 29, 2009 2:34 pm

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

Please be civil.

I've used a Glide wrapper recently for a small set of games. They work just fine, but ultimately need DX9 to be optimally useful (for performance/feature reasons). Shaders are generally used to emulate many aspects of the older hardware (usually transform and lighting AFAIK, a DX7 feature). I think people getting paranoid over finer details of these things... but let's say it's mainly a problem with people's unfamilarity of the matter.

It does sound like most of you have missed the time when you couldn't apply AA to many shader-based games (specifically those with HDR)... there were discussions on that (in the graphics card communities), and now you people reinvent the wheel?

DancemasterGlenn · Post by **DancemasterGlenn** » Wed Jul 29, 2009 3:52 pm

Wait, you came to the zsnes board to avoid flame wars? Hm.

Well, thanks for the post, anyway. Interesting stuff. What are you working on, at the moment?

funkyass · Post by **funkyass** » Wed Jul 29, 2009 6:24 pm

Voodoos supported hardware transform and lighting?

Deathlike2 · Post by **Deathlike2** » Wed Jul 29, 2009 6:53 pm

No, it was a tangent on what shaders are used for. IIRC, late drivers for Voodoos had the closest thing to software T&L via using CPU extensions. Although, it was probably to get around the hardware T&L checks...

Anyways, shaders cover many things these days... I suggest looking up dgVoodoo or zeckensack's Glide wrapper (where is the guy lately?)

funkyass · Post by **funkyass** » Wed Jul 29, 2009 7:22 pm

Before the Geforces, T&L was handled on the CPU.
Can't recall if it was handled by the driver or the software doing the rendering, I think the latter.

Deathlike2 · Post by **Deathlike2** » Wed Jul 29, 2009 7:44 pm

The latter sounds about right. CPU instructions (SSE/3dnow) are commonly used for drivers to help accelerate this task... not sure if they do it with non-ATI/NVidia hardware these days though.

mudlord · Post by **mudlord** » Wed Jul 29, 2009 11:46 pm

It does sound like most of you have missed the time when you couldn't apply AA to many shader-based games (specifically those with HDR)... there were discussions on that (in the graphics card communities), and now you people reinvent the wheel?

The reason for that was they used deferred rendering.

Its pretty much the same here. We can't do AA due to how HWFBE is implemented. To add AA would involve rewriting it all. Which is what the Dolphin people have done with their HWFBE implementation in thier GC stuff.

Well, thanks for the post, anyway. Interesting stuff. What are you working on, at the moment?

The Vectrex stuff. At the moment, all thats left is minor things like input/overlays/phosphor emulation by the GPU with GLSL, etc. I have to do the phosphor stuff on my own, because...again of the byuu dictatorship so I am unable to give ideas,etc.

Deathlike2 · Post by **Deathlike2** » Wed Jul 29, 2009 11:52 pm

I'd swear you need an avatar of an iron fist.

Post by **grinvader** » Thu Jul 30, 2009 12:10 am

Squall_Leonhart · Post by **Squall_Leonhart** » Thu Jul 30, 2009 12:18 am

mudlord wrote: Its pretty much the same here. We can't do AA due to how HWFBE is implemented. To add AA would involve rewriting it all. Which is what the Dolphin people have done with their HWFBE implementation in thier GC stuff.
.

are you meaning AA isnt meant to work in Glide64... because i just tested it on 190.38 and it did O.o

Deathlike2 · Post by **Deathlike2** » Thu Jul 30, 2009 12:41 am

It is more than likely that driver hacks to work around those issues have been done with more recent hardware. I think mudlord is referring to built-in AA for the app.

The built-in AA driver hack is not guarenteed to work across the board though.

mudlord · Post by **mudlord** » Thu Jul 30, 2009 1:12 am

Squall_Leonhart wrote:
mudlord wrote: Its pretty much the same here. We can't do AA due to how HWFBE is implemented. To add AA would involve rewriting it all. Which is what the Dolphin people have done with their HWFBE implementation in thier GC stuff.
.
are you meaning AA isnt meant to work in Glide64... because i just tested it on 190.38 and it did O.o

Correct. AA on Voodoo 5's with texture buffer usage (for HWFBE) won't work. Likewise, with the wrapper, it won't work because of how things are done on a code level.

As I said before, doing it on a in-app level would require a lot of rewriting and a extra FBO to resolve to.

..And if you use D3D, you can avoid that issue entirely by supporting multisampled render targets IIRC >.<

Gil_Hamilton · Post by **Gil_Hamilton** » Thu Jul 30, 2009 5:09 am

mudlord wrote:
Well, thanks for the post, anyway. Interesting stuff. What are you working on, at the moment?
The Vectrex stuff. At the moment, all thats left is minor things like input/overlays/phosphor emulation by the GPU with GLSL, etc.

WHOO! VECTREX!
It'll be nice to see an emulator that does it right.

mudlord · Post by **mudlord** » Thu Jul 30, 2009 6:35 am

Yes, all emus I seen are either half done (vecx) or damn contrived to use (like MESS). I want something that is feature rich and does the job well.

Richard Banister's emu is cool from what I seen, but sadly its for MacOSX only. And I don't like the emu in Java, no offense.

Squall_Leonhart · Post by **Squall_Leonhart** » Thu Jul 30, 2009 6:39 am

mudlord wrote:
Squall_Leonhart wrote:
mudlord wrote: Its pretty much the same here. We can't do AA due to how HWFBE is implemented. To add AA would involve rewriting it all. Which is what the Dolphin people have done with their HWFBE implementation in thier GC stuff.
.
are you meaning AA isnt meant to work in Glide64... because i just tested it on 190.38 and it did O.o
Correct. AA on Voodoo 5's with texture buffer usage (for HWFBE) won't work. Likewise, with the wrapper, it won't work because of how things are done on a code level.

As I said before, doing it on a in-app level would require a lot of rewriting and a extra FBO to resolve to.

..And if you use D3D, you can avoid that issue entirely by supporting multisampled render targets IIRC >.<

ah, ok so it works when forced globally

Gil_Hamilton · Post by **Gil_Hamilton** » Thu Jul 30, 2009 7:08 am

mudlord wrote:Yes, all emus I seen are either half done (vecx) or damn contrived to use (like MESS). I want something that is feature rich and does the job well.

Richard Banister's emu is cool from what I seen, but sadly its for MacOSX only. And I don't like the emu in Java, no offense.

Last I checked, MESS didn't do it right, either.

And not just from a display point of view. First run of Minestorm would drop all the mine seeds in one quadrant of the screen without fail.

This was... 0.84, it looks like. So quite a long time ago.

mudlord · Post by **mudlord** » Thu Jul 30, 2009 7:21 am

It'll be nice to see an emulator that does it right.

Define "right".

You want something sub cycle based? Or even more accurate?

creaothceann · Post by **creaothceann** » Thu Jul 30, 2009 8:01 am

Voltages, in float please.

mudlord · Post by **mudlord** » Thu Jul 30, 2009 1:00 pm

Its such a shame that the things are utter collector's items nowadays. D:
Which makes research hard.

Gil_Hamilton · Post by **Gil_Hamilton** » Fri Jul 31, 2009 3:09 am

mudlord wrote:
It'll be nice to see an emulator that does it right.
Define "right".

You want something sub cycle based? Or even more accurate?

Something that approaches correct, from the perspective of an end-user that's actually used a Vectrex before.

Reasonably close behavior to the original hardware, and vector display emulation(while closer in spirit to graphics filtering than core emulation, vector display emulation makes a hell of a lot more difference than NTSC display emulation does on a TV-based game console).

I'm not saying we need a bVectrex here.
Just something that runs software properly, and looks and sounds close to right while doing so.

Hell, not even asking 3D Imager or lightpen emulation.

mudlord wrote:Its such a shame that the things are utter collector's items nowadays. D:
Which makes research hard.

Yeah, the Veccy community's always been small but loyal, so it's held onto value MUCH better than most other systems.

Look at it this way, though... at least there's no electrical differences between the GCE Vectrex, Milton-Bradley Vectrex, and (god help us) Bandai Vectrex.
And I don't think anyone in their right mind would attempt emulation of the color Vectrex prototype.

mudlord · Post by **mudlord** » Fri Jul 31, 2009 4:39 am

Reasonably close behavior to the original hardware, and vector display emulation(while closer in spirit to graphics filtering than core emulation, vector display emulation makes a hell of a lot more difference than NTSC display emulation does on a TV-based game console).

Ah, you had me scared for a moment. I honestly don't see in this case the need to go pure sub cycle or more, or even cycle accuracy to the extent some emulators does.

The display emulation is what really interests me though (my main programming interests are in image processing on modern cards). Hence why I was interested in those phosphor filter discussions. Doing those with shaders would be very interesting, as well as some other things but that might depend on the renderer architecture. Currently I have:

* the main render texture for the vectors
* the shader texture which contains framebuffer info from the first texture
* the overlay texture

I honestly see that I might need more filter textures, because of how certain things might be done. For instance, for NTSC filters in D3D, coefficient textures are used (or so I heard from psxAuthor when he played with NTSC emulation in his pSX stuff), so might need the same for the phosphor stuff, dunno yet.

... at least there's no electrical differences between the GCE Vectrex, Milton-Bradley Vectrex, and (god help us) Bandai Vectrex.

..Oh god. Considering the current license situation with the Veccy, I am amazed no other companies made thier variant.

ShadowFX · Post by **ShadowFX** » Fri Jul 31, 2009 8:07 am

mudlord wrote:
ShadowFX wrote:one argument against it is that these wrappers have slight issues (off-by-one on rounding, missing blending effects, etc)

Please don't quote something I didn't write. Thank you.

mudlord · Post by **mudlord** » Fri Jul 31, 2009 12:44 pm

...Excuse me?

No need to be so snarly, jeez.

Sorry for misquoting then..................

Now I regret posting all this in the first place. Now the same shit is happening that I wanted to avoid in the fucking first place!!!!!!!

Give me a fucking break, please? Or are some people also still bitter?

Squall_Leonhart · Post by **Squall_Leonhart** » Fri Jul 31, 2009 4:07 pm

dude, just ignore shadowfx, hes a prudish asshole no matter the site he is on.

ZSNES board

In response to N64 emulation threads on byuu.org

In response to N64 emulation threads on byuu.org

Re: In response to N64 emulation threads on byuu.org