Achilles1515
Smash Master
Oh. I thought you were talking about CMPRs and searching for them the way Steelia mentioned.
Last edited:
-
Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!
You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!
Official DAT Texture Wizard (current version: 6.1.4)
- Thread starter DRGN
- Start date
CeLL
Smash Lord
Oh I forgot. Function to compare paletted textures. I originally wrote it including palettes, which is why the parameter is there, even though as far as I know it doesn't work whatsoever for palettes. In all the places it's called in my program I put None for palette because I didn't want to have to change a bunch of stuff lol. If you don't specify an "original" parameter, it returns a list that sort of matches pixels, like I explained above. If you put one of these lists in as the "original" parameter, it will return a Boolean for whether it matches that of the image data you put in.
According to that page on TPLs, _8's have 4 bits per pixel, which would make me think this wouldn't find them, since it does 8 bit chunks. But it seems to so idk. I haven't tried it on _a's.
I'm sure there are a lot more efficient/more accurate/faster ways of doing it, but this works, at least afaik. To be honest I didn't think it would when I had the idea, but tried it anyway.
The image parameter is supposed to be a bytes object (or byetarray? Idk the difference), like what you get when you read from a file in rb mode.
Python 3.3.5 btw
According to that page on TPLs, _8's have 4 bits per pixel, which would make me think this wouldn't find them, since it does 8 bit chunks. But it seems to so idk. I haven't tried it on _a's.
I'm sure there are a lot more efficient/more accurate/faster ways of doing it, but this works, at least afaik. To be honest I didn't think it would when I had the idea, but tried it anyway.
The image parameter is supposed to be a bytes object (or byetarray? Idk the difference), like what you get when you read from a file in rb mode.
Code:
def check(palette, image, original = None) :
if not original :
complete = OrderedDict()
if palette :
for byte in palette :
if byte not in complete :
locations = []
i = 0
while i < len(palette) :
if palette[i] == byte :
locations.append(i)
i += 1
complete[byte] = locations
paletteCheck = list(complete.values())
complete.clear()
else :
paletteCheck = None
if image :
counter = 0
for byte in image :
if byte not in complete :
locations = []
i = 0
while i < len(image) :
if image[i] == byte :
locations.append(i)
i += 1
complete[byte] = locations
counter += 1
imageCheck = list(complete.values())
else :
imageCheck = None
return paletteCheck, imageCheck
else :
complete = OrderedDict()
if image :
i = 0
for byte in image :
if byte not in complete :
complete[byte] = [i]
else :
complete[byte].append(i)
if complete[byte] != original[1][list(complete.keys()).index(byte)][:len(complete[byte])] :
return False
i += 1
imageCheck = list(complete.values())
return imageCheck == original[1]
Last edited:
Slick function, man. Nice work.
I plan to implement something that does this sort of thing in the future for DTW 3.0. I'll let you know if I use this.
BTW, do you want me to include your program in the op? I'll link to your post though so you can update the program at any time. Also I linked to it in my guide.
CeLL
Smash Lord
Yeah you can link it if you want. Though personally I think that things like this work better all included in one program, like if DTW had a button that let you find textures. In fact I hope that at some point we can just "open" a DAT and see all the textures in it, like Melee Toolkit, which would make this entirely pointless lol
That's what I'm planning.
Though that wouldn't make the functionality you have useless. It would be awesome to be able to browse a whole dat, but that would be tedious if there's a specific texture someone wants to find. Especially if they don't know what file it's in. So something that can browse as well as search would be ideal. This and more is what I hope to pack into DTW 3.0. However, I'm also rewriting parts of it so I can go from Python 3.4 to 2.7, which has better support for some interface features I want to use.
CeLL
Smash Lord
True, but with this hypothetical "MeleeBox" it would be possible to check just the actual images, instead of 1000's of pointers (including many, many repeats [which I guess I shouldn't check in my program lol, forgot about that])That's what I'm planning.
Out of curiosity, what is it that 3.4 doesn't support as well?
Yeah. The scenario I'm thinking about is if you dumped the texture you wanted to edit from Dolphin for example, and then loaded it into the program. Having a search function to then track it down would probably be a lot easier & faster than looking through all the dats (even if they are already images). It would still have to follow those pointers to pull up the images in the first place, but because that part of the process, as well as getting rid of redundant pointer trails, would happen separately from the search, then the texture matching itself would go quicker at least (is speed why you were saying that?).
The two main things are tkDND, which I really wanted to add, and something in PIL (I read about the PIL issues like a month ago so I don't remember what it was specifically, but decided it would be better to get more into it with 2.7). Another thing is, I think there was something I ran into with tkinter's geometry manager that was giving me trouble before, and that was why I don't have DTW resizeable by the mouse, so that's something I'm hoping will go better in Python 2.7. I also actually really don't like the default file chooser available via tkDialog's askopenfilename. And I found this article a while back, which shows a different file choosing dialog box if you scroll down a bit. If you scroll down and look at this image, that's what I wanted. It's just way better and more convenient to use over-all. That's not what you get at all with Python 3+, so I figured it must be with 2.x. (Since the versions are so different and there are other things I've found to support 2.7 more, I wouldn't have been surprised.) Unfortunately, after setting everything up for 2.7, the dialog box is still the same. I don't know how the heck that article got that dialog box.
Anyway, I've at least got tkDND working with 2.7, which is pretty cool and has already made it worth it.
CeLL
Smash Lord
I mean like since it would be able to display the image, it would likely have a full understanding of the format, and would be able to compare two images in a much more efficient way, in addition to already having checked every pointer.
Hyped for dragging and dropping.
Edit: I took out all the duplicate pointers and it is slower lol. Idk maybe Python is bad at that.
Last edited:
Oh, I see.
You mean programmatically took them out? Earlier this week while looking for a way to add to a file without adding duplicates, I came across this article, which talks about using sets for comparisons. Sets are like lists or dicts, but simpler (they're non-indexed and don't preserve order), and are much faster for use in checking if something is in a group of something else.
CeLL
Smash Lord
By removing duplicates I mean I took my list of pointers in the relocation table and followed each of them until I found a pointer not in the relocation table, as the program already does, though in a different place, and then took that list and made it into a set (removes duplicates).
CeLL
Smash Lord
@
DRGN
I'm sure I'm being dumb but for some reason I can't make an image with transparency with PIL. I tried creating a new image in RGBA mode but it just ignores the alpha value for each pixel. Any help?
The reason is that I've made a function to convert CI4's to PNGs in Python, which lets me display them in the program. But it's ignoring the alpha channel. Converting the others should be simple now that I understand how it works.
DRGN
I'm sure I'm being dumb but for some reason I can't make an image with transparency with PIL. I tried creating a new image in RGBA mode but it just ignores the alpha value for each pixel. Any help?The reason is that I've made a function to convert CI4's to PNGs in Python, which lets me display them in the program. But it's ignoring the alpha channel. Converting the others should be simple now that I understand how it works.
I haven't gotten to that point with PIL yet, since I stopped to port everything to 2.7, as well as to design a brand new interface to include a lot more features, including displaying images in the program. You might be running into an issue with how the transparency is stored. If the PNG has a palette (as Cl4s do), then it won't have a standard full alpha channel. Instead it'll basically have two indexed palettes, one for the colors (in the PLTE chunk), and one for transparency (in the tRNS chunk). The tRNS chunk is what's called an ancillary chunk, which means it's not critical to decode to still display the image and is technically less supported (although most decent decoders should still be able to read it). But it's not what's usually used for full PNG transparency. In fact, such configurations aren't very common, and you can't even export an image from GIMP that has both a palette and transparency (probably not in Photoshop either). Maybe PIL has a problem with that chunk? If so, you could convert it without preserving the palette since you don't need it anyway just to display it. You can read about PNG chunks and reading PNG files from their specs here. Particularly useful is the Image Type byte in the image header, which you can use to quickly get what kind of PNG it is (grayscale/full-color/uses-palette/transparency/other-combinations), especially if you also scan for either a PLTE or tRNS chunk.@
The reason is that I've made a function to convert CI4's to PNGs in Python, which lets me display them in the program. But it's ignoring the alpha channel. Converting the others should be simple now that I understand how it works.
The PNG I have in DTW is displayed using tkinter's PhotoImage. Basically I just gave it the file path. I can go into more detail with that if you want, but I'm guessing you want it as a data stream so you don't need to create a file. If so, you might try this function which I already wrote into DTW specifically for generating C14s and other TPLs as PNGs so they can be played with by PIL and then displayed in the program:
Code:
def getImageAsPNG(filepath):
filename = path.split(filepath)[1]
fileFormat = filename[-4:].lower()
with open(filepath , 'rb') as binaryFile:
if fileFormat == '.tpl':
## Get image attributes.
binaryFile.seek(4)
status = 'formatSupported'
## fileByteObj = binaryFile.read()
elif fileFormat == '.png':
## Get image attributes.
binaryFile.seek(16)
width = toInt(binaryFile.read(4))
height = toInt(binaryFile.read(4))
bitDepth = toInt(binaryFile.read(1))
colorType = toInt(binaryFile.read(1))
## Get the image data.
binaryFile.seek(0)
imageBinary = toStr(binaryFile.read())
status = 'dataObtained'
else:
imageBinary = ''
status = 'formatUnsupported' ## Not a PNG or TPL.
## File is closed for reading.
if status != 'formatUnsupported' and fileFormat == '.tpl':
## Convert the image to PNG format.
try:
outputStream = toStr(subprocess.check_output(wimgtPath + ' copy "' + filepath + '" - -x .png', stderr=subprocess.STDOUT, creationflags=0x08000000))
startOfData = outputStream.find('89504e470d0a1a0a') ## 16 char PNG file ID.
imageBinary = outputStream[startOfData - 16:]
status = 'dataObtained'
except subprocess.CalledProcessError as error:
imageBinary = error.output
exitcode = str(error.returncode)
status = 'conversionError: ' + exitcode
return (status, unhexlify(imageBinary))
Last edited:
CeLL
Smash Lord
Sorry, what I meant by converting a CI4 to a PNG was actually reading the image from a TPL with a CI4 and creating an image object out of the pixels with the Image module in PIL, with which I could then save that image as a PNG, no need for wimgt. It was actually working fine, btw, it's just image.show() that was messing up lol. Haven't started PNG to CI4. I believe PIL can take a full RGBA image and index it for you, though, so it shouldn't be that hard.
The ramification of this is that if I can figure out which pointers in the relocation table of a DAT point to images, it would be fairly simple to display all the images in a DAT with previews and the ability to import/export them as PNGs. Like Melee Toolkit does for some images.
And if I understand correctly, game.toc gives the locations and names of all files in the iso, so theoretically it wouldn't be TOO hard from here to "complete" Melee Toolkit, i.e. a program that can open ALL the DATs and display ALL their images.
[Hype intensifies]
[collapse="Mandatory Pun"]
Sorry I just found this lol[/collapse]
Last edited:
Oh, so do you even have to parse or change the format, or is it already known by PIL?
Yep! That's what I've been thinking! XD We're definitely on the same page here, haha. The main thing for figuring out the RT atm is figuring out where (or the pattern for how) an entry is branched between image and palette. They have to be linked in some way, so I figure there's either a pattern in the RT itself, or there might be headers that contain pointers to both data sets. I haven't looked into it recently since I've been working on the interface in the spare time I can scrounge.Sorry, what I meant by converting a CI4 to a PNG was actually reading the image from a TPL with a CI4 and creating an image object out of the pixels with the Image module in PIL, with which I could then save that image as a PNG, no need for wimgt. It was actually working fine, btw, it's just image.show() that was messing up lol. Haven't started PNG to CI4. I believe PIL can take a full RGBA image and index it for you, though, so it shouldn't be that hard.
The ramification of this is that if I can figure out which pointers in the relocation table of a DAT point to images, it would be fairly simple to display all the images in a DAT with previews and the ability to import/export them as PNGs. Like Melee Toolkit does for some images.
And if I understand correctly, game.toc gives the locations and names of all files in the iso, so theoretically it wouldn't be TOO hard from here to "complete" Melee Toolkit, i.e. a program that can open ALL the DATs and display ALL their images.
[Hype intensifies]
[collapse="Mandatory Pun"]
Sorry I just found this lol[/collapse]
CeLL
Smash Lord
This is what I did. It works fine for little images but for larger ones the blocks are put in the wrong order, scrambling the image... I don't know how to fix that.
Just call whatever = CI4.fromTpl(filepath) and it returns a CI4 object. whatever.image is then the Image object that goes with it.
If you want to display it in Tkinter you have to use ImageTk.PhotoImage(whatever.image), from the ImageTk module in PIL.
Code:
from PIL import Image
def byteToHex(byte) :
return int.from_bytes(byte, byteorder='big')
class CI4 :
def __init__(self, image) :
self.image = image
def fromTpl(tpl) :
with open(tpl, "rb") as file :
file.seek(0x1c)
paletteStart = byteToHex(file.read(4))
file.seek(0xc)
paletteEnd = byteToHex(file.read(4))
paletteLength = paletteEnd - paletteStart
file.seek(paletteEnd)
width = byteToHex(file.read(2))
height = byteToHex(file.read(2))
file.seek(paletteStart)
palette = file.read(paletteLength)
file.seek(paletteEnd + 8)
imageStart = byteToHex(file.read(4))
file.seek(imageStart)
imageData = file.read()
return CI4.build(imageData, palette, width, height)
def build(imageData, palette, width, height) :
colors = []
for i in range(0, len(palette), 2) :
colors.append(rgbyToRgb(byteToHex(palette[i:i+2])))
blocks = []
block = []
for i in range(len(imageData)) :
byte = hex(imageData[i])[2:]
if len(byte) == 1 :
byte = "0" + byte
block.append(colors[int(byte[0], 16)])
block.append(colors[int(byte[1], 16)])
if len(block) == 64 :
blocks.append(block)
block = []
imageBlocks = []
for block in blocks :
new = Image.new("RGBA", (8, 8))
new.putdata(block)
imageBlocks.append(new)
image = Image.new("RGBA", (height, width))
i = 0
for row in range(0, width, 8) :
for column in range(0, height, 8) :
image.paste(imageBlocks[i], (column, row))
i += 1
return CI4(image)If you want to display it in Tkinter you have to use ImageTk.PhotoImage(whatever.image), from the ImageTk module in PIL.
Last edited:
Cool. Nice clean code too. Strange about the sometimes-scrambling. How large of an image does it work for?
CeLL
Smash Lord
Fixed it, edited my post.
Do I have the height and width from the TPL backwards?
The problem with transparency is my function for converting the colors in the palette to RGB. I really have no clue how the color format works my function just grabs the red/blue/green values like in Achilles' post and then uses the first bit as either 255 alpha (1) or 0 alpha (0). If this is fixed, it will work quite well. Steelia's post talks about a different type of palette for transparent and non-transparent, I bet that's relevant.
Fixed and I'm a silly goose.
Last edited:
CeLL
Smash Lord
In the mean time, here's the slightly modified version for CI8s.
Code:
class CI8 :
def __init__(self, image) :
self.image = image
def fromTpl(tpl) :
with open(tpl, "rb") as file :
file.seek(0x1c)
paletteStart = byteToHex(file.read(4))
file.seek(0xc)
paletteEnd = byteToHex(file.read(4))
paletteLength = paletteEnd - paletteStart
file.seek(paletteEnd)
width = byteToHex(file.read(2))
height = byteToHex(file.read(2))
file.seek(paletteStart)
palette = file.read(paletteLength)
file.seek(paletteEnd + 8)
imageStart = byteToHex(file.read(4))
file.seek(imageStart)
imageData = file.read()
return CI8.build(imageData, palette, width, height)
def build(imageData, palette, width, height) :
colors = []
for i in range(0, len(palette), 2) :
colors.append(rgbyToRgb(byteToHex(palette[i:i+2])))
blocks = []
block = []
for i in range(len(imageData)) :
byte = imageData[i]
block.append(colors[byte])
if len(block) == 32 :
blocks.append(block)
block = []
imageBlocks = []
for block in blocks :
new = Image.new("RGBA", (8, 4))
new.putdata(block)
imageBlocks.append(new)
image = Image.new("RGBA", (height, width))
i = 0
for row in range(0, width, 4) :
for column in range(0, height, 8) :
image.paste(imageBlocks[i], (column, row))
i += 1
return CI8(image)CeLL
Smash Lord
Hmm. That would make sense if brawl uses TPLs. Do you know what language it's written in? I remember a while back I found some source code for some imaging functions, but I can't remember if it was part of one of the brawl programs. Perhaps we should look into it more.
I still have the wimgt fallback though, even if it is less efficient. I could always replace it later if we find/write a good new set of functions.
What I'm currently stuck on is reading dat files. It's such a pain that they're inexplicably different from one another. I really don't want to rely on an offset database. I'll probably post more details soon in case anyone else can help find some reliable patterns.
Edit:
I still have the wimgt fallback though, even if it is less efficient. I could always replace it later if we find/write a good new set of functions.
What I'm currently stuck on is reading dat files. It's such a pain that they're inexplicably different from one another. I really don't want to rely on an offset database. I'll probably post more details soon in case anyone else can help find some reliable patterns.
Edit:
Depends on whether you're pulling data from a dat file or tpl file. In dat files, the width comes first, but in tpl files, it's the other way around for some reason. Guessing probably already figured this out by now though.
Last edited:
A small update:
To DTW:
Version 2.2:
I could've prepared this weeks ago actually, but I've just been so busy with other stuff I haven't stopped to post much.
I've been well underway on building DAT Texture Wizard 3.0, which is a complete redesign on the GUI and the concepts of working with textures, with a lot more features that will make texture hacking much easier than even DTW 2.x. So this should be the last update to v2.x, unless you guys find any bugs.
@
CeLL
, I finally found some functions for converting TPL formats (not sure if they're they same I had found before; wish I had bookmarked those). They're built into LibWiiSharp. Obviously we'd have to rewrite them into Python. And granted, we already have everything we would need on the MK wiki on their formatting to build some functions from scratch anyway, but these could probably still help speed things up. I wanted to share in case you still want to create converter functions for each image type. For now I'm going to continue with wimgt so I can get something working released much quicker. But I may create my own converters if you don't make some and then switch to using those later, since it would be so much more efficient.
I also found wimgt's source code and BrawlBox's source. I didn't see any functions for tpl conversions in with BrawlBox's source, but maybe I just missed them because I might not have checked every folder.
To DTW:
Version 2.2:
- Added a "Placements files" folder for auto-loading Placements files & offsets
- Button to automatically create a placements file based on what's currently given to the program
- Warnings and other help/notice messages now clear upon selecting new files.
- Added a more specific warning if a file is missing its image type
- Added red line highlighting in cases where an image has the wrong formatting
- "Scan folder structure" will now work with folder names that contain only numbers
- Small updates to the user guide
- Pro-tips always show (originally intentionally only showed when you didn't load files via drag-and-drop)
- Button to automatically create a placements file based on what's currently given to the program
- Warnings and other help/notice messages now clear upon selecting new files.
- Added a more specific warning if a file is missing its image type
- Added red line highlighting in cases where an image has the wrong formatting
- "Scan folder structure" will now work with folder names that contain only numbers
- Small updates to the user guide
- Pro-tips always show (originally intentionally only showed when you didn't load files via drag-and-drop)
I could've prepared this weeks ago actually, but I've just been so busy with other stuff I haven't stopped to post much.
I've been well underway on building DAT Texture Wizard 3.0, which is a complete redesign on the GUI and the concepts of working with textures, with a lot more features that will make texture hacking much easier than even DTW 2.x. So this should be the last update to v2.x, unless you guys find any bugs.
@
CeLL
, I finally found some functions for converting TPL formats (not sure if they're they same I had found before; wish I had bookmarked those). They're built into LibWiiSharp. Obviously we'd have to rewrite them into Python. And granted, we already have everything we would need on the MK wiki on their formatting to build some functions from scratch anyway, but these could probably still help speed things up. I wanted to share in case you still want to create converter functions for each image type. For now I'm going to continue with wimgt so I can get something working released much quicker. But I may create my own converters if you don't make some and then switch to using those later, since it would be so much more efficient.I also found wimgt's source code and BrawlBox's source. I didn't see any functions for tpl conversions in with BrawlBox's source, but maybe I just missed them because I might not have checked every folder.
I recently decided to start on learning Melee hacking and I'm very interested in improving my knowledge. I've been reading many threads and it's comments, but still I'm struggling to follow this simple tutorial.How to Replace the CSS Closed Port Texture
1) Modify this image:
*Anything in the transparent area will not show up correctly on the CSS and the image will be displayed as black and white (so make your image in grayscale).
2) Use the PNG to-from TPL tool to create a TPL of your modified image.
- This image is a "_3" type.
3) Use the TPL Overwriter to insert the image into the MnSlChr.usd file.
- Placement is 0x2F760.
- Alternatively to using the program, open the TPL in a hex editor and copy from 0x40 onward and paste at the above address in MnSlChr.usd.
EDIT: How to Edit Both Sides of the Closed Texture Port - DRGN
First, I tried editing the file achilles1515 posted in the above comment, as well as one posted by DRGN, but neither GIMP, Photoshop or my standard Windows image viewer would open it and all told me the file could be damaged. So I tried using the custom one by CeLL and it worked. I edited it and created my custom png texture in GIMP following DRGN's tutorial and converted it into a TPL using DRGN's program and went on the last step to incorporate it into the MnSlChr.usd file.
But then, I didn't know which offset(s) to use. I did read DRGNs How to Hack Any Texture thread but struggled to understand the section about offsets as well as the one about placements (english isn't my first language), but there I found this link by Steelia that allegedly contains MnSlChr.usd's offsets. Inside the .rar, I found a file called 'Placements.txt' containing the next data:
01 - 00013f80
25 - 00014fa0
24 - 00015fc0
00 - 00016fe0
02 - 00018000
03 - 00019020
04 - 0001a040
05 - 0001b060
06 - 0001c080
07 - 0001daa0
08 - 0001eac0
09 - 0001fae0
10 - 00020b00
11 - 00021b20
12 - 00022b40
13 - 00023b60
14 - 00024b80
15 - 00025ba0
16 - 00026bc0
17 - 00027be0
18 - 00028c00
19 - 00029c20
20 - 0002ac40
21 - 0002bc60
22 - 0002cc80
23 - 0002dca0
~USED IN MnSlChr.usd (same file that contains CSPs)
25 - 00014fa0
24 - 00015fc0
00 - 00016fe0
02 - 00018000
03 - 00019020
04 - 0001a040
05 - 0001b060
06 - 0001c080
07 - 0001daa0
08 - 0001eac0
09 - 0001fae0
10 - 00020b00
11 - 00021b20
12 - 00022b40
13 - 00023b60
14 - 00024b80
15 - 00025ba0
16 - 00026bc0
17 - 00027be0
18 - 00028c00
19 - 00029c20
20 - 0002ac40
21 - 0002bc60
22 - 0002cc80
23 - 0002dca0
~USED IN MnSlChr.usd (same file that contains CSPs)
So those are 26 series of numbers that I believed were the offsets I needed to type in the Source Texture(s) section in DAT TW. So I went on typing the 26 offsets and created my new MnSlChr.usd file that I then Imported into my iso using GCR. The result was horrible, the CSS was all messed up (meaning the Character Choose Icons textures were all replaced by a weird gray inconsistent image), but I did saw my new texture with an odd placement in the CSS.
So that was my first try, then I tried messing with only some of those offsets only to keep failing miserably.
Now, I have a couple of problems that I'd really appreciate if someone could help me with:
- I don't know what the "x" stands for in "0x40". I believe it represents a series of 0s but I'm not sure.
- Therefore, I don't know where in the Hex do I have to look for said 0x40 and what to copy as well as where and how to paste it.
- I don't know what "Placement is 0x2F760" means, so I didn't know what to do with that. I believe it's something to be found in the Hex, I did find offset 0002F760 in it and tried using it as an offset for MnSlChr.usd in DAT TW, but the resulting ISO wouldn't even load on Dolphin.
- I don't know why I couldn't work with achilles1515's or DRGN's files.
- Lastly, could somebody please ELI5 the 3rd step in achilles1515's tutorial?
Last edited:
I'm sure someone else will soon answer your other questions, but until then paste this in DTW:
0002F760 - _624092e7
Also, if your edited .png/.tpl isn't named correctly, name it:
GALE01_624092e7_3
This should work. You also need to paint the alphas (just make a slice from the top right corner of the image to the bottom left, white on the right side with black on the left).
In order to save a .png's alpha channel with Photoshop, use this plugin.
gn
Last edited:
CeLL
Smash Lord
The 0x in 0x40 just means that the 40 is hexadecimal. The decimal equivalent of 0x40 is 64.
When Achilles said placement, he was referring to the offset of the start of the image. So if you counted every byte (a byte is one of those groups of two numbers you see in a hex editor), starting with 0, from the beginning of MnSlChr.usd, the texture would start at byte number 0x2F760, which is equivalent to 194400 in decimal.
I have no clue what the issue with the images is, they work fine for me.
Step 3: Open DTW, select MnSlChr.usd, select either the TPL or PNG you made, then make the source textures field look like this :
Code:
filepath_of_your_texture --> 0x2F760
Last edited:
Thank you both. I was able to finally see my edit on the screen as well as have a better understanding on the subject. Years ago, my younger self wouldn't have imagined someday he would be editing such aspect of his beloved game. Thanks to Anutim I was essentially able to get my design right so that it looks the way it's supposed to in the CSS. I actually like the idea that the background image of the selected character must be in grayscale. Also, downloading the plugin fixed the error I had when trying to use the image achilles1515 posted.
And thank you for the response, CeLL. I now understand the reasoning behind getting the offset to use and was able to make the MnSlChr.usd file correctly.
Today was a good day for me.
And thank you for the response, CeLL. I now understand the reasoning behind getting the offset to use and was able to make the MnSlChr.usd file correctly.
Today was a good day for me.
Last edited:
For any that might be following this thread or wondering about DTW3: Yes, it's still a living project. Progress was good, but I took a break to work on a 'small' side project. (Though technically DTW is also a side project. )
Also I wanted to point out that it works for files besides characters; it should work with about any dat file. I just happened to post character related textures above since that was the file I happened to be testing with at the time. For example here's a shot of some textures from Venom (no wonder this stage doesn't have any texture hacks. Besides no one playing here ever, it has ~100 textures):
Yep, those are the taunt easter egg images for Slippy. For this or Corneria, these could be changed to a character from any game/movie/whatever, along with the lines they say and audio, haha. I'll just let your imagination fill in the blanks on that one.
)Also I wanted to point out that it works for files besides characters; it should work with about any dat file. I just happened to post character related textures above since that was the file I happened to be testing with at the time. For example here's a shot of some textures from Venom (no wonder this stage doesn't have any texture hacks. Besides no one playing here ever, it has ~100 textures):
Yep, those are the taunt easter egg images for Slippy. For this or Corneria, these could be changed to a character from any game/movie/whatever, along with the lines they say and audio, haha. I'll just let your imagination fill in the blanks on that one.
Last edited:
Achilles1515
Smash Master
Is this thing finding textures and displaying them? If so, then thats amazing and I vote that this takes precedence over the DOL program because that would be totally revolutionary. But that's just my stupid opinion. Good work!For any that might be following this thread or wondering about DTW3: Yes, it's still a living project. Progress was good, but I took a break to work on a 'small' side project. (Though technically DTW is also a side project.
Also I wanted to point out that it works for files besides characters; it should work with about any dat file. I just happened to post character related textures above since that was the file I happened to be testing with at the time. For example here's a shot of some textures from Venom (no wonder this stage doesn't have any texture hacks. Besides no one playing here ever, it has ~100 textures):
View attachment 44264
Yep, those are the taunt easter egg images for Slippy. For this or Corneria, these could be changed to a character from anything, along with the lines they say, haha. I'll just let your imagination fill in the blanks on that one.
Last edited:
Yes.
Although I haven't been able to move up the data structure hierarchy to find palette headers like I thought for some reason. So _8 & _9 textures aren't working yet. But for commonly used things (like the CSS/SSS) I could temporarily hardcode the palette offsets until I have a true fix.
Also, I agree this is better than the DOL program. It even kinda pained me to move away from DTW. It's just that the other is already so close.... XD Oh well, I should be able to get back to this soon, I think.
Last edited:
Don't know if you've already found them, but... the Reg & Poison mushroom icons on the Item Switch are in MnExtAll.usd (all the other icons are in there as well), @ 0x11C6A0 and 0x1266A0, respectively.
Guys, sorry to bother you again, but I really need help with CSPs. I made an entire pack of textures for Melee (.pngs) which were basically wireframes of different colours. However, when I used the wizard to mass import them I got this (they're using mostly the colours for the white wireframe, with some specs of the other colours thrown in).
Please, I would greatly appreciate any and all help (I have a few days to finish this hack). All 118 filenames end with a .png and have transparency.
EDIT: Could it be the amount of different transparencies I use? The wireframes are all semi transparent.
Please, I would greatly appreciate any and all help (I have a few days to finish this hack). All 118 filenames end with a .png and have transparency.
EDIT: Could it be the amount of different transparencies I use? The wireframes are all semi transparent.
Last edited:
The green tint is all intentional, rather than part of the problem, right? (I don't really see how that could happen, lol)Guys, sorry to bother you again, but I really need help with CSPs. I made an entire pack of textures for Melee (.pngs) which were basically wireframes of different colours. However, when I used the wizard to mass import them I got this (they're using mostly the colours for the white wireframe, with some specs of the other colours thrown in).
Please, I would greatly appreciate any and all help (I have a few days to finish this hack). All 118 filenames end with a .png and have transparency.
EDIT: Could it be the amount of different transparencies I use? The wireframes are all semi transparent.
For the CSPs, it could be that you had a typo in an offset somewhere. I've done that a few times. That could really mess things up because it can cause data to overwrite over image/palette headers or other data structures. And because DTW2 is only replacing the data portions and not the headers, you can't fix the problem by simply trying to reinsert the image at the correct offset. If you know where the mistake was, then you could copy/paste original header info from a vanilla copy of the file. But since that's usually not the case, the best way to fix it is to go back to a known-good copy and do the operation again. But before trying them all again, the best way to troubleshoot at this point (mostly to determine if that was the cause or if there's a problem with the initial image), is to take a known-good MnSlChr file and try just one of the problem images by itself, like the green Pikachu you have there. Creating a palette for the images will improve quality.
Also, keep a copy of the CSPs without a palette as well, because in the future I think I'll have a way to replace all of the CSPs with larger, non-paletted image types, allowing them to better support transparency and greatly increasing their quality. The in-game copies would then basically look just like the original pngs. I'm pretty sure I can create a file like this, but I don't know about fitting the whole file into RAM since it'll be bigger.
Edit: If it still doesn't work, you could post one of the CSP images and I could take a look at it.
Last edited:
So I did just yellow Pikachu by itself (completely fresh MnSlChr), and the problem persisted. When I checked the palette in Photoshop, it said I only had two colours (the whole image was just different transparencies of yellow). I then put a solid black background behind it and well... it worked. Is there no way to fix the transparency issue? It's not the end of the world if I put black backgrounds on everything I suppose, but I'd still like to know.
http://puu.sh/hCRps/20d5814d0e.rar
^ a sample of some of the textures I use if it helps.
EDIT: This is what it looks like with solid backgrounds (I just need to untexture the Red/Blue/Yellow/Green player colours behind them). If it's too hard to fix don't worry about it, this is an adequate solution (also yes, the green character icons were intentional).
Last edited:
Achilles1515
Smash Master
Try using a plain magenta background (#ff00ff) and then putting it through DTW instead of having the background as transparent.
So I did just yellow Pikachu by itself (completely fresh MnSlChr), and the problem persisted. When I checked the palette in Photoshop, it said I only had two colours (the whole image was just different transparencies of yellow). I then put a solid black background behind it and well... it worked. Is there no way to fix the transparency issue? It's not the end of the world if I put black backgrounds on everything I suppose, but I'd still like to know.
http://puu.sh/hCRps/20d5814d0e.rar
^ a sample of some of the textures I use if it helps.
EDIT: This is what it looks like with solid backgrounds (I just need to untexture the Red/Blue/Yellow/Green player colours behind them). If it's too hard to fix don't worry about it, this is an adequate solution (also yes, the green character icons were intentional).
I thought that's how DTW deals with transparencies, by automatically converting the magenta color into transparent. And just try one to begin with.
Last edited:
CeLL
Smash Lord
I'm actually a big fan of those CSPs.
So I did just yellow Pikachu by itself (completely fresh MnSlChr), and the problem persisted. When I checked the palette in Photoshop, it said I only had two colours (the whole image was just different transparencies of yellow). I then put a solid black background behind it and well... it worked. Is there no way to fix the transparency issue? It's not the end of the world if I put black backgrounds on everything I suppose, but I'd still like to know.
http://puu.sh/hCRps/20d5814d0e.rar
^ a sample of some of the textures I use if it helps.
EDIT: This is what it looks like with solid backgrounds (I just need to untexture the Red/Blue/Yellow/Green player colours behind them). If it's too hard to fix don't worry about it, this is an adequate solution (also yes, the green character icons were intentional).
Why thankyou. I'll have them made public as soon as I can then.
@
Achilles1515
I'm afraid that won't work this time, as there are multiple levels of transparency per image. It's quite ok though, the black background trick is almost unnoticeable given what I need to do (and I doubt it's possible to distinguish on a CRT anyway).Also, another quick question while I'm here. How do you change the character select door texture?
When ripped with Dolphin I get this, but the other half is nowhere to be seen. What's weird is if I change this too drastically, the other half of the door texture also gets affected with weird colouration (almost as if they share a palette, despite being _3s).
For anyone interested, the offset for the texture above is: 2F760
Last edited:
http://smashboards.com/threads/new-tools-for-texture-hacking.373777/#post-17895928Why thankyou. I'll have them made public as soon as I can then.
@
Also, another quick question while I'm here. How do you change the character select door texture?
When ripped with Dolphin I get this, but the other half is nowhere to be seen. What's weird is if I change this too drastically, the other half of the door texture also gets affected with weird colouration (almost as if they share a palette, despite being _3s).
For anyone interested, the offset for the texture above is: 2F760
Edit: I'm also really hyped to see you messing around with the CSS, can't wait to see what you create!
Last edited:
Oh, I didn't even realize how the CSPs were supposed to look at first. I thought the white wireframes were intentional and just the green & blue Pikachus were the problem.
So I did just yellow Pikachu by itself (completely fresh MnSlChr), and the problem persisted. When I checked the palette in Photoshop, it said I only had two colours (the whole image was just different transparencies of yellow). I then put a solid black background behind it and well... it worked. Is there no way to fix the transparency issue? It's not the end of the world if I put black backgrounds on everything I suppose, but I'd still like to know.
http://puu.sh/hCRps/20d5814d0e.rar
^ a sample of some of the textures I use if it helps.
EDIT: This is what it looks like with solid backgrounds (I just need to untexture the Red/Blue/Yellow/Green player colours behind them). If it's too hard to fix don't worry about it, this is an adequate solution (also yes, the green character icons were intentional).
achilles is right that you can use "replacement colors". Like you said though, the problem is that you want many different levels of transparency. I only designed DTW with 2 levels in mind; magenta (ff00ff) will turn into full transparency, and lime green (00ff00) will turn into the shadow/half-transparency.
A little while back I did some CSPs for the Fighting Wire Frames, which are just about the same as these.
In the download for those there are _9.png copies with palettes, as well as copies with full transparency ranges that you can compare to. You can see a difference, but even with only two levels of transparency the _9 versions still turned out pretty well I think. The purple background they have on their body makes it hard to tell they don't have transparency there. To do something similar, maybe you could just mimic the color that will be behind the CSP to make it appear to be transparent. And generate a palette in your png (I don't have GIMP with me, so I can't check the images you posted atm).
I haven't tried it, but it should be possible to get more levels of transparency. _9 with transparency should use RGB5A3 for the palette format, which means 3 bits are available for the alpha channel, allowing for 8 different values. The full two bytes that you'd see for each color in the tpl file work like this:
0110000010001000
The first/top bit tells whether all of the bits will be used for color, or if some of them will be used for an alpha channel. 0 I'm pretty sure designates alpha use. If it uses one, the alpha channel is the next 3 bits, followed by the colors at 4 bits each. To convert to hex you would multiply the alpha by 0x20, and the colors by 0x11. So in the example above you would have green and blue at 0x88 (full color = #008888), and alpha at 0xC0, or a value of 192 out of 256 (75% opaque). So in other words that should be a 25% transparent teal. You would do the reverse to convert a color to the two byte format.
Even if you have multiple pixels that are the same color, if they have different transparencies then they'll each take more counts out of your palette total. But since you have so few colors in your images already that shouldn't really matter. You could have full transparency range (of 0-7 levels anyway) of up to 32 colors, which would be way more than enough.
But of course the problem with all of this is that you'd have to manually put these colors into the tpl. (At least I think so; I'll need to experiment with the tRNS chunk in pngs and see if it's properly used by the image converter (wimgt). It could be that we just haven't been outputting files correctly from our image editors. If you see an option to generate the tRNS chunk in Photoshop, try it with a paletted texture.) You'd have to create one of these byte values for each of the 8 transparency levels, for each color in the 118 CSPs. Although that's only like 6 colors, right? Anyway, like I said, there's a few things I'll have to look at in GIMP once I'm home.
And yeah, I agree with Cell, that CSS is looking pretty cool. I like these CSPs.
Btw, if you want to know the locations of any other textures, like the back button, HMN buttons, or behind the selection icons, let me know, I should be able to find them. Hm. Maybe the moving text behind the whole menu too. Maybe change it to lines of 1s and 0s or something. For the CSPs, I wonder if it would look good to add a gray line at the top, so it looks like the section with the name is intentionally divided (not necessary if I figure out better transparency though). Or it might work better to get rid of the current gray border entirely, and add a border to the CSP images instead. Just some ideas.
Last edited:
CeLL
Smash Lord
How do you move the HMN button?Why thankyou. I'll have them made public as soon as I can then.
@
Also, another quick question while I'm here. How do you change the character select door texture?
When ripped with Dolphin I get this, but the other half is nowhere to be seen. What's weird is if I change this too drastically, the other half of the door texture also gets affected with weird colouration (almost as if they share a palette, despite being _3s).
For anyone interested, the offset for the texture above is: 2F760
358874 - Move the top menu bar
359278 - P1 Border position (followed by the other 3 directly after)
3593BB - P1 Logo position for chars (followed by the other 3 directly after)
3594F8 - P1 Character image (followed by the other 3 directly after)
35B2F8 - P1 HMN button (followed by the other 3 directly after)
(Apply to MnSlChr.ukd, but I'm pretty sure they're at the same location since textures are). You need to know how position data works mind you.
Oh, and downside: moving HMN doesnt change the place where you press it.
359278 - P1 Border position (followed by the other 3 directly after)
3593BB - P1 Logo position for chars (followed by the other 3 directly after)
3594F8 - P1 Character image (followed by the other 3 directly after)
35B2F8 - P1 HMN button (followed by the other 3 directly after)
(Apply to MnSlChr.ukd, but I'm pretty sure they're at the same location since textures are). You need to know how position data works mind you.
Oh, and downside: moving HMN doesnt change the place where you press it.