PDA

View Full Version : N64 Glide Plugin



Pages : [1] 2

Dave2001
January 18th, 2002, 04:50
Hmm.. it appears to be YET ANOTHER matrix problem. :devil:

An interesting effect:
When I comment out the last line in matrix multiplication, the zooming in the game works perfectly, but the mario logo, text, and portraits do not work.


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++)
{
for (int j=0; j<4; j++)
{
rdp.model[j][i] =
m_src[0][i] * m[j][0] +
m_src[1][i] * m[j][1] +
m_src[2][i] * m[j][2]/* +
m_src[3][i] * m[j][3]*/;
}
}
}

or even more specific, if I don't add the projection matrix's z:

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

Martin
January 18th, 2002, 05:16
Great thread, but it's getting a bit big. Mind if I split it into two threads?

Dave2001
January 18th, 2002, 06:04
Sure, go right ahead.

I don't believe it!!! I should have listened to myself earlier. I fixed the zooming problem. You ARE supposed to divide by w instead of z during the 3d->2d stage.

Now princess shows up, and also it doesn't get too close to mario when in mario camera mode.

(don't ask me HOW I figure all these strange things out, it just kinda happens, and very quickly at that :D)

Martin
January 18th, 2002, 06:07
Alright, first time I'm splitting a thread. Let's hope it works okay. :)

:emutalk1:

Dave2001
January 18th, 2002, 06:10
Ah, good, we're still here. :cool:

Quvack
January 18th, 2002, 08:25
Lol, the thread split perfectly, the gfx plugin's errors are getting fixed, and im eating BBQ Shapes, lifes good ;)

gokuss4
January 18th, 2002, 08:39
woohoo just fix the ucode 0 probs and than move on to ucode 1 dave :cool:

Glize
January 18th, 2002, 09:32
Great work Dave!

Works very well on my V3 2000, PIII 550Mhz and WinXP.

Quick question:

What's the next game you are going to concentrate on?

gokuss4
January 18th, 2002, 09:58
well all games that has ucode 1 he will be next. like SF Rush and Mario Kart i think ???

Glize
January 18th, 2002, 10:04
I dont mean to be a pain, but what games are on Ucode 0?
:plain:

icepir8
January 18th, 2002, 10:13
Originally posted by Dave2001
Hmm.. it appears to be YET ANOTHER matrix problem. :devil:

An interesting effect:
When I comment out the last line in matrix multiplication, the zooming in the game works perfectly, but the mario logo, text, and portraits do not work.


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++)
{
for (int j=0; j<4; j++)
{
rdp.model[j][i] =
m_src[0][i] * m[j][0] +
m_src[1][i] * m[j][1] +
m_src[2][i] * m[j][2]/* +
m_src[3][i] * m[j][3]*/;
}
}
}

or even more specific, if I don't add the projection matrix's z:

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

Dave2001,

The modelview matrix is handled a little differently then the projection matrix.

the modelview should only deal with x,y and z values while the projection matrix deals with x,y,z and w values.

maybe this will help out.

Cya,

Icepir8

:tr64:

Dave2001
January 18th, 2002, 10:57
Yes, I figured it out. It works now. :)

Cyberman
January 19th, 2002, 05:45
Cool

Now if only one could do something similiar to ye olde PSX. Unfortunately you are stuck with there GTE seperate from the GPU (heh).

Well Dave if you have any questions feel free to express your anger.. err ;) express them here ;)

Cyb

Swampylee
January 19th, 2002, 05:59
This is so cool. Watching a plugin progress is awesome.

Can we have more screenshots when you get a chance please?

Thanks, and great work.
-Swampylee

Renegade
January 19th, 2002, 06:14
at least we know it's not a HYDRAHLE thing.
(what if dave2001 had said, "I'm developing a new plugin for Glide2x users!!! it can run Mario64 very well!!! too bad I feel that it doesn't need to be released though")

on the flip side, very good work dave2001!

EeeK
January 19th, 2002, 10:19
Keep up the great work, Dave2001!

Anyone interested in working winglide for glide3x.dll?

More info at http://www.nullsoft.com/free/winglide

gokuss4
January 19th, 2002, 11:25
heres a screenshot

gokuss4
January 19th, 2002, 11:42
just a little issue for me but whats wrong with the sky?

Dave2001
January 19th, 2002, 13:14
Ok, I've released Glide64 v0.03. Go to my homepage (http://www.emuxhaven.net/~glide64/) to download.

It's 1:16 A.M., time to get some sleep ;)

2fast4u
January 19th, 2002, 21:03
Originally posted by gokuss4
just a little issue for me but whats wrong with the sky?

hmm... i think i remember having that same problem already in ultrahle. could be glide's fault then. ???

Dave2001
January 19th, 2002, 23:39
just a little issue for me but whats wrong with the sky?

Yeah, there are some texture coordinate errors, it's not just with the sky. I'll try to fix it soon.

flow``
January 20th, 2002, 00:10
Davy, please read your pm?

thanks :)

gokuss4
January 20th, 2002, 02:20
oh yeah. no other plug-in i tried fixed that problem but nemu did. there are no bad texture coordinance so no sky problem :) in nemu.

Dave2001
January 20th, 2002, 08:46
So far I have been able to get Mario 64, Pilotwings 64, Chopper Attack, and Tetrisphere to show up.

While trying to get Pilotwings to work, I noticed that a lot of the combine modes include G_CCMUX_TEXEL1. Does any emu coder know how the N64 does multi-texturing? Where do the set of texture coordinates for the second texture come from, and how does it know which texture to use (or is it always tile descriptor 1)?

To LoneRaven:
Your list of ucodes is nice, but a lot of the games (such as goldeneye and f-zero x) are listed under the wrong ucode, (goldeneye should be ucode1 and F-Zero X I think should be ucode5). How did you compile the list? Anyway, for the most part they are right. :alien:

LoneRaven
January 21st, 2002, 01:13
I am very sorry for any inaccuracy. ??? I compiled a complete rom list using GoodWindows/GoodN64. Next, I compiled a Ucode list based on Daedalus findings. I am not sure how to find the "for sure" Ucode, myself, but I believe most of the Ucodes should be right.

Eddy
January 21st, 2002, 02:50
dave does glide have filtering options ? trilinear? bilenear or linear filtering? because only the v4 and v5 have AA, other than that there is no way to remove jagged edges, besides putting up resolution.

Reznor007
January 21st, 2002, 09:28
Originally posted by Eddy
dave does glide have filtering options ? trilinear? bilenear or linear filtering? because only the v4 and v5 have AA, other than that there is no way to remove jagged edges, besides putting up resolution.

Glide supports point sampling, bilinear, and trilinear. Hardware support is the thing.

V1/Vrush/Vbanshee=Bilinear only
V2/V3=trilinear for free when doing single texturing, bilinear when multitexturing
V4/V5=1/2 speed trilinear for single texturing, bilinear for multitexturing.

Eddy
January 21st, 2002, 09:36
then dave later on in the project, you can add these features. You just have to autodetect the voodoo card, and gray out the checkboxes that do not correspond to the card. For example. trilinear filtering for the v1, greyed out. But for v5, it is selectable.

gokuss4
January 22nd, 2002, 03:36
when the explosion happens when you throw bowser into the bomb its a block

Eddy
January 22nd, 2002, 04:26
sounds like a combiner isnt present, thats why there is a black block when the bomb occurs

gokuss4
January 22nd, 2002, 06:39
ok. its fixed now. he had one thing mixed up.

Dave2001
January 22nd, 2002, 11:45
Ok, it may be a while until the next release. I'm trying to make games other than Mario work. Currently, Chopper Attack, Blast Corps, and Pilotwings 64 show up, all with texture problems. Chopper attack is doing best so far.

Ogy
January 23rd, 2002, 18:48
great PlugIn, looks amazing on my voodoo 5 5500 64 MB,
only thing missing from mario is fog emulation, other then that it's almost flawless , well there are some very small glitches (like metal mario being black)
but as you said on your site you probably know it and working on it.

i have a question though, (being that i don't know anything about programming) will it be very hard to add an on-screen FPS counter?
also a wireframe mode (like in 0.01) to 0.03?

just a couple of suggestions, don't get mad.

if you don't have someone /w a v5 and need to test somthing i'll be glad to help.

Dave2001
January 24th, 2002, 05:59
Wow, Starfox and Mario Kart (ucode 1 games) show up now. Expect them to be working in the next release :). I'll put up screenshots once I fix a few things.

They run at a very good speed too, even the planet map in starfox.

Eddy
January 24th, 2002, 06:24
:D

gokuss4
January 24th, 2002, 07:02
ill post screenshots of mario64 right now. marios face has multitexturing ^_^ in other words multitexturing ahas been added to ucode 0 although lighting still needs to be fixed a little

gokuss4
January 24th, 2002, 07:04
here is the sky, its also been fixed.

gokuss4
January 24th, 2002, 07:05
here is another screenshot of when you go into the star level select, spherical mapping needs to be fixed/added for the stars and other misc things to not show aup like that but i believe its only the stars.

Dave2001
January 24th, 2002, 07:06
Actually, mario's face is not multitexturing, it's just using spherical mapping. It's a little too bright right now because I haven't finished with the texture sizes.

gokuss4
January 24th, 2002, 07:06
here is the bubble. it looks a lot better.

gokuss4
January 24th, 2002, 07:08
finally metal mario emulation has been added ^_~

gokuss4
January 24th, 2002, 07:09
heres the front side of metal mario the metal mario looks a lot better than the real N64 version :)

