HD Sprite project Attempt #5,912

So I've been seeing a lot of attempts at making Hd versions of the monsters lately, and well, none of them really seem to either get very far and/or are stopped due to the general consensus that they're lacking in quality, or don't capture the spirit of the originals. I've read a lot of the criticism directed at these, and took them into account when attempting this. Specifically, I laid down a bunch of rules before attempting these sprites:

1. Rather than going for 4x the size of the originals, I'm going for 2x, as this is much faster and less daunting.

2. I am trying to stick to the design of the original monster as closely as possible.

3. I am also sticking to the Doom pallete for these.

4. They'll be freely available for anyone to reuse/edit/etc.



I got this much done within the last two days fairly easily by using a program specifically designed to scale sprites, then modifying the results to look like what you see above. The process of redoing one sprite takes roughly an hour, maybe an hour and a half.



I want to know what people think of what I've done so far. And yes after animating it I have already noticed a few issues with the spikes.

Scaling up without losing the "spirit of the originals" literally can't be done, btw.

I mean, it looks pretty good. But when you faithfully scale up sprites it's suddenly clear how silly they look. I mean, look at a cybs face ffs :)

Making 'Hi-res sprites' doesn't just mean rounding off the corners.

That is unfortunately what most seem to think 'hi-res sprites' means.

But yes, the resolution of the original graphics also hides that some of them may defy logic.

The texture filter thing in the OpenGL renderer does that already, doesn't it?

Blue Shadow said:

The texture filter thing in the OpenGL renderer does that already, doesn't it?

I don't think so. To the best of my knowledge it just smooths out what's there, based on a fixed algorithm.

This is different because it's intelligently (and painstakingly) redrawing the original sprites, frame-by-frame; so if something doesn't look right you play around with it until it does. Also, it's supposed to maintain the crispness of the original sprites, whereas all the texture filters I've seen suffer from universal blurriness.

Alright, maybe it really isn't completely faithful to the originals. I should've worded that differently since being faithful to the originals would be just leaving them alone.

And while the OpenGL renderer does do soemthing with similar results, these still look a bit better in comparison. (Note that version of the sprite is a bit older)

Awesome efforts Egg, but i wouldn't want you to pour too much time into something that people will probably not really appreciate anyway. The only reason I say this is, the sprite looks almost exactly like "scale 2x sai" or whatever in Zandronum's/GZDoom's GL options.

The only true way to get Hi-Res versions of the sprites would be for an incredibly talented person to re-sculpt the models based off the sprites, or hand-draw them at a very high definition. I've thought about this so many times, but I'm just not good enough and hand drawn art, and my sculpting abilities are non-existant.. :P

If I had the time and patience though, the results would be amazing. I hope at some stage someone does this, after all, it's how we got the original sprites in the first place :)

yeah I have to aggree with Doomkid92 there. many source ports like gzdoom or glboom already have scaling algorithms integrated like hqNx or scaleNx. so unless you really wanna put some effort in it and redraw all the animation frames with more appropriate detail your work is pretty much pointless.

I dunno, it's still a bit of a step up from the original sprites even with the scaling algorithm. Among the many purposes of this is to create at the very least base sprites that could more easily be upscaled to 4x than the originals.

I think it looks really good, and still faithful to the original, which is the whole point of this, isn't it?

Looking side by side, yours actually is far better. I just wouldn't want to see so much effort go unappreciated!

Finished the attacking frames.

Sp00kyFox said:

yeah I have to aggree with Doomkid92 there. many source ports like gzdoom or glboom already have scaling algorithms integrated like hqNx or scaleNx. so unless you really wanna put some effort in it and redraw all the animation frames with more appropriate detail your work is pretty much pointless.

Thing is, these algorithms rely on "guessing" what pixel patterns are supposed to be what and are entirely general purpose, meaning that if the algorithm thinks the imp's spikes should look wrong, then they will look wrong every time and there's nothing you can do to fix it. Having a human being inspect the sprites individually and redraw details correctly is the only way the sprites will ever look right after upscaling, so his work is far from pointless, but perhaps a little niche since everyone apparently thinks hqNx is better even though it's completely not

@Fisk
yeah sure, the human brain can interprete the images correctly in comparison to an upscaling algorithm. but still the effort in manually upscaling in contrast to the result seems unnecessary if you can do something very similar with those algorithms. I doubt that you notice a big difference during gameplay.

and nah, I don't like hqNx too. it washes out too much details in my opinion. it's great for unary colored surfaces but not so much for fine detail and gradations.
for emulation I'm pleased with 2xSaI or NxBR, but they both aren't featured in any doom source port to my knowledge. so I usually just use scale2x with bilinear filtering if I'm using an opengl renderer.

@Death Egg
but to give some ideas, besides implementing new upscaling algorithms to the usual source ports you could use one of the advanced ones to use as a basis for a further manual edit. I'd suggest looking into the already mentioned NxBR algorithm, it seems very good in detecting and upscaling edges without destroying detail.
it's based on a paper for vectorizing pixelart graphics by microsoft research and was implemented as a pixel upscaling filter for emulators (like bsnes or finalburn alpha) by Hyllian. I'm pretty sure there was a standalone executable but I couldn't find it, it must be in the release thread. here are the two links:

