N64 Glide Plugin Part 4
- Thread starter Slougi
- Start date
- Status
Reznor007: the reason jabo grabs it from the CFB is that you do not know before hand that is how the dlist is going ... If you just looked at the dlist you would have no idea what the textures where .. as this is the common method, but they are useally dmaed in to the memory from the rom, not created from a dlist. We had discussed ways of making use of the cfb in to the dlist .. some of the methods we disscussed did come in to jabos plugin. But it is not very nice methods they use for the PC hardware (at least going through drivers) where it is nice for the n64
CpU MasteR
omg h4x
eVoodoo XP
Ahhhhhhh. I hope This is Not Just me ???
Ahhhhhhh. I hope This is Not Just me ???
Ogy
3Dfx Fanatic.
Quackat0r said:Hehehe, I can't remember what the damn thing is supposed to look like anyway, so it doesn't bother me at allLike you said, it's not a game crippling problem or anything.
ok, i managed to get my CD64 fully working (
) and now a few notes:1. the banjo-kzooie start menu is just the background picture of the game (like zelda's strat menu)
2. Gukoss4 was right!!, the items in SSB (including the glowing shield) are simply turning to the wrong direction! in both jabo's and Glide64!
3. umm... Reznor007 what did you use to make that shot... i have a good (supposed to be good?) digital camera but the shots come out real bad.. ???
Reznor007
New member
I have a video input card on my computer. I run my N64 into it using Svideo, then process it using a freeware program called DScaler.
www.dscaler.com
Use the Greedy High Motion deinterlacer with 3:2pulldown and sharpness filter.
My video setup was calibrated using the THX optimode from the Toy Story DVD, since DScaler can digitally autocalibrate the color/brightness/etc. using that.
Also, about Banjo and Zelda, the pause screens are probably done that way to save processing time. Simply render that scene once, save it as a texture, and render the menu system with that texture as a background, rather than re-rendering the entire scene with the menu over it every frame.
www.dscaler.com
Use the Greedy High Motion deinterlacer with 3:2pulldown and sharpness filter.
My video setup was calibrated using the THX optimode from the Toy Story DVD, since DScaler can digitally autocalibrate the color/brightness/etc. using that.
Also, about Banjo and Zelda, the pause screens are probably done that way to save processing time. Simply render that scene once, save it as a texture, and render the menu system with that texture as a background, rather than re-rendering the entire scene with the menu over it every frame.
CpU MasteR
omg h4x
Re: eVoodoo XP
hehe, It was me. It fucked up the settings in eV00d00
CpU MasteR said:
hehe, It was me. It fucked up the settings in eV00d00
lightknight
New member
ha Dave2001! hows your work doing on zelda642 MOM??
your last screen shots of it looks very awsome!!! keep up the awsome work!! i think you r a awsome gfx coder!!!
i wish i chould make a gfx plugin , as good as yours some day...right now i am studying C , and C++........and am downloading mirosoft visual studio 6!
your last screen shots of it looks very awsome!!!
keep up the awsome work!! i think you r a awsome gfx coder!!!i wish i chould make a gfx plugin , as good as yours some day...right now i am studying C , and C++........and am downloading mirosoft visual studio 6!
euphoria
Emutalk Member
Dave, I got the impression that you wasn't really sure where those F3DEX. and SW 2.0x ucode names come from. I found out last night that they are in DMEM.
I call function PrintDMEMinfo() (in debug.c.txt) once per game in RDPProcessDList() and in the ucode data part are those ucode names and some other stuff. These are ripped off from the output:
mario64:
Zelda OOT:
in debug.c.txt is a working function for printing ucode, ucode data, and dlist to file dmem.txt, use it if you want. Probably you already know all of this, but in case you don't and for others who want to know i decided to post this stuff.
And finally a question: Is the data from address found in [0x04000fd0] loaded to the RSP or how does the ucodes work? is it like a GFX "BIOS" which is loaded for every dlist? I really doubt it is loaded every time a new dlist comes so there must be some flag that gets set if ucode is to be changed? Or am i totally lost here?
Code:
If you know the following you can directly start HLE out of it.
HLE: High Level Emulation - first hacked out by Epsilon and RealityMan. (Authors of UltraHLE.)
The DMEM is filled from 0x04000fc0 - 0x04000fff with the following:
0x04000fc0: task
0x00000001 ... Graphics Task
0x00000002 ... Audio Task
0x04000fc4: flags?
0x00000002 ... DP wait
0x04000fc8: bootcode
0x04000fcc: bootcode length
0x04000fd0: ucode
0x04000fd4: ucode length
0x04000fd8: ucode data
0x04000fdc: ucode data length
0x04000fe0: dram stack (for matrices)
0x04000fe4: dram stack length
0x04000fe8: ?
0x04000fec: ?
0x04000ff0: display list
0x04000ff4: display list length
0x04000ff8: ?
0x04000ffc: ?mario64:
Code:
RSP SW Version: 2.0D, 04-01-96 SGI U64 GFX SW TEAM: S Anderson, S Carr, H Cheng, K Luster, R Moore, N Pooley, A SrinivasanZelda OOT:
Code:
RSP Gfx ucode F3DZEX.NoN fifo 2.06H Yoshitaka Yasumoto 1998 Nintendo...
RSP Gfx[Safe] S2DEX fifo 2.05 Yoshitaka Yasumoto 1998 Nintendo...in debug.c.txt is a working function for printing ucode, ucode data, and dlist to file dmem.txt, use it if you want. Probably you already know all of this, but in case you don't and for others who want to know i decided to post this stuff.
And finally a question: Is the data from address found in [0x04000fd0] loaded to the RSP or how does the ucodes work? is it like a GFX "BIOS" which is loaded for every dlist? I really doubt it is loaded every time a new dlist comes so there must be some flag that gets set if ucode is to be changed? Or am i totally lost here?
How about this..Hacktarux said:
place in the 'hardware' that's emulated a hook that each time the uCode is changed a 'tag' is made for the DLIST that's being displayed. Perhaps switching the uCode once per DList is a good idea too. Unfortunately that would require a bit of work to read the DLIST do the HLE stuff and let it run not too mention the slow down.
(shrugs)
Cyb
Ah, one more question...
What do you (and everybody) think about this post?
http://www.emutalk.net/showthread.php?s=&threadid=4757
Why we might wait the Smiff release if Doomulation can post it today?
What do you (and everybody) think about this post?
http://www.emutalk.net/showthread.php?s=&threadid=4757
Why we might wait the Smiff release if Doomulation can post it today?
Dave2001
Moderator
I am currently in the middle of a very big task, rewriting the texture loading code to more closely emulate the n64's texture memory. This should 1) fix some of the texture errors i was having before and 2) load textures faster since now I am putting the loading loop in assembly and always reading 32-bit values instead of 4/8/16/32 bit ones.
so yes, I am still alive
so yes, I am still alive
- Status