Somebody must implementing the mirror part for hires textures in LoadTex of Glide64/TexCache.cpp to work correctly when the texture must also be clamped. Right now it sets GR_TEXTURECLAMP_MIRROR_EXT for this texture in TexCache... which is not really the expected result. But it should most likely mirror in software and then set GR_TEXTURECLAMP_CLAMP. At least this is what is done or this texture for the original lowres version
-
Most issues reported these days stem from users not enabling their emulators to use the required amount of RAM.
We also tend not to use the search feature but post our issues within the texture pack release page.
Failure to load a texture pack should not be posted in the release thread unless you have already patched the emulator.
If you don't have the resources to use Large/HD texture packs please do not attempt to do so.
Users should have a minimum amount of System RAM not less then 4GB's.
If you have less then 4GB's of RAM do not post about how your emulator crashes,
RAM is dirt cheap so invest some money into your PC.
I would like to say thanks to squall_leonhart
for posting this Solution. -
As members seem to have a problem reading the release threads:
Djipi's packs are built for the (Glide64 finale) Plugin. Nolonger supported!
Djipi's packs are built for the (GlideN64) Plugin.
These two Plugins are two completely different pieces of code.
GlideN64.HTC archived packs locked by Djipi are not compatible with use on Glide64, Rice video, nor Jabo video.
Glide64.DAT archived packs locked by Djipi are not compatible with use on GlideN64, Rice video, nor Jabo video.
Djipi has never made a pack for use with Rice video and never will. any packs found in this format are not authorized!
GlideN64 is the new standard and only requires an Radeon 6XXX.
This is a somewhat older GPU and should be readily available.
Do everyone a favor and upgrade!
Merry Xmas: OOT 2011 and MM 2001
- Thread starter Djipi
- Start date
Somebody must implementing the mirror part for hires textures in LoadTex of Glide64/TexCache.cpp to work correctly when the texture must also be clamped. Right now it sets GR_TEXTURECLAMP_MIRROR_EXT for this texture in TexCache... which is not really the expected result. But it should most likely mirror in software and then set GR_TEXTURECLAMP_CLAMP. At least this is what is done or this texture for the original lowres version
- Thread Starter
- #382
ok i see. can you send me by MP only the texture for the LOT?
I will rework to a new Update for the pack , increasing some texture ^^ so if people see problem , can you post here the texture problem and a screen? I will redone it and included it on the new update^^
I will rework to a new Update for the pack , increasing some texture ^^ so if people see problem , can you post here the texture problem and a screen? I will redone it and included it on the new update^^
Done
But the European version has lower fps, odd well, it's only a piece of the main menu that is messed up.go for europe version of majoras mask, us version wont load some text textures
If you did all this work already and it's only minor changes to work with NTSC (everyone else uses it, Asia, both Americas, basically anywhere that's not Europe (like the US with Fahrenheit) uses it, and on PC it allows both, why don't you make a few small patches for an NTSC version so it can get 20 fps instead of a lousy 16-17 fps. Pal had the higher screen resolution at the time, but now, it doesn't matter anymore. It already mostly works so it shouldn't be hard (and people redownloading will add to you adf.ly income) This video should clear up any confusion notice how pal is quite a bit slower as in wasted time. Japanese use NTSC, so that is the speed it was meant to be played at.
Why? Because the game divides TV hz by 3 to get framerate, due to N64 hardware limitations, it couldn't go to 25 fps pal (50/2) so they did (50/3) pal and got about 16.66 fps pal vs (60/3) NTSC which gets a consistent 20 fps. Nintendo is Japanese, Japanese use NTSC, so PAL support was merely an afterthought, and it's not the way it was meant to be played.
Note: US version is slightly behind JP because it had a longer loading time, however, PAL is actually slow motion.
Why? Because the game divides TV hz by 3 to get framerate, due to N64 hardware limitations, it couldn't go to 25 fps pal (50/2) so they did (50/3) pal and got about 16.66 fps pal vs (60/3) NTSC which gets a consistent 20 fps. Nintendo is Japanese, Japanese use NTSC, so PAL support was merely an afterthought, and it's not the way it was meant to be played.
Note: US version is slightly behind JP because it had a longer loading time, however, PAL is actually slow motion.
Last edited:
I tried for hours 
to get the European version converted to NTSC, or anything else that will make Zelda run at its proper frame rate, but the only solution is to use the native NTSC version. Please make an NTSC version, it's so close to complete with the PAL version, it should only take a few minutes.
to get the European version converted to NTSC, or anything else that will make Zelda run at its proper frame rate, but the only solution is to use the native NTSC version. Please make an NTSC version, it's so close to complete with the PAL version, it should only take a few minutes.
Last edited:
NTSC is not another game, most textures already work, it only requires minor changes to a few textures that had their filenames changed in the European translation process. What's the point of playing 16 fps on a 60 hz monitor/TV instead of 20 fps. Also, playing at 16.666 fps on a 60 hz monitor also introduces jumpy video, which makes it seem like your computer is lagging out the game, which to me is unbearable. I wouldn't mind if the game went from 60-50 fps, but at low 20 fps already, every fps is precious. Why patch a technically inferior version (I'm NOT saying Europe itself is interior, just their version of the game). It's not like someone is going to run this texture park on a real n64 hooked up to a PAL 480p CRT TV.
Last edited:
It also only requires minor changes to fix lens of truth- after all, they work in OOT. The lens of truth have been a problem for years and they make it actually impossible to complete the game. All I'm saying is that we have a clear priority here: fixing the lens of truth should come first.
Fix lens of truth with NTSC fix, since it will kill 2 birds with one stone.
And save files go across versions, so no need to fix PAL version.
Well, except the PAL version has more languages I think, but that's the only reason to use PAL, and if he doesn't re texture every language, what's the point.
Also, wouldn't you like to make copyright 1999-2015, that would be cool.
And save files go across versions, so no need to fix PAL version.
Well, except the PAL version has more languages I think, but that's the only reason to use PAL, and if he doesn't re texture every language, what's the point.
Also, wouldn't you like to make copyright 1999-2015, that would be cool.
Last edited:
http://www.emutalk.net/showthread.php?t=55421 this guy seems to be making the NTSC version even more superior.
Looks like digipi is making his new texture pack with NTSC in mind.
Looks like digipi is making his new texture pack with NTSC in mind.
Last edited:
Why should it be supported? Your Firefox also has no support for your Chrome browser cache format. Why should it? This glide64 .dat is a cache which has to be created from the actual textures. It is like the browser cache which has to be generated from the actual websites. This means: not by the website owner but by the users (actually their browsers) of this website.
Gonetz already spoke against the interpretation that it is DRM. He was also against the distribution of the cache because it is only an optimization for the texture loading algorithm but depends heavily on the user settings. Now we can even see that it also depends on the plugin version.
It was already shown that the texture cache files are not exchangeable between Glide64<->GLideN64 but can be extracted with minimal effort. These extracted files can then be used on Rice, Glide64, GLideN64, ...