WinTeX is unbeatable for graphics editing

I know that in recent posts there has been a little WinTex-bashing, and alternative graphics editors have been suggested. However, here is an anecdote that should please those of you who have come to rely on WinTex as much as I have.

I needed to insert some weapons graphics into a wad. I was unable to use WinTex on my Win2000 computer, so I was considering alternatives. I had looked at WadEdit when it was introduced a couple of weeks ago, and realized that it was not yet capable of true editing. I decided to try DeePSea, and used Rick Clark's tutorial. The tutorial is really for texture/patch editing and does not cover sprtites. However, as the principle is the same, I had no problem inserting the sprites. The first problem occurred when I tested the level -- the new sprites didn't show. I went back and checked, and realized that the S_Start and S_End were missing. So I tried to figure out how to insert them. I read the help file, which directed me to use "Insert Dummy" to put in the control information. I quickly realized that the "Insert Target" button was what the help file was referring to, and I put in the required information.

Eagerly I fired up DooM only to realize that while the new sprites were in, they were way up in the left corner. Further, the cyan (transparent in DooM) color had been converted to a dusky green. I decided to tackle the color problem first. I opened up "Auto Options" then "Color & Gamma" and noticed that the default was R255, G0, B255, causing the green color. I read and re-read the help file, changed the defaults to R0, G255, B255, tried other combinations, but no luck. I was stuck with the ugly green color.

(Update: I opened up the color table in "Color & Gamma" and manually selected Color 247, then manually changed the defaults to R0, G255, B255, and came up with a gray background. Apparently this is the transparent color used by DeePSea, so that ends well. But why DeePSea had a different default beats me. The help file said something about graphics in colors other than 8-bit, but that was not clear, and it does not apply in this case.)

I moved on to off-setting the sprites. The help file said that toggling the Textures-Projectiles-Sprites button would convert the graphics into the appropriate format, and for sprites would assign the offsets. I'm not sure what I did wrong, but it appears that the graphics were not being imported as sprites. (Btw, I used the same sprite names as those in DooM.) Anyhoo, I decided to use the sprite editor mentioned in the help file. I did a search for "Sprite Editor" in the help file and came up with nothing, not even for "sprite". Luckily, I remembered the "Sprite Name Edit" button in the graphics edit panel. I opened up the file and offset the graphics in the usual way, exited, and fired up DooM. Several hours later I had the desired sprites in my level.

Later yesterday I went into my other computer (which still has Win95 and a working version of WinTex), opened up WinTex, and within 5 minutes had inserted the exact same graphics into my wad, which worked perfectly. Within 30 minutes I had inserted graphics for 5 weapons.

What is the purpose of this anecdote? I guess it is to say that we are most comfortable working with familiar tools. Don't get me wrong -- DeePSea is an excellent tool (although the help documentation could be significantly improved). However, as with other versatile and powerful tools, DeePSea comes with a steep learning curve. Will I continue using DeePSea for graphics editing? Probably, especially now that I have climbed that learning curve. Will I go back to using WinTex? Certainly. I've never had a complaint about WinTex (except that I can't run it on my Win2000 system!). It has a few limitations (e.g., oversize textures) that I've always used DeePSea to overcome. But aside from that, it offers the same functionality as (if not more than) other graphic editors, while streamlining the process in many places:

* automatically inserting control information
* quick two-step cut-and-paste of graphics already in the desired format (e.g., from one wad to another)
* immediate access to graphics (e.g., for offsetting, as in the example described above)

So, to all you WinTex users out there I say: Give DeePSea and other graphic editors a try, but I believe, like me, that you will not abandon WinTex.

What you say is true. The key difference between Wintex and DeePsea is that are NO predefined assumptions about names or anything else. One can insert anything they like in a PWAD, even stuff that has nothing to do with DOOM<g>

To beginners, sprite offsets, control names and all that stuff is all Greek (or Latin). Wintex DOES make assumptions about names - assumptions that can get in the way:) It does make replacing existing old stuff easier since there's less/little to learn.

