[$threadinfo[title]]

[Dave2001]

Ok, I'm continuing my post on Emu Coding.

The status of the glide plugin:
It runs almost all 2D demos.

Thanks Azimer for the interrupt code. I had put it into ProcessRDPList instead of ProcessDList :plain: . Now the games run right.

I still need information about how the N64 draws 3d objects though.

Oh, and remember, you can contact me using ICQ #24553273.

[Dave2001]

Ok, I'm having EXTREME difficulty finding information on display lists. Can anyone provide me with some information?

[Hacktarux]

Display lists are lists of commands that are used by the rsp to draw graphics. A library executed by the rsp take each command of the DList and execute a code corresponding to the command. What you have to do is to understand what is done in this code. (And also it is what will take a long long long long long time to understand).

In a first time you don't really have to understand all the rsp code, you can use header files and the different man pages that describe the ucode0. For more informations, look at the documentation files of TrueReality, you will find on it where are located the data you need in the N64 memory.

To find how each command are encoded, look at the gbi.h file. (I know it looks quite complex, the first time you will look at it, but it isn't, it's just very long).

Good luck man !

[Dave2001]

Ok, thanks. Now I know where to start looking. By the way, I was unable to find the TrueReality documentation files you mentioned. They weren't with any version of TrueReality that I could find.

Anyway, without them, I need to know where the codes are located in memory. I'm (in the video dll) responsible for executing them, right?

[Hacktarux]

It's only located on the sources release of TR.
Find the unix version at www.emuhq.com/truereality, I know these files are included with.

[Dave2001]

Actually, there was a broken link for the download. It's ok, though, because I got it at Zophar's Domain and it had all the documentation with it.

[Dave2001]

OK, as most people who wrote video plugins once were, I am somewhat confused. The documentation with TrueReality is very confusing. I have several things I need to verify:

#1. I am responsible for emulating both the RSP and RDP processors in my plugin, right?

#2. DMEM in the plugin stands for the RSP data memory, and IMEM stands for the RSP instruction memory, correct?

#3. Am I supposed to emulate the RSP in ProcessDList and the RDP in ProcessRDPList?

I also have some questions that I need to have answered:

#1. Where do I find the start of the code to be executed?

Please tell me exactly what I am responsible for doing in ProcessDList() and ProcessRDPList().

If I said something that doesn't make sense, please try to clear it up for me.

[Dave2001]

Ok, let's keep it simple.

Do I need to emulate the RSP?

I'm starting to understand the RSP processor, but I'm not sure if I'm supposed to emulate it in the plugin.

I'm pretty sure I am, but am I supposed to emulate the RDP?

[Eddy]

CAN SOMEBODY HELP THE GUY?? Cyberman :D i know you can help :D well i dont think you need to emulate the rsp in the gfx plugin, that wouldnt make sense, but i think you need to take the commands it gives you, and convert it into direct x coding and stuff. Thats where the coding comes in, im guessing all around dave.

[Azimer]

Originally posted by Dave2001
Ok, I'm continuing my post on Emu Coding.

The status of the glide plugin:
It runs almost all 2D demos.

Thanks Azimer for the interrupt code. I had put it into ProcessRDPList instead of ProcessDList :plain: . Now the games run right.

I still need information about how the N64 draws 3d objects though.

Oh, and remember, you can contact me using ICQ #24553273.

It *IS* ProcessDList. ProcessRDPList occurs when the RSP does the graphics geometry (which is a bad thing). Make sure it isn't.

[Azimer]

Originally posted by Dave2001
OK, as most people who wrote video plugins once were, I am somewhat confused. The documentation with TrueReality is very confusing. I have several things I need to verify:

#1. I am responsible for emulating both the RSP and RDP processors in my plugin, right?

#2. DMEM in the plugin stands for the RSP data memory, and IMEM stands for the RSP instruction memory, correct?

#3. Am I supposed to emulate the RSP in ProcessDList and the RDP in ProcessRDPList?

I also have some questions that I need to have answered:

#1. Where do I find the start of the code to be executed?

Please tell me exactly what I am responsible for doing in ProcessDList() and ProcessRDPList().

If I said something that doesn't make sense, please try to clear it up for me.

#1. HLE Bypasses the RSP and simulates what it does. Graphics HLE also simulates a lot of what the RDP does, but must follow some rules since some of the RDP is immediately accessable.

#2. That is correct. You may need to work with RSP microcode in the future to reverse information about certain things that don't seem sto be so apparent. (Diddy Kong Racing, Perfect Dark, Environment Mapping in Zelda, other things). This is a lot of fun... ???

#3. You are to simulate (or emulate I suppose) the RSP in ProcessDList and emulate the RDP in ProcessRDPList. You can basically ignore ProcessRDPList for HLE Audio. It's only necessary for Low Level Graphics (which zilmar's RSP dll sends to the graphics dll).

#1. Thanks to the hard work by Epsilon, we have the following information available to us which was posted on the old UltraHLE page. Check this out:

Initialisation:
If you know the following you can directly start HLE out of it.
HLE: High Level Emulation - first hacked out by Epsilon and
RealityMan.
(Authors of UltraHLE.)
The DMEM is filled from 0x04000fc0 - 0x04000fff with the following:
0x04000fc0: task
0x00000001 ... Graphics Task
0x00000002 ... Audio Task
0x04000fc4: flags?
0x00000002 ... DP wait
0x04000fc8: bootcode
0x04000fcc: bootcode length
0x04000fd0: ucode
0x04000fd4: ucode length
0x04000fd8: ucode data
0x04000fdc: ucode data length
0x04000fe0: dram stack (for matrices)
0x04000fe4: dram stack length
0x04000fe8: ?
0x04000fec: ?
0x04000ff0: display list
0x04000ff4: display list length
0x04000ff8: ?
0x04000ffc: ?

[Dave2001]

OK, I'm still a little confused. Do I not need to worry about the RDP yet, since it's not even calling ProcessRDPList? Isn't the RDP responsible for actually drawing the stuff?

And I'm still not sure where the code is that I'm supposed to be executing.

or is it at (as a word) display list with (as a word) display list length in imem?

[Hacktarux]

The display list is stored in the RDRAM, the RSP load them to the IMEM but you don't have to emulator the RSP, so you will take the display list on the RDRAM.