Renegade
January 25th, 2002, 14:32
...my most heartfelt congrats.
hm, ON TO PERFECT DARK!!!!

Slougi
January 25th, 2002, 14:43
Congratulations, things are looking extremely nice :)
Keep up the good work :thumbsup:

Swampylee
January 25th, 2002, 15:54
WOW - getting better all the time.

More shots please Dave ;)
-Swampylee

Dave2001
January 26th, 2002, 05:17
Ok, heres some screenshots of games other than Mario. Below are shown Star Fox, Mario Kart, Mace: The Dark Age, and Chopper Attack. As you can see, I still have a long way to go before these games are worth playing.

Cyberman
January 26th, 2002, 07:24
Ok, heres some screenshots of games other than Mario. Below are shown Star Fox, Mario Kart, Mace: The Dark Age, and Chopper Attack. As you can see, I still have a long way to go before these games are worth playing.
The look better than anything else I've seen on my machine :)
Unfortunately my machine is slow at 300mhz

Quvack
January 26th, 2002, 07:31
Those screenshots look excellent so far :) Personally I think watching the plugin progress can be more fun than playing the games :) Thats what I think anyway :p

bodie
January 26th, 2002, 07:49
i second that ..i don't have a voodoo based card, but i think it's fantastic what you are doing for people that do .. i have been watching it with interest ..and you are progressing at an astonishing rate ..
keep up the great work dave
regards bodie

Eddy
January 26th, 2002, 09:50
exactly :D

flow``
January 26th, 2002, 09:51
looks really great dave.. makes me want to find a voodoo 2 just to use your plugin =p

kinda like when ppl bought v2's for uhle

Teamz
January 26th, 2002, 14:16
any1 knows where I can find Trwingl Video dll source code ?
it's ok i found it !

2fast4u
January 27th, 2002, 05:35
(off-topic) nice signature teamz! ;) smash capitalism!!!

Eddy
January 27th, 2002, 05:41
what makes you say that 2fast4u?

Remote
January 27th, 2002, 06:05
Perhaps he was inspired by Dave´s amzing progress, I am extremely impressed by how fast he pounders the code. I have yet to use his plugin but judging from the screenshots on this forum and on his site it looks like VooDoo owners are in for a threat... and if it keeps progressing this nicely the purshace of two VooDoo 2 cards would be in order, perhaps one VooDoo 4 or VooDoo 5 would be a better purshase, used ones can not cost that much... How is performance with say a VooDoo 2 SLI configuration compared to a VooDoo 5?

A little off topic but how many uCodes are there?

2fast4u
January 27th, 2002, 06:12
uh, well. i gotta say very honest: yes, i am extremely impressed by how fast dave progresses. it wasn't too long ago when we saw his first wireframes and now that ...

but my comment refered to his signature under the message. i said i was going off-topic. just couldn't help it.

remote: i think most ppl wouldn't want to buy a v4 or 5 coz they already have excellent 3d boards. the v2 is pretty popular coz it works as add-on to the existing board (thou it really decreases the 2d image quality ??? ).

Remote
January 27th, 2002, 06:55
Yes, that is what I thought. I looked around some hardware stores and none of them I browsed through sold VooDoo 2 cards, can VooDoo 3 act as a secondary display, I do not want to sacriface my current graphic card, for one which is no longer produced.

When looking through my prior post I saw that I missed one crusial thing, Eddy was refering to 2fast4u and I was refering to Teamz. But still this is amazing, a mere month has passed since Dave introduced his plugin and now it is capable of running Super Mario 64 with only a few graphic errors, with more to come.

2fast4u
January 27th, 2002, 07:27
voodoo3 can't work as secondary display. only voodoo graphics and voodoo2 can (i was also able to run a banshee and a v1 in one system using creative's glideswitcher).

Ogy
January 27th, 2002, 23:45
well if you lived in israel i could point you to a place to buy a V2 for about 50 NIS.

i myself have:
Diamond monster II 12MB (the best voodoo 2 card)
3dfx voodoo 3 2000 pci 16MB (though better then a regular V2 not as good as the diamond)
3dfx voodoo 4 4500(i think) AGP 32MB
3dfx voodoo 5 5500 AGP 64MB ( i'm using it on this comuter)

2fast4u
January 28th, 2002, 00:15
w00t! ogy, do u collect old graphics boards or do they acutally all run in a system?

remote...well, i could give u advice to get a 2nd-hand v2 pretty cheap, if u lived in germany (should be about €20-30 by now or something like that).

flow``
January 28th, 2002, 00:25
*winks at fizban*

mind if i take one of those off your hands? :)

Ogy
January 28th, 2002, 00:36
Originally posted by 2fast4u
w00t! ogy, do u collect old graphics boards or do they acutally all run in a system?



i colloect everything coumputer related, and except the V3 they are all on different systems, i could assemble a system for the V3 in about 2 sec though... i have cpu's, Mboards, sound cards.
but the reason i mainly collect voodoo's is because i like them so much... it's just like my fav sound card is SB16 so i have three.

and flow, sorry i'm very possessive;)

BTW we are getting off-topic... this is dave's plugin topic

Dave2001
January 28th, 2002, 01:48
Any programmers that wish to help develop Glide64, come to the Glide64 development channel on mIRC:

#Glide64 at DALnet

Glide64 is developed using MICROSOFT VISUAL C++ 6.0

My name on mIRC is CM256. I may not be at my computer at all times, so if you say something and I don't respond, just wait or try again later.

type !rules for development rules, and !list for my fserves (current source, plugin directory...)

Dave2001
January 28th, 2002, 04:39
Ok, I'm having trouble with the ul_s, ul_t, lr_s, and lr_t coordinates in settilesize.

For example
ul_s: 114
ul_t: 143
lr_s: 238
lr_t: 267

what would this represent? To my understanding it represents
(28,35) -> (59, 66) which are those coords divided by 4
which would be a 32x32 texture. Is this really what it means?

Teamz
January 28th, 2002, 04:59
(off-topic) 2fast4u: I dont want to start a mess, but I agree with the sentence u made hihi =)

flow``
January 29th, 2002, 01:57
Davy.. not sure exactly why you're on efnet. but most (n64) emulator authors roam around Efnet..

flow`` on #tr #thecompany #PJ64Cheats #pj64 #nemu64 #emulation64 #apollo64 #1964

unless there's a reason you're on dalnet, might not hurt to hop on efnet sometime :)

Cyberman
January 29th, 2002, 03:39
Originally posted by Dave2001
Any programmers that wish to help develop Glide64, come to the Glide64 development channel on mIRC:

#Glide64 at DALnet

Glide64 is developed using MICROSOFT VISUAL C++ 6.0

My name on mIRC is CM256. I may not be at my computer at all times, so if you say something and I don't respond, just wait or try again later.

type !rules for development rules, and !list for my fserves (current source, plugin directory...)

Merf...
I'm on EFNEt sometimes but never on Dalnet :p
I'm always busy too, so I never get anything done, <sigh>. However I might just pop over to see what your rules are if I can remember too. Did I mention I'm busy AND FORGETFUL? :)

By the way I tested your plugin the other night, I was pretty impressed with how well things worked on SuperMario. I'm sure the difficulties will be getting other games because I know SM is the easiest to get working :)


Cyb

Dave2001
January 29th, 2002, 04:23
Well, #Glide64 was originally a channel I just made up on dalnet to send my files to testers. I didn't know it was going to be a registered channel there, someone registered it for me. Maybe we can move it to efnet later.

Anyway, ignore the post for help earlier, I figured it out.

(btw, there is screenshot support now too ;))

gokuss4
January 29th, 2002, 05:26
does anyone know what the problem could be with this?

Dave2001
January 29th, 2002, 05:40
The texture stretch (to the right) is just because I haven't implemented scaling down textures to 256 pixels max.

I'm not sure how to fix the lines though :angry:. If any plugin author knows about how to fix these texture offset problems, please tell me.

Dave2001
January 29th, 2002, 06:39
Never mind, I figured it out, it was the same thing as the other offset problem. It has to do with bilinear filtering using .5 as the middle of a pixel. I had done this in 3d, but not 2d texrects.

Smiff
January 29th, 2002, 07:23
bloody hell Dave you really are f**ing good.

I remember saying something similar to a stranger called Jabo when his test plugin was released lol.

P.S. I'm not trying to shag you, don't worry.

Smiff
January 29th, 2002, 07:29
Actually after reading this thread Ive changed my mind, there is definately some alien technology here, no f**ing way could anyone go that fast.


lol

:pj64:

^ someone make a Glide64/Dave2001 version of that will you, we'll be needing it frequently. Unless they take him back to Venus.

gokuss4
January 29th, 2002, 07:32
Originally posted by Smiff
Actually after reading this thread Ive changed my mind, there is definately some alien technology here, no f**ing way could anyone go that fast.


lol

:pj64:

^ someone make a Glide64/Dave2001 version of that will you, we'll be needing it frequently. Unless they take him back to Venus.

hey smiff whats up i never seen you post in this topic before. in my opinion even if i did have a goforce 2 gts pro 64mb i'd say if i would compare mario 64 dave is the winner. but this is not competition i just wanted to post :D im bored

Dave2001
January 29th, 2002, 07:32
lol :alien:

gokuss4
January 29th, 2002, 07:38
Originally posted by Dave2001
lol :alien:

wow dave i never seen you post a laugh before :) cool. :alien:

