Emulator

GREAT Idea.
A real step forward if it finds it way into both plugins.

I don't think this would be the hardest thing in the world to do

How better looking can the GC graphics get. I can see the N64 games needing this but
GC games already look great.

All games can look better if you tweak the textures, just look at some actual games
and the available high res texture packs, eg. Resident Evil 4 for PC.
It would be great to use this pack on the best console version, too.

Okay what is the deal here, I posted two problems I found and all you guys could do
to thank me is to slap me in the face and delete them. I posted about the RE0
graphics and the Wii controller and now both of those topics are gone. If you guys
are unwilling to listen to others just close this down and only let devs post here.

I see many other stupid threads here that are not deleted but for some reason the
only two I ever posted you guys got rid of very quickly. It's kinda lame, leave
peoples posts alone or do not allow us to post here.

tommy...@hotlmail.com, you probably should open all issues before you moan about
your missing issues. The WII controller has an invalid status, because it isn't
possible atm to emulate it, because the hardware isn't documented enough - like I
told you yesterday.
The RE0 one is a GameIssues and only if a Game Issue affects other games or has a
special reson which is known, it stays in teh Issues list. A lot issues aren't
checked yet, you should just look out how many of them still have the status new.
The devs have a real live, you know.
So please, calm down and thanks for the help, but these two issues aren't really
important. And stop spam other issues. /me aswell

Yeah. In case you missed it, see that drop box at the top, that says "Open Issues"?
Click on it and choose all. As MasterPhW says, we just moved them away for now.

Not sure if this will be helpful, but I've made a very basic custom texture loader to
the OpenGL plugin. It only takes TGA files and the feature itself is not optimized at
all (no caching; tries to load a custom texture whenever it loads a new texture), but
it works.

It only works for textures the same size of the ones they're replacing. Otherwise, it
get corrupted.

Nice baby.lueshi

I may try and improve it :)

Ok added some gui checks for it :)
So it will only work when load hires textures is turned on.

I'll do some more work as soon as i can :P

I have a few ideas on how to improve stuff with dumping :P

Added a file exists check so it checks that a dumped texture does not allready exists
before it dumps it :)

Here is a patch file with the original and my edits :)

nice feature, but remember we're talking about textures of the SAME size, so it's not
really high res textures :p

:P
I'll see if i can find out a way to allow it to increase the size :P

I believe I finally got the scaling down correctly with this patch.

However, even with that out of the way, we still have to decide on an image library
to use for loading textures before I feel it's worth committing. We should at least
be able to load PNG, JPEG, and probably BMP files for custom textures, not just TGA
files.

any chances to correct use alpha-channels on ANY custom textures (very useful for
modding)?
in Texture Dump Patch1, alpha's dont working, if original texture dont use it (

Once someone adds .png or .dds support, it should be trivial, since these formats
support alpha.

If you save the custom texture as a 32-bit TGA file, it should load alpha channels
that way.

At least it does so in my latest patch.

I don't think support for jpeg is a good idea :P
Most people would use PNG or BMP so only have support for them.

Testing last patch in Soul Calibur 2. Alpha channels on costumes still not working.

Try to find a texture that was dumped that looks like an silhouette of the one you're
changing and make that texture completely transparent and see if it fixes it.

I made it.Full transparent silhouette works, but does not fix the transparency of
the costumes.

This patch uses SOIL for loading images and implements a very simple cache to
minimize disk I/O.

Since I don't have Soul Calibur 2, so I can't test zagzag's exact problem.

The patch looks very good :P
I'll add it as soon as i can.

Just one thing to add: You should also add the directory Data/User/Load/Textures, so
the compile script adds the correct folders. I don't know how to add an empty
directory with a patch file though, and TourtiseSVN doesn't seem to know either, so
it was left out.

Ok I'll see if i can add anything then I'll submit it into the svn if you want !

If you could just text a couple of textures in some different formats (PNG/BMP, with
and without alpha) and the recursive directory feature, that would be great. Feel
free to commit it if you don't run into any bugs.

Looks like your commit accidentally added some header lines multiple times and is
breaking the build.

Thanks fixed it

Well, this patch wasn't committed as smoothly as I wanted to...

Here's the missing file if somebody wants to fix it before death2droid gets back on.
(Source/Core/VideoCommon/Src/HiresTextures.h)

thanks

I can't believe i made so much stupid mistakes :(

See my first commit: r2551
You're not alone :)

Hi, guys. I've found load hi res textures option in some revision. I dumped textere,
edited it. And it doesn't work. What I'm doing wrong? Should there be a special
folder for custom textures or somethig else. Thanks

Right now, they should be placed in User/Load/Textures, and you can organize them by
subfolder in there.

Wow! It works! Thanks alot! You made my day :)

Anyone feel like writing an article for the wiki that we can point people to, that
explains how it works?

I might do it since i have nothing better to do :P

Your patches to move SOIL over to an external library missed some configurations for
64-bit builds.

Ahh cool thanks baby.lueshi i completely forgot about x64

