Menu
What's new
By:
Filters

N64 Glide Plugin

Status
Not open for further replies.
OP
Dave2001

Dave2001

Moderator
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)
 
OP
Dave2001

Dave2001

Moderator
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

Azimer

Emulator Developer
Moderator
Dave2001 said:
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?)
Click to expand...

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

Cyberman

Moderator
Moderator
Azimer said:


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.
Click to expand...

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

Hacktarux

Emulator Developer
Moderator
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

crhylove

Banned
it's threads like this why i read emutalk.

and stupid people like me why i don't sometimes... lol

wtg dave! congrats man, u r a brain.

:devil:
 
OP
Dave2001

Dave2001

Moderator
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 :)
 
OP
Dave2001

Dave2001

Moderator
Another note: if you exclude texrects using loadblock from being considered "loadblock", then that would fix the SF rush problem.
 
OP
Dave2001

Dave2001

Moderator
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
 
Azimer

Azimer

Emulator Developer
Moderator
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.
 
Cyberman

Cyberman

Moderator
Moderator
Dave2001 said:
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
Click to expand...

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

Azimer

Emulator Developer
Moderator
Classified by the uCode revision number found in the dmem data. Not a good autodetect method however.
 
Cyberman

Cyberman

Moderator
Moderator
Azimer said:
Classified by the uCode revision number found in the dmem data. Not a good autodetect method however.
Click to expand...
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
 
Status
Not open for further replies.

Top