OPENGL used in n64 emulation

[CyDEtrakD]

ayo,
i'm utterly amazed by the advancements with n64 emulation since the ultrahle days.. back then i was pushing a 300mhz amd k6, 64 megs of ram, 4 gig hard drive, monster3d II (voodoo2) w/ 12 meg and now i got a 1.3 gig athlon, 40 gig hd, 128 ram, and geforce 2 mx 64 meg.. most games run fine but classic like killer instinct and gauntlet legends isnt full speed just yet. my only complaint is there is no good support for opengl in the n64 scene.. i mean whats the deal? I've been browsing thru the forum for a good lil minute and peeped that most kats use geforce cards which is designed to run opengl faster than direct3d.. why not make a opengl plugin that is worth something. is it more complicated coding opengl than direct3d? personally when i run something in opengl there is a dramatic speed increase over direct3d in such games/emu as zinc, a ton of fps, psx emus, and hence i'm wondering why there isnt proper opengl support to my knowledge.

one,
cydetrakd

 

[schibo]

There are other OpenGL plugins in the works, but from our position it's really an issue of time and will, both of which are in short supply. I can tell you that Jabo has encouraged us to go the way of OpenGL, but I'm lazy and not very skilled in graphics.

I am in no way the authority on this, but the simple way I see it (for argument sake) is: from the display lists that i've analyzed, they use functions written by SGI. So is OpenGL. But microcodes (like Rare's) can do weird stuff. I have seen others argue that Direct3D is better for certain combine modes and other stuff, though I haven't dug deeply enough to make an intelligent argument for or against that. Only a serious opengl plugin developer can really answer your question. (Hm, why did i even post this? )

 

[icepir8]

There are other OpenGL plugins in the works, but from our position it's really an issue of time and will, both of which are in short supply. I can tell you that Jabo has encouraged us to go the way of OpenGL, but I'm lazy and not very skilled in graphics.

I am in no way the authority on this, but the simple way I see it (for argument sake) is: from the display lists that i've analyzed, they use functions written by SGI. So is OpenGL. But microcodes (like Rare's) can do weird stuff. I have seen others argue that Direct3D is better for certain combine modes and other stuff, though I haven't dug deeply enough to make an intelligent argument for or against that. Only a serious opengl plugin developer can really answer your question. (Hm, why did i even post this? )

I think Schibo hit the nail on the head.

The bottle neck in my OpenGL pluggin id probably in the textures load. First off I am converting all textures to 32bit RGBA (read slow) and the combine modes used in a lot of games require that I load differrent versions of the same texture (again read slow). I am looking into using OpenGL extension to help with this, but I don't know how much of a performance gain I will be able to relize by this.

The N64 has a pretty flexable combine system that does not translate into OpenGL easily. Actually Glide simes to have the closest match to the N64. Maybe this is why UltraHLE used Glide for graphics.

I'll keep pluggin' away at it.

 

[CyDEtrakD]

ayo,
i want to personally thank u for lookin into something that has bugged me since i found that all the opengl plugins arent compatible like the direct3d ones.. i see that it is hard work and i myself have no clue on coding plugins so mad props to u ice for workin on something that hasn't been solved in the n64 mystery of emulation.. u'll hit it on the nail one day and everyone with a geforce card will be giving u props. good lookin out yo.

one,
cydetrakd

 

[conkerman]

The N64 has a pretty flexable combine system that does not translate into OpenGL easily. Actually Glide simes to have the closest match to the N64. Maybe this is why UltraHLE used Glide for graphics.

maybe this is also why dave2001 has advanced so quickly with his plugin. do any of you guys know if opengl 2.0 (whenever it scomes out...anytime now....) will possibly make it easier to emulate the graphics (combine system and all)?
conkerman

 

[Dave2001]

yes, glide works VERY well for it

