What's new
  • 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.

Possible new way to texture Mario Kart Characters with zip

CCTEX

New member
I've used some of the awesome textures packs on here for a while, and was inspired to take a stab at it for myself when I noticed the MK 64 characters had yet to be textured. I've never worked on anything like this before, so forgive me if any of this information is not completely accurate. As I quickly realized, there are a ton of textures dumped for the characters, with a high level of redundancy. Here is the process I developed yesterday, and it seems to be viable and fairly efficient:

1. Dump textures selectively during a time trial race while jumping onto hills to roll, spinning out by running into a tree, turning left and right all the way, braking, being picked up by Lakitu out of bounds, and winning the race.

2. Delete all textures in dump directory that do not contain the player or kart. (fairly quick with large thumbnails in Windows Explorer)

3. I then wrote a quick c++ program to process the remaining contents of the directory, which at this point still contains a lot of redundancy. Here is what the program does in case you wanted to do it manually:
-Deletes all but one png of groups that share the first 8 hex digits in the filenames, ie. the '00EA5375' in 'MARIOKART64#00EA5375#2#1#5862F1A9_ciByRGBA.png'.
-Once those duplicates are removed, the remaining filenames are truncated at the 3rd # sign, and '_all' is appended to the end of the filename before '.png', ie 'MARIOKART64#00EA5375#2#1_ALL.png'
-NOTE: This was pure intuition from analyzing the filenames of the amazing mario 64 texture pack, I don't know if it's proper.

4. The textures in the directory can now be batch upscaled or one could manually create new textures, as we are now dealing with a vastly smaller amount of files. (I quickly used the S-Spline Max upscaling algorithm as a proof of concept.)

5. Load the textures into your emulator (I use Project 64 2.2 w/ Glide), and voila, it seems to work.

Below is a comparison shot and a zip of upscaled yoshi proof of concept... try it out!

Enjoy, and let me know if this is something you'd like to work on with me/something you'd like me to continue pursuing.

Cheers!
File downloads.
Mariokart64 Characters 1.0

 

Attachments

  • cctex-comparison.jpg
    cctex-comparison.jpg
    58.6 KB · Views: 1,528
  • CCTEX-YOSHI.7z
    9.1 MB · Views: 526
Last edited by a moderator:

NES_player4LIFE

Texture Pack Invader
Moderator
This sounds great!
I was not able to load the test so I'll have to post with only the information available.

#2 Well editing unretextured files place your unused files into a folder named "unused dev junk" and place this folder into the load directory.
Doing this will eliminate some redundancy as Glide64 will not dump files that are loaded.

On note #3 the files that share the address are of the same position but supply movement.

I can give you access to my Mario'sKart!!! organized files if you would like.
I also have threads kicking around here somewhere that you can reference.
 
Last edited:
OP
CCTEX

CCTEX

New member
This sounds great!
I was not able to load the test so I'll have to post with only the information available.
You mean the dat wouldn't load? I can post the raw textures in another .7z if you like, let me know!

#2 Well editing unretextured files place your unused files into a folder named "unused dev junk" and place this folder into the load directory.
Doing this will eliminate some redundancy as Glide64 will not dump files that are loaded.
That is a great idea, don't know why I didn't think of that!

On note #3 the files that share the address are of the same position but supply movement.
Not sure what you mean here. After I run the program, I end up with a couple hundred textures only, and it works flawlesly in-game...

Thanks for posting your sorted Mario files, I'll look at it and see if it can further speed up this frankenstein process or not! :tup:
 

NES_player4LIFE

Texture Pack Invader
Moderator
Are you using the stock version of Glide64 or Glide64 finale?

;)
A devs gotta do what a devs gotta do.

If you delete three of the four files associated with a position I can't see how they would be edited to provide the desired outcome.
I would like a peek at your work if you could upload the files in question.
 
OP
CCTEX

CCTEX

New member
Are you using the stock version of Glide64 or Glide64 finale?
Glide64 for PJ64 2.0.0.5 (Project64 2.2)