The library executed by the rsp analyse the top byte of each command of the DLIST, if it is greater than 0xC0 it sends it directly to the RDP, if it is less than 0xC0, it executed an appropriate code that can for example send many commands to the RDP or anything else.
In ProcessRDPList (lle emulation you only have to handle commands greater than 0xC0 since the RSP plugin must have already processed other commands).
In ProcessDList you have to execute each commands. Of course you don't need to emulate the RSP, but you have to find what the RSP code that is normally executed do and then write a C++ hle code to simulate what the RSP does.

[Dave2001]

By the way, Azimer, check your messages. I sent one, but I'm not sure if it's going to tell you by email.

Never mind.

[Dave2001]

I bring good news from the glide plugin! :D ;) :colgate: By looking at the TR64 source and talking to Azimer, I finally got the display list to execute in a logical order (ex. set all the segments, set clipping, set modes). Now I'm on to the actual simulation of these instructions.

[Eddy]

WOW Dave good to hear, i wanted to make a plugin based on glide, but then i realized, i didnt know the first step to doing it, ill stick to my homebrew input. Its not bad, at least i got dinput working good :-) but rumble? raw data? thats all too much for me at the moment. Good to hear you taking a stab at it.

[Azimer]

I'll do anything to promote new plugin development while I am in this emulation world. :)

[Dave2001]

Ok, I'm getting kinda sick of parts of my source being deleted by corruption ???. When glide freezes (switching windows, ex. illegal operation), I have to reset my computer, resulting in the loss of some of the files I'm working on. I learned after the first time to keep lots of backups, but it's still annoying to have to redo a function that you just implemented. :plain2:

Is there ANY way to use glide in a window? I can't find it if there is.

[Eddy]

Sorry to say dave, glide had window support in its new version. But glide 4 was never released, because 3dfx went to bankruptcy. But until then, glide 3 or 2 had no window support. SORRY :-]

[Dave2001]

That's Ok... It's somewhat hard to program in, but I think I can do it. I just have to make backup copies every time I want to try something new that might perform an illegal operation. Also, you must switch to fullscreen mode to see anything. There is an option for that in Project64, but for some reason on my computer, it performs an illegal operation if you switch to fullscreen too fast after loading a ROM.

Hey, rewriting the uc0:vertex function helped me notice a bug that I had before anyway :).

[Eddy]

Damn dave i wish i could help, i cant imagine the excitement of making a gfx plugin and seeing your own gfx plugin do its magic.

[Dave2001]

Well guys, I finally got something to show up. :) It now shows wireframe models from mario64. There are no world translations yet, so everything appears right in front of the camera, but you can tell what the things are. I can't believe it's working!!! :) :colgate: Glide doesn't allow screenshots, so I can't show you pictures, but I will try to implement screen saving soon.

Happy New Year!!!

[VTT]

Difference Glide from all graphic this that that it is realized is hardware, all other known interfaces are realized software.
Glide gives the big speed in processing graphics.

[2fast4u]

Originally posted by Eddy
Sorry to say dave, glide had window support in its new version. But glide 4 was never released, because 3dfx went to bankruptcy. But until then, glide 3 or 2 had no window support. SORRY :-]

that what i thought, too but i recently tripped over a piece of code at www.nullsoft.com (go to "free shit" and then to "winglide"). this appearantly (did i spell that right?) enables u to use glide in a window, at least with v1 + v2 cards.
u oughta try it out. i am a vb-coder, i'm too dumb...:D

2fast4u

[2fast4u]

Originally posted by Dave2001
Glide doesn't allow screenshots, so I can't show you pictures, but I will try to implement screen saving soon.

Happy New Year!!!

u can always use hypersnap dx or some other screenshot proggie (www.download.com). it can make screenshots in glide.

2fast4u

[Dave2001]

Now this looks hopeful...

Oh, and about winglide, it's glide2x only. I'm using glide3x.

[Slougi]

Hmm couldn't you release a preliminary version of the stuff you have made so far?
Cause that looks sweeet :)

[2fast4u]

woa! this looks like progress! congrats dave, it looks like u will be able to accomplish that plug-in! keep it going!

:colgate: :thumbsup:

[Dave2001]

Ok, you can have it, but it doesn't do much more than that yet. It doesn't translate anything, it just places all objects in front of the camera, bringing jumbled messes during the game. Also, it only works with UCode 0 games, like Mario. If anyone knows of any other UCode 0 games, please tell me.

Oh, by the way, the final name will be Glide64. I just haven't gotten around to changing it from n64Glide.

*** By the way, you must switch to fullscreen to see anything!!!

[VTT]

I shall do too support Glide. not at once and with time.
For now I yet have not let out also the emulator, I work...
Nitn64??? ??? ???

[VTT]

Originally posted by VTT
I shall do too support Glide. not at once and with time.
For now I yet have not let out also the emulator, I work...
Nitn64??? ??? ???
:cool:
I try to bring in emulation new promotions.

[Dave2001]

It may seem like a silly math question, but how do I process the projection matrix? I'm used to Direct3D doing it for me and I've never done it manually before.

[VTT]

Originally posted by Dave2001
It may seem like a silly math question, but how do I process the projection matrix? I'm used to Direct3D doing it for me and I've never done it manually before.

Closely study GBI.h. You not have registered all, when at me the picture from for matrixes I is deformed see the deformed structures, at you on screenshots one sides are visible only. Not which people like to show work graphics without drawing textures thus having shown speed of work of the program. I saw many fakes and a deceit, I know as to force to work plugin faster, but thus quality of display graphics will be very low.

[Dave2001]

I said I haven't put in matrices yet, it just draws temporary wireframe images in front of the camera to make sure it was loading them right. It's not meant to look right because it has no real transformations.

[VTT]

Originally posted by Dave2001
I said I haven't put in matrices yet, it just draws temporary wireframe images in front of the camera to make sure it was loading them right. It's not meant to look right because it has no real transformations.

I did not want you to offend.
Sorry...

[Hacktarux]

I think the matrix mechanism is explain in the directx manual.
You should just have to multiply each vertex's coordinate by the projection matrix. If you don't know how works a matrix multiplication ask me and i will explain it in more details.

[Dave2001]

I did not want you to offend.

It's ok, I understand why you thought that. I just used temporary scaling values, but now I'm working on the actual matrices. Textures are still a long way off, though. I'm going to get the game working completely in wireframe before even starting on those.

to Hacktarux:

Yeah, I heard that you just multiply it. I'll try it and tell you if it worked.

[Eddy]

