Definitely got a Kratos from GOW vibe to him, but that does match the feeling you are going for (eg. anti-Hero, driven by rage).
No digits on his hands? Is that intentional? TBH it looked a little like his free hand was missing (chopped off).
The highlight on top of his head is a little shiny, gives him a bit of a plasticy look. Like a bubble or a bobble-head toy. But on the other hand it does soften him a bit, adds to the cartoony charm so maybe it's what you want.
Well those are just my two cents, good luck with the project!
Sunday, June 19, 2016 - 07:57
yeah, that is quite a bit of info there.
There is a tool to generate an 'CREDITS.TXT' file from an OGA collection.
Just look for the 'DOWNLOAD CREDITS FILE' option under a collection,
I don't know id the resultant file covers every box in that list, but it does seem to contain all the information OGA collects for each submission, so I'm not sure more is possible.
It'd be nice to have that button there for individual submissions, or better yet, to have submissions automatically rolled into a zip file that includes the CREDITS.TXT file, but for now this is the best OGA has to offer.
Sunday, June 19, 2016 - 07:48
Just to add to what kagerato's had already said, the scaling algorithm is what will determine how the art looks when scaled or rotated. Nearest neighbor and bilinear filtering are by far the most common and if you are scaling the image 'in engine' than one of these most likely what you are getting. There should be some way to control which filtering algorithm is used, but where that control is will depend on what API/engine you are using. You'll need to check the docs for that.
If you're doing the rotating in MS Paint, there should be some option for what scaling algortim to use. If not, as Magic105 suggests give another paint program a try. Gimp is a good free one. Paint.Net is another one you might try. It's more like MS Paint than GIMP, so might work better for you if you are already comfortable with MS Paint.
Two notes about scaling and rotating with bilinear of other filtering techniques:
These techniques compute the scaled/rotated pixel colors by averaging pixels around a given spot in the original image, INCLUDING TRANSPARENT PIXELS!
Note that in a standard 32bit RGBA pixel (the kind used by most paint programs and game engines), transparent pixels still have color values even if you cannot see them.
These values can 'bleed' into edges of the image when scaling or rotating using bilinear or other 'averaging' type filters.
To take an example from my own experience, imagine you are working on a little 2D character sprite. Rather than working against a blank background, you fill the whole canvas solid green (color 0,255,0) and draw the sprite on there. Then you select all the green pixels and 'delete' them by making them transparent.
Trouble is those green pixels are not really gone, their just set to transparent. If you rotate the sprite using a simple bilinear filter, suddenly the character sprite starts picking up green all along it's edges.
That's because the algorithm is averaging the invisible pixels along with the visible ones!
Gimp doesn't seem to have this problem with it's scaling filters (perhaps it ignores full transparent pixels when averaging pixels?) but from my experience hardware based bilinear filters (the kind your using if you do the rotations in engine) do.
There are several soltions to this problem. The simplest is to flood fill transparent pixels black. This isn't perfect but works better than green!
The more elaborate solution is to add color data to the transparent (invisible) pixels by averaging the color data in the surrounding non-transparent (visible) pixels. There's probably some combination of basic select and scale or blur operations that could produce this effect for you in Gimp, photoshop, etc. Since I am a programmer, I have just written my own program to do it.
Finally, if you are doing the rotations in MS Paint, etc, I've heard it suggested that the best results can be had by first scaling the image by 2x, then doing the rotation, then scaling back down to 1x.
Haven't personally explored this idea, but it's certainly worth trying to see if you like the results better.
@Denislav: The license is CC0 so you most certainly can! Giving surt credit for the tiles would be nice courtsey, but even that is not strictly required.
Friday, June 3, 2016 - 10:57
Well, I think there are two problems:
One problem is a general issue with the search. It's not that great at finding things. Taking my own meager contribution as an example, searching for 'instant dungeon' turns up nothing. Searching for 'dungeon' does turn up the work, and searching for "Instant Dungeon" (with the quotes) returns an endless list of surt's Ikaros submission, I guess because I mentioned Instant Dungeon! in a comment??
Anyways, this is a general issue, and bart was working on a newer search engine that seemed to work much better, so there's hope on this front.
A second, acute problem is that the search cache/database doesn't appear to be updating anymore.
If I search 'dungeon' and sort by date the first result is from Jan 16, 2016. Similarly, if I search 'Town' the most recent result is dated Jan 17, 2016. Search 'tiles' and the most recent result is Jan 16, 2016. Even though, in all three cases there are many newer submissions that should match that search query (admittedly, given problem one, it can sometimes be hard to say for sure what 'should' return in a search).
This problem has occured before, and Bart did eventually fix it. IIRC, he said he did so by pushing a giant 'UPDATE SEARCH DATABASE' button somewhere in the admin pages for the site. My guess is that that was only a temporary fix, it updated the search database with all the submissions up until that moment, but whatever process is supposed to continuously update the database with new submissions is either not working correctly or not running at all anymore. Of course, I don't really know anything about the software that runs this site, so that's really strictly a guess.
Sadly, last time it took months to get the issue addressed and here we are again, this thread is already four months old :(
I really wish there was something I, or anyone else, could do to help with the admin of the site. It seems like the community is doing a great job keeping the submissions going and the mods are still doing there best to handle the licensing issues, etc. but there doesn't seem to be anyone who can handle the site administration (and development, see my seperate post about updating the faqs/guidelines, etc) except bart and he appears to be busy with other responsibilities for now.
Friday, June 3, 2016 - 10:30
These are great! Thanks for sharing!
Kind of takes me back to my Amiga days, when every game seemed to have it's own cool cursor!
Wednesday, May 25, 2016 - 05:39
This is great! Any interest in sharing the layers? It's really crying out for some serious parallax scrolling action!
Definitely got a Kratos from GOW vibe to him, but that does match the feeling you are going for (eg. anti-Hero, driven by rage).
No digits on his hands? Is that intentional? TBH it looked a little like his free hand was missing (chopped off).
The highlight on top of his head is a little shiny, gives him a bit of a plasticy look. Like a bubble or a bobble-head toy. But on the other hand it does soften him a bit, adds to the cartoony charm so maybe it's what you want.
Well those are just my two cents, good luck with the project!
yeah, that is quite a bit of info there.
There is a tool to generate an 'CREDITS.TXT' file from an OGA collection.
Just look for the 'DOWNLOAD CREDITS FILE' option under a collection,
ex.
http://opengameart.org/content/epic-fantasy-music
I don't know id the resultant file covers every box in that list, but it does seem to contain all the information OGA collects for each submission, so I'm not sure more is possible.
It'd be nice to have that button there for individual submissions, or better yet, to have submissions automatically rolled into a zip file that includes the CREDITS.TXT file, but for now this is the best OGA has to offer.
Just to add to what kagerato's had already said, the scaling algorithm is what will determine how the art looks when scaled or rotated. Nearest neighbor and bilinear filtering are by far the most common and if you are scaling the image 'in engine' than one of these most likely what you are getting. There should be some way to control which filtering algorithm is used, but where that control is will depend on what API/engine you are using. You'll need to check the docs for that.
If you're doing the rotating in MS Paint, there should be some option for what scaling algortim to use. If not, as Magic105 suggests give another paint program a try. Gimp is a good free one. Paint.Net is another one you might try. It's more like MS Paint than GIMP, so might work better for you if you are already comfortable with MS Paint.
Two notes about scaling and rotating with bilinear of other filtering techniques:
These techniques compute the scaled/rotated pixel colors by averaging pixels around a given spot in the original image, INCLUDING TRANSPARENT PIXELS!
Note that in a standard 32bit RGBA pixel (the kind used by most paint programs and game engines), transparent pixels still have color values even if you cannot see them.
These values can 'bleed' into edges of the image when scaling or rotating using bilinear or other 'averaging' type filters.
To take an example from my own experience, imagine you are working on a little 2D character sprite. Rather than working against a blank background, you fill the whole canvas solid green (color 0,255,0) and draw the sprite on there. Then you select all the green pixels and 'delete' them by making them transparent.
Trouble is those green pixels are not really gone, their just set to transparent. If you rotate the sprite using a simple bilinear filter, suddenly the character sprite starts picking up green all along it's edges.
That's because the algorithm is averaging the invisible pixels along with the visible ones!
Gimp doesn't seem to have this problem with it's scaling filters (perhaps it ignores full transparent pixels when averaging pixels?) but from my experience hardware based bilinear filters (the kind your using if you do the rotations in engine) do.
There are several soltions to this problem. The simplest is to flood fill transparent pixels black. This isn't perfect but works better than green!
The more elaborate solution is to add color data to the transparent (invisible) pixels by averaging the color data in the surrounding non-transparent (visible) pixels. There's probably some combination of basic select and scale or blur operations that could produce this effect for you in Gimp, photoshop, etc. Since I am a programmer, I have just written my own program to do it.
Finally, if you are doing the rotations in MS Paint, etc, I've heard it suggested that the best results can be had by first scaling the image by 2x, then doing the rotation, then scaling back down to 1x.
Haven't personally explored this idea, but it's certainly worth trying to see if you like the results better.
This is awesome! And you're right, it's a slow burner but it really takes off right at about the 2 min mark.
Love it! Thanks for sharing!
This is great! Thanks for sharing!
Looks yummy! Thanks for sharing!!
@Denislav: The license is CC0 so you most certainly can! Giving surt credit for the tiles would be nice courtsey, but even that is not strictly required.
Well, I think there are two problems:
One problem is a general issue with the search. It's not that great at finding things. Taking my own meager contribution as an example, searching for 'instant dungeon' turns up nothing. Searching for 'dungeon' does turn up the work, and searching for "Instant Dungeon" (with the quotes) returns an endless list of surt's Ikaros submission, I guess because I mentioned Instant Dungeon! in a comment??
Anyways, this is a general issue, and bart was working on a newer search engine that seemed to work much better, so there's hope on this front.
A second, acute problem is that the search cache/database doesn't appear to be updating anymore.
If I search 'dungeon' and sort by date the first result is from Jan 16, 2016. Similarly, if I search 'Town' the most recent result is dated Jan 17, 2016. Search 'tiles' and the most recent result is Jan 16, 2016. Even though, in all three cases there are many newer submissions that should match that search query (admittedly, given problem one, it can sometimes be hard to say for sure what 'should' return in a search).
This problem has occured before, and Bart did eventually fix it. IIRC, he said he did so by pushing a giant 'UPDATE SEARCH DATABASE' button somewhere in the admin pages for the site. My guess is that that was only a temporary fix, it updated the search database with all the submissions up until that moment, but whatever process is supposed to continuously update the database with new submissions is either not working correctly or not running at all anymore. Of course, I don't really know anything about the software that runs this site, so that's really strictly a guess.
Sadly, last time it took months to get the issue addressed and here we are again, this thread is already four months old :(
I really wish there was something I, or anyone else, could do to help with the admin of the site. It seems like the community is doing a great job keeping the submissions going and the mods are still doing there best to handle the licensing issues, etc. but there doesn't seem to be anyone who can handle the site administration (and development, see my seperate post about updating the faqs/guidelines, etc) except bart and he appears to be busy with other responsibilities for now.
These are great! Thanks for sharing!
Kind of takes me back to my Amiga days, when every game seemed to have it's own cool cursor!
This is great! Any interest in sharing the layers? It's really crying out for some serious parallax scrolling action!
Pages