(except for the fact that it can't have non-power-of-two textures, and >256 size textures... GRRRRR...)

 

[Hacktarux]

I think Schibo hit the nail on the head.

The bottle neck in my OpenGL pluggin id probably in the textures load. First off I am converting all textures to 32bit RGBA (read slow) and the combine modes used in a lot of games require that I load differrent versions of the same texture (again read slow). I am looking into using OpenGL extension to help with this, but I don't know how much of a performance gain I will be able to relize by this.

The N64 has a pretty flexable combine system that does not translate into OpenGL easily. Actually Glide simes to have the closest match to the N64. Maybe this is why UltraHLE used Glide for graphics.

I'll keep pluggin' away at it.

In the old version of the plugin i have noticed that you have used the gluScaleImage function to have power two textures. I don't know if you are still making it this way, but if you do, i think it can use much time. I think that you can allocate a bigger area (power 2) and decompress the texture into a little part of this area. Then you load this texture in the video memory. And finally when the texture is actually used, you have to divide the coordinates by the width of your texture.

I think this can give you a nice speed up without changing many things in your code. (of course if it has not already been done)

The second thing i see that can speed up things is the texture cache size : it seems that when it is too large it slow downs things a bit. And when it is too low it also slow downs things. I don't know how you have implemented it, but maybe it is possible to make a hash table to search the textures faster.

 

[pj64er]

ayo,
i want to personally thank u for lookin into something that has bugged me since i found that all the opengl plugins arent compatible like the direct3d ones.

id like to correct u on that. for a long time there was only one worthy DX gfx plugin (do i have to name it?), in fact there still is only one. your complaint actually came a few months too late, for 3+ ogl plugins are at the works even before u made your poll and your requests. Look around before u do this kinda thing.

o ya, u have to be patient, the best is yet to come:colgate:

 

[Dave2001]

In the old version of the plugin i have noticed that you have used the gluScaleImage function to have power two textures. I don't know if you are still making it this way, but if you do, i think it can use much time. I think that you can allocate a bigger area (power 2) and decompress the texture into a little part of this area. Then you load this texture in the video memory. And finally when the texture is actually used, you have to divide the coordinates by the width of your texture.

That's exactly what I do. I round up to the next power of two and load it into a smaller area. There does however come a problem with this. What if it needs to wrap on a non-power-of-two boundary? Then it's trouble and you must scale. I haven't handled this yet, but have seen things that require it.

It is nice if it clamps though. Then when you load it to a smaller texture, all you have to do is clamp to the rest of the area.

 

[CyDEtrakD]

ayo,
i just wanted to spark some intrest on the topic. i've seen that a few of the plugins are already available they just are all out a the early stages.. maybe some kid will see my posts and decide to make one from scratch and come up with some kind of new discovery that will aid all the opengl coders and the n64 will be emulated perfectly for all kats with geforce cards.. i forgot to give props to schibo for his work on this great emu and responding to me. its just strange that this topic isnt really discussed since from what i seen opengl runs things alot nicer than direct3d on geforce cards.

one,
cydetrakd

 

[DeadRabbit]

o ya, u have to be patient, the best is yet to come:colgate: [/B]

Yes I can't wait for LightKnights plugin either

I'm on the edge of my seat here in anticipation :happy: :happy:




I'll just get my coat then

 

[Doomulation]

Yes I can't wait for LightKnights plugin either

I'm on the edge of my seat here in anticipation :happy: :happy:




I'll just get my coat then

I doubt it'll get very good...
lightknight is more a fool than a plugin-developer.

 

[icepir8]

I doubt it'll get very good...
lightknight is more a fool than a plugin-developer.

lightknight is more a fool than a plugin-developer is a fool?

to tell the truth, I am tied of hearing about lightknight.:sleeping: Just ignore the fool. he's been ban. End of story. OK?

 

[Azimer]

icepir8, I love your signature. It's all too true lol And to stay on-topic, I will just add opengl to this post and plugin. Now it contains the on-topic keywords

 

[Slougi]

Ah, Azi that was so informative. Now I understand the principal differences between ogl and dx

Didn't mention plug-in yet so here goes

 

[Jabo]

Alright, I'm pretty bored at work. :bunny: woo bunnies. anyway.

Worrying about performance in an emulation world for graphics api's isn't really relevant unless you have serious issues understanding how drivers work, and AGP. That being said, I think my plugin spent < 15% of it's time in Direct3D (i would imagine my opengl was similar), 85% was spent outside it.. i think one of the biggest overheads is interpreting display lists, it was something I researched back in february or january one day but didn't really find any satisfactory solution to in the limited time I worked on it... there is also other stuff, but it's been a while since I've done anything.

Peace.

 

[CyDEtrakD]

ayo,
so icepir8 and jaboo.. when do u guys think myself and all the geforce users are going to get a new release on your opengl plugins for n64 emus anytime soon? keep up the good work guys. no rush.. just cuirous.. thanks once again guys for your hard work.

one,
cydetrakd