So, I'm not really sure anyone here will actually be interested in the progress of this, but I want somewhere to document said progress--this seems like a good enough place.
I've started working on a tool to recolor the sprites in the game
Wolfenstein 3D. There are lots of tools out there for modifying the game, but none that I know of that will actually recolor the sprites based on the palette, and I kind of wanted to make one anyway to play with reading in/writing the files. A long time ago I started working on a map editor, but my lack of understanding of both C and C# put that on hold. Maybe if I get this finished I'll continue working on that. In any case, here's some screen shots:
This shows one of the enemy sprites (the SS running toward you). In the right pane are all the colors that make up the sprite. The two colored squares represent the mapping. Right now there's no difference, so they're all the same color. The text shows the mapping as which color in the palette is mapping where. The text in parentheses is how many pixels are of that color. You can right click on a mapping and select "Highlight pixels" to show all the pixels that are of that color:
The idea is that you'll want to see what you're changing. Soon you'll be able to configure the mappings and preview the sprite. You'll also be able to bulk-map the sprites, so that you can recolor all the sprites on one enemy type at a time. Ideally I'll also make it so you can mark off places where the recolor won't happen (so you can change the blue in his uniform, for example, without changing his eye color).
So, yeah, that's the progress for now.
Wow very nice project. Hope this goes far. Brings me back to the days when I played it.
That's a pretty nifty thing there merth
Very nice work, merth!
Glad to see this pulling together, having heard you talking about it on IRC. Do you see this turning into a more complete sprite editor in the future?
I'll probably add some simple editing things, like a pencil tool, pen tool, maybe some primitive shapes, flood-fill, that sort of thing. There are already some pretty nice existing sprite editors, so I don't really want to remake those (and I imagine most people export the sprites and edit them in a full-fledged graphics editor), but for quick cleanup after recoloring, it seems like it would be a good idea to add those things as well.
Alright, progress (sorry for the image-heavy post)!
So, let's say you have the sprite open like this (this is the
officer looking forward):
And you double click on the color you want to change, you get this:
We want to make him green, so select a green:
Hit save:
Repeat for all the pixels you want to change:
You can see there's some white/grey in his hat that got turned green, so when there's some edit tools, you can force those colors once you save the mapping.
Here's another example of
Hans Grosse
Turned red:
And grey:
And purple:
Note: Sometimes in the screenshots the pixel map box doesn't render right. That's just something weird with the screenshot software, not the actual program itself.
Cool stuff, it's nice to see examples of what it can be used for. Something to map several colours at once to a gradient (e.g. dark to light greys mapped to dark to light greens) would seem one way to speed up the process.
That would be very handy, indeed. I've added a couple more things tonight:
I added an "update" check box that can toggle whether the mapping is displayed or not, so you can see before and after:
There's also copy and paste for the mapping to quickly edit multiple sprites, so here's the next in the series:
This doesn't always work perfectly, here's him shooting:
So you can see I need to map those purples, but that can be done and you can copy again etc. The save button saves the mapping to the sprite. The reset resets it back to the mapping that's saved (originally the original colors).
So I did a little work this weekend. You can change the palette file (in case you're working on the Spear of Destiny sprites or your own mod that has its own palette), you can export a range of sprites, and there's now a label that tells you which sprite you're looking at. There are a couple of things I want to add before I make the first release to the Wolf3D community:
1) Saving (obviously this needs to be done)
2) Zoom in/out buttons for the sprite
3) A gradient map thing like benryves suggested
4) I want to turn the "copy" button into a combobutton that can either copy the current mapping, or add any additions to whatever's currently copied
5) A way to mark certain pixels as "safe" from the mapping (see the post with the officer to get an idea of what I mean)
At the very least I want to get the first three done before a release, but I'll probably try to get all five of them done.
So I managed to get 4 done after much internet searching. I kept searching for "combobutton". If I had just been searching for "splitbutton" this whole time, I could've saved a lot of time. I'm not sure why this isn't built in, but oh well, I have it now. I probably could've saved some time just building it myself, but I feel the solution I found is better than whatever I could've come up with.
merthsoft wrote:
So I managed to get 4 done after much internet searching. I kept searching for "combobutton". If I had just been searching for "splitbutton" this whole time, I could've saved a lot of time. I'm not sure why this isn't built in, but oh well, I have it now. I probably could've saved some time just building it myself, but I feel the solution I found is better than whatever I could've come up with.
I thought it very odd that with the amount of use C# is seeing in the real world these days, someone wouldn't have implemented combo buttons. This is looking great, by the way; I just haven't commented because it's not particularly applicable to my own needs. Out of curiosity, do other games like Doom use some similar format? Those enemy guys look a lot like some of the Doom enemies.
It's similar enough that some DOOM file documentation was able to help me figure out what was going on, but different enough that you can't just plop it in there. Anything based on the Wolf3D engine should work, though--Spear of Destiny, Blake Stone, Super 3D Noah's Ark, Operation Body Count, Corridor 7, maybe Rise of the Triad, but probably not. And, of course, the numerous mods available for Wolf3D and SoD.
The similarity of the sprites is probably because Adrian Carmack was the artist for both games (he hand-drew all the sprites in Wolf3D (!), and hand-drew many of the DOOM sprites).
merthsoft wrote:
The similarity of the sprites is probably because Adrian Carmack was the artist for both games (he hand-drew all the sprites in Wolf3D (!), and hand-drew many of the DOOM sprites).
Is there anything awesome that Carmack didn't do?
merthsoft wrote:
Wrong Carmack.
*facepalm* And that's what I get for skimming and multitasking. Still very impressive spriting, obviously. I know this is completely off-topic, and I'll stop hijacking your thread post haste, but I would love for one of us to sit down and port Doom or Wolf3D or something similar to the Prizm.
I have been looking at getting the id Tech 1 engine ported to the prizm. Since it was partly written in x86 asm and x86 and SH asm are similar, it could be done.
(By id Tech 1 I mean the quake engine, not the doom engine)
AHelper wrote:
I have been looking at getting the id Tech 1 engine ported to the prizm. Since it was partly written in x86 asm and x86 and SH asm are similar, it could be done.
(By id Tech 1 I mean the quake engine, not the doom engine)
That would be an impressive feat. How much of the engine is hand-carved ASM, with the balance I presume being tight C?
Adding walls was very simple:
Same infrastructure, and same clipboard for the mapping table that way you can map everything if you need too (this could be useful if you actually change the palette but want to keep certain colors or whatever).
I also improved performance and lowered memory usage tonight, though you can't really see that, so no screenshots of that.
I've got the infrastructure in place to do exclusion, but I'm still not 100% on how I want to represent that, so that's on the back-burner. Next up will be actually saving the VSWAP file out (very important!).
Ohhh, ahhhh so perty!
Nice work there merth, this is really turning into a cool little tool.
So, just a quick little update. I got the first step to saving done, that is, I can take a sprite and convert it to the data-chunk it needs to be to be loaded correctly--at least, it loads correctly in my tool, I haven't actually saved out a file yet. This is a pretty good start, so I think saving will be done by the end of the week. One issue I know of is that the data I make tends to be bigger than what was initially loaded in, but I think I know how to handle that.