https://research.microsoft.com/en-us/um/people/kopf/pixelart/
http://board.byuu.org/viewtopic.php?f=10&t=2248

Oh, wow, those results look way better than the current sprite upscaling filter I use. I'm gonna have to see if I can find it and use it instead.

Sp00kyFox said:https://research.microsoft.com/en-us/um/people/kopf/pixelart/

That is a vectorization of a 8 bit sprite that has 1/4 of the resolution of a Doom sprite. Vectorizing Doom sprites ends up in an horrible result. Somebody else already tried this back in the day.

http://www.doomworld.com/vb/showthread.php?s=&postid=932021#post932021

Well, I like it. I personally see an improvement. I quite enjoy the "cartoony" look of the Doom sprites and don't think it does any disservice to the spirit of vanilla Doom.

I think that if it is important to your enjoyment that a lot of people like it I wouldn't keep doing this. But if your enjoyment of working on these does not really depend on how other people like it I would keep working on it. I say, for the sake of creativity and progress, keep up the good fight.

That being said, there are a shit-load of sprites you would have to work on. I just don't see a project like this ever ending.

sigh.

sorry to piss on your parade, but increasing sprite size by (n) on it's own does squat for realism; the higher the res of the sprite, the jerkier it is going to animate. Doom's saving grace is, strangely, the low resolution. The 'raw' pixels actually have an effect on the eye similar to a motion blur.

increasing sprite size by (n) means you're going to have to increase animation frames by (n).

Well as much as I would love to do that idea, that would be double, no, more like triple the work... the only way to be able to add both extra frames and do high resolution sprites of every single doom enemy/item is if I had quite a few people working with me on this. By some stroke of luck though, Sergeant_Mark_IV has just begun working on a project to add more animation frames to the Doom enemies. So, I guess that if he was willing to collaborate and I got quite a few more people to help me, doing such a grandiose project could be possible... Just very, very time consuming.

I suppose if you put each "key frame" into a 3d model (like an x/y/z point per individual imp claw etc) then the "in between" frames could be interpolated. Not sure how, but since each point in frame 0 would correspond to each point in frame 8, you could just move each point halfway toward its next key frame to create frame 4 etc.
A scaling algorithm might make each pixel rounded to an average of neighboring pixels or something, not sure if that would look ok.

if you were going to do that I'd recommend vectors. Trace over the sprite once (including highlights), move it to a position relative to the next frame then 'tween the vertices.

that's what I do.

Sergeant_Mark_IV said:

Vectorizing Doom sprites ends up in an horrible result. Somebody else already tried this back in the day.

like I said, the actual implementation of hyllian is not a vectorization but an ordinary upscaling algorithm which is based on this paper.
I'm not saying that it will look good but it can be a solid base for additional work.

@Death Egg
I found the standalone version, first post on this page:

http://board.byuu.org/viewtopic.php?f=10&t=2248&start=105

Usage: xBR <input png> <output png> [<scale_factor>]
scale_factor: 2x or 3x or 4x. (default: 4x)

btw I'd suggest to use the animation frames from the sprite fixing project by revenant100 which fixes many little issues with the original sprites:

http://www.doomworld.com/vb/wads-mods/62403-doom-2-minor-sprite-fixing-project-v1-2-release-updated-1-1-13/

Sp00kyFox said:

https://research.microsoft.com/en-us/um/people/kopf/pixelart/

The dolphin on the main page is really impressive, and if it wasn't for the slightly bumpy outline I'd think it was hand drawn. Some of their other examples...not so much. More realistic graphics completely lose all of their detail, so this would be terrible for Doom.

darknation said:

if you were going to do that I'd recommend vectors. Trace over the sprite once (including highlights), move it to a position relative to the next frame then 'tween the vertices.

that's what I do.

I guess you use flash for that? That animation looks good/smooth.

Dragonsbrethren said:

Some of their other examples...not so much. More realistic graphics completely lose all of their detail, so this would be terrible for Doom.

I didn't post the second link for nothing. take a look into hyllians thread (from page 11 on). he noticed it himself and made a hybrid shader out of his first attempts, where dithering and small color shifts aren't effected by the original filter and are handled differently. the hybrid variant does a very good job on games with digitized sprites like mortal kombat or donkey kong country, look at the example screenshots in the thread. I think it could work pretty well with doom sprites, it's worth a try.

Yeah, I missed the examples in that thread. Those MK shots definitely look better than what the other page shows.

These monster sprites would fit nicely to the 2x-res item sprites which are available already (those from the Skulltag site back then). IMHO a better approach than trying to do 8x or even higher resolutions and failing miserably with adding details. Hopefully there is a realistic chance this gets finished!

Can't say I'm impressed with the XBR results when presented with graphics which aren't already "vector-like", in their use of block areas of solid colours. On something like Super Mario sprites the results are fairly good but I can't see this working out-of-the-box on DOOM graphics. The sample weighting is just all wrong for those.

you should check out the xbr-hybrid results, they also work well on non-cartoony sprites. here is the shader reposit from the bsnes/retroarch forum:

https://github.com/libretro/common-shaders

it's a problem though to use it on image files, since there is no tool for image processing which can use (cg) shaders for scaling to my knowledge. so one needs to code a little tool to use it.