whoa dave, i think im happier than you to see your glie plugin working! YAY! Good work dave, i heavily congratulate you.

[Dave2001]

Ok, can someone check my math here? (I know it can be simplified, I'll do that after I get it working)

v[i] is a vertex structure that has x,y,z, and w as floats. x,y, and z were set by the uc0:vertex command
rdp.model is a 4x4 matrix
rdp.proj is a 4x4 matrix

float x=v[i].x;
float y=v[i].y;
float z=v[i].z;
float w=1.0f;

v[i].x = x*rdp.model[0][0] + y*rdp.model[0][1] + z*rdp.model[0][2] + w*rdp.model[0][3];
v[i].y = x*rdp.model[1][0] + y*rdp.model[1][1] + z*rdp.model[1][2] + w*rdp.model[1][3];
v[i].z = x*rdp.model[2][0] + y*rdp.model[2][1] + z*rdp.model[2][2] + w*rdp.model[2][3];
v[i].w = x*rdp.model[3][0] + y*rdp.model[3][1] + z*rdp.model[3][2] + w*rdp.model[3][3];

x = v[i].x;
y = v[i].y;
z = v[i].z;
w = v[i].w;

v[i].x = x*rdp.proj[0][0] + y*rdp.proj[0][1] + z*rdp.proj[0][2] + w*rdp.proj[0][3];
v[i].y = x*rdp.proj[1][0] + y*rdp.proj[1][1] + z*rdp.proj[1][2] + w*rdp.proj[1][3];
v[i].z = x*rdp.proj[2][0] + y*rdp.proj[2][1] + z*rdp.proj[2][2] + w*rdp.proj[2][3];
v[i].w = x*rdp.proj[3][0] + y*rdp.proj[3][1] + z*rdp.proj[3][2] + w*rdp.proj[3][3];

// final screen coords (640x480 res) (do I divide by w or z?)
v[i].x = 320.0f + v[i].x / v[i].w;
v[i].y = 240.0f - v[i].y / v[i].w;

[Azimer]

I dunno... this is what I use to Transform shit. It works for OGL.
MatrixVersions are Model Matricies and
MatrixVersions2 are Projection Matricies.

Since OpenGL does all the Geometry, I can do the transformations with Identity Matricies loaded without worrying about scaling to the screen. I hope this helps a little at least. It's been months since I looked at this code or worked with gfx. :)


static void
Transform(GLfloat *matrix, GLfloat *in)
{
int ii;
GLfloat out[4];

for (ii=0; ii<4; ii++) {
out[ii] =
in[0] * matrix[0*4+ii] +
in[1] * matrix[1*4+ii] +
in[2] * matrix[2*4+ii] +
in[3] * matrix[3*4+ii];
}

memcpy (in, out, sizeof(float)*4);
}

void TransformVectors (int a, int b, int c) {
if (MatrixVector[a] != 0) {
Transform (MatrixVersions[MatrixVector[a]], vtxBuff[a]);
Transform (MatrixVersions2[MatrixVector[a]], vtxBuff[a]);
}
if (MatrixVector[b] != 0) {
Transform (MatrixVersions[MatrixVector[b]], vtxBuff[b]);
Transform (MatrixVersions2[MatrixVector[b]], vtxBuff[b]);
}
if (MatrixVector[c] != 0) {
Transform (MatrixVersions[MatrixVector[c]], vtxBuff[c]);
Transform (MatrixVersions2[MatrixVector[c]], vtxBuff[c]);
}
MatrixVector[a] = 0;
MatrixVector[b] = 0;
MatrixVector[c] = 0;
}

[Dave2001]

Am I correct with inputting 1 for w?

[Azimer]

You are correct about w before transformation. Your question about dividing by w or z is a good question. I believe you divide ALL points by w before you scale using z. It's been a helluva long time since I did software rendering.

[Dave2001]

This looks good... I got my first wireframes showing just a few minutes ago, after about 7 hours of fooling with the matrices. Mario 64 is now playable (I beat first level with it).

There were several problems with my matrices:
* I didn't multiply them properly (forgot it was different than adding, then remembered later)
********* It was setting the decimal part of the float to the exact same thing as the integer part of the float (typo), which made it only work for identity matrix projections.
* You do actually divide by z, not w

I'm not going to show anything yet though, because I have some drawing problems I have to work out. It needs a Z-buffer, clipping (it only draws triangles that are all the way on the screen), and also it draws what's behind the camera instead of in front of it (I did some really weird shift and it looked right, but I know it isn't because the Mario64 logo comes forward through you)

[gokuss4]

hey thats a big update dave post the file here

[Slougi]

Now, now, we don't want to push him do we? ;)
He'll make the file available when he feels it' ready :p
Oh and leave this thread alone; don't clutter it with stuff. There is the other thread in talk of the town for speculations and other stuff :)
:alien:

[gokuss4]

lol i already have it :p it looks good although the super mario 64 logo at the start goes forward instead of backwards after mario says "it's a me, Mario!"

[Dave2001]

I'll post it tomorrow, after I've implemented clipping (it would be a lot easier if the objects around you didn't disappear when they touch the edge of the screen).

Anyway, does anyone know where I can find a list of which games have what ucodes? The only ucode 0 game I know of is Mario 64.

[euphoria]

Well congratulations to you Dave2001 (a year late?). I'm making a glide plugin aswell. Are you one of the guys who started this glide project couple months back when this forums was still on emulation64.com? I've too banged my head against a wall with those matrices. Good luck with your plugin! it's still a long way to go... btw. i found that using debug screen activated ultrahle to print out dlist info is quite convenient - as it shows the right matrices and vertices ;)
cheers!

[Azimer]

Many demos use that uCode also. SF Rush is the only other game I can think of off hand. You are best off with Mario64 and Demos.

[Eddy]

euphoria and dave. i again congratulate both of you, ima start picking up d3d coding and see if i can tryt o od a d3d plugin down the year.

[Cyberman]

Woa.. I missed this thread!

Nifty good to see someone brave enough to tackle Glide.

Silly question on WinGlide, does it come with source? :)

Cyb

[Dave2001]

Ok, I said I would post my plugin today, so here it is. Do not be deceived by it, though. It's not as far as it looks. Think of all the other ucodes I have to implement. Also, I'm about to venture into one of the hardest parts: texturing and texture combining. Luckily, I have some experience in this, from writing a glide wrapper (which was never actually released).

I'm thinking about making my glide plugin open-source, so that others can help too. At least if I had to leave the project at some point, somebody else could pick it up. It would be sad to see an attempt at something that is wanted so much go to waste. Anyway, it's not going open-source yet, since it's progressing too fast. Once progress slows, I'll consider doing it.

By the way, can someone try running SF Rush and tell me how it works?

to Cyberman:
Yes, Winglide does come with source. Just search on yahoo for "Winglide". I don't have time to redo it for Glide3x, though.

[Cyberman]

Cool, I'll have to have a looksie since I changed the card in this machine to a Voodoo3 2000 PCI :)

Texturing might be a sticky point with Glide2/3. If I remember correctly (I've made mistakes before) There is an issue of 32/16 bit textures with older/newer 3dFX cards. In any case best of fortune seems you've done better than I would of!

Cyb

[Eddy]

Well can i use a glide wrapper ? i would love to see your pgoress dave

[Dave2001]

Glide3x isn't compatible with Glide2x. It should work with Voodoo 3 and above, but not before. I'm not going to include support for Voodoo 2 and lower, because it's a whole different SDK. If someone wants to port, I'm sure it wouldn't be hard to do, though.

Eddy: my glide wrapper wasn't nearly as good as any of the others. It's not something you'd want to use.

[Eddy]

ok no prob.

About textures, voodoo 3 and below cant handle 32bit textures, 24 at max i think. And glide2x and 3x is all the same thing, just a different dll, so there is no need to port, just have the newest drivers, and glide3x.dll in the plugin directory.

[Dave2001]

I don't have anything but a Voodoo 3 2000, so it would be somewhat hard to add support for textures higher than 24 bit for the newer Voodoo cards. I guess they'll just have to settle for 16-bit color. Besides, don't those cards have better support for Direct3d anyway?

If someone has a Voodoo2, please try out my plugin and tell me if it works. I don't think it will, though. I have read that Glide3x is totally incompatible with Glide2x.

[Eddy]

glide2x should be compatible, just that it will be missing some blends, features, ect. Besides, the last voodo drivers for the 2 where 3x compat.

[Dave2001]

Ok, I'm trying to use a w-buffer instead of a z-buffer. What coordinate do I need to input for q? I tried 1/z, but that didn't work.

[gokuss4]

stick with z-buffer since the n64 has it and even the voodoo 3 has z-buffer so stcik with that dave

[Dave2001]

Well, with z-buffer the water in mario doesn't show up. I know it will with a w-buffer because in my glide wrapper, the same thing happened. The only problem is: the glide wrapper is in Direct3d and I'm using glide, so I can't just copy the code.

[Eddy]

Dave do you have textures showing up already ?

[Dave2001]

not yet, that's what I'm going to work on next.

[Reznor007]

Originally posted by Dave2001
I don't have anything but a Voodoo 3 2000, so it would be somewhat hard to add support for textures higher than 24 bit for the newer Voodoo cards. I guess they'll just have to settle for 16-bit color. Besides, don't those cards have better support for Direct3d anyway?

If someone has a Voodoo2, please try out my plugin and tell me if it works. I don't think it will, though. I have read that Glide3x is totally incompatible with Glide2x.

You might want to get in contact with Lewpy. He did an excellent Glide plugin for PSX emulators. It fully supports the newer V4/V5 features, so he might be able to tell you how to get 32bit working.

Glide2x and Glide3x are different API's. Glide3 supports things Glide2 did not, such as triangle arrays, strips, and fans. Glide3 drivers were made for the older hardware(V1, V2) as well.

[Dave2001]

Ok, my glide plugin is hosted by emuxhaven. There's not much there yet, but here's the URL:
http://www.emuxhaven.net/~glide64

[euphoria]

Dave: I have Voodoo1 card and i tried your plugin and it worked ok.

[Dave2001]

Cool! :D

[mesman00]

hey dave, i was wondering if you would like me to work on a new webpage for you. i like to design and also it helps me learn, so if your interested, let me know.

also, u can use the print screen button, and then just paste it into a program like adobe photoshop, or even regular old paintbrush.

[2fast4u]

Originally posted by mesman00
also, u can use the print screen button, and then just paste it into a program like adobe photoshop, or even regular old paintbrush.

as far as i know print screen is not supported in glide. everytime i was doing that with my v2 i got a black picture returned :(

[mesman00]

oh, if i had read the other previous replies before posting i would have known that too!

[Dave2001]

Ok, can anyone give me a description of the following commands? I can't tell exactly what they are supposed to do, and they seem very much alike to me. I won't be able to implement texture caching right if I don't know what they do. I looked deeply into GBI.h and the TrueReality source, but they still didn't explain much about what the commands actually do (need very general description, not code):

rdp : loadtlut (texture look up table?)
rdp : settilesize
rdp : loadblock
rdp : loadtile
rdp : settile
rdp : settextureimage
uc0 : texture

[Dave2001]

mesman00:
Sure, that'd be great. I don't have time to make a better one myself. You can contact me on AOL IM, CodeMaster256

[euphoria]

Dave: have you looked daedalus source? Its internal gfx plugin is showing stuff pretty good. Just make sure you download the older 0.07b source because the newest 0.08b(?) doesn't include the gfx source.

[Hacktarux]

Dave, check your private messages :)

[Azimer]

Dave... this turned out messy quick. If you need to contact me, use AIM or email me.

[Gideon007]

Don't know if that helps you but you might want to contact Ryan Nunn (Colourless) who recently did some extreme glide coding to fix issues with glide.
See http://www.users.on.net/triforce/glidexp/

btw. I mean, if Dave has any specific glide questions.

[EdgeBlade]

I'd love to check it out but I gave my VooDoo 3 3000 to a friend after I upgraded

[VTT]

At the moment few who has videocards 3Dfx. The majority gets cards of manufacturers NVidia (TNT and GForce series), Matrox (G series), ATI, Diamond (Savage series). The given videocards support most rasprostranenye video interfaces DirectDraw/Direct3D and OpenGL. Cards 3Dfx too support abundant videos interfaces, but already with the least quality of reconstruction. It is not meaningful to start the emulator on a videocard in mode Glide using utilities for a deceit of initialization of cards 3Dfx, because Glide it is the hardware interface it gives besides a qualitative picture also the big speed of reconstruction of video of a stage.

[LoneRaven]

I have tried to use your plugin, but I always get an error (Access Violation?). Is there any special place that the glide3x.dll needs to be. Could it have anything to do with the fact that I am using older drivers?

Also, I too am working on making you a page. When it is complete I will send it to you through AIM. If you like it, I think you will, you can use it. :D

Best of Luck

[LoneRaven]

No reply to the error message ???. Oh well, here is a preview of the site I made. The top bar will be for a logo for Glide64 once one is created. Tell me what you think.

[Dave2001]

Whoa!! That's absolutely AWESOME!

Yeah, try updating your drivers, see if it works. Also, make sure that you are only running Mario 64. That's the only game that works. Glide3x.dll should be in the system directory (or the directory you run the program in).

By the way, I just got textures working (and mapped to the objects correctly). I'll be starting on texture blending in a few minutes.

[Cyberman]

Dave2001
Yeah, try updating your drivers, see if it works. Also, make sure that you are only running Mario 64. That's the only game that works. Glide3x.dll should be in the system directory (or the directory you run the program in).

By the way, I just got textures working (and mapped to the objects correctly). I'll be starting on texture blending in a few minutes.
Wow.. heh.. you are progressing faster than I did on my soft GPU for the PSX, then again I haven't worked on it in a bit (grins). Trying to do it in MMX mostly I think I messed a few things up ;)

Cyb

[Dave2001]

Ok, I'm sure someone has had this happen to them before:

When objects go off the screen and are clipped, the texture perspective gets totally warped. Does anyone know how to fix this?

(by the way, I know the colors are wrong on shadows and mario, and there is no transparency, but these are very easy things to fix. I just haven't gotten around to them yet.)

[LoneRaven]

I tried again using updated drivers and it worked great. Great job, keep it up.

[Dave2001]

By the way LoneRaven, what is your AOL IM handle? I tried KingDavid44 and it didn't work. I have no way of contacting you since you aren't on my contact list yet.

[Cyberman]

Originally posted by Dave2001
Ok, I'm sure someone has had this happen to them before:

When objects go off the screen and are clipped, the texture perspective gets totally warped. Does anyone know how to fix this?

(by the way, I know the colors are wrong on shadows and mario, and there is no transparency, but these are very easy things to fix. I just haven't gotten around to them yet.)
well if I remember this problem ( I get it too) you are actually changing the area you are maping the texture too..

IE
you are bound by an initial list of triangles and this triangle changes as you move. So if you cliped on of your objects Say a triangle and one of the points is now outside of viewable range.. you need to break that triangle into 3 triangles one where the EDGE of the cliping begins and two which were your original vertices that are still viewable. A halfway point between these two vertices constitutes the point on the edge triangle (the edge triangle is a triangle whose edge constitutes the cliped portion of the original triangle). You have to Chunk the orignal texture appropriately with the new 'triangles'

This was a pain for me to fix on my soft GPU .. I figured it out but never implemented it due to lazyness! ;)

I wanted to color to work first go figure ;)

Cyb

[Dave2001]

I assume you mean a triangle strip approach as in [figure A] rather than my current triangle fan approach [figure B]. This is what you mean, isn't it? How would you divide the triangle in a case like [figure C]? or would you leave it as it is? I think one vertex has been on the screen before, and it was still warped.
(green is the screen's right edge)

[gokuss4]

hey figure a is the triforce :D

[Azimer]

I would imagine both methods would work fine. This might sounds stupid... but are you sure you are redoing the texture coordinates correctly as well?

[Dave2001]

Yes, I am.

Here's basically the clipping code (one side only, sorry it's so long). It's really simple once you look at it. Don't pay attention to the vertex buffer stuff, buffer 2 is where you are copying from, buffer 1 is where you are copying to, n is 3 for the first clipping.

Look here if you want to see where I got it from:
http://www.voodooextreme.com/glide3tutorial/html/tutorial19.htm

After I do the clipping, I draw the points as a GR_TRIANGLE_FAN.

#define Vj rdp.vtxbuf2[j]
#define Vi rdp.vtxbuf2[i]

int i,j,index;
float percent;

if (rdp.clip & CLIP_XMAX) // right of the screen
{
// Swap vertex buffers
VERTEX *tmp = rdp.vtxbuf2;
rdp.vtxbuf2 = rdp.vtxbuf;
rdp.vtxbuf = tmp;
rdp.vtx_buffer ^= 1;
index = 0;

// Check the vertices for clipping
for (i=0; i<n; i++)
{
j = i+1;
if (j == n) j = 0;

if (Vi.x < rdp.scissor.lr_x)
{
if (Vj.x < rdp.scissor.lr_x)
// Both are in, save the last one
{
rdp.vtxbuf[index++] = Vj;
}
else
// First is in, second is out, save intersection
{
percent = (rdp.scissor.lr_x - Vi.x) / (Vj.x - Vi.x);
rdp.vtxbuf[index].x = (float)rdp.scissor.lr_x;
rdp.vtxbuf[index].y = Vi.y + (Vj.y - Vi.y) * percent;
rdp.vtxbuf[index].z = Vi.z + (Vj.z - Vi.z) * percent;
rdp.vtxbuf[index].u = Vi.u + (Vj.u - Vi.u) * percent;
rdp.vtxbuf[index].v = Vi.v + (Vj.v - Vi.v) * percent;
rdp.vtxbuf[index].b = (BYTE)(Vi.b + (Vj.b - Vi.b) * percent);
rdp.vtxbuf[index].g = (BYTE)(Vi.g + (Vj.g - Vi.g) * percent);
rdp.vtxbuf[index].r = (BYTE)(Vi.r + (Vj.r - Vi.r) * percent);
rdp.vtxbuf[index++].a = (BYTE)(Vi.a + (Vj.a - Vi.a) * percent);
}
}
else
{
//if (Vj.x >= rdp.scissor.lr_x)
// Both are out, save nothing
if (Vj.x < rdp.scissor.lr_x)
// First is out, second is in, save intersection & in point
{
percent = (rdp.scissor.lr_x - Vj.x) / (Vi.x - Vj.x);
rdp.vtxbuf[index].x = (float)rdp.scissor.lr_x;
rdp.vtxbuf[index].y = Vj.y + (Vi.y - Vj.y) * percent;
rdp.vtxbuf[index].z = Vj.z + (Vi.z - Vj.z) * percent;
rdp.vtxbuf[index].u = Vj.u + (Vi.u - Vj.u) * percent;
rdp.vtxbuf[index].v = Vj.v + (Vi.v - Vj.v) * percent;
rdp.vtxbuf[index].b = (BYTE)(Vj.b + (Vi.b - Vj.b) * percent);
rdp.vtxbuf[index].g = (BYTE)(Vj.g + (Vi.g - Vj.g) * percent);
rdp.vtxbuf[index].r = (BYTE)(Vj.r + (Vi.r - Vj.r) * percent);
rdp.vtxbuf[index++].a = (BYTE)(Vj.a + (Vi.a - Vj.a) * percent);

// Save the in point
rdp.vtxbuf[index++] = Vj;
}
}
}
n = index;
}

[LoneRaven]

I am sorry about that, KingDavid44 was my temp account an I forgot to change it. You can get a hold of me in two ways:

Email: Kingdavid_12@hotmail.com
AIM: LoneRaven12

I would have replied earlier but the board was down yesterday.

[Dave2001]

Actually, I take what I just said back. Vertex colors are hard to tell if they warp. When I map the vertex colors to objects, they warp also. The answer probably is within my clipping (posted earlier).

(said earlier that vertex colors worked)

[Dave2001]

BTW, get the new version here if you want to see what the problem is (don't pay attention to the combine errors, I know mario is invisible)

[StonedConker]

hehe this is surely fresh thing !
i'm going testing :)

[Dave2001]

Also, I think the zbuffer artifacts are caused by the same thing that causes the texture warps. I think that my method of clipping doesn't work very well. Can someone give me a new method?

[Cyberman]

Dave2001 said
Also, I think the zbuffer artifacts are caused by the same thing that causes the texture warps. I think that my method of clipping doesn't work very well. Can someone give me a new method?
Are you using a cliping volume and finding the slope intercept on the volume edges to find the end points of the polygons?

Heh.. I remember this stuff 10 years ago :)

I'm feeling old suddenly

Cyb

[icepir8]

:tr64:
Dave,

I'm willing to help you in anyway I can. I have a banshee based video card I can install in a computer for testing. Let me know.

Cheers,

Icepir8

[Eddy]

Well dave, now you got cyberman, azimer, and icepir :-)

[Dave2001]

Yeah, I've got lots of others on my contact lists also, I might need to create a list of who's who and has what card.

[LoneRaven]

Voodoo 3 AGP - Primary

Voodoo Banshee - Not currently in, but could be done with a little bit of time

Voodoo 5 AGP - I am not sure but can probably make it work out to have it be tested

[Dave2001]

The method of 2d clipping that I'm using is percentage based. It checks the percent of the line on one side of the edge of the screen, and uses that to calculate the intersection point. Here's how it works with one line (this is right side clipping only, it does the other sides afterwords, with code almost exactly the same):

[Quvack]

I've got a Voodoo Banshee :) and ur plugin runs well :)

/me loves watching progress and helping with where possinble ;)

[Dave2001]

Ok, so what's been happening recently:
* Fixed mario cannon bug in snow level that used to freeze (actually had to do with pushing/popping the matrices!!! It took me 2 days to find the source of this bug)
* Added support for texture cache using any size texture memory
* Fixed the 2MB texture memory boundary bug

The next thing I need is to fix my matrices. I think that is why SF Rush and Tetrisphere don't work well. I think I'm reversing something and I absolutely cannot figure it out, considering I'm not very good with matrices in the first place. I'll post my code here, and PLEEEASSE help me :cry: (look down for main uc0:matrix function, look at post on a previous page to see how I'm using matrices to draw):

in rdp:
// Matrices
float model[4][4];
float proj[4][4];
float model_stack[10][4][4]; // 10 deep, will warn if overflow
int model_i; // index in the model matrix stack

void modelview_load (float m[4][4])
{
memcpy (rdp.model, m, 64); // 4*4*4(float)
}

void modelview_mul (float m[4][4])
{
float m_src[4][4];
memcpy (m_src, rdp.model, 64);

for (int i=0; i<4; i++) // row in result
{
for (int j=0; j<4; j++) // column in result
{
rdp.model[i][j] =
m_src[i][0] * m[0][j] +
m_src[i][1] * m[1][j] +
m_src[i][2] * m[2][j] +
m_src[i][3] * m[3][j];
}
}
}

void modelview_push ()
{
if (rdp.model_i == 9)
{
RDP_E ("** Model matrix stack overflow ** > 32 push");
return;
}

memcpy (rdp.model_stack[rdp.model_i], rdp.model, 64);
rdp.model_i ++;
}

void modelview_pop ()
{
if (rdp.model_i == 0)
{
RDP_E ("** Model matrix stack failed** too many pops");
return;
}

rdp.model_i --;
memcpy (rdp.model, rdp.model_stack[rdp.model_i], 64);
}

void modelview_load_push (float m[4][4])
{
modelview_push ();
modelview_load (m);
}

void modelview_mul_push (float m[4][4])
{
modelview_push ();
modelview_mul (m);
}

void projection_load (float m[4][4])
{
memcpy (rdp.proj, m, 64); // 4*4*4(float)
}

void projection_mul (float m[4][4])
{
float m_src[4][4];
memcpy (m_src, rdp.proj, 64);

for (int i=0; i<4; i++) // row in result
{
for (int j=0; j<4; j++) // column in result
{
rdp.proj[i][j] =
m_src[i][0] * m[0][j] +
m_src[i][1] * m[1][j] +
m_src[i][2] * m[2][j] +
m_src[i][3] * m[3][j];
}
}
}

static void rsp_uc00_matrix()
{
RDP("uc0:matrix ");

// Use segment offset to get the address
DWORD addr = segoffset(rdp.cmd1) & 0x003FFFFF;
BYTE command = (BYTE)((rdp.cmd0 >> 16) & 0xFF);

float m[4][4];
int x,y; // matrix index

addr >>= 1;

for (x=0; x<16; x+=4) { // Adding 4 instead of one, just to remove mult. later
for (y=0; y<4; y++) {
m[x>>2][y] = (float)(
(((__int32)((WORD*)gfx.RDRAM)[(addr+x+y)^1]) << 16) |
((WORD*)gfx.RDRAM)[(addr+x+y+16)^1]
) / 65536.0f;
}
}

switch (command)
{
case 0: // modelview mul nopush
RDP ("modelview mul\n");
modelview_mul (m);
break;

case 1: // projection mul nopush
case 5: // projection mul push, can't push projection
RDP ("projection mul\n");
projection_mul (m);
break;

case 2: // modelview load nopush
RDP ("modelview load\n");
modelview_load (m);
break;

case 3: // projection load nopush
case 7: // projection load push, can't push projection
RDP ("projection load\n");
projection_load (m);
break;

case 4: // modelview mul push
RDP ("modelview mul push\n");
modelview_mul_push (m);
break;

case 6: // modelview load push
RDP ("modelview load push\n");
modelview_load_push (m);
break;

default:
FRDP_E ("Unknown matrix command, %02lx", command);
}
}

[Hacktarux]

The algorithm seems to be right but are you sure that a tab like model[4][4] can be linearly accessed (that you can use the memcpy function). I know that in gnu compilers it's not. If it is the problem, it should work until it erased some other important data. The solution is to use a tab like : float model[16].

I know I had this problem but maybe your compiler handle it correct :)

[EeeK]

Wo.....great work Dave2001! I think I can keep my Voodoo3 2K a few more yrs with this plugin. :)

