Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
mac53

Doom 2 Sprites Project Inquiry

Recommended Posts

I am attempting an enhancement project for the Doom 2 iwad sprites. After extracting them to a folder and converting their formats to png, 24 bit true color and resolution increase to 200 pixels, I have constructed two
separate sprites wads using Xwe. One wad I used the standard wad building techniques by loading the sprites
in between the SS_ headers. Although I had gone through extensive graphic display enhancements, the sprites
still doesn’t display as well as I would like to see them. Plainly put, if I enhance these sprites any more, then I'll probably start seeing graphic distortion. On the other hand, my second sprite's wad, the same enhanced pngs were loaded in between to headers SS_, but as "raw data", and are being displayed as pngs and not sprites.
There are no x-y offset settings and trying to match these settings with the ones from the Doom 2 iwad is useless!
---------------------------------------------------------------------------------------------------------------------------------------

After say this... Here's what I would like to accomplish.

Using the standard enhanced sprites wad, the Doom 2 engine just breaks them back down to the 256-color palette!
There's nothing I can do about this, so this approach is out! On the other hand, if I can get the "raw data" sprites wad to display the sprites thus getting around the filtering of the engine, then this is what I'm interested in doing!!!
I'm using the Zdoom/Hexen format for the construction configuration of my map and am recommending Gzdoom
port engine for game play, because of its excellent OpenGL rendering capabilities. What processes do I have to
do to get these "raw data" sprites into my map and function properly for game play?

Share this post


Link to post

Hmmm....no idea really because I'm only using WinTex, and I don't really know if any port really supports 24 bit sprites. Some DO support truecolor pngs for skyboxes and the such, but sprites, as well as textures, are typically limited to the One True Doom Palette, as they are subject to lighting effects etc.

At least WinTex would refuse to open anything but 8-bit bitmaps, and would then convert the to the "one true Doom palette" by a closest color matching. Dunno how XWE handles that, though, but I assume that even if it's capable of opening 24 bit images, first it downgrades them to doom's palette and 8 bits, before storing them.

Same thing goes for "hi-res" sprites": making them bigger, will also make them look bigger, for there is no "scale correction". So if you make an imp large enough to be detailed as a cyberdemon, it will also look big like one, you can't have two different units for textures and sprites.

Also, since the "enhanced" look you're probably accomplishing via spline "resolution enhancers" and hardware texture filters, which can be done real-time by OpenGL capable ports, this whole thing has little sense.

Just for curiosity, what source port you're using that explicitly says that it support 24 bit sprites and/or hi-res sprites for use with the Doom engine? The only one I know that kinda gets close to that is Risen3D, but that's another story altogether.

Share this post


Link to post

From what I understand, Gzdoom handles the Hi-Res in OpenGL pretty good. At least that's what I hear! Now, as far as rendering 4x Hi-Res sprites, either a "Dehacked" or "Decorate" has to be written for each of the 1,381 sprites!!! I know, I know... If this is so, then that's a helava lot of work and believe me I agree. This is something I'm looking into... just probing around to see what I can find out. I'll tell you this much though... I extracted all the sprites from the iwad, changed them to 24 bit true @ 400 dpi, then ran them through some filters... technically cleaned them up and enhanced the hell out of'em, then made a wad. I merged the wad into the map that I'm working on and this is no sh!t... they look pretty damn good just with the little work I put into them. Now, as far as Risen3d!!! Now, this is my opinion... "sucks", for a port engine. It's one of the most unstable piece of work I've seen while I've been in the Doom authoring kingdom. Back to the sprites issue, if you are interested in taking a look at this wad I put together, then just let me know and I'll upload it to a ftp and post the link to it, so you can download it. That way you can see how they look. Just let me know.

Share this post


Link to post
mac53 said:

Here's what I would like to accomplish.

Using the standard enhanced sprites wad, the Doom 2 engine just breaks them back down to the 256-color palette! There's nothing I can do about this, so this approach is out! On the other hand, if I can get the "raw data" sprites wad to display the sprites thus getting around the filtering of the engine, then this is what I'm interested in doing!!! What processes do I have to do to get these "raw data" sprites into my map and function properly for game play?

