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. I don't know how the heck that article got that dialog box.Īnyway, I've at least got tkDND working with 2.7, which is pretty cool and has already made it worth it. (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. That's not what you get at all with Python 3+, so I figured it must be with 2.x. It's just way better and more convenient to use over-all. If you scroll down and look at this image, that's what I wanted. And I found this article a while back, which shows a different file choosing dialog box if you scroll down a bit. I also actually really don't like the default file chooser available via tkDialog's askopenfilename. 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. 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). 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?). 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). 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.Ĭlick to expand.Yeah. To be honest I didn't think it would when I had the idea, but tried it anyway. I'm sure there are a lot more efficient/more accurate/faster ways of doing it, but this works, at least afaik.
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.Īccording 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. If you don't specify an "original" parameter, it returns a list that sort of matches pixels, like I explained above. 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. 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.
0 kommentar(er)