If you delete three of the four files associated with a position
I can't see how they would be edited to provide the desired outcome.
Like I said before, I know nothing about re-texturing specifically as I've never done it. But my theory on why this works is that there is unnecessary specificity after the first 8 hex digits. By only keeping one of a set that share the same 8 hex digits and truncating the other hex digits, Glide64 uses that singular file for all cases where it would be required... but I could be wrong!

I would like a peek at your work if you could upload the files in question.
I ran my c++ program on your Mario directory you sent me, and then did the quick batch upscaling, screenshot is below.

Should I PM you the raw textures or just post it here? I'm not sure why the dat isn't loading... did you try PJ64 2.2?

If there's interest, I could post the program I made as well, perhaps it could prove useful for other games too?
 

Attachments

  • cctex-comparison-2.jpg
    cctex-comparison-2.jpg
    61.9 KB · Views: 1,770

NES_player4LIFE

Texture Pack Invader
Moderator
WOW!!!
That's freaking awesome!
Your tool may eliminate the need to retexture. Upscaling could be the new deal!
Please do upload your tool. Is it completely your code or open source from someone else?

If you wish you may post the modified files HERE
Lets keep this thread dedicated to your tool. Or you could make a new thread for the release.

I must have my plugin configured wrong.
Please explain where your .dat is located. Is it GFX/cache?
 
Last edited:

NES_player4LIFE

Texture Pack Invader
Moderator
I haven't had a chance to play around it was dinner time; pizza night, I'll get back to you. Right now I'm making a more fitting home for CCTEX Texture Parse v1.0b.
Here is your Release Thread.


Snipped from post for a more professional release thread.
  Spoiler:
I must have my plugin configured wrong.
Please explain where your .dat is located. Is it GFX/cache?
It is in %appdir%/Textures/Cache

WOW!!!
That's freaking awesome!
Your tool may eliminate the need to retexture. Upscaling could be the new deal!
Please do upload your tool. Is it completely your code or open source from someone else?
Awesome, hopefully I'm not mistaken and I'm actually onto something here :)! The code is completely mine. It is attached below as well as some screenshots.
 
Last edited:

microdev

Member
But my theory on why this works is that there is unnecessary specificity after the first 8 hex digits. By only keeping one of a set that share the same 8 hex digits and truncating the other hex digits, Glide64 uses that singular file for all cases where it would be required... but I could be wrong!
These first 8 hex digits are the CRC of the texture data. The second CRC is of the texture palette. If the texture changes the palette in memory, the dump function of the plugin mistakenly detects it as an undumped texture and redumps it with the now differing palette CRC. For such textures the filename should be identical besides the 2nd CRC code.
 

LyonHrt

Dcemu.co.uk guy
Very impressive work, if you want the files that i had started working on, i'll pm you a link, if they can help in any way then cool :)
 
OP
CCTEX

CCTEX

New member
Mario Texture Preview

Not sure what the deal is with the .dat... but so anyone who wants to can preview the development, here is a .7z of upscaled Mario textures, uncompressed. Load it up, it's a big difference :)
 

Attachments

  • CCMario_Upscaled.7z
    28.3 MB · Views: 224
OP
CCTEX

CCTEX

New member
Thanks, I can't wait to get all the characters done that way. I tried loaded up my mario textures on top of kerbers pack and it was much more fitting than the stock mario textures.
 

NES_player4LIFE

Texture Pack Invader
Moderator
I think that would be great. I have most of Luigi's files and have quite a few of Toad's also.

Animation of the tires no longer exists would you upscale the files I sent you without using CCTEX Texture Parse?
 
OP
CCTEX

CCTEX

New member
Interesting... I suspect that the tire animation is gone due to the detail loss from upscaling, not the parsing program, but I will find out! Btw, check out the new 2.0b on the release thread.
 

mendus

New member
Out of curiosity, is the s-spline magnification filter so much nicer than the built in filters like hq4x?
 

Top