Greetings, mortals. I occasionally make Diablo 2 assets
... Meaning that unless I've specified otherwise, these are hand-made. Sometimes they're made purely in GIMP, other times I model them in Blender first, but they're never from other games, and they're never made from assets from other games. My only real goal is that they blend in with D2's actual sprites.

Regarding requests:
Most of what I do is meant for the D2 modding community in general. If you want to put these in a game you're developing, pm me. If you want something specific, I'll see what I can do. However, barring me actually joining your mod team (or whatever) I prefer to fulfill requests only occasionally. If your request is massive (i.e. an entire new GUI or a ton of animations) you may be unsatisfied with the pace at which I work - most of the sprites below gestated for a while before I was happy with them.

"Ready to convert to .dc6" signifies the sprite has already been adapted to the units palette and will not suffer distortion when converted to .dc6. This is also why I upload so many sprites that differ only by color - every one of those color variations have already adapted to the units palette beforehand. Take your pick.

Future project:
- Set of Font with FULL Latin, CHI, JAP and RUS character support. To much time needed.
- BFE by TrueMage - to Simplified Chinese from English
- ES (original) by PerfectCell to Simplified Chinese from English/Japanese
-Touhou Diablo by Bishibosh-A - to English/Japanese from Chinese

Hand-picked

Might be interesting if you created a tutorial on how you had some of these effects, with specific attention to the palette and frame optimization you are doing.

BTW for aura's, anything thats not at the units feet (in fact, any aura/overlay that is meant to envelop/surround), you want to split into a front and back portion. This allows you to have the game correctly render the back portion behind the player/unit instead of on top of it.

Hm. Well, regarding actually making the auras and skill effects, there is no quick-and-dirty method, so I'm just going to dump a bunch of information you'll have to bear in mind if you want to get into this stuff. The heavy lifting is done almost entirely in Blender, and your mileage there will vary based on how well-versed you are with that program. Your biggest constraint will be getting your animations to loop, there are no online tutorials for that. If you're going to take the plunge, my advice is to learn what you need as you need it, do not cover-to-cover a bunch of 3d modelling books. It will be slow at first, then it won't be. Not as painstaking as learning to program, but as there is an element of art here, you'll be relying on your intuition and taste to come up with something decent. And you're never really done looking stuff up, but once you've got the basics down it's manageable.

Actually, there is one rule you'll generally need to follow if your asset is going to be in the game world and not the player's inventory. You'll need to work with isometric projection. To achieve this, press 5 on the num pad to enable isometric projection itself. Then, rotate your camera 60 degrees on the X axis, 45 degrees on the Z axis, and move it to aim it at whatever you're modelling. One thing worth mentioning is that there is no zooming out on big sprites, as objects in the distant background will not shrink in size in isometric projection. So if you want to do something big (I believe the limit on sprite size is 256x256) the most straightforward way to do it is simply exporting the animation to larger png's.

The fire plume thing, for example, was done with the smoke simulator, and as such it took far longer than any of the others to bake and render - fire simulation being extremely resource intensive. The others are just random shapes that slowly rotate, swell, fade, glow, etc., and most of that was achieved using Blender's compositor, keyframing various values along your animation's timeline so that they fade up and down as the animation progresses. The most recent one was achieved using particle emission and sampled motion blur. I also used a vortex force field to give my particles an interesting path. Otherwise they'd just travel upward in a straight line along the Z axis.

All of the auras and such will be split back to front, including the flat ones. There are no frame optimizations, I designed these animations to be as long as they are. Though the frame count will often drift up or down a bit by the end due to tweaking. It's difficult to end up with what you set out to make. If you tweak some random value and the sprite gets noticeably better, it's often better go with it even if turns your original design on its head.

Regarding palette stuff, again, there's not much to it. First I export my animation to png's via Blender. Import those png's inyo GIMP and export it to a .gif, which puts you at 255 colors. The drop in quality at this point is barely perceptible. I then open that gif in Graphics Gale, which is a small, but excellent shareware program for pixel art. It has the most outstanding color depth algorithm I've ever seen. With it you can decrease your color count drastically - by literally hundreds of colors - and it will often spit out something of quality.

Compare these:
255 colors
24 colors

I literally reduced the color count by over 90%, and it still looks less pixelated than the actual blue D2 portal. The difference in speed is from where I omitted every other frame, otherwise the animation would have been 50 frames long. This is why Graphics Gale rules. So, in Graphics Gale: All Frames --> Color Depth --> specify your color count. I match whatever color count the D2 artists used for that kind of sprite, 24 in the case of that portal.