icepir8
January 29th, 2002, 09:00
Originally posted by Dave2001
The texture stretch (to the right) is just because I haven't implemented scaling down textures to 256 pixels max.

Dave you don't need to scale the texture to 256 you need to break it into parts. that way you won't lose detail. I know the width is 320 pixels. If you do it as 2 parts of 160 pixels it will work and you won't lose any detail.:colgate:

cya,

Icepir8

Dave2001
January 29th, 2002, 09:03
Ok, I'll do that instead. Thanks :D. Someone earlier suggested that I use the frame buffer, but I think your idea is better since it allows for filtering also.

conkerman
January 29th, 2002, 09:11
sorta OT, but anyway...
hey dave, nice to see u progressing at such a fast rate. i kinda followed what smiff said and made a crappy little sign, just some good old editing of an existing one ( i'm not too talented at graphics editing).

enjoy what must have taken me 5 good minutes to do (hahaha)
conkerman

Dave2001
January 29th, 2002, 09:14
Arrrgggghhhh!!!!! Why won't they do things consistently!?!?!!!!

Take two 32x32 textures:

One uses coordinates (0,0) -> (31,31)
the other uses coordinates (0,0) -> (32,32)

It's REALLY annoying, and making it very hard to keep both the sky problem in mario and the offset problem in the other games both working.

2fast4u
January 30th, 2002, 02:55
hehe

gokuss4
January 30th, 2002, 06:49
can anyone tell me and dave why the nintendo logo looks like this?

LoneRaven
January 30th, 2002, 07:10
Despite the problems that continually arise, you are doing great. I would really like to congratulate you. I really wish I could help you along even more.

PS: After see what I have done to the site, does anyone have any suggestions to make it better/cooler. Input would greatly be appreciated. :colgate:

icepir8
January 31st, 2002, 01:07
Originally posted by gokuss4
can anyone tell me and dave why the nintendo logo looks like this?

This caused by the Line3D ucode command actually being a DrawQuad command.

:tr64:
Cheers!

Icepir8

mesman00
January 31st, 2002, 02:49
loneraven, what the site link again?

sk8bloke22
January 31st, 2002, 03:18
**** good job...

cant believe that uve got so many games already working in like a few months. keep up the good work.

Dave2001
January 31st, 2002, 05:06
Originally posted by icepir8


This caused by the Line3D ucode command actually being a DrawQuad command.



Yes, I suspected something with those plentiful Line3d commands it was giving me... :)

Thanks again Icepir8!

gokuss4
January 31st, 2002, 06:23
hey dave is metal mario suppose to be this color?

Dave2001
January 31st, 2002, 06:26
hmm... that doesn't happen on my computer.

LoneRaven
January 31st, 2002, 17:38
The Glide64 Homepage is here:

www.emuxhaven.net/~glide64/index.htm

Keep up the Great work Dave.

mesman00
January 31st, 2002, 22:35
cant believe that uve got so many games already working in like a few months. keep up the good work.

actually, i think it has been like 2 days more then a month, or something like that. so, yah, its super fast work!

gokuss4
February 2nd, 2002, 06:15
well heres a slight problem. this happens when i go to window mode and back to fullscreen again.

gokuss4
February 2nd, 2002, 06:17
here it is again same thing but when the stars come in mario's face looks like this.

Quvack
February 2nd, 2002, 12:44
Thats just coz Glide was never made to run in a window (well at least not Glide2x and Glide3x) so thats what causes those errors... as far as i know anyway :P

gokuss4
February 2nd, 2002, 12:58
no it doesn't do that in uhle or shle

Reznor007
February 2nd, 2002, 15:54
I would try it on my V5, but I don't have the latest version, only .03 with added resolution support(1280x960, etc.).

Quvack
February 3rd, 2002, 08:19
Originally posted by gokuss4
no it doesn't do that in uhle or shle

UltraHLE and SupraHLE only work in full-screen by default (without wrappers) and when u stop emulation and then start it again it re-initialises glide... but when using Glide64 in PJ64, the emulation continues and the glide still is active, so when u return to full screen it messes up, because glide does not like being tried to be run in a window :)

Thats how I explain it :P So ner ner!

gokuss4
February 3rd, 2002, 08:21
ahh shutup :p :p :p :p

Dave2001
February 3rd, 2002, 09:37
Actually, the problem has nothing to do with window switching. (by the way, this only happens with the development version) If you just let it sit for a minute it happens. I'm not sure what's causing it yet, just because I haven't had time to look into it.

Reznor007
February 3rd, 2002, 10:22
Dave, have you thought about an option for "accuracy"? What I mean is to have polygons that are intended to be point sampled, actually be point sampled, and use scanlines to make it look closer to the original?

I'm asking because 2d objects often look worse when they are unncessesarily filtered.

Dave2001
February 4th, 2002, 03:44
yes, I thought about that, but right now I'm just trying to get the games working. I'll add that soon

Glize
February 4th, 2002, 10:44
hey dave do you need anymore testers?

my system specs:

P3 550MHz
128mb RAM
Voodoo3 2000
Win98SE (with 2000 pro, XP pro, and ME handy)

im pretty knowledgeable on computers. i just don't know how to program yet.

crhylove
February 6th, 2002, 11:00
i get naught but a black screen on this voodoo 3000 with the plugin... jabo 1.4 worx flawless, but a little slow.... i bet everything would speed up nicely if i could get your glide plugin workin'... let me know what i might be doin wrong.

:devil:

PS... i posted this in the plugin section of emutalk, too, isn't that a better place for this whole thread?

Slougi
February 6th, 2002, 14:01
Originally posted by crhylove
PS... i posted this in the plugin section of emutalk, too, isn't that a better place for this whole thread?
Not really as the plug-in section is for help with plug-ins, not coding.

Epic64
February 6th, 2002, 14:23
Sorry to be picky but is this not a plugin although I supose it is to do with emu coding too!

Slougi
February 6th, 2002, 18:34
I think questions regarding the usage of Dave's plugin should be posted in the plugin forum, but technical questions by dave and testers here.

2fast4u
February 6th, 2002, 18:35
crhylove, u stole my avatar !!! :******: *&^#@#!!

Dave2001
February 9th, 2002, 08:06
Ok, it's been a long time since I've said anything, so I just want to let you all know that this project is still going very well. I'm hoping to release the next version over the next few days.

BTW, I'm working on fog right now, but I'm having some trouble with glide. It's giving me very non-interpolated fog, I'm assuming because the w coordinate is like 10000, and the precision isn't very good there. I was going to try fog coordinates, but when I put in the GR_PARAM_FOG_EXT, it wouldn't draw many objects anymore!

crhylove
February 10th, 2002, 02:25
sorry dude... I HAD to.... here's why:

http://artists.mp3s.com/artists/194/communizt_******.html

enjoy!

oh yeah, dave... i'm excited about your plugin. voodoo rulez!

rhy

Dave2001
February 10th, 2002, 03:01
Ok, does anyone know of a good graphical HTML editor (preferably free) that I can use to update my web page? I'm absolutely sick of having to type in the HTML code each time.

2fast4u
February 10th, 2002, 04:38
Originally posted by crhylove
sorry dude... I HAD to.... here's why:

http://artists.mp3s.com/artists/194/communizt_******.html

ok comrade, that changes everything. ;)

Remote
February 10th, 2002, 05:04
Originally posted by Dave2001
Ok, does anyone know of a good graphical HTML editor (preferably free) that I can use to update my web page? I'm absolutely sick of having to type in the HTML code each time.

My personal experience is that graphical HTML editors, although they speed up work, has a tendency of doing unwanted things. But if you have had it I guess a WhatYouSeeIsWhatYouGet HTML editor is for you. Good free choices are Arachnophilia and CoffeeCup. Netscape Composer, included with Netscape Communiactor v4.91, is a another free alternative, Microsoft Word has the ability to save HTML files. Dreamweaver, Homesite and GoLive which although cost money offers more features. Most of them has sharp evaluation versions avalible for download...

Dave2001
February 10th, 2002, 08:42
Ok, Glide64 v0.04 released at http://www.emuxhaven.net/~glide64/

:colgate:

Make sure to configure the ucode for each game you run.

btw. the sources have been released there also

Eddy
February 10th, 2002, 08:43
Well merry chirstmas people :-D can someone post a screenshot for glide64's config screen, i would like to see how configurable it is :-) congrats dave

Dave2001
February 10th, 2002, 08:46
even if you can't run my plugin, you should at least be able to run configure :)

it doesn't use glide until you switch to fullscreen

Smiff
February 10th, 2002, 16:27
Originally posted by Dave2001
even if you can't run my plugin, you should at least be able to run configure :)

it doesn't use glide until you switch to fullscreen


No Dave PJ even stresses when you go to Settings - "Unable to locate DLL / The DLL glide3x.dll could not be found in the specified path." then "Failed to load ...Glide64.dll" Then it's not in the vid plug menu. So that's a no I guess :/

I'm actually seriously thinking of setting up my V3 PC just to see this :)

Eddy
February 10th, 2002, 22:48
yup im thinking about that too smiff

crhylove
February 11th, 2002, 03:06
actually, i have a voodoo 3 installed and all i get is the 3dfx splash screen, then black. i got the latest drivers off of voodoofiles.com, i am excited to get it working, but i'm out of ideas! maybe install this old voodoo 2 add on board? (eww!!!)

rhy

gokuss4
February 11th, 2002, 03:16
did you setup the ucode number? the games the glide64 plug-in can mostly play is

