Easy to do in gimp - change the image mode to Indexed and choose the dithering method. Gimp does both the palette reduction and the dithering using algorithms that were invented in the 70s. The one I used there is "positioned" dithering, which is also the easiest one to do by hand, so there is a lot of pixel art which is hand-dithered using that technique too.
16-bit game art looks the way it does because of the limitations that were imposed on games running on that era of hardware: the low screen resolutions, and a low, fixed number of different colours on screen at once. Megadrive and SNES games were usually at a 320x240 screen resolution; PAL Amiga games were at 320x256. Art for Megadrive games usually had to be limited to having no more than 32 different colours on the screen at once (and I think it may have been only 9-bit colour, while the Amiga used 12-bit colour). SNES games could have 128 colours on screen at once, and Neo Geo games could have 256. So to get that kind of look, you re-impose some similar limitations.
Preserving any of the detail in this image - especially on the face - at lower sizes looks to me like it would require a lot of manual post-editing. To scale down well to smaller sizes without manual work, the original needs to be drawn with wider brushes, to avoid creating high-frequency detail. The large character pictures on surt's CC0 thread are a great example of how to do that.
Do not learn C++ for game development. Nobody in their right mind will be using C++ for that within a few years. It's on the way to being a niche industrial language, it takes years to get genuinely good at it, and there are way better options now. Learn C++ for learning C++, not for any other reason! It's an "interesting" language in every sense of that word. If what you really want to do is learn C++, then small-ish game projects (e.g. roguelikes) can be a good starter.
Out of "traditional" languages, Python, Javascript, and C# seem to me like the best choices right now, depending on whether the engine that you want to use supports them. You can write code that is "fast enough" in all of these if you know what you're doing, and until you know what you're doing then any language can produce slow code. So you want one that is relatively easy to use, and try to make something which the available hardware can easily run with only a fraction of its power.
Always start from something that already works. I.e. find someone else's source code which isn't too big or complicated, does something remotely close to what you want, and already works when you build and run it. Then start working out how to change its behaviour in various ways.
Easy to do in gimp - change the image mode to Indexed and choose the dithering method. Gimp does both the palette reduction and the dithering using algorithms that were invented in the 70s. The one I used there is "positioned" dithering, which is also the easiest one to do by hand, so there is a lot of pixel art which is hand-dithered using that technique too.
16-bit game art looks the way it does because of the limitations that were imposed on games running on that era of hardware: the low screen resolutions, and a low, fixed number of different colours on screen at once. Megadrive and SNES games were usually at a 320x240 screen resolution; PAL Amiga games were at 320x256. Art for Megadrive games usually had to be limited to having no more than 32 different colours on the screen at once (and I think it may have been only 9-bit colour, while the Amiga used 12-bit colour). SNES games could have 128 colours on screen at once, and Neo Geo games could have 256. So to get that kind of look, you re-impose some similar limitations.
Here's two very quick ones.
Preserving any of the detail in this image - especially on the face - at lower sizes looks to me like it would require a lot of manual post-editing. To scale down well to smaller sizes without manual work, the original needs to be drawn with wider brushes, to avoid creating high-frequency detail. The large character pictures on surt's CC0 thread are a great example of how to do that.
I made an expansion for these: https://opengameart.org/content/heroine-dusk-in-world-monsters
Shame not to show the animations. Like the designs though.
Maybe also "Dragonman". That's definitely a dragon man. Or a man dragon.
"Dragonborn" may be more commonly associated with Skyrim these days...
Love those buildings.
The quality here looks to me as good as GBA- and DS-era pokemon games.
Some pretty sweet stuff here. That innkeeper sprite in particular is gorgeous.
That twig girl is seriously good. Could be a new character made for a Flintstones SNES game with a more chibi-leaning art style.
I love the tiny ghost as well. He deserves to be in some roguelike tilesets.
Oh wow, this is an old and long-running thread.
Do not learn C++ for game development. Nobody in their right mind will be using C++ for that within a few years. It's on the way to being a niche industrial language, it takes years to get genuinely good at it, and there are way better options now. Learn C++ for learning C++, not for any other reason! It's an "interesting" language in every sense of that word. If what you really want to do is learn C++, then small-ish game projects (e.g. roguelikes) can be a good starter.
Out of "traditional" languages, Python, Javascript, and C# seem to me like the best choices right now, depending on whether the engine that you want to use supports them. You can write code that is "fast enough" in all of these if you know what you're doing, and until you know what you're doing then any language can produce slow code. So you want one that is relatively easy to use, and try to make something which the available hardware can easily run with only a fraction of its power.
Always start from something that already works. I.e. find someone else's source code which isn't too big or complicated, does something remotely close to what you want, and already works when you build and run it. Then start working out how to change its behaviour in various ways.
Pages