Anyway if you need any help pls let me know.

[Dave2001]

I think my compiler handles it correctly. I'm using Microsoft Visual C++ 5.0. I tried replacing the memcpys with for statements and it acted exactly the same. I'm almost positive that the problem is that I have the matrices flipped somehow. Check if my code here is consistent with the matrix transformations posted earlier.

[Dave2001]

I fixed it i fixed it I FixED it I FIxeD it I FIXED IT!!!!!!!!!!!!!!!!!!! :D :) :colgate:

By the way, I'm talking about the clipping problem (texture warping)!!! It's completely fixed! The problem (totally unobvious) was that I needed to, during screen edge clipping, use the q value instead of z. I guess q interpolates better or something. There's no more artifacts either. You can see the water now (although it's not translucent yet).

Now there's only one known problem with the current version of Glide64 (aside from several texture offset things, ex. Nintendo copyright), the matrix problem! :devil: Everything else that doesn't work just hasn't been implemented yet.

Since this is a big update, I'll post Glide64 v0.01b with the fixed clipping on my webpage in a few minutes.

http://www.emuxhaven.net/~glide64/

By the way, I'm pretty sure that my plugin runs faster on Voodoo cards than Jabo's, since in Hazy Maze Cave using Jabo's the sound would skip, and using mine it runs smoothly.