just a thought, but do we really need another folder for loading the textures ? can't
we load them from the dump folder ?

anyway, it's a good feature, i already like it
(http://forums.ngemu.com/dolphin-discussion/122029-about-hi-res-texture-loader.html#post1648540
:p)
good job baby lueshi :)

The separate folder was added for distinguishing custom textures from ones that were
just dumped. Loading textures from files is slower than loading them from the game
itself, and loading unedited textures from the dump folder would just slow things down.

Looking over the patch, I just now realized that is creates the filename hash from
the PC-formatted texture data, not the data on the game disk. While it won't cause
many problems now, keeping it like this will only cause problems in the future if we
keep it like this.

This patch uses the same technique the Safe texture cache uses to create the hash,
which should be safe.

Updated patch to work with r3187.

Well, it still chokes on funky textures (like text in MP), but it fixes the errors
caused earlier.

Thanks baby.lueshi

Ok I've being working on trying to make SOIL save textures.
It's proving a lot harder then i thought.

Here's a small patch to get intensity textures and homebrew textures working. Still
can't find any leads on why some textures can't be scaled.

patch?

Sorry, forgot to attach it.

A quick look at your problem saving textures using SOIL:

It turns out SOIL can only save textures in Targa, Bitmap, or DirectDraw Surface
files without any compression, and I'm guessing we want to save the textures as PNG.
We either have to:
A) Switch the image library used for loading textures to one that also supports
saving textures in PNG files. (SFML_Graphics might be a good choice; it uses a
combination of SOIL for loading images and SOIL/libpng/libjpeg for saving images.)
B) Keep SOIL and just use a different library for saving textures.
C) Just use what we have. (Probably Bitmap files for compatibility.)

Whoops, forget using Bitmaps to export textures. They don't support alpha channels
which we need.

jpg and bmp are a big no no for hires textures.

Oh yeah a good thing to add to dumping is to make it dump into a folder with the same
name.
Should probably also do the same with loading

I'm assuming by same name you mean the name of the game? That might make dumping
textures easier.

I've tried to add libpng as an external library so we can save textures as PNGs, but
wxWidgets seems to have it's own copy of libpng and the two run into problems when
trying to compile. If somebody else with more experience with Visual Studio wants to
try and give this a shot, please do.

Yeah i do mean by the name of the game :P

Ok almost finished the dumping modifications!

Could you post a patch here before committing them? I just want to make sure things
go a little more smoothly this time ;)

Ok sure XD
I've only done the texture dumping modifications.
It should run fine as i did test it!

I don't really understand what you're using bCheckedDir for in this: If you're
meaning for it to be a static variable, you have to declare it as such, and it can
have unpredictable results if you don't assign it a default value.

Your patch also uses Windows-only functions, which isn't gonna work. I'm positive
there's some functions in Common somewhere which should do the job for making
directories.

I read somewhere mkdir works with linux.
The checking stuff probably doesn't.

Look under Source/Core/Common/Src/FileUtil.h, those should be the functions you
should be using.

my suggestion: look at other code, like the video dumping and the texture dumping.

Ahh never noticed that it had functions for directory's :P
Ok I'll fix it up now.

Also just noticed a few more things i need to fix up like the bool needs to be reset
to false when the dumpTextures is turned off.

I wanted you to post a patch of every update to it before committing, not just the
first one. :(

The loading function shouldn't have been touched; it's already set up so the user can
organize it however they want, and your commit changed it for no real reason. I
thought you were just talking about separate directories for dumping textures. Also,
your method for detecting the directory was flawed.

Seperate directories for loading is quite required otherwise it's going to result in
a slowdown when you have many texture packs.

That was the reason for implementing the cache of textures to use, so it only goes
over the directories once. Even with thousands of custom textures, it should take
only moments to check the files for correct names.

Go have a look at all the Nintendo64 plugins!
Glide64 and Rice Video they use separate folders for the hires textures.

The way I had it set up was so people could do it like that or not, but if you really
think it should be in there, be sure to use the game code instead of the name, and
try to account for homebrew stuff, which don't have gamecodes.

Hmm ok maybe check if the folder exists if it doesn't check any?

That will only cause confusion if people mix-and-match them. Do it one way or the other.

Ok sure.

Issue 1015 has been merged into this issue.

so isn't this issue already over and done with? (as soon as someone makes a guide or
a great GUI for it)

I was going to say the same thing. It should be easy to add an option to
enable/disable Hi-res textures for each game individually in the Game's properties.

But I guess this could be closed. I say it should be.

So what exactly did you want done???

Is this finished?

@death2droid :
Maybe not really. High-res texture pack need be for D3D plugin too.

is it done if so I wanna start making some textures. I could make melee look like brawl

@masterkillua123
I'm owkring on the D3D plugin part right not.
@somlibs It is practically finished now.

*working

load hires-textures doesn't work if you Load a save state.

ok D: ...
Ps : I don't think that is fixed, becouse u can't load textures with D3D plugin...
(D3D plugin only read .png textures or .tga?)