Game name ucode
-----------------------------
Aerogauge 1
Chopper Attack 0
Mario Kart 1
Mortal Kombat Trilogy 1
Star Fox 64 1
Super Mario 64 0

those games are all fully playable with maybe barely or no problems at all

Dave2001
February 11th, 2002, 10:37
Glide64 DOES work under Windows XP!!! Gugaman got it working using 3dfx Underground VoodooXP Series Driver (http://www.voodoofiles.com/5621). This should work with voodoo 3/4/5.

euphoria
February 11th, 2002, 17:35
Here are two pictures from PJ1.4 and Glide64 v0.04:
The shadow mirroring problem has bee there since the texturing was introduced. And screenshots are in their original form (they are upside down;))
1st pic:

euphoria
February 11th, 2002, 17:36
2nd pic:

pj64er
February 12th, 2002, 03:20
on a side note, Glide 64 v0.4 was put on the news of emulation64.com as an input plugin!:D

(when i get bored i get nitpicky)

LoneRaven
February 12th, 2002, 03:42
Great job dave. Now I have a question and a suggestion. Instead of having the user choose the ucode, why not use rom detection to select the corret ucode accordingly. You could probably leach code off of the PJ detection if needed. My suggestion also ties in to my question. Instead of using huge switch statements, can you not use rom detection. That way, you can have rom specific code without continually testing what the rom is. Correct me if I am wrong, but wouldn't this add a bit more speed and cleaner code?

flow``
February 12th, 2002, 04:48
You could probably leach code off of the PJ detection if needed.

Isn't this part of Jabo's plugin? If so, then the source is closed so there is no "leeching" of it.

Heh.. Dave works so hard and people dont take the time to check a game to see if its ucode 0 or 1.. my god

lazy *******s ???

Eddy
February 12th, 2002, 05:45
do you guys want glide64 to brush your teeth too?!

mesman00
February 12th, 2002, 07:20
do you guys want glide64 to brush your teeth too?!

well, i did just drop mine in the toilet, sooo that would be awesome!

anyways, the plugin looks great, keep it up

LoneRaven
February 12th, 2002, 07:58
Isn't this part of Jabo's plugin? If so, then the source is closed so there is no "leeching" of it.

Heh.. Dave works so hard and people dont take the time to check a game to see if its ucode 0 or 1.. my god

To flow:

No, the CRC detection is not part of Jabo's D3D video plugin. It is part of the main program. Regardless of the used plugin, the list of Roms names and info is generated using the core of the emulator. I am not trying to belittle Dave, but save him time. Why not just (leech = site and use) leech it and move on without spending a great deal of time finding out how the CRC codes work. Anyway, where is there a ucode list of all the games. I looked everywhere to compile a ucode list for Dave and ended up using the Daedelus findings. According to Dave not all of them are correct either.

crhylove
February 12th, 2002, 11:36
i sent martin the original news about the glide plugin.. i'm pretty sure i made it clear it was a vid plugin... :) just my 2 cents...

oh yeah..yay!

crhylove

Smiff
February 12th, 2002, 23:30
Originally posted by LoneRaven


To flow:

No, the CRC detection is not part of Jabo's D3D video plugin. It is part of the main program. Regardless of the used plugin, the list of Roms names and info is generated using the core of the emulator. I am not trying to belittle Dave, but save him time. Why not just (leech = site and use) leech it and move on without spending a great deal of time finding out how the CRC codes work. Anyway, where is there a ucode list of all the games. I looked everywhere to compile a ucode list for Dave and ended up using the Daedelus findings. According to Dave not all of them are correct either.

Er.. no, the uCode detection is definately part of the plugin, I know from working with Jabo and supplying him CRC->uCode references... it is not real 'autodetection' at all, his video plugin contains a huge table, each CRC has one corresponding uCode but one uCode can have many CRCs, it has to be checked on state loads also because they can change during execution.. simple to understand but not as easy a thing as it first appears to make reliable... still better than a simple ROM header CRC lookup though, but if you have relatively low compatibility i don't see that being a problem... I'm not sure of the formulae Jabo is using to derive his CRC, maybe he'd tell you, maybe he wouldn't :p

flow``
February 13th, 2002, 02:28
heh i have no idea what you think i meant and how you stated that paragraph.. but anyway


No, the CRC detection is not part of Jabo's D3D video plugin.

the CRC detection is a simple calculation of the first 8 bits of the rom header, then the seconds crc is a calc of the last 8 bits

is it bytes or bits? i can't remember

i doubt the crc has much to do with the roms corresponding ucodes since some games for instance; yoshi's story; relies on 2 ucodes doesn't it? one for the 2d gfx/sprites and another for the 3d animation and stuff

correct me if im' wrong..

Hacktarux
February 13th, 2002, 02:41
I think you are speaking about 2 totally different things. There's a CRC code in the header of each rom : this is used in emus to identify a rom. If the ucode is stored in an ini file, the emu can find it with the CRC that is in the header rom but this has nothing to do with autodetecting an ucode.

The other thing that can be checked by CRC is the RSP code that is simulated by the GFX plugin. This can be used to autodetect ucode. I have tried to implement it in the glide64 source code but i haven't get any result : i have many differents CRC on roms that are supposed to have the same ucode.

Cyberman
February 13th, 2002, 05:14
Originally posted by Hacktarux
I think you are speaking about 2 totally different things. There's a CRC code in the header of each rom : this is used in emus to identify a rom. If the ucode is stored in an ini file, the emu can find it with the CRC that is in the header rom but this has nothing to do with autodetecting an ucode.

The other thing that can be checked by CRC is the RSP code that is simulated by the GFX plugin. This can be used to autodetect ucode. I have tried to implement it in the glide64 source code but i haven't get any result : i have many differents CRC on roms that are supposed to have the same ucode.

Well acording to Smiff


Er.. no, the uCode detection is definately part of the plugin, I know from working with Jabo and supplying him CRC- >uCode references... it is not real 'autodetection' at all, his video plugin contains a huge table, each CRC has one corresponding uCode but one uCode can have many CRCs, it has to be checked on state loads also because they can change during execution.. simple to understand but not as easy a thing as it first appears to make reliable... still better than a simple ROM header CRC lookup though, but if you have relatively low compatibility i don't see that being a problem... I'm not sure of the formulae Jabo is using to derive his CRC, maybe he'd tell you, maybe he wouldn't

That means that the CRC's are multitudinal for each uCode.

This seems like an inherently unreliable method really. I'm sure it works great for a specific few roms. I've no clue though what would be better.

CRC calculations very all over as well, they depend on the polynomial you are using and the Initial State of the CRC register you are storing the CRC in. Most CRC generators start with All ones to eliminate dead zones for CRC's. For each byte of the CRC value you need a 256 entry table to look up a new CRC value. Then on matching CRC's generated by various RSP code patterns being sent to the GPU. This costs time and is kind of challenging to implement. Is there a better way though? That's a tough question.

If one can use LLE for detecting the codes used then use HLE afterward for actually doing the emulation that might have promise. With LLE you will have a huge slow down but it could allow you to detect the uCode being used more acurately.

Cyb

mesman00
February 14th, 2002, 21:21
what happened to all the action in this thread... two days without a post!

Cyberman
February 15th, 2002, 01:14
You posted that just to complain about action?

The last post was by mean and it was about using CRC's for detecting what uCode is being used by the N64 program. My Last suggestion was using an LLE interpretor to determine what set of uCodes were being used (and use it to generate a real image as well) then switching to HLE for when the uCode is determined. Code that isn't compiled properly HLE wise would force another LLE pass and then redetct the uCode set being used.

Not simple but more likely to work than using CRCs :)

Cyb

Hacktarux
February 15th, 2002, 04:45
Hmm, i can't understand exactly how you want to do it with a lle interpreter but when a task is started on the N64, the address and the length of the ucode is given to the rsp in order to allow it to load the code in its own memory. It's that code that we have to identify, and we have less than 10 possibilities. The CRC algorithm speed is not a problem because we only have to make it the first time a gfx task is launched (then to be sure that it is always the same ucode that is used, we can check if the address where the ucode start is always the same). And because of the few possibilities we have, the CRC algorithm doesn't need to be very accurate.

I think the problem i had is because the length that is indicated, is larger than the real one (or there is data that are not part of the ucode).

Cyberman
February 16th, 2002, 02:24
So you don't think that 32bit CRC's are necessary then? Possibly 24bit or 16 bit? Those use less space and are faster to calculate. (One less look up table entry to use to get the next byte basically).

It sounds to me that you might have to parse the data stream some to find out what is in it or find non RSP codes then filter them out. Not sure how to do that but hey.

The other problem is as someone stated early is some games switch code sets and use them for different things. Thus you might have to do your CRC check every frame in order to automatically adjust for new uCodes. And if you have combined uCode sets.. what then?

If as an example there are 8 uCode sets. From those uCode sets you can have potentially 2 Code sets used together that would give you the possibility of 56 combinations of CRCs. Plus you still need to throw out non RSP code (does the same chip handle sound data as well?).

Cyb

Hacktarux
February 16th, 2002, 03:20
I'm almost sure that it is impossible to have two ucodes for the same task. Each time a task is lauched the RSP load the ucode and execute the display (or audio) list. AFAIK, most roms use only one graphic ucode but maybe there are some that use one for 3d and one for 2d.

Audio tasks are handled by the same chip but not at the same time ! The emulator detect if it is a graphic task or an audio one before sending it to the plug-in.

For these reasons, i think that once we have identified the ucode, we only have to check at each frame if the ucode address is always the same => just one test. We are very unlucky if the rom put two different ucodes at exactly the same address.