[Eddy]

congrats 200000000000x damn now when i want a voodoo, i cant have one :-( i can i just dont have another agp port :-(

[2fast4u]

Originally posted by Eddy
congrats 200000000000x damn now when i want a voodoo, i cant have one :-( i can i just dont have another agp port :-(

i think u mean pci slot. there's no motherboard w/ 2 agp slots existing. hehe, i bought a v2 extra for ultrahle ... :D

[Eddy]

well yeah i can do that. .. :-D

[linker]

Dave, I see that you are working hard on your plugin and I wish you luck. The problem is that I don't have Voodoo, so is there any wrapper for glide3x (just like glide2x wrapper for uhle).

[Dave2001]

If you don't have a Voodoo, you would probably be better off just using a Direct3d plugin. There's no point to my plugin unless you have a Voodoo. You could run it through a glide wrapper, but it would just make it go slower and lose texture blending.

[Rice]

I tried 0.1b under XP with my voodoo3, does not work. I know I need to wait a bit longer, but does it work under win xp, or my voodoo3 driver in win XP does not support Glide very well?

[Harteex]

I downloaded some drivers for my VooDoo2 and the drivers installed glide3x.dll...
But pj64 crashes in glide3x when I try to play.

[BatBoy]

Rice:
The Glide64 Plugin will work in XP. Im using v0.1b in XP with a Voodoo 3 but I had to update the drivers. The XP default drivers don't support Glide. I tried to post the file but it's over the upload limit. Ill try to Span it over 2 images.

Dave2001:
Great job on the plugin it's working well. Good luck with the project

[Reznor007]

Rice, you may be interested in this:

http://www.users.on.net/triforce/glidexp/

GlideXP, built from Linux source code converted to Windows. The person that is doing it was the person that came up with the idea for doing trilinear on V5 6000, so Quantum3D gave him one for free.

[milen]

I have Savage4 video card and Jabo's plugin hangs on my computer. So I'll be very happy to use glide wrapper with your plugin. There isn't good plugin that works for me.
Only TrWin is fast and compitable enough for Savage4.

[mesman00]

you know, there are other plugins other than jabo's, such as icepir8, and there are a few others, such as the 1964 ogl plugin, and it seems as azimer is workin on a graphics plugin, and icepir8 is starting a new direct3d plugin.

[Dave2001]

#1. Ok, anyone that has had problems, update your drivers and tell me if it worked (www.voodoofiles.com).

#2. Try checking AND unchecking "go to fullscreen on rom load"

#3. I've heard of crashes on Voodoo 2, I think I need to have a debugging session with somebody that owns this type of card.

Tell me if #1 or #2 fixed it for you

[Dave2001]

Ok, I decided it would be a good idea to fix the matrix problem before implementing lighting, considering lighting may use the matrices.

Does anyone have any idea what (with matrices) might cause things to spin around me instead of their origin? I think in tetrisphere I saw that happening.

[Dave2001]

YAY!!! I fixed the matrix problem! :cool:

Now the Super Mario 64 logo works right, and Mario's face shows up. Also, Tetrisphere works! SF rush still has problems though.

By the way, the problem was that I was STILL multiplying wrong. When I stepped through it, I noticed I was doing it backwards and should've used [j][i] instead of [i][j].

[Quvack]

Congratulations :)

[Swampylee]

Well done Dave!!!

Please could you post some more screenshots, either here or on your site.

I don't have a 3DFX card installed at the moment but would love to see how it's progressing.

Keep up the great work.
-Swampylee

[Dave2001]

Oh, come on! Where are the beta testers when I need them? All I need is someone using a voodoo 2 to work with me for an hour to figure the problem out. Contact: ICQ: 24553273 AIM: CodeMaster256 MSN: Dave2001

By the way, I've found that combine modes in Glide are the easiest thing in the world! This is especially true with the new graphical debugger I implemented. I'll post more stuff after I finish lighting and the rest of the combining modes. (mario's colors show now with lighting)

[Eddy]

well dave i wish i could help, but again, i dont got a v3. Its good to hear that combines are easy to do in glide :-) and also good to hear that you are implementing lighting

[Dave2001]

Actually, I had lighting done at about 11:00 this morning :). Also, I have most combine modes that mario uses implemented. (single textured only so far)

I have several questions, and maybe someone here can tell me the answer:

#1. In Glide, there is something called bias that makes objects on the same plane separate. Is there something like this on the N64? (trying to fix the bug with the border around front door, stars on doors, sun picture on the castle floor)

#2. If you look at the water through the fence, the water doesn't draw where the fence is. This is because the fence is drawn first, writes to the z-buffer, and then the water is drawn, but rejected, even in the transparent areas, because the fence was closer. What is actually supposed to happen with the fences and trees with the z-buffer?

By the way, can Voodoo 2 have a w-buffer?

[Eddy]

for the sidenote:

voodoo 2 supports a z buffer only on 640x480 and 800x600, you need TWO v2's for a z buffer on 1024x768, so you can make a feature that if the plugin detects a v2, it grays z buffer when it detects a res higher than 1024

[Dave2001]

No w buffer... that could explain the problem people are having on voodoo 2's. I'll add support for z-buffer right now. Or if "z-buffer" includes w-buffer, the last two releases I think were in 1024x768.

[LoneRaven]

While testing GLide64, so far I have only found one bug. However I have not been able to recreate it. While playing the first level, it crashed PJ64. Has anyone else had this same problem. I will continue testing and see what I find. Good job Dave, keep it up. :colgate:

*Note : I am currently working on fixing the site up more, while doing this should I change the site from 1024 * 786 best resolution to 800 * 600?

[Dave2001]

Voodoo 2 users, try this and tell me if it works. Anyone else, try this and see how the project is going. There is lighting now and many combine modes that mario uses. This is a work-in-progress version, so it isn't on the main site.

[Eddy]

i need a glide wrapper, whats the best one for geforce2 mx 64mb

[Dave2001]

I think glide wrappers are for Glide2x stuff only (like UltraHLE). I don't think they will work with my plugin since it uses Glide3x. I can almost assure you that you wouldn't want to use my plugin unless you have a Voodoo card anyway.

[Dave2001]

Ok, so far I've confirmed that it works exactly how it should on a Voodoo Banshee. I need a Voodoo 2 user to try it now.

[Reznor007]

Are you using the right texture format for the fence texture? Since the parts of the fence that you can normally see through are probably given an alpha value of transparent, the texture would have to be an RGBA texture. If you only use RGB, it will be seen as a solid object, and will be given priority over the water. If it is given alpha values, it should be blended properly.

[Dave2001]

The alpha values are correct, that's why you can see through the fence. Even when the alpha value is not one, it still writes to the z-buffer, making some things behind it not show.

[mesman00]

two things
1. lone raven, leave the webpage in 1024, its almost what everyone is running these days, and imo its much better.

2. someone who is using the newly released version of glide64 wanna post some screenshots so us non voodoo people can see how it's goin??

thanks.

[Dave2001]

Ok, here you go.

By the way, I think the day I started this plugin was the day you said it would be awesome if someone made a glide plugin, but knew it would never happen. Strange how that works, isn't it?

[mesman00]

even though i don't have a voodoo card in my comp anymore, i think it would be wicked cool to see a glide plugin. ok, now im gonna go back to reality cuz i know that isn't gonna happen. anyways, great work on the ogl.

i said that over in the n64 screenshot board on 12/29/01. guess u really proved me wrong, haha. anyways, the plugin is lookin great, thanks for the shots.

[Swampylee]

WOW - it's really starting to look good. Well done.

I bet all those 3DFX users are wetting themselves after seeing these screenshots. :)

I may even re-install my old Banshee to take a look!

Please post more shots when you get a chance.
Regards, Swampylee

[icepir8]

Originally posted by Dave2001
Actually, I had lighting done at about 11:00 this morning :). Also, I have most combine modes that mario uses implemented. (single textured only so far)