For a little more insight into how this works, look at my avatar. Do you see how its color transitions aren't terribly smooth? That's because gifs are limited to 255 colors, and I'm cycling through the entire rainbow. This is also why my animations tend to stick to one general color - red, green, white, and so on. For this reason I'm convinced Blizzard hand-edited at least some of their auras frame by frame. Specifically Salvation, which has rainbow particles throughout. My method of color count reduction would make that aura extremely noisy.

I'll answer any other questions you have, and I'm sorry for the lack of specifics, but as I said there is no real pipelines, it's just basic 3d modelling. I could probably throw a tutorial together, but it would only be useful for one specific kind of aura, which I will have already made. But if you want it, I'll make one. Hope there's some usable information in here anyway.

Hand-picked

Daimoth" wrote:
Regarding palette stuff, again, there's not much to it. First I export my animation to png's via Blender. Import those png's inyo GIMP and export it to a .gif, which puts you at 255 colors. The drop in quality at this point is barely perceptible. I then open that gif in Graphics Gale, which is a small, but excellent shareware program for pixel art. It has the most outstanding color depth algorithm I've ever seen. With it you can decrease your color count drastically - by literally hundreds of colors - and it will often spit out something of quality.

Compare these:...snip...

I literally reduced the color count by over 90%, and it still looks less pixelated than the actual blue D2 portal. The difference in speed is from where I omitted every other frame, otherwise the animation would have been 50 frames long. This is why Graphics Gale rules. So, in Graphics Gale: All Frames --> Color Depth --> specify your color count. I match whatever color count the D2 artists used for that kind of sprite, 24 in the case of that portal.

For a little more insight into how this works, look at my avatar. Do you see how its color transitions aren't terribly smooth? That's because gifs are limited to 255 colors, and I'm cycling through the entire rainbow. This is also why my animations tend to stick to one general color - red, green, white, and so on. For this reason I'm convinced Blizzard hand-edited at least some of their auras frame by frame. Specifically Salvation, which has rainbow particles throughout. My method of color count reduction would make that aura extremely noisy.

Hmmm, the color reduction step here seems unneeded, because its not really gonna help when you need to convert to D2's fixed palette colors (right now, your tools are just making the minimum palette for the image, not for the game engine). You'd want to index this to the units palette (which you can grab out our filecenter), and then see how well it translates. This is why some of D2's animations look terrible, they had to take a lowest common denominator palette. That being said, I think its better to create and release resources in full color, it opens up certain options one doesn't normally get.

As for the hand edited conversions, I'm not so convinced, I think they where just converted straight out (their palette indexing code is still in D2CMP.dll), its possible that for effects they could restrict the palette during creation.

Yeah, I thought something like that may be necessary by the end. Been putting it off, frankly. I'll try to work it out later today. Let's hope it doesn't bring this whole process to a screeching halt, yeah? I had been meaning to ask about the specifics of this and whether I'd be able to liberally use my own palettes, but it doesn't sound like that will be the case. In any case, I greatly appreciate the info.

Other questions: Will I only be able to use colors that exist in all 5 act palettes? Or can I, as an example, use sprites which use act 2's palette in act 1? I'm aware that palettes can be added to the game, could I possibly use that to get around adapting to D2's native palettes?

Started converting them to .dc6 files. Some came through particularly badly. The most recent overlay (the firey one) came through damn near perfectly. I'll update this thread as I update my sprites.

Last edited by Daimoth on Tue Nov 10, 2015 6:02 pm, edited 1 time in total.

Hand-picked

Daimoth" wrote:Other questions: Will I only be able to use colors that exist in all 5 act palettes? Or can I, as an example, use sprites which use act 2's palette in act 1? I'm aware that palettes can be added to the game, could I possibly use that to get around adapting to D2's native palettes?

The only palatte usable in all 5 acts is the units palette; the other palettes are (partially) act specific, so they'll look fine in one act, and possibly spaz out in another. New global palettes can't really be added, you can replace existing ones (unless you do some code work to allow hot swapping of palettes on the fly*); you might be thinking of the PL2 or monster palshift palettes (the latter of which isn't actually a palette, its a palette indirection for color replacement).

*But this has other issues, for the SW based renderers (Pure SW, GDI), its easy, swap when said image is rendered; but then you have to branch for the HW renderers (DDraw, D3D, OGL/Glide, 3DFX), which normally cache the image as a texture or surface. but now the problem is, some, like D3D expand it out to 24Bit color, so thats easy, others like DDraw create palettized surfaces, which means you have to fiddle with palettes on the DDraw side. Gets a little complex. IMO, one might as well rewrite the gfx driver, allow for non-palette based images.