Mac, I know that sprites in png format can be used in ZDooM & GZDooM, but they need to be 8-bit (I believe). I have not heard of 24-bit graphics being supported, but I am not an expert in this matter, so you should check at the GZDooM forums.

In response to what Maes said, sprites do not need to be oversized. Using either DECORATE (the preferred method) or DeHacked you can scale sprites down or up. If a png image is being scaled down, GZDooM and ZDooM will retain or enhance the image resolutions, so that you will get no color loss. I'm not sure if this is also true for 24-bit images. Again, check at the ZDooM forums.

Share this post


Link to post

Hi Rex... How ya doin?

I have a link that I would like for you or anyone else to check out
in order to see how these sprites turned out for me. The sprite
texture went in fine as 24 bit color. Now, whether or not the format remained that way when they were loaded in as a wad, I have no idea. But, if you would like to see what they look like then go here:View

and scroll down to where you see the first pic. There are other links there also.

mac

Share this post


Link to post
mac53 said:

But, if you would like to see what they look like then go here:View

I took a look at the pics, and they surely have better definition and colors than the original DooM sprite graphics. However, because the pictures are relatively small and your enemies are far away the degree of improvement is difficult to gauge.

If you want to get real close up to an enemy without them being active, simply use your map editor to make them dormant. Then you can get as close to them for your screenshots as you like. I believe your improvements will be more evident in close-up screenshots.

Share this post


Link to post

Thank you for you compliment... You mentioned for me to use my editor to stop the movement of the monsters so I can get closer shots of them... How do I do that, Rex? I'm using DeePsea.

Share this post


Link to post
mac53 said:

You mentioned for me to use my editor to stop the movement of the monsters so I can get closer shots of them... How do I do that, Rex? I'm using DeePsea.

It's been a while since I used DeepSea, but I'm pretty sure that in the Thing attributes you should have the ability of selecting "Dormant". In other words, open your map in DeepSea and select your enemy. The properties menu (or attributes) should appear - the one where you make your selection for skill level, deafness, player class, single or multi-player, etc. In there will be a selection for dormancy. Check the box, and your enemy will be completely still in-game. The great thing is that in this way you can get behind the enemy or to its side (i.e., all the eight frames for a still sprite will be available to view by circling around the enemy), and get very close.

To reverse the dormancy (i.e., make the enemy active again) in-game requires a simple script or a linedef switch with the Thing_Activate(tag) special.

Share this post


Link to post

I downloaded the Dm2Sprites.zip thing and....maybe I didn't figure out what you were trying to do exactly, however the file size seemed a bit suspicious: 3.6 MB unzipped WAD size for something that was supposed to carry 400 dpi true color sprites, seemed a bit too small to begin with.

Then in game: I tested it with various ZDoom versions (namely ZDoom (pure software) and ZDoomGL and GZDoom, however that would later prove not to be the point: the sprites were at normal resolution and used the same old doom palette, period.

To confirm this, I extracted them with WinTex: if those were truly hi-res true color images, WinTex should have cried in pain, but it didn't, it displayed and extracted sprites just fine. The only visual difference, is that they look like somebody applied a filter than made their edges more sharp and visible, like they were comic drawings, and heavily saturated colors and boosted contrast, while still using the One True Doom Palette.

This just confirms what you said about DECORATE: unless you use port-specific extensions, you can't exceed the normal scale and detail/color depth of ANY texture or sprite within the game.

OpenGL ports basically pre-compute a "beautified" version of sprites and textures and use them for display, or use real-time filters that "smooth" things out, and have the side-effect of using 24-bit color depth (or 32 bits, with alpha transparency).

3D ports on the other hand use models, which too, have the side-effect of being true color and not following the usual map unit conventions that apply to normal sprites and textures.

So...sorry to say it, but nothing accomplished with your sprite mod. It's just a rehash containing most Doom (and Doom 2?) sprites at their original size and resolution, only with altered colors, which is debatable if they look better.

The screen shots you have posted on that other site were obviously taken with an OpenGL or otherwise 3D accelerated port, judging from the smoothing effect. Whether your "enhanced" sprites look better than "normal" sprites when used in a hardware accelerated source port is something else, but they still are not hi-res, nor truecolous sprites, at most they can be labeled as "optimized for better appearance after hardware bitmap filtering".

@Rex: the "improvement" is only given by OpenGL/Direct3D/hardware texture smoothing, not by the sprites themselves. Take a look at the cyberdemon +rocket pic: the texture filtering is apparent on the rocket, and has NOTHING to do with the sprite resolution itself. Also, in the Cacodemon pic it's obvious how it's the hardware filtering alone giving the illusion of a higher resolution, and not equally for every detail.

Share this post


Link to post

Simple... you don't like it don't use it. I spent around a week enhancing these sprites and no, I never declared them Hi-Res just enhanced, but I am working on a project to make 4x Hi-Res sprites!
You're not the only one that downloaded this file. I have received compliments about the wad. Now, whatever you extracted these sprites with, doesn't change the fact that they were 24 bit color @ 400 dpi when I loaded them into the wad.

Share this post


Link to post
mac53 said:

Simple... you don't like it don't use it. I spent around a week enhancing these sprites and no, I never declared them Hi-Res just enhanced


I agree on the "don't like it, don't use it" part, as for the enhanced, that's debatable. I hope the 4x-res sprite project has more success, but I would personally advise you to avoid putting any more effort into it because:

  1. In the best of cases, it will be highly port-specific.
  2. Visually, it will NOT look better than OpenGL/Direct3D filtering (actually, that kind of filtering can exceed even a 16-fold artificial incease of resolution)

Now, whatever you extracted these sprites with, doesn't change the fact that they were 24 bit color @ 400 dpi when I loaded them into the wad.


...and now they are not. Both XWE and WinTex extract them for what they are: standard resolution, 256 color doom-format bitmaps. Whatever "enhancements" you applied must have been lost somewhere in the way, and all that was left of them was a sprite recoloring. Even VANILLA DOOM is capable of using your "enhanced" sprites (after removing some off-spec entries), if that means something.

When loading them, XWE probably just took your 24 bit images and properly converted them into 8-bit images using the Doom palette, as it should.

You probably never worked with "high-res" images at any part of the process, and contrary to what you many believe, the DPI setting doesn't affect resolution. You can have the same exact pixel dimensions, but different DPI settings, which won't have ANY effect on how Doom or XWE will display your sprites.

It's not time for an image processing course, but changing the "physical dimensions" and DPI of any image, DOESN'T change it's resolution in pixels, only its intended printing resolution and size: you can even have a 10x10 PIXEL square image and declare it as having a 1200 DPI print resolution and to be printed 1 mile wide per 1 mile tall, but that won't change it's screen resolution of 10 x 10 pixels.


Get over it, you didn't do anything original or groundbreaking with your sprite recoloring attempt (that's the best way to classify it).

Share this post


Link to post

I'm not quitting Maes... No matter how much you sit there and write these long drawn-out posts. It's people like you who like putting other folks down for their efforts. No, you get over it and stay the hell off my thread!

Share this post


Link to post

If you feel so confident of what you're doing, I invite you to upload this to idgames and test the reaction of gamers.

And I didn't tell you to "quit", just to put more energy into something that will be better for you and for Doom, like e.g. a nice big level with new graphics, instead of something essentially useless.

Again, if you think what you're doing is not useless, then let's upload it at idgames and see people's reactions.

Share this post


Link to post

Let's upload DM2Sprites.wad then, and see what people will think of it :-) If you don't upload it, I will. :-D

Share this post


Link to post
mac53 said:

why not? this project is in it's testing stages anyway.


One of the BFG sprites (BFE1F0) is corrupted, and gives an error, perhaps you'd want to fix it.

However, it just hit me that this wad of yours could be just barely legal to distribute: since it essentially contains all of Doom II's sprites in their original resolution, only with altered colors, the file is usable even with vanilla doom (I tested it, it works if the broken entry is removed) and could be considered borderline distribution of original iD artwork (not sure about it, better ask someone more knowledgeable about it). Or it may just be subject to the same rules valid for recolorings/minor edits of original sprites ( a lot of other WADs or TCs use those, so it may really not be a problem).

However, until the legal stuff is clarified you should probably remove the download link(s) ASAP and not upload it anywhere, yet.

Share this post


Link to post

Valid Point!!!

I was thinking about that, wasn't sure and like I said in the read me file, that the enhanced sprites weren't altered from their original state, other than changing them from the 256 color palette
to 24 bit. Doing so, allowed me to work on the color and richness
of them. Hell, I even used the same offsets from the actual positions in the iwad. See Maes, try to understand that I am trying to help out in the community, not screw anything up. I'm new at mapping and saw that the only thing that needed updating were the sprites. So, I had an idea and that was to extract them, run them through some filters... which we all probably agree... they look a hellava lot better than the originals, and was just going to keep them for my own map authoring. After loading them in and saw how nice they looked when I ran the map through Gzdoom, I just wanted to share this with other authors and even players if they wanted to launch it with the map. These were my intentions! As far as pulling it! I'll pull from here, but will keep it at the original location.

Now, you talking about a corrupt BFE file? Because I didn't see it. Now, I'm going to go back and check it out. And by the way... if you're interested in helping me out with the actual Hi-Res project I'm attempting, just let me know.

Share this post


Link to post
mac53 said:

I was thinking about that, wasn't sure and like I said in the read me file, that the enhanced sprites weren't altered from their original state, other than changing them from the 256 color palette
to 24 bit.


Actually they still are 256 color, they just have been processed and recontrasted/recolored. I also saw that if you load an image file in XWE when editing a graphic/patch/sprite lump, it will be automatically processed and converted to the standard 256-color doom palette and into DOOM's internal bitmap format, with all its inherent limitations.
To avoid that, you must tell XWE to load "raw data", but this probably makes the standard preview and alignment tools unavailable. Instead, you must use scripting for those.

The sprites in your DM2Sprites.wad are still 8-bit, that's why vanilla doom/chocolate doom are still able to use them, and tools with no support whatsoever for truecolor like WinTex can display and extract the entries with no problem.

To load and use 24-bit images, you should first find a source port that 100% guaranteed accepts them as such (I *think* ZDoom and maybe others accept PNG format images, but you must load them as raw data, so what they find is a PNG image, and not a standard DOOM image/sprite lump. Of course, then there are scaling/resolution issues to handle and you should probably use DECORATE (for ZDoom) or whatever other extension is used.

if you're interested in helping me out with the actual Hi-Res project I'm attempting, just let me know.


As I said, I wouldn't bother with something like that because it's really too much work, and with a great chance of going unappreciated and/or appear substandard/getting dissed, since any OpenGL port produces "enhanced" sprites using only iD's original WAD. Those look like they're 10-16x times the original resolution and acquire truecolor depth, not to mention fully 3D ports.

Unless you redraw the sprites one by one and at least double the resolution (that is not the same thing as automatic scaling), they are not going to look any better than any OpenGL port can do automatically.

I can give you tech tips, if you still wish to proceed, but nothing more.

Share this post


Link to post

Ok... sounds good... Any tips you can send my way would definitely be appreciated!

Actually Maes... I did load up a wad with "raw data" sprites. I haven't played with that one, yet. I'm thinking that the offsets may be a bitch to adjust though.

You mentioned about "redrawing", what do you think about the idea of me trying to find a way to have rescanned? Wouldn't that do a better job than the actual redrawing?

Share this post


Link to post
mac53 said:

Ok... sounds good... Any tips you can send my way would definitely be appreciated!


Well, first document yourself on which source ports -if any- support 24 bit sprites and graphics, and allow resolution scaling to match game units, and with what methods. Probably it must be done, as you said in one of your first posts, with a combination of loading PNGs and scripting, that's why none ever considered doing a full hi-res TC.

Also, using general-purpose editors like XWE is not very helpful in this case, as it can essentially only load the PNG files as raw data, at best, without aiding you in setting offsets or scale

E.g. Doomguy's DEH stats are 56 units tall and 20 units wide, and his PLAYB1 sprite lump is actually 56*37 pixels (he can look wider than the places he can squeeze into!). Other Doomguy's sprites may have different sizes.

Anyway, supposed you produce a 24-bit png of PLAYB1 upscaled to exactly 2x the original resolution, both V and H, so that would be 112*74 pixels: without a scaling correction, Doomguy will look GIGANTIC (without considering color depth yet)

So you need a way to tell your source port to:

  1. Load 24-bit PNG images for some or all of the sprites
  2. For each of those images, apply a scaling corrective factor when displaying them (Doomguy must still appear 56 game units tall to render correctly, so a scaling must be applied.
A side effect of this is that Doomguy's pixels will look smaller than those of e.g. nearby textures or unprocessed sprites. From a distance, he will not look anymore detailed from normal sprites, while from a closer distance, he will appear more detailed up to certain point, before starting to pixelate again.

Other issues:
  1. Size: 24 bits means 3x more space compared to 8 bit, and 2x increase in resolution means 4x the initial space. Sure, PNG files are compressed, but in memory those hi-res sprites will consume 12x more memory than normal ones, for just 2x increase of resolution. That's one of the reasons why gaming switched to 3D models, eventually.
  2. Port support: most likely, only OpenGL ports will be able to use 24 bit sprites, as those Doom software renderer only works with 8-bit graphics, and uses special palettes for lighting effects, which true colour sprites cannot use. No idea if a mixed port could be made, that uses both. OpenGL ports however use exclusively OpenGL functions for that.
  3. OpenGL/Direct3D texture filtering: that feature alone makes the whole hi-res sprites useless, as even "normal" sprites will benefit from it. Sure, hi-res ones will still look a bit better, but basically it will be like they have just one extra step of pre-filtering and different color balance, so they won't look VERY different from normal ones.


You mentioned about "redrawing", what do you think about the idea of me trying to find a way to have rescanned? Wouldn't that do a better job than the actual redrawing?


I said "redrawing" because that's the only way you can enhance/add detail on original sprites. Using Photoshop's "smooth scaling" or even the best spline modelling program won't magically add extra detail on sprites when there isn't any. That's what texture filtering does, btw: it creates smoother color transient and makes things look less blocky, but it doesn't really add detail where there isn't any.

About rescanning...unless you have access to the original clay figures and metal&latex models of some of the original Doom sprites, it's unlikely you'll be able to digitize them again at a better resolution. Most of them were hand drawn though, and again it's unlikely you'll be able to get hold the original drawings (if any, they could have just been drawn at that resolution in the first place).

An intermediate solution is to create accurate 3D models of the original sprites, and use those as a basic for producing hi-res and true-colour 2D sprites (yeah, that involves rotating and taking 8 photos of each model in every possible pose). 2D spriting is a bitch :-)

Share this post


Link to post

Correct me if I'm wrong...

Basically what I get out of what you're telling me is, to accomplish this, I'll have to write a decorate covering each and every sprite, something of which I already knew. Then, after going through the process of making them Hi-Res, then there's a chance that there will be very difference in the appearance! Is this what I'm hearing?

Share this post


Link to post

Maes said:
An intermediate solution is to create accurate 3D models of the original sprites, and use those as a basic for producing hi-res and true-colour 2D sprites (yeah, that involves rotating and taking 8 photos of each model in every possible pose). 2D spriting is a bitch :-(


I hear you... load and clear. Well, the best thing I tell you I can do, is to throw an effort into it and see what turns out! I'm not in a major hurry, but I really would like to do something cool for the Doom community!

Share this post


Link to post
mac53 said:

Correct me if I'm wrong...

Basically what I get out of what you're telling me is, to accomplish this, I'll have to write a decorate covering each and every sprite, something of which I already knew. Then, after going through the process of making them Hi-Res, then there's a chance that there will be very difference in the appearance! Is this what I'm hearing?


Yes. Oh and BTW...

First I checked through your WAD with XWE: once again, the sprites are at normal doom resolution (e.g. doomguy is 56*37 pixels, nothing wrong, and the BFE1F0 entry is still borked BTW...).

I extracted a few of them and used "color count" in PSP: OK, so now they HAVE more than 256 colors, but that's not really a feature when there are barely more pixels than colors in any image; anyway:

I tried to use both ZDoom and GZDoom with them: ZDoom uses a software renderer, GZDoom uses OpenGL. In both cases, the sprite offsets were far off (but that was expected, so no problems here). A bigger problem was that most of those sprites lacked transparency, so they appeared like big cyan,blue or grey boxes containing sprites.

What's more, both ports first applied a sort of color downstep to 8-bit before displaying sprites (at least ZDoom did so), so they really didn't look any different from the "non-truecolour" version of the sprite wad.

I'm not sure if GZDoom actually applied it, however it didn't look any better. I tried to artificially increase to resolution of some sprites in PSP using bilinear filtering, and guess what, they look exactly like OpenGL sprites do. So even if you successfully scale up all the sprites with bilinear/trilinear/whatever filtering, save them as truecolour images and fix all offsets and scales, AT MOST you will make software-rendered ports look as good as OpenGL ones, provided they can render 24-bit sprites, while OpenGL ones will show little improvement.

Share this post


Link to post

Ok...

Let me explain that BFE1F0 file. There's a contact I have been tossing this idea, [Hi-Res sprites] with in the UK. He downloaded my sprites wad and had a look at it and made a comment about the BFE1F0.lmp. I explained to him that's how this particular file was extracted using Xwe, I also asked him what was this file all about. He explained to me that certain softwares don't see this file properly and Xwe is one of them. Then, I asked him what was this lmp suppose to represent and I was told "a graphic", just like the rest of them. Well, I asked him if he had the graphic form of the particular file, he said yes, and sent it to me. The file's not corrupted Maes, it's just a long thin line that's displayed during the end [final frame]of a BFG shot. So, there's your answer and BTW, it's works very well in my map.

Share this post


Link to post

Exactly what source port are you using for testing?

Latest ZDoom and all of its derivatives, and also latest PrBoom, report that particular sprite as invalid.

ZDoom in particular says "Invalid data for TEXTURE BFE1F0", which means it doesn't even recognize it as a sprite.

XWE doesn't display it as either a sprite or PNG image, about only displays raw hex data, which also means it can't display it as any known type.

More in detail, for the WAD with all the PNGs (dm2sptspng.wad) all other sprites' types are set to "PNG" and display correctly (although with borked offsets), while that particular entry proudly displays "SPRITE" as its type, and doesn't get displayed as anything but raw data.

The "non truecolour" wad, Dm2sprites.wad, has the type of BFE1F0 set to SPRITE but again, DOESN'T display it correctly.

WinTex actually displays something, but that something is an obviously corrupt graphic, which doesn't look like a line at all.

The bottom line? Entry BFE1F0 is broken and needs fixing.

So what we have so far? A wad full of standard-resolution sprites which lack transparency, which get downsampled to the 8-bit One True Doom palette anyway, and a nonfunctional entry, at least when using the most popular ports and editors.

If you got entirely different results, then it's about time you specify what source port this WAD is intended to be used with, as it's obviously not prBoom or ZDoom friendly.

Share this post


Link to post

And for everyone who thought tl;dr, this is a waste of time with little to no real benefit. This is not a personal attack against anyone, it's just the facts.

Share this post


Link to post
mac53 said:


Same thing: Dm2Sprites.wad looks just like it did with older versions, and dm2sptspngs.wad looks still broken and with cyan boxes around each sprite. Any "enhancement" in appearance is given only by the OpenGL renderer, and disappears when switching to the software renderer.

So once again, nothing accomplished. The only one of the two files that has some usability is Dm2Sprites.wad: in software render mode it looks just like normal Doom 2 sprites, only with different colors (some may find them better, some may not).

In OpenGL ports, your recoloring may lead to better-looking sprite texture filtering in some cases, but the sprites are still limited to 256 colors, which limits what can be achieved.

Share this post


Link to post

Alright... Thanks for the finalizing report...

I merged these sprite into my map I'm working on and the sprites look great and I have absolutely no problems with them. Sorry about your negative experience!

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×