I have several questions, and maybe someone here can tell me the answer:

#1. In Glide, there is something called bias that makes objects on the same plane separate. Is there something like this on the N64? (trying to fix the bug with the border around front door, stars on doors, sun picture on the castle floor)


Yes/No on the N64 the are settings that are used for decal mode. and to emulate them zbias works great. Email me if you need more info.

#2. If you look at the water through the fence, the water doesn't draw where the fence is. This is because the fence is drawn first, writes to the z-buffer, and then the water is drawn, but rejected, even in the transparent areas, because the fence was closer. What is actually supposed to happen with the fences and trees with the z-buffer?

You need to enable a alpha test. so that if the alpha in is less than a set value the pixel is not updated. what is happenning is that the pixel is being updated even when the result is the same color as before because of a alpha value of zero.

Good work!

Cheers,


Icepir8
:tr64:

[Eddy]

lol ice i always laugh of that little guy holding the tr64 sign, he looks funny :D

[Dave2001]

Okay, I've uploaded Glide64 v0.02 at the glide64 homepage: http://www.emuxhaven.net/~glide64

Take a look and tell me what you think.

[Swampylee]

Great stuff. An amazing amount of improvement with each version and those screenshots look lovely.

Keep up the great work (and screenshots :D )
Regards,
Swampylee

