N64 Glide Plugin

[Hacktarux]

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]

Mipmap problems

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]

grr, didn't attach

 

[Dave2001]

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]

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]

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!

 

[Dave2001]

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]

your referring to trwin i think, by niki waibel

 

[Dave2001]

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]

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]

tr64 5.666a is far different than niki's, just put niki in the credits, this is kind of confusing to talk abuot

 

[Dave2001]

Anyway, you guys don't need to worry about ucode autodetection, I've got it all planned out.
Thanks ZeZu!!!

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]

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]

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]

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``]

hmm.. ini eh? :>

/needs a voodooo card

 

[flow``]

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]

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]

dave can you look at my compatibility list? i posted it on your forum.
any chance you would put it on your site? (the finished list, that is)

 

[Dave2001]

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.

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