Dave2001
February 16th, 2002, 05:42
grr, it stopped emailing me about new posts, so I haven't checked this forum for about 5 days

Anyway, about the flipping problem on voodoo 1: Soon I'm going to implement something that should fix the texmirror problem, but about the full-screen flipping, do you think that setting the origin to upper-left instead of lower-left would fix it (maybe voodoo1 doesn't support lower-left origin?)

Thanks for trying to figure out how to autodetect ucodes! :) :)

Cyberman
February 16th, 2002, 06:01
Originally posted by Hacktarux
I'm almost sure that it is impossible to have two ucodes for the same task. Each time a task is lauched the RSP load the ucode and execute the display (or audio) list. AFAIK, most roms use only one graphic ucode but maybe there are some that use one for 3d and one for 2d.

Audio tasks are handled by the same chip but not at the same time ! The emulator detect if it is a graphic task or an audio one before sending it to the plug-in.

For these reasons, i think that once we have identified the ucode, we only have to check at each frame if the ucode address is always the same => just one test. We are very unlucky if the rom put two different ucodes at exactly the same address.

Hmmm.. So what you are saying for each task list the RSP code used is usually one ucode?

Then once you have identified each pointer to the task list you only need to check for the address for each uCode pass.

Might work.. assuming that uCodes sets are sent singularly to be processed that is. Might have a problem with getting CRC's to match ucodes though. Since CRC's are supposed to be unique as possible for a given data stream.

How are you matching uCode to CRC's?

Cyb

Hacktarux
February 16th, 2002, 23:49
The ucode (which is loaded on the rsp's instruction memory area) is supposed to not contain data. This is the reason why the CRC should be the same from one rom to another. (I have tried to check the CRC ucode of many frames of a rom and these are always equal). Unfortunately, i have experimented that this is never the case from one rom to another. I think that there are pieces of code that do nothing and that interfere in the CRC's calculation. I think that i will have to disassemble some ucodes to understand why but i have not the time needed now.

Dave2001
February 17th, 2002, 03:08
Ok, here's a problem I have in several games. In mipmapped textures, they seem to be interleaved (see road in screenshot below for example). Am I correct about mipmapped textures being layed out flat in memory like this?:

000000000000000011112
(numbers represent a texture, 0 is 4x4, 1 is 2x2, and 2 is 1x1)

or graphically like this:
0000
0000
0000
0000
11
11
2

Dave2001
February 17th, 2002, 03:09
grr, didn't attach

Dave2001
February 17th, 2002, 03:25
About the ucodes, I was chatting on mIRC with ZeZu:

<ZeZu> some of that stuff about uCodes and CRC's is goofy on that mb post
<ZeZu> there can and will be different CRC's for different versions of the same ucode
<ZeZu> 0x7FE32C72, 1, // RSP SW Version: 2.0D, 04-01-96 Super Mario
<ZeZu> 0x6F0064B6, 1, // RSP SW Version: 2.0D, 04-01-96 Pilot Wings 64
<ZeZu> 0xC2F0F0FF, 1, // RSP SW Version: 2.0D, 04-01-96 Dark Rift
<CM256> post that stuff there to maybe help them figure it out
<ZeZu> CRC here : *((u32*)&RDRAM[StartRDRAM+(i<<2)]);
<ZeZu> ugly code but you can see what it does
<CM256> is that the crc for the ucode or for the game?
<ZeZu> ucode on bootup
<CM256> can ucodes change after bootup?
<ZeZu> ;)
<ZeZu> yes
<CM256> how do you tell when they change?
<ZeZu> and contrary to what some people were saying games can contain more than one ucode and some have their own ucodes
<ZeZu> #define F3DEX_LOAD_UCODE (F3DEX_IMMFIRST-16) & 0xFF
<CM256> ok, that acts like an instruction, right?
<ZeZu> yea

linker
February 17th, 2002, 04:39
Dave, I've never heard about Zezu, is he an emu writer? Also Dave, you used some parts of tr and i think that it is necessary to give some credits to niki (he started the whole project and I think that he has a big role in making possible to run mario with trwingl).

Dave2001
February 17th, 2002, 07:31
Oh, I didn't know niki was a part of it too, I put Icepir8 and F|res, but I didn't see that name. Sorry! :cry:

Dave2001
February 17th, 2002, 07:37
Hmm, wait, do I have my credits for tr64 all wrong? I put Icepir8 and F|res as the authors, but I think I actually have another TR64, which appears to be made only by Nikki.

Eddy
February 17th, 2002, 07:59
your referring to trwin i think, by niki waibel

Dave2001
February 17th, 2002, 08:37
Wait, now I change my mind again, it says by Niki, but in the diary.txt, everything says FiRES. I think this is a ported version, where the original was by niki, but the port is by FiRES.

mesman00
February 17th, 2002, 08:58
the original true reality was by niki, and was made for Linux. Then ice and fires ported it to windows, using openGL (their version was known as trwingl before they closed the source and renamed it TR64).

then, u have rcp, who ported the original true reality to windows using direct x.

but, i think both emu's have been completely rewritten, so they no longer have any original True Reality Code in them.

Eddy
February 17th, 2002, 09:00
tr64 5.666a is far different than niki's, just put niki in the credits, this is kind of confusing to talk abuot

Dave2001
February 17th, 2002, 09:43
Anyway, you guys don't need to worry about ucode autodetection, I've got it all planned out. ;)
Thanks ZeZu!!! :D

I'm thinking about switching to INI-based settings instead of registry, so that when you find a new ucode crc, you can add it there. What do you think about this? Advantages/disadvantages?

Eddy
February 17th, 2002, 09:44
disadvantage: confusing

but there is a alternate, a built in ini, like a table, like jabo's gfx, and people can supply you with ucodes

Dave2001
February 17th, 2002, 09:46
Wow, nice response time! Less than 1 minute! :)
Anyway, I won't put it in just yet, I want to hear more opinions.

Why I wanted it editable was because there are many different crcs for each ucode. This is what I have so far out of the ~18 games I have:

05165579=1
3a1cbac3=0
3f7247fb=0
4165e1fd=1
5d1d6f53=0
64ed27e5=1
6eaa1da8=1
8805ffea=1
a346a5cc=1
e41ec47e=1
e89c2b92=1
ee47381b=1
fb816260=1

(crc=ucode)

Hacktarux
February 17th, 2002, 14:26
I know that there are many CRCs for one ucode, but i think this is because we take wrong data to calculate it. This is why i will disassemble some ucodes. Anyway i don't know if i will get any result.

flow``
February 17th, 2002, 20:20
hmm.. ini eh? :>

/needs a voodooo card

flow``
February 17th, 2002, 20:21
oh dave.. it might be a little more convenient to have a little table:

goodn64 rom name | crc1/2 | ucode

i have no idea what 18 games you have are =p

Dave2001
February 17th, 2002, 22:49
Well, there's more than one game per crc, so it wouldn't do much good to include a name with the crc. Do you think it would be a good idea to switch to ini-based settings instead of registry, or should I keep the registry and just write the table directly into my program? (meaning, if you find a crc that I havent implemented, you will ALWAYS have to select the ucode for that game)

I think we are calculating from the right data, but there may be different versions of the ucode, which accounts for the different crc's. Most games of the same ucode tend to have one crc, but then there are several exceptions.