[Rice]

This's not bad at all on my voodoo3. Keep up good work.

[Dave2001]

Ok, anyone who ran config in v0.02 probably had it crash. There was a serious registry bug, but now it's fixed in v0.02a. Like I said before, v0.02 did support Voodoo 2. The thing is: Voodoo 2 users all ran config because I told them to set the resolution to 640x480, and then it would crash. For some very odd reason it would never crash on my computer though.

Download v0.02a here: http://www.emuxhaven.net/~glide64/glide64_002a.zip

[Azimer]

Originally posted by icepir8

Yes/No on the N64 the are settings that are used for decal mode. and to emulate them zbias works great. Email me if you need more info.



I've experienced this too ice and used glPolygonOffset (similar to zbias in D3D). It does work well, except for me, I had to disable writes to the zbuffer to be able to have decal over decal. Otherwise I would get a flicker fest when they overlapped. I hope that lil hint from experience helps? I don't think it matters if the decal isn't written to the zbuffer since it IS a decal after all :)

[Dave2001]

That's a wonderful idea, Azimer! :D I'll do that.

[Dave2001]

Any theories about what could cause it to zoom in way too close to things?

[Martin]

Thread grew to huge, so I split it. The thread is continued here (http://www.emutalk.net/showthread.php?threadid=2175).