If one starts modifying WAD files with "extra" stuff, it becomes a prerequisite to understand what belongs where. The tools in DeePsea permit individual detailed manipulation to accomplish and accommodate any current and future DOOM port(s) using the PWAD lump naming conventions.

Actually, even in Wintex one gets into the sprite offset area. The key is that you could correct it and it's pretty fast and easy to do so.

The transparency issue is 2-fold. First, historically the value was changed. Second, if the bitmap was not a 256 color, DOOM palette image, then it can't be automatically matched for transparency.

The default color is not the "green" color you mentioned - it's either the Wintex value (247) or 251. These values are palette index values into the DOOM palette. You normally DO NOT want to change the RGB values, that's mainly for matching "other" palettes. Could be in tinkering it got mushed.

There is actually no such thing as a "transparent" color in DOOM. The color is only used by DeePsea (and Wintex) to decide where there are NO pixels and construct the DOOM picture format accordingly - hence there has to be information telling DeePsea what color value to consider as "transparent".

I do understand that there is a degree of frustration involved in learning something new. It's so hard to keep that "I want to get this done and over with" feeling from overhelming one's mind. It shows you are pretty competent and dedicated in how you persisted and learned how to do it.

Jack

As you get more deeply into Wintex the number of bugs that Wintex has becomes a real problem. For example, if you edit a lump and save it, Wintex inserts a new lump with the same name and leaves the old one. You have to go back and delete the old lump.

If you create a texture, you can't delete it since Wintex doesn't updated the Textures1 lump correctly.

You can't insert special lumps without getting an error message ans sometimes bad lumps.