(by the way, I'm checking 3072 bytes at RDRAM+DMEM[0xFD0], 3072 because 4096-1024=3072, ZeZu had experiences with junk being in the last 1k sometimes. You must check AFTER the rom is loaded, not in LoadROM!!! Do it in ProcessDList)

Anyway, the source of my plugin getting slower I believe is in the lighting :devil:. Can someone try to optimize the lighting code? (and possibly fix the problem with something going negative [see starfox title screen, move the 64 logo])

Another problem I'm having:
I've heard that you ALWAYS use the settilesize lr-ul to get the size of a texture. This works fine... except for the starfox water and land. It seems to give me a moving ul_t coordinate.

ul_s = 0
ul_t = 59 (goes up constantly)
lr_s = 124
lr_t = 124

The problem with this is: the texture gets smaller and smaller each frame! What's really supposed to be going on?
(124-59 +4)>>2 = ~17, the texture probably shouldn't be 17 pixels large in the t axis. ???

Ogy
February 17th, 2002, 23:06
dave can you look at my compatibility list? i posted it on your forum (http://www.hosthq.net/~emuxhaven/cgi-bin/ikonboard/ikonboard.cgi?s=3c6feecd6470ffff;act=ST; f=17;t=20).
any chance you would put it on your site? (the finished list, that is)

Dave2001
February 17th, 2002, 23:10
Thanks! I'll do that now. Not only does that allow people to know what works, but it also allows me to find out what games I need to get in order to fix them. :cool:

Do you want me to put it up as .txt, .zip, or .html?

Ogy
February 18th, 2002, 00:02
whatever you like :)

linker
February 18th, 2002, 01:34
Make an ini, it'll be better.

Smiff
February 18th, 2002, 01:41
just a suggestion, get away from the numbered uCodes and use the real names (RSP SW 2.0x etc) as soon as possible, while the compat. is small, this way you won't have as much to redo later, and you'll be able to use PJ64 as a reference.

2nd point, definately use a redistributable file rather than the registry so someone who knows what they're doing (but not Dave) can manage it. Put known references into the plugin and use the INI when an unknown CRC is encountered. Every so often, you add the confirmed references to the plugin and reset the INI, and so on.

Ogy
February 18th, 2002, 01:53
Originally posted by Smiff
just a suggestion, get away from the numbered uCodes and use the real names (RSP SW 2.0x etc) as soon as possible, while the compat. is small, this way you won't have as much to redo later, and you'll be able to use PJ64 as a reference.

2nd point, definately use a redistributable file rather than the registry so someone who knows what they're doing (but not Dave) can manage it. Put known references into the plugin and use the INI when an unknown CRC is encountered. Every so often, you add the confirmed references to the plugin and reset the INI, and so on.


umm.. who are you referring to smiff? dave?

Dave2001
February 18th, 2002, 02:08
Yes, but they must be numbered in some way, because it needs an instruction table index. I will probably switch the config dialog to the name, but on the inside it still needs numbers.

This is what it is:
gfx_instruction[settings.ucode][rdp.cmd0>>24] ();

What, should I do:
gfx_instruction["RSP SW 2.0x"][rdp.cmd0>>24] ();

See the problem?

Cyberman
February 18th, 2002, 02:17
Originally posted by Dave2001
Yes, but they must be numbered in some way, because it needs an instruction table index. I will probably switch the config dialog to the name, but on the inside it still needs numbers.

This is what it is:
gfx_instruction[settings.ucode][rdp.cmd0>>24] ();

What, should I do:
gfx_instruction["RSP SW 2.0x"][rdp.cmd0>>24] ();

See the problem?

Well if rdp.cmd0 is a 32 bit entity >> 24 leaves you 256 possible codes (if they are all used) you can create an enumerated data type with each possible code identified in it (instead of the uCode sets). I think that's what he was refering too. :)

Might be wrong though... it's happened before!

Cyb

Smiff
February 18th, 2002, 02:23
yeah of course, it's just that there are several uCodes to each common number, e.g. many plugins would call Zelda and Doom "3", even though Zelda is using a custom uCode. Not sure how much this matters, I haven't exactly thought this point through :p but somewhere here there is a point. Depends how far ahead you want to plan :p Anyway, the 2nd half of my post was better.

Ogy
February 18th, 2002, 02:54
from glide64 website:
Ogy has created a compatibility list for Glide64! It includes game name, ucode, and comments.
Download it here!

i think you should put the zip file there and not the txt, because if you rightclick and choose "save as" it screws the file.

Dave2001
February 18th, 2002, 02:57
Ok, I'm also changing the filename so that it's one word, and shorter, just to avoid problems.

Ogy
February 18th, 2002, 03:07
ok, thanks

Quvack
February 18th, 2002, 07:09
I think ini would be the best way to go, because people who dont know much about *.reg files might go to run an un-offical one which could destroy some windows settings and thats not fun to fix :P

Ini is a safer system for what you want to do, and makes it easier in the long run I think for a few reasons.

Dave2001
February 18th, 2002, 10:38
Development on Glide64 is almost at a complete halt. I can get things working if I know what the n64 is trying to do, but when I don't even know what the n64 is trying to do, it's impossible for me to get anywhere. I asked many emu coders about my lr and ul problems, but nobody seems to know anything about them! It's not something wrong with my plugin, I don't even understand what the n64 is trying to do! :cry:

Ok, as a start, can ANYBODY tell me what the n64 is trying to do here? (as in load a texture of __ size, __ offset [if any]) I just need a general description with numbers! (by the way, this was taken out of a log from tetrisphere)

0026b888: settextureimage: format: RGBA, size: 16bit, width: 320, addr: 003da800
0026b890: settile: tile: 7, format: RGBA, size: 16bit, line: 16, t_mem: 00000000, palette: 0, clamp_t/mirror_t: CLAMP, mask_t: 0, shift_t: 0, clamp_s/mirror_s: CLAMP, mask_s: 0, shift_s: 0
0026b898: loadsync - ignored
0026b8a0: loadtile: tile: 7, ul_s: 0, ul_t: 120, lr_s: 252, lr_t: 236
0026b8a8: pipesync - ignored
0026b8b0: settile: tile: 0, format: RGBA, size: 16bit, line: 16, t_mem: 00000000, palette: 0, clamp_t/mirror_t: CLAMP, mask_t: 0, shift_t: 0, clamp_s/mirror_s: CLAMP, mask_s: 0, shift_s: 0
0026b8b8: settilesize: tile: 0, ul_s: 0, ul_t: 120, lr_s: 252, lr_t: 236
0026b8c0: settilesize: tile: 0, ul_s: 0, ul_t: 0, lr_s: 2016, lr_t: 928
0026b8c8: texrect (0, 30, 63, 59), tile: 0, cmd2: 00000000, cmd3: 04000400

euphoria
February 18th, 2002, 16:08
Could someone explain to me how exactly ucodes work? I know that ucode stands for microcode, and the rsp/rdp(?) contains 8-bit instruction set, but does it contain 'number of ucodes' * '256' sized "table" or does the rom's ucode change something inside the processor. If i've understood correctly Zelda roms have a ucode of their own. Then something must be "uploaded" to the processor? And why zeldas are the only ones to use their own ucode? I'm probably totally lost here...

Dave2001
February 19th, 2002, 05:18
Hey, just out of curiosity, is uCode an abbreviation for microcode (u as in micro, like the prefix)?

Eddy
February 19th, 2002, 05:24
yup

Smiff
February 19th, 2002, 05:24
Originally posted by Dave2001
Hey, just out of curiosity, is uCode an abbreviation for microcode (u as in micro, like the prefix)?


Yes, lol

Dave2001
February 19th, 2002, 05:51
Anyway, if nobody answers my Starfox water problem, Starfox won't even be supported in the next version. :cry: Look a few posts back (NOT the tetrisphere post [the one with actual code]), it's the one about the ul and lr coords. SOMEBODY must have gotten it working, and if so, they must know what the N64 is trying to do. NOBODY WILL EXPLAIN TO ME THOUGH!!!!

Please note, the UL and LR coords there had not yet been converted to 10.2 format. The coordinates in 10.2 format would be:

ul_s = 0
ul_t = 12 (changes)
lr_s = 31
lr_t = 31

crhylove
February 19th, 2002, 13:20
i totally dig the way you conduct business. wish i knew more about the inner workings of the n64. unfortunately all of my knowledge is theoretical, and in unrelated fields.

keep on truckin' brutha.
:devil:

Eddy
February 19th, 2002, 23:01
lol, "dig"

gokuss4
February 20th, 2002, 08:36
dude you guys this is way serious, star fox has a problem with its water right now and dave needs help so can anyone help him?

Dave2001
February 20th, 2002, 09:19
Anyway, it turns out that even Icepir8 didn't have this fixed in his plugin, so of course it wouldn't work in mine if everyone tells me to use lr-ul always. I'm reverting back to my old approach that works, and hopefully I can fix whatever was wrong with that.

BTW, I'm working on Zelda right now, and it's going very well. (no Gfx yet, but there are no undefined instructions, and everything seems to be executing logically)

gokuss4
February 20th, 2002, 09:47
dangit dave should of kept it a surprise until at least textures were working ;)

Dave2001
February 20th, 2002, 09:50
Well I've heard Zelda is one of the hardest games to do, so don't expect it anytime soon.

gokuss4
February 20th, 2002, 10:20
dont worry dave i dont really expect much, i just wait :alien:

Eddy
February 20th, 2002, 10:46
thats not a nice thing to say

Dave2001
February 20th, 2002, 12:36
That's not what he meant

Anyway, Gugaman and I implemented some MAJOR MAJOR speedups with lighting. Now almost every game I've tried runs at a very decent speed. I've also fixed the starfox water problem (maybe for the last time?)

Azimer
February 20th, 2002, 18:51
Originally posted by Dave2001
That's not what he meant

Anyway, Gugaman and I implemented some MAJOR MAJOR speedups with lighting. Now almost every game I've tried runs at a very decent speed. I've also fixed the starfox water problem (maybe for the last time?)

What does your experience with the problem tell you as a whole? A lot of times... it seems we are getting texture coordinates that are completely offbase for no reason at all. I know of the problem you spoke of. Just didn't know the solution.

Cyberman
February 20th, 2002, 20:04
Originally posted by Azimer


What does your experience with the problem tell you as a whole? A lot of times... it seems we are getting texture coordinates that are completely offbase for no reason at all. I know of the problem you spoke of. Just didn't know the solution.

I wonder if the solution is held in that monsterous #include file in the graphics dev kit for the n64 or at least the answer to what is happening to ul_t. I wonder if it's an offset into the texture image?

Cyb

Hacktarux
February 20th, 2002, 20:36
I'm not sure but maybe, the width of the texture can be calculated by the dxt parameter of the loadblock command. Then, uls can be used as an offset on the texture. But maybe, it's stupid because i have just started my gfx plugin and i have not much experience on this.

crhylove
February 21st, 2002, 02:08
and stupid people like me why i don't sometimes... lol

wtg dave! congrats man, u r a brain.

:devil:

Dave2001
February 21st, 2002, 04:32
Ok, the solution I use, and it is correct as far as I know:

When using loadblock to load a tile:
width = lr_s + 1;
height = lr_t + 1;

then, when scaling your texture coordinates right (ex: multiply by s_scale and t_scale), do the following:
s -= ul_s;
t -= ul_t;

When using loadtile, don't do either of those. Do the following:
width = (lr_s - ul_s) + 1;
height = (lr_t - ul_t) + 1;

Now, of course, all of this is assuming you already have your coordinates in 10.2 format (without the fraction of course), and all the ul and lr coords come from settilesize.

The only problem I know of is that the Midway logo at the start of SF rush loads a texture larger than it needs to, but that's not really a problem though, since it displays correctly anyway.

Hope this helps somebody :)

Dave2001
February 21st, 2002, 04:39
Another note: if you exclude texrects using loadblock from being considered "loadblock", then that would fix the SF rush problem.

Dave2001
February 21st, 2002, 07:23
OMG!!!!! After just 2 days of work, and only GBI.h to work with, I got Zelda wireframes working!!!! Was that microcode supposed to be hard?? that was one of the easiest things in the world! and I had school today and yesterday also, but STILL managed to get it done. I also checked the texture cache, and 95% of the textures are loading correctly, I just haven't mapped them yet.

On the left is Zelda 64: OOT, and on the right is Super Smash Brothers

Eddy
February 21st, 2002, 07:36
lol wow dave great work! your progressing faster than jabo!

Azimer
February 21st, 2002, 08:15
Problem isn't the polygons... persay... There are some things that are just odd with that GBI... possible issues. Also the blending and CC is a lil harder to get correct. There are also lighting issues. Those were my experiences.

Eddy
February 21st, 2002, 09:14
anybody need anything? i want to help but im not good enough to code a plugin yet :-)

gokuss4
February 21st, 2002, 09:24
well you can observe these screenshots that ill post tomorrow :D

Cyberman
February 21st, 2002, 12:23
Originally posted by Dave2001
OMG!!!!! After just 2 days of work, and only GBI.h to work with, I got Zelda wireframes working!!!! Was that microcode supposed to be hard?? that was one of the easiest things in the world! and I had school today and yesterday also, but STILL managed to get it done. I also checked the texture cache, and 95% of the textures are loading correctly, I just haven't mapped them yet.

On the left is Zelda 64: OOT, and on the right is Super Smash Brothers

You should allow this mode to be called something clever how about "plasma wire frame" because the red lines look like those old plasma displays on lugable compaq computers :)

I am wondering how one can classify the set of microcodes used in a particular rom.

The only thing I can think of is using sets. IE 256 'bits' and scaning for the microcode sets that are being utilized with that game. That of course means 32 bytes worth of bits to twiddle for all 256 possible codes (sigh) :)

Anyhow!

Looks good!
would be cool if Zelda was working :)

Cyb

Azimer
February 21st, 2002, 20:28
Classified by the uCode revision number found in the dmem data. Not a good autodetect method however.

Cyberman
February 21st, 2002, 20:43
Originally posted by Azimer
Classified by the uCode revision number found in the dmem data. Not a good autodetect method however.
Yes that's what we were puzzling over.
you have microcode 'sets' but they seem to not be used quite the same way as one would hope. IE mixing of codes at different times. I suppose hand tweaking helps :)

It's probably about time this thread gets split again isn't it? We are at 14 pages or something? :)

Cyb

LoneRaven
February 22nd, 2002, 04:59
Anyone know what is happening with www.emuxhaven.net. I cannot access the Glide64 homepage or the eumxhaven main page.

Again as always, when the page is back up, email me any suggestions for the page. kingdavid_12@hotmail.com

Dave if you you need any help let me know.

Dave2001
February 22nd, 2002, 11:17
The site will be down for a few hours, as Tekken1096 informed me.

Anyway, I really doubt anyone knows the answer to this question, but what makes the water move in Zelda? It seems to use the same address, same ul and lr coords, so what is changing?

Anyway, here's a screenshot of what's currently done. There are many unimplemented combine modes and some triangles are missing, but it's playable, and runs at a fairly good speed. (I was expecting Zelda to go REALLY slow, but it turns out that it runs just fine)

Dave2001
February 22nd, 2002, 11:39
Nevermind that question!

Stupid hack :P, I put something in to attempt to fix something else, but it caused it to only call settilesize the first time, the second time is when it sets the offset.

EeeK
February 22nd, 2002, 13:25
Wahh...I can't wait to play Zelda but I'm upgradin my Voodoo3 2K to Ati RADEON 8500. Arrgghhh.....both are AGP.....now to have 2 AGP in 1 system??!??!?!

Remote
February 22nd, 2002, 14:39
Originally posted by EeeK
Wahh...I can't wait to play Zelda but I'm upgradin my Voodoo3 2K to Ati RADEON 8500. Arrgghhh.....both are AGP.....now to have 2 AGP in 1 system??!??!?!

Well, you can not. But once again I must say that I am very impressed by the furious progress you are making Dave.:D If you keep this pace God will have to give his poor servants a Glide Wrapper compatible with glide3.

Glize
February 22nd, 2002, 21:39
Originally posted by Remote


Well, you can not. But once again I must say that I am very impressed by the furious progress you are making Dave.:D If you keep this pace God will have to give his poor servants a Glide Wrapper compatible with glide3.

Eddy
February 22nd, 2002, 21:50
:happy: :o :thumbsup: :innocent: :lookaway: :inlove: :colgate: ;) :cool:

Jabo
February 22nd, 2002, 22:07
Originally posted by Eddy
lol wow dave great work! your progressing faster than jabo!

The reason zelda is such a difficult game to emulate was mostly due to the fact that when it was first being worked on ...


Originally opsted by Dave2001
OMG!!!!! After just 2 days of work, and only GBI.h to work with


i wasn't lucky enough to have the software development kit headers for the game then, (i know rcp wasn't either) now apparently it's easy to get ahold of that information, and much more things than we had when nothing existed for us to use, now there is lots of open source, from everything from graphics plugins to RSP information, we reversed everything from scratch -- things are much different now, n64 emulation is a much easier thing to get into, i doubt anyone will ever even have reverse engineer something major for quite some time

Smiff
February 23rd, 2002, 02:44
what jabo did and what dave is doing do not really seem comparable (other than both being very impressive in their own way :p)

Azimer
February 23rd, 2002, 03:32
Originally posted by Smiff
what jabo did and what dave is doing do not really seem comparable (other than both being very impressive in their own way :p)

It's not. I spoke to J-Bird about this earlier. I always thought we had the same GBI.H files we do now. I guess I am quite fortunate to have gotten an updated SDK awhile ago. I makes me more impressed with Jabo's work. He reversed the entire Zelda microcode without looking at GBI.H for the information. RCP had done the same thing. I wish I would have done graphics back then so I could have also claimed the same. :) Jabo rocks... there is no doubt about it.

hotshitu
February 23rd, 2002, 05:15
What about epsilon, what did he have that others didn't at the time? (assuming _he_ was the sole mastermind behing UHLE) Or is it a different ballpark? Certainly not in terms of HLE'ing gfx, or am I wrong??

hotshitu
February 23rd, 2002, 05:17
Oh, and great job Dave. Can't wait to get my hands on your next release.

Eddy
February 23rd, 2002, 07:02
this is getting out of hand, lets stop now, and yeah jabo has done alot of things for n64 gfx but dave is making very fast progress, thanks to jabo, now are we all happy ?

flow``
February 23rd, 2002, 08:13
azimer.. [or jabo], have either of you talked to RCP lately to see whats he's up to?

CpU MasteR
February 23rd, 2002, 12:17
Originally posted by flow``
azimer.. [or jabo], have either of you talked to RCP lately to see whats he's up to?

Plz...

Dave2001
February 24th, 2002, 12:47
AWESOME!!!!!!

I just fixed about 80% of my texture size problems!!! When I use "mask" to get the size instead of the lr-ul coords, it gives me the correct size! The starfox water is fixed too by this! And also the quest64 spells like fireball that don't even work in Jabo's! _ALL_ of the textures load correctly in zelda and super smash brothers!!! :) :) :)

(btw, I use lr-ul if mask is 0)

crhylove
February 24th, 2002, 18:10
YOU ROCK!

i've said my fill on this matter.

:devil:

guess who only HAS a voodoo 3? hey!

Gummy bear
February 24th, 2002, 19:09
Dave, keep up the steady progress. I can't believe your plugin is coming along so fast. *worships Dave*

2fast4u
February 24th, 2002, 22:09
i just post again to congratulate dave (again). i cant believe how fast ur plugin is progressing. :thumbsup:

Eddy
February 24th, 2002, 23:33
this should be no surprise, i think its quite clear dave is a hell of a coder. Azimer is progressing fast also, he got all that working in a few days. Damn dave good luck on the plugin :-) your progress is awesome

Dave2001
February 25th, 2002, 01:07
Ok, I just ran into the biggest math problem of all time. I need to either figure this out or find a way around it.

This is the way around it:
How can I clamp AND wrap at the same time (like wrap once and then clamp)?

otherwise:
I will need to implement triangle splitting, which probably will slow the plugin down, and it is extremely hard to figure out. (splitting the triangle at the clamp point, not too hard if one, but if many... it's very difficult)

Dave2001
February 25th, 2002, 01:13
Ah, I think I found a good way to split the triangles though, I can always use wrapping since it can only wrap on power of two, and then I can manually implement clamping myself.

Ogy
February 25th, 2002, 01:38
dave, i need to get on IRC with you but i never seem to find you there.

Azimer
February 25th, 2002, 02:02
Originally posted by Dave2001
Ah, I think I found a good way to split the triangles though, I can always use wrapping since it can only wrap on power of two, and then I can manually implement clamping myself.

You could always double the texture size then clamp. Where do you find this occurring? I have a breakpoint set up for this condition but never found it. (Assuming you meant mirroring and clamping)

Dave2001
February 25th, 2002, 02:32
Ogy: Well, now I'm usually on #Glide64 on EFnet instead of DALnet.


Clamping and mirroring occurs on mario's hat (and other places) in Super Smash Brothers. What it does: it mirrors once, then clamps, so that it can do the other half of the "M", but not go beyond that. Right now it repeats the "M" another half a time.

Also, the stair steps in the mario stage should wrap several times before clamping.

Dave2001
February 25th, 2002, 02:42
ok, I think I've figured out how I could do it, but how could I do textures bigger than 256 size without splitting triangles?

Reznor007
February 25th, 2002, 09:08
I'm not sure how Creative did it, but they made an OpenGL driver for Voodoo2 boards that supported 512x512 textures in Quake3. I'm fairly sure they did it by splitting it into 4 256 textures, but I don't know if they split the polygons into 4x as many, or just placed the 4 textures into the normal polygons. Something like that might work.

Ogy
February 28th, 2002, 02:05
ok, emuXhaven board is still down so i'll put my finished compatibility list here, this should have all the (U) games and most (all?) (E) but no JAP games.

2fast4u
February 28th, 2002, 03:04
Originally posted by Ogy
ok, emuXhaven board is still down so i'll put my finished compatibility list here, this should have all the (U) games and most (all?) (E) but no JAP games.

holy **** ogy, u sure did a lot of work there. very nice job! :thumbsup:

Dave2001
February 28th, 2002, 06:53
Ok, I think I'm going to need to use multi-pass rendering to interpolate between two textures, Glide won't let me just enter a float value to do so. How does multi-pass rendering work? If I render one triangle with .5 alpha and another with .5 alpha, it isn't going to give me .5 alpha total, correct? I don't have an equation to find the correct alpha values yet.

icepir8
February 28th, 2002, 07:34
Dave2001,

a = total alpha of the resulting multipass texture.

b = the blend percentage between the two textures.

d = the frame buffer.

t0 = texture 0.

t1 = texture 1.

pass 1 would be:

d = ((t0 * b)* a) + (d * (1 - a))

pass 2 would be:

d = ((t1 * (1 - b)* a) + d

I hope this helps.

Cya,

Icepir8
:tr64:

Dave2001
February 28th, 2002, 07:38
Do I need a seperate buffer to do this or can this be done just where I am rendering normally?

thomas_callahan
February 28th, 2002, 19:47
Wow, I just read through the last few days' worth of posts - I can't wait for the next release. I have a PIII 800 and GeForce 2 at home but never had much time there to play games. At work I have a PIII 667 and Voodoo3 and plenty of downtime lately but PJ64 ran like poo with other video plugins on the Voodoo3 so I was prevented from putting that downtime to good use ;)

Thanks for you hard work.

Dave2001
March 2nd, 2002, 11:29
Yes!!! :) Instead of multipass for texture interpolation, I figured out how to fake the LOD into inserting a float value to the texture combine equation.

in the function:
void grTexDetailControl (GrChipID_t tmu, int detailBias, FxU8 detailScale, float detailMax)

it uses the equation:
b = min( detailMax, max( 0, (detailBias–LOD) << detailScale ) / 255.0 )
where b is the detail factor. Now, if I insert the highest value possible for detailBias and detailScale, it will allow me to use the value of detailMax no matter how far away the object is. Then I just combine the two TMUs with detail factor as the scale:

grTexDetailControl (GR_TMU1, 31, 7, 0.5f);
grTexDetailControl (GR_TMU0, 31, 7, 0.5f);

grTexCombine (GR_TMU1,
GR_COMBINE_FUNCTION_LOCAL,
GR_COMBINE_FACTOR_ONE,
GR_COMBINE_FUNCTION_LOCAL,
GR_COMBINE_FACTOR_ONE,
FXFALSE,
FXFALSE);
grTexCombine (GR_TMU0,
GR_COMBINE_FUNCTION_BLEND,
GR_COMBINE_FACTOR_DETAIL_FACTOR,
GR_COMBINE_FUNCTION_BLEND,
GR_COMBINE_FACTOR_DETAIL_FACTOR,
FXFALSE,
FXFALSE);

(the 0.5f in grTexDetailControl is the interpolation % from TMU0 to TMU1)

The ground in Zelda works very nicely now, and there was no error due to distance :)

btw, for those of you who don't know what LOD is, it's what causes textures to change as distance changes.

Ogy
March 2nd, 2002, 14:48
umm.. dave, you still haven't updated my compatibility list on your site.

Dave2001
March 2nd, 2002, 14:50
oops, sorry, I didn't even think about it. I'll do it now.

Dave2001
March 2nd, 2002, 15:20
Wait a minute, isn't that list for the beta? There's no point in releasing a compatibility list for a future version.

Reznor007
March 2nd, 2002, 17:33
Dave, have you tested the new LOD code on Voodoo1 and Voodoo Banshee cards? I'm not sure how they would react since they only have 1 TMU.

Ogy
March 2nd, 2002, 18:56
Originally posted by Dave2001
Wait a minute, isn't that list for the beta? There's no point in releasing a compatibility list for a future version.

no, it's for 0.04.

i would like to test the new beta and start working on the next list, but unfortunately you didn't give me the current beta:(

Remote
March 3rd, 2002, 06:54
A little suggestion, please organize the games in your compatibility list by status, level of playablilty... So instead of looking through a blur... you can instantly see which games that are supported... and perhaps you could add a change log...

Playable...
0-9
A-Z

Errors
0-9
A-Z

Unsupported
0-9
A-Z

Ogy
March 3rd, 2002, 07:07
thanks, maybe i will in the next release.

gokuss4
March 4th, 2002, 06:21
is there anyway dave could fix a certain problem with his plug-in? it has to do with lighting and how accurate it is (e.g marios big face in the beginning)

Reznor007
March 4th, 2002, 07:22
I noticed that too. Mario has a hint of red on his face, this does not happen in Jabo's plugin(or UltraHLE).

Dave2001
March 4th, 2002, 08:15
I'm not an expert on lighting math, so I'm having a little trouble figuring out what's wrong with my lighting calculations. Can someone download the sources and check the lighting code in 3dmath.cpp calclights() to see if it's correct? light_vector[l] is the direction towards the light, and v->vec is the normal. I think that the problem is that I need a min() or max() somewhere, but I'm not sure where. (see starfox intro to find real problem, something goes negative and it dies as you move the 64 to the left of the characters)

Ogy
March 5th, 2002, 02:17
Dave we have a problem:
when you use the plugin, the plugin searches for the INI and if it can't find it, it creates a new one. the problem is that the INI must be the same name as the DLL and if someone want's to change Glide64.dll to something else the INI will not work anymore.

Ogy
March 5th, 2002, 02:24
i'm sorry for posting these things here but due to time differences it's really hard for me to talk to you on IRC.


anyway, when using RSP: interpreter on some games Glide64 gives this error (but keeps working well) :

Dave2001
March 5th, 2002, 05:34
well, that's not Glide64 giving that error, Project64 may be doing it because of an invalid memory access in Glide64 though.

Also, RSP interpreter when I''ve tried it also had problems, make sure that the problem you're giving me does not occur with all plugins.

Anyway, about the Glide64.ini name, I meant for it to be like that. Would you rather me _REQUIRE_ that the name be Glide64.ini, because I can do that too. I did it so that you might be able to have different settings for different games. (of course I will still need to add an INI title to the plugin string for that)

Quvack
March 5th, 2002, 12:43
Regarding the ini:

I'd keep it the same, because usually people wont need to rename the dll anyway, and having the ability to have different settings could be usefull... Maybe an option in the plugin itself to name the ini or select a different may be of use, i dunno :)

crhylove
March 5th, 2002, 14:12
Originally posted by Ogy
i'm sorry for posting these things here but due to time differences it's really hard for me to talk to you on IRC.


anyway, when using RSP: interpreter on some games Glide64 gives this error (but keeps working well) :

and because i'm a total idiot with no real input....

that color scheme is horrible!

:devil:
krhydaddy

icepir8
March 5th, 2002, 17:56
Originally posted by Dave2001
I'm not an expert on lighting math, so I'm having a little trouble figuring out what's wrong with my lighting calculations. Can someone download the sources and check the lighting code in 3dmath.cpp calclights() to see if it's correct? light_vector[l] is the direction towards the light, and v->vec is the normal. I think that the problem is that I need a min() or max() somewhere, but I'm not sure where. (see starfox intro to find real problem, something goes negative and it dies as you move the 64 to the left of the characters)

I think I found the mistake.

in rsp_uc00_movemem change:

rdp.light[i].dir_x = (float)(((BYTE*)gfx.RDRAM)[(a+8)^3]) / 255.0f;
rdp.light[i].dir_y = (float)(((BYTE*)gfx.RDRAM)[(a+9)^3]) / 255.0f;
rdp.light[i].dir_z = (float)(((BYTE*)gfx.RDRAM)[(a+10)^3]) / 255.0f;

to:

rdp.light[i].dir_x = (float)(((signed BYTE*)gfx.RDRAM)[(a+8)^3]) / 127.0f;
rdp.light[i].dir_y = (float)(((signed BYTE*)gfx.RDRAM)[(a+9)^3]) / 127.0f;
rdp.light[i].dir_z = (float)(((signed BYTE*)gfx.RDRAM)[(a+10)^3]) / 127.0f;

the light directions are signed byte values ranging from -127 to 127. This is the same mistake I made when I started doing the lighting.

Cya L8r,
Icepir8
:tr64: