I like big butts!
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:
- Load 24-bit PNG images for some or all of the sprites
- 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.
- 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.
- 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.
- 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 :-)
Ranked #1 in google for FORCED and PAINFUL! Ranked #3 for Chocolate Shotgun!
Last edited by Maes on 02-25-07 at 21:14