If you try and merge a wad that has special lumps, it may or may not work; usually not (DON'T try this with ZDoom); and the list goes on.

Wintex does have its good features and frankly we don't have much to choose from, so its better than nothing. However, since I know now what I want to do, DeepSea lets me do it without getting in the way. DeepSea does have a learning curve, but once you get it, it is a nice tool.

Something with WinTex that's been bugging me lately is this:

If you edit the textures and simply resize a few of them (e.g. 128x128 to 128x64 say), it doesn't realise you've changed anything and therefore doesn't save the changes unless you do something else, such as move a patch slightly, and then move it back again.

And yeah, the fact that you if you want to delete a texture, you have to rename it to an existing texture, is also VERY annoying.

deepteam said:

After reading Rick and NM's post I realized there are indeed several limitations in WinTex that DeePSea overcomes. As a matter of fact, on several occasions I have used DeePSea to overcome those limitations. In retrospect, I should have said that I would use a combination of WinTex and DeePSea for my graphics editing needs (which is what I currently do). WinTex for the (relatively) quick functions of cutting and pasting between wads, etc., and DeePSea for stuff that's beyond WinTex.

A quick note on the transparency issue. The image was indeed a 256-color DooM palette image, with which I had no problem when I used WinTex. The default color in DeePSea was 251, which converted the cyan into the green that I referred to. I had to manually change the value to 247 in the color chart, and the RGB values to be able to get the so-called transparent color (which in DeePSea must be grey).

Thanks for your feedback. If you have read any of my posts here at DooMWorld pertaining to good editors, you will have realized that I think highly of DeePSea. It is one of the top 2 editors I recommend when people ask for suggestions on which editor to use. My post on WinTex was certainly not intended to suggest that DeePSea is lacking in the graphics editing department.

Wildman said:

As you get more deeply into Wintex the number of bugs that Wintex has becomes a real problem. For example, if you edit a lump and save it, Wintex inserts a new lump with the same name and leaves the old one. You have to go back and delete the old lump.

If you create a texture, you can't delete it since Wintex doesn't updated the Textures1 lump correctly.

You can't insert special lumps without getting an error message ans sometimes bad lumps.

If you try and merge a wad that has special lumps, it may or may not work; usually not (DON'T try this with ZDoom); and the list goes on.

Wintex does have its good features and frankly we don't have much to choose from, so its better than nothing. However, since I know now what I want to do, DeepSea lets me do it without getting in the way. DeepSea does have a learning curve, but once you get it, it is a nice tool.

Wintex comes in real handy when you are trying to make *new* sprites and sounds for edge. Althought I wish it had this funtion more fully implemented (and not just in some corner that says 'guru only'), it is a real pain to put in say, a whole enemy because that's about 60 some-odd sprites and it takes about forever to get all the lumps named (inserting graphics is a snap if they are the same name as the lumps).

Sounds are abit tricky to put it, since wintex will NOT allow you to put in new sounds with new names (like DSBOOM or DSPOWPOW, or DSSCREWU), you have to insert something like DSPISTOL and rename the lump to what you want.

Raw data lumps are abit tricky to accomplish too, especially things like palettes and other misc edge stuff (like RTS scripts and ddf-in-wad). You have to make something like the demo1 or other lump names and load your data into them, then rename them (then save the thing and see if it didn't leave behind empty shells).

I haven't climbed the learning curve for mapediting yet so i have little/no use for texture options.

I wish the guy who wrote it would make a patch or something and update his crap.

ReX said:

Thanks for the reply. I am a bit confused, but that's easy to get at a distance:)

The color index of 247 is "green" for Wintex and 251 (default) is sort of violet. I needed to refresh myself on the Wintex transparent thing. As it notes in the little dialog box, change the index value to 247 and the RBG to 0 255 255. You DO have to change the RGB - I forgot about that.

The reason you have to change the RGB is that the value Wintex puts in there is NOT the actual color at that position in the DOOM palette. So when you enter 241 and 0 255 255, DeePsea changes the DOOM palette at that location, overriding that position. If you bring up the little color palette again (in that dialog box), you will see that the color changed.

In this way, you can use custom palettes and always get around the problem of choosing a transparent color. It also helps when importing a bitmap > 256 color where the colors are automatically mapped to the DOOM palette. The only rule for a transparency index is that the image should not use any pixels with that as an index value.

So to match Wintex, change it to 247 and change the RGB to 0 255 255. From now on it will use the same transparency, since those values are saved.

You are correct that the color index for 251 is violet. However, when the default color index value (251) is used with default RGB values (R=255, G=0, B=255), importing a graphic with cyan converts the cyan to green. (As a common reference point, WinTex treats the cyan in the same graphic as a transparent color. I point this out simply to confirm that the color palette is acceptable to DooM.) To get the proper "transparent" color, I changed the color index to 247 (gray), and the RGB to 0,255,255. In DeePSea, this made the original cyan into gray, and in DooM the gray was "transparent". This accomplished what I was trying to do. Thanks for the clarification.

There was one sentence you wrote that made me think I did not explain it clearly enough. DOOM does not use the index value of 247 nor 251 in any graphic I ever found so that's why those values were chosen for "transparent" values - to not get in the way of actual graphics.

Even if DOOM did use those values, it wouldn't "hurt", since you can make the palette anything you like. I say that because you said "color palette is acceptable to DOOM". Just making sure that everyone is clear that DOOM does not have a transparent color at all.

Wintex choose an arbritary index value of 247 (it was different a long time ago) and DeePsea has an arbritary index value of 251. The key difference is that Wintex creates an artificial RGB that does not exist in DOOM's palette, DeePsea's value does exist.

If you Import graphics to EITHER program with the other programs "transparent" value, it will not work. The RGB values have to be "matched" to the palette in use. Since the 247 index value does NOT exist as shown in Wintex, what you get is the closest match to the RGB that Wintex used - but there is no such RGB as such - just the actual RGB of index 247 which is 0,0,0 (there are other wasted spaces in the DOOM palette). So DeePsea looks for some other match - which is the "green".

Neither program is right or wrong - but one does have to understand the process of color matching. When Wintex exports a graphics it creates a "fake" color value that does not exist in the DOOM palette. So when DeePsea reads in that image the closet RGB match is the "green" in the stock unmodified DOOM palette.

Indeed, Wintex has glitches when matching "non-Doom" palettes because his algorithm is a "difference" algorithm of rgb values which can result in erroneous matching. Some palettes will present problems no matter what technique is used because of missing RGBs.

To more clearly illustrate what is going on, export a sprite using DeePsea and then use Wintex to import it. Wintex will show the actual color (since it's real),however it will not transform it into a transparent format correctly.

(damn typos)

Got it. Thanks.

Btw, reading SirGalahadWizard's post reminded me of another feature of DeePSea that is hugely time-saving:

"...it is a real pain to put in say, a whole enemy because that's about 60 some-odd sprites and it takes about forever to get all the lumps named (inserting graphics is a snap if they are the same name as the lumps)."

I plan to write another post that highlights the advantages of DeePSea over WinTex.

Well, Im going to kill this issue.

The color that is always used for transparency is 247 I think, it is completlty black and at the end of the darkest blue color range (it's right before a school bus yellow color and an orange color).

The default representation for this color is teal: or 0,255,255. This color however does not exist in the doom palette (so dont make teal objects, they will be either transparent or turned blue)

Wintex automaticially reassigns the colors in a sprite, graphics, or texture data set to match as closly as possible the doom palette. Wintex will automaticially assign it's transparency color to entry 247 (usually teal, but you can change it).

This allows you to do some extraordinary things. In a snap you can turn a green fireball into a purple, orange, or tutti-frutti colored one by just changing the colors in the image's palette. Wintex will automaticially refit the new colors to other ones in the original doom palette, effectivly making your fireball change color (this is sorta like a palette remap trick the exe does, but it sticks).

Lets say entry 4 in the doom palette is white (which it is), and you extracted an image that had a bright fireball in it - but no white present. If you changed all the colors to white in the image's palette and loaded the graphics back into wintex, it is highly likely that all of those colors will be referenced to entry 4. If you extract the new image it should be one color (two if you include transparenacy).

Any teal-like colors that exist in the graphics are in danger of being remapped to the transparent color, effectivly making them look like they have "holes" in them (usually happens when you try to load heretic/hexen blueish blasts liek the centaur's sheild blast into doom - they get lots of holes in them).

You can change what color wintex looks for to remap to the transparent color in it's main menu.

R255, G0, B255 will make it look for hot pink (a color that already exist in the palette, look out if you have purple sprites).

R0,G255,B255 makes it look for teal colors (bad for hexen spites).

R255, G128, B255 is a pretty unique color, and shouldn't cause much distress (unless you have intense purple sprites).

-----

Recently I made a color palette to replace the doom one that I feel is better. It makes the greens brighter, yellows jsut a little more workable with orange, and includes some teal-like colors that do not conflict with wintex's default transparency.

I took some fireballs such as the cacodemon's fireball and some misc fireballs that werent used in doom (like bal3, bal4, bal5, bal6) but were in doom1 for some reason (rejects? , bal5 may have been used as the plasma balls for the original bfg2740 - the plasma cone weapon, and bal4 was used in part for the arachnotron plasma i think) and changed their colors to provbide a much wider range of special effects for people to use.

Got caco fireballs:
orange
lightning blue
darker blue
teal
beige/white (good for magical effects)
deep orange
frost shards
fire shards

going to post them on my website as soon as i get off my lazy ass and update it (heh, like anyone goes there).

ReX said:

Got it. Thanks.

Btw, reading SirGalahadWizard's post reminded me of another feature of DeePSea that is hugely time-saving:

"...it is a real pain to put in say, a whole enemy because that's about 60 some-odd sprites and it takes about forever to get all the lumps named (inserting graphics is a snap if they are the same name as the lumps)."

I plan to write another post that highlights the advantages of DeePSea over WinTex.

Better you than me - lol.

I better shut up before I get in trouble.

Looking forward towards your views.