gonetz / GLideN64

A new generation, open-source graphics plugin for N64 emulators.
Other
778 stars 180 forks source link

GLideN64 Texture Pack neglection #1906

Open theboy181 opened 6 years ago

theboy181 commented 6 years ago

@gonetz

I think that a few people who are willing to spend time making GLideN64 shine with "HD Texture Packs" might not be getting the support they need to keep them interested in spending their time to do so.

I hope that you can have a look at some of the issues, explain the technical challenges with the hack, and give some direction on it's future.

I stopped working on MK64 HD texture pack after I was challenged with textures getting NEW crcs while navigating the menus in that game. its too bad that there is not a work around :(

Can you please take a look at this YT video, and explain if any of these issues can be fixed for this user and his HD texture project? He has gone out of his way to make a very detailed video of his struggles.

https://www.youtube.com/watch?time_continue=381&v=_w2vIBfCFBM

I do hope that he is reporting bugs, and that they can be overcome.

Past submitted issues on texture packs:

https://github.com/gonetz/GLideN64/issues/1692

gonetz commented 6 years ago

I'm not an expert in HD texturing support. We need dedicated person such as Koolsmoky, who will take that task and solve issues with HD textures. I can just keep HD textures support on the same level as in Glide64. So, if your pack shines with Glide64, it should work well with GLideN64 too. I currently have no time to develop GLideNHQ module. And yes, I see no work around for MK64 menus.

oddMLan commented 6 years ago

How about adding wildcard support? https://es.dolphin-emu.org/blog/2018/09/01/dolphin-progress-report-august-2018/#50-8619-improve-custom-texture-wildcard-symbol-by-techjar Unless CRCs are completely different, then I guess it defeats its purpose...

gonetz commented 6 years ago

Look: https://github.com/gonetz/GLideN64/issues/1692#issuecomment-353677314 How can it be wildcarded?

kaSparta commented 6 years ago

I'm not an expert in HD texturing support. We need dedicated person such as Koolsmoky, who will take that task and solve issues with HD textures. I can just keep HD textures support on the same level as in Glide64. So, if your pack shines with Glide64, it should work well with GLideN64 too. I currently have no time to develop GLideNHQ module. And yes, I see no work around for MK64 menus.

Hey gonetz, I'm the one who made that video. First let me say that I think your plugin is by far the best for N64 emulation. I found out about GlideN64 on NeoGAF in 2013 and have been quietly following your blog ever since. It's taken awhile, but I think N64 emulation is finally starting to see a resurgence. This is in large part due to you which has inspired others like myself (and I imagine theboy181) to get involved as well. I know texture support probably isn't your main priority, nor should it be, but it's a reality that today people are doing amazing things with N64 whether it be mods or texture packs. Whatever the contribution is, I think we can all agree that we love N64 and want to bring new life to those great games. That to me is what the scene is all about and the people that are part of it wouldn't do it if that weren't the case.

So this is just one specific problem that I wanted to point out and make sure the right person is made aware of it. All theboy181 is trying to do is help me tell the right person. As far as the issue I'm having, it doesn't occur on Glide64. The other videos I posted on my YouTube page of F-Zero X are using the Glide64 Final Version plugin. I'd very much like it to work on GlideN64 though. If you look closely at the videos I posted using Glide64 you will see some graphics anomalies. These don't occur on GlideN64. I don't expect the issue to be fixed overnight, and I'm also trying to find a work around for this issue but I just wanted to reach out and see if there was anything that can be done. I'm also on the discord channel now and if you'd like, we could discuss it in further detail there.

Jj0YzL5nvJ commented 6 years ago

If what @gonetz described on https://github.com/gonetz/GLideN64/issues/1692#issuecomment-353264795 is correct. Then GLideN64 needs a parameter to change how xxHash is applied to certain parts of textures in problematic games.

gonetz commented 6 years ago

@kaSparta If you experienced problem with HD textures in GLideN64 and that problem does not occur with Glide64, I'm the best person to report about it. Note, that in that case best does not mean good. The best means that there is nobody better at this moment. I'd be glad to delegate GLideNHQ maintenance to somebody else. Please open new issue with description of the problem and attach to it all necessary data, which can help me to investigate it, such as link to texture pack, save state from the place where problem occurs, scenario to reproduce, screen shots etc. This github bug tracker is the main source of information about issues in GLideN64. I don't have time to read topics on forums or discord channel.

Nerrel commented 6 years ago

I just wanted to echo this request. I understand that time is limited and that priority has to be given to the basic functions of the plugin before optional enhancements, but there is at least one area of Majora's Mask that just can't be retextured ( #1885 ) and a few additional issues have caused me to consider switching over to Dolphin instead.

In addition to sorting out the issues being reported, I wanted to ask if it's possible to add an option to load textures as the game needs them (as Dolphin does) rather than loading them all at once. I'm only halfway through MM and it takes two minutes to load new textures in order to see what they look like in-game, and any adjustments take two minutes to view again. As the pack gets farther along, that wait will get longer and longer.

Having an option to load only the textures currently being used or to prefetch all custom textures at startup would make texture creation much less painful. A hotkey to toggle textures on and off would also make comparison screenshots much easier to capture as opposed to opening the graphics menu over and over.

Hopefully some time can be devoted to these issues soon. This is the best video plugin by far and I'd like to keep working on textures for it.

oddMLan commented 6 years ago

^ What this guy just said. His WIP texture pack is one of the best I've seen.

Just take a look: https://www.youtube.com/watch?v=rLVLXJhC5cs

kaSparta commented 6 years ago

@Nerrel - As far as only loading the textures that are needed in a specific part of the game, this is something that can be done on your end. Just create a separate folder for the game and rename the one that has all of the textures in it or move it out of your load directory. In the new folder, only place in it the textures you want loaded. I understand what a pain it is to have to wait for all those textures to load when you're making a texture pack, but it only affects the person making the texture pack while in the editing process. Once the pack is complete, the user should only have to wait for the new textures to be loaded once.

gonetz commented 6 years ago

I'll try to fix texture mapping issues.

I don't have time for texture dumping fixes. Since Rice Video dumps textures correctly, better use it for now.

It is possible to add an option to load textures as the game needs them, but again, I don't have time for that. So far, the best way to test changes in textures is to use some subset of texture pack, as kaSparta suggests.

A hotkey to toggle HD textures on and off is not hard to do. I'll add it.

Nerrel commented 6 years ago

Thanks for making some time for this. Using Rice for dumps when needed isn't a problem, but the texture loading is troublesome for a few reasons:

-A large texture pack can use up a huge amount of memory when loaded all at once, which can make it harder for users to run the game. My pack uses over 1GB with "compress texture cache" on and is only halfway done, the finished pack could easily use over 3GB of RAM. A 32-bit program like Project64 can't use this much memory without being patched. A lot of Android users have expressed interest in the pack and I have no idea if it's even possible to load this much on a mobile device.

-On my end, it's hard to remove folders to cut down on loading times without also removing textures that are currently in use. Majora's Mask constantly reuses textures from earlier areas, for example the mountain area has textures from Clock Town and the swamp, and it's important to load these textures to see how everything meshes together.

Again, I know that this isn't a priority, but if anyone can devote time to changing the way textures are loaded to be more like Dolphin I think it would be a big improvement for the plugin.

gonetz commented 6 years ago

"My pack uses over 1GB with "compress texture cache" on and is only halfway done, the finished pack could easily use over 3GB of RAM."

Serious argument. I still can't take this task right now, but I'll put it on top of my post-release todo list.