I like the idea that the mappings are displayed in between the two pictures like that.
Having slept on the idea, is region mapping really the right approach? What about a way to simple specify how many different mapping sets you want? Something like this butchery of your very nice mock-up?
The idea is this would save you both the initial step of creating 4 copies of the sprite in your source image and the trouble of defining/saving/loading a set of region maps for it.
I could see other uses for the region mapping concept. For example if you had a sprite sheet with multiple different characters on it, you may want to use a different mapping for each character. But in your case, taking one sprite and spinning off multiple color variants it seems like it would be easier just to tell it 'I want 5 variants'.
Quick questions:
Merge - creates a third color that is: (color1 + color2) / 2?
Revert - restores palette from source file?
Best Fit - selects the closes value in target palette? based strictly on HSV or RGB, or is it worth doing a CIE Delta E Color Difference computation?
Mapping - Remove - if don't specify a mapping for a color what happens? Does it just pass through as itself or does get dropped (mapped to black?)? I guess I prefer the idea that there is always a mapping defined for each color, even if it just points to the same color. Is the idea that you only want to see the mappings that actually change something? Maybe a toggle to show you all the mappings and one to show you just the 'changes'?
Tuesday, July 11, 2017 - 21:11
@Noonan.Design: wow! Must've been some long train rides. Looks great, I especially love the way the trees bounce as you run past them, great little extra touch!
@stackboot: That's a really clever inversion of the normal shmup format, I love it! Bonus points for dropping the FBI screen in there!
@styno333: Nice choice of sprite! Definitely one of my all-time OGA favs! Can't wait to see where you take it!
@MedicineStorm: I'm not sure I understand what's going on in that screenshot but whatever it is it looks awesome!
I've been lost in palette swap land but that idea that I said's been percolating has gotten clearer in my mind and there's still time...
Tuesday, July 11, 2017 - 19:38
@surt:
> to be bothered to use something like this outside of the editor
Just want to say I agree with your general sentiment here. There's sort of a high bar before I want to fire up a separate tool for something. There's also the distinct possibility that one might want to edit the output sprite somewhat in order for it to work right in the new palette. To be honest, the whole thing would probably best be done as a script or extension for some existing editor. Indeed, if I was fluent (or had more time to get fluent in) Gimp's Script-Fu or Grafx2's LUA script engine, I'd have certainly tried going that route. On the otherhand, doing it homebrew has at least given me a chance to puzzle out what exactly 'it' is.
> perform many different mappings on different areas of the same image
That's interesting, sort of the inversion of what I was thinking with the bulk application stuff. That's applying one mapping to many sprites. Here the idea would be to apply multiple mappings to the same sprite. Definitely doable. I guess to keep it simple, you'd just set the grid size for the sprites (over even just the row height) and then it'd let you set a mapping for each row. That would be as opposed to something that let you select wholly arbitrary sections of the source image.
> Being able to create new colours is important, rather than being limited to a pre-existing palette.
Interestingly, one of the big 'aha' moments I had thinking about how to lay this out was realizing that I explicitly /didn't/ want to edit the palettes (add/change colors, etc). My use case was pretty narrowly just converting sprites from one palette to another. Still, I can certainly see where this would be helpful for other cases and it wouldn't be too big a deal to add. The idea is you'd be able to alter the palette in the THIRD row, adding or changing colors, etc. Is that what you were thinking?
> support for gradient-to-gradient mappings
Definitely an interesting idea. You're not suggesting that the tool /create/ any colors for the gradients right? Just sort of 'auto-assign' mappings for the gradient. The gradients would have to be arranged in good order in the palette views right?
So you click four colors: start of src gradient, end of src gradient, start of new gradient, end of new gradient
And it sets up a mapping for start of src gradient through end of src gradient to start of new gradient to end of new gradient?
If you picked:
start src gradient = image palette #1
end src gradient = image palette #4
start new gradient = new palette #1
end new gradient = new palette #4
you'd end up with a mapping like:
1->1
2->2
3->3
4->4
and if picked something like:
start src gradient = image palette #1
end src gradient = image palette #4
start new gradient = new palette #1
end new gradient = new palette #8
1->1
2->3
3->5
4->8
and if picked something like:
start src gradient = image palette #1
end src gradient = image palette #8
start new gradient = new palette #1
end new gradient = new palette #4
1->1
2->1
3->2
4->2
5->3
6->3
7->4
8->4
So basically, it either repeats or omits colors as needed.Not too big a deal really, toughest part would probably be GUI'ing it up in a way that makes it clear what the heck you're doing ;)
@Evert: Indexed colors is definitely close to what I'm after, and you're right, Gimp's index color toolset is 'Ok' ;)
@surt: Had not heard of GraphicsGale, but took a look and it looks fantastic, will definitely give it whirl. I guess the idea with your method is that you can quickly check any palette changes against the original since you'd have both versions open in the editor at once.
@DawnBringer: Indeed, GrafX2's 'Swap' button feels tantalizingly close to what I am after.
After sleeping on this for a bit, I came up with some stronger vision for what I wanted and went ahead and viddled something up. Feels a bit like bad programmer hubris as I know somewhere there must be a tool that already does this and much better, but what can I say, guilty as charged. :) Attaching two screen shots of the tool in action.
Tool shows the original image on the left and the color swapped image on the right.
There's a small window that show's three rows of colors.
First row is the colors in the original image.
Second row shows the corresponding colors in the swapped image.
Third row shows colors loaded from another image or palette file.
First you click anywhere on the first two rows to choose a color.
Then you click on the third row to set what color your chosen color will be swapped to.
The idea is to make it quick/easy convert an image a different palette. So you load in the image, the load in the target palette, then setup a mapping from colors in the original image to colors in the new palette.
In the second screen shot, I've converted him to a NES palette.
On the todo list is a way to save a mapping once you've set it up. And a way to bulk apply a mapping to a bunch of sprite files at once.
OGA doesn't really have a way to post tools, but if anyone thinks this might be interesting or useful for them, I'd be happy to slap together an installer and make it available for download somewhere.
@SleepProgger: GUI Toolkit? Lol, don't I wish! Everything you see there is strictly homebrew. More programmer hubris I suppose, it just seemed faster to toss something together with what's already in my engine then to go find a toolkit and get it up and running, even though I know that's probably not really true...
@DawnBringer: While I've got you on the horn, is there a canonical home for your famous (and wonderful!) DB16 and DB32 palettes? As a side project to this, I am endevouring to compile a set of popular color palette's along with analysis from your Grafx2 toolkit (also wonderful!). Figure I'd post them as a series of entries on OGA. Googling DB16 and DB32 I've only ever found them in message board posts, which works well enough but I thought I'd ask if you'd ever put up an official page for them or anything.
This stuff all looks so great! You guys are really tempting me to jump in even though it goes against all my better judgement! Have an idea percolating, we'll see if it boils over...
Monday, July 3, 2017 - 17:14
general.png all the way! but then again, I grew up on pixel art and for whatever reason, my eyes can just never get enough of it!
There's something charming and interesting about general.png to me, whereas ghrl.png just seems a bit flat and bland.
That said, I can see that ghrl.png is technically better executed than general.png. As Reemax pointed out, the arm and leg in general.png are positioned a bit funny.
I'll also second Reemax's comment that you should pick the style that's easiest for you because you'll need a lot of art for a finished game, especially an RPG. Although, I'll add that for the same reason, you should probably also pick the style that you like the best, since you'll be spending alot of time with it!
I have to say this is one of the very few issues where I respectfully (very respectfully ;) disagree with bart.
There is no stated license for the preview image. That could imply 'all rights reserved', but it could just as easily imply that the preview is distributed under the same license as the work. That certainly wouldn't be an unreasonable assumption for someone to make.
It's also not unthinkable that someone might grab a preview image and use something from it without realizing that it wasn't part of the actual submission and not covered by the same license.
I think just some clarifying language on the submission form and the site FAQ would be very helpful.
If the previews aren't distributed under the same license as the submission, then that should be stated clearly somewhere.
Wednesday, May 3, 2017 - 13:10
Playing on the different societal norms between the two time periods is definitely an interesting direction. My only concern would be that it strips some of the agency out of the characters but I'm sure you could write it in such a way that it hits both points, ie the characters in the two timelines make different decisions, those decisions are in part driven by different societal norms around them.
You're right about Doom, he definitely deserves his own movie! :)
Wednesday, May 3, 2017 - 08:28
I guess I was asking how it fits into the character archs and dynamics. The existence of two timelines, one where the FF succeed and one where they fail immediately begs the question why? What's different between the two time lines? If the only difference is that Reed magically succeeds in one and fails in the other, well, that seems like a) a wasted opportunity for some good character driven storytelling and b) alot to ask audiences to sit through just the further the plot.
To me the obivous path would be for the group's squabling and petty differences to get the better them in 1968 (perhaps a fight with Ben is what triggers Johnny's rash behavior) whereas in the modern era they find a way to pull together due to some specific 'putting the good of the team ahead of myself' decisions on the part of the characters. This would explain to the audience why one team succeeded and the other failed and re-enforce the family dynamic that's at the core of the FF.
Well just my two cents ;)
My only other thought would be that you find a way to work Doom in there. Perhaps as a background thread that comes together at the end to setup the next picture.
Gotcha, that's a pretty good mock-up!
I like the idea that the mappings are displayed in between the two pictures like that.
Having slept on the idea, is region mapping really the right approach? What about a way to simple specify how many different mapping sets you want? Something like this butchery of your very nice mock-up?
The idea is this would save you both the initial step of creating 4 copies of the sprite in your source image and the trouble of defining/saving/loading a set of region maps for it.
I could see other uses for the region mapping concept. For example if you had a sprite sheet with multiple different characters on it, you may want to use a different mapping for each character. But in your case, taking one sprite and spinning off multiple color variants it seems like it would be easier just to tell it 'I want 5 variants'.
Quick questions:
Merge - creates a third color that is: (color1 + color2) / 2?
Revert - restores palette from source file?
Best Fit - selects the closes value in target palette? based strictly on HSV or RGB, or is it worth doing a CIE Delta E Color Difference computation?
Mapping - Remove - if don't specify a mapping for a color what happens? Does it just pass through as itself or does get dropped (mapped to black?)? I guess I prefer the idea that there is always a mapping defined for each color, even if it just points to the same color. Is the idea that you only want to see the mappings that actually change something? Maybe a toggle to show you all the mappings and one to show you just the 'changes'?
@Noonan.Design: wow! Must've been some long train rides. Looks great, I especially love the way the trees bounce as you run past them, great little extra touch!
@stackboot: That's a really clever inversion of the normal shmup format, I love it! Bonus points for dropping the FBI screen in there!
@styno333: Nice choice of sprite! Definitely one of my all-time OGA favs! Can't wait to see where you take it!
@MedicineStorm: I'm not sure I understand what's going on in that screenshot but whatever it is it looks awesome!
I've been lost in palette swap land but that idea that I said's been percolating has gotten clearer in my mind and there's still time...
@surt:
> to be bothered to use something like this outside of the editor
Just want to say I agree with your general sentiment here. There's sort of a high bar before I want to fire up a separate tool for something. There's also the distinct possibility that one might want to edit the output sprite somewhat in order for it to work right in the new palette. To be honest, the whole thing would probably best be done as a script or extension for some existing editor. Indeed, if I was fluent (or had more time to get fluent in) Gimp's Script-Fu or Grafx2's LUA script engine, I'd have certainly tried going that route. On the otherhand, doing it homebrew has at least given me a chance to puzzle out what exactly 'it' is.
> perform many different mappings on different areas of the same image
That's interesting, sort of the inversion of what I was thinking with the bulk application stuff. That's applying one mapping to many sprites. Here the idea would be to apply multiple mappings to the same sprite. Definitely doable. I guess to keep it simple, you'd just set the grid size for the sprites (over even just the row height) and then it'd let you set a mapping for each row. That would be as opposed to something that let you select wholly arbitrary sections of the source image.
> Being able to create new colours is important, rather than being limited to a pre-existing palette.
Interestingly, one of the big 'aha' moments I had thinking about how to lay this out was realizing that I explicitly /didn't/ want to edit the palettes (add/change colors, etc). My use case was pretty narrowly just converting sprites from one palette to another. Still, I can certainly see where this would be helpful for other cases and it wouldn't be too big a deal to add. The idea is you'd be able to alter the palette in the THIRD row, adding or changing colors, etc. Is that what you were thinking?
> support for gradient-to-gradient mappings
Definitely an interesting idea. You're not suggesting that the tool /create/ any colors for the gradients right? Just sort of 'auto-assign' mappings for the gradient. The gradients would have to be arranged in good order in the palette views right?
So you click four colors: start of src gradient, end of src gradient, start of new gradient, end of new gradient
And it sets up a mapping for start of src gradient through end of src gradient to start of new gradient to end of new gradient?
If you picked:
start src gradient = image palette #1
end src gradient = image palette #4
start new gradient = new palette #1
end new gradient = new palette #4
you'd end up with a mapping like:
1->1
2->2
3->3
4->4
and if picked something like:
start src gradient = image palette #1
end src gradient = image palette #4
start new gradient = new palette #1
end new gradient = new palette #8
1->1
2->3
3->5
4->8
and if picked something like:
start src gradient = image palette #1
end src gradient = image palette #8
start new gradient = new palette #1
end new gradient = new palette #4
1->1
2->1
3->2
4->2
5->3
6->3
7->4
8->4
So basically, it either repeats or omits colors as needed.Not too big a deal really, toughest part would probably be GUI'ing it up in a way that makes it clear what the heck you're doing ;)
Hi all! Thanks much for all the responses!
@Evert: Indexed colors is definitely close to what I'm after, and you're right, Gimp's index color toolset is 'Ok' ;)
@surt: Had not heard of GraphicsGale, but took a look and it looks fantastic, will definitely give it whirl. I guess the idea with your method is that you can quickly check any palette changes against the original since you'd have both versions open in the editor at once.
@DawnBringer: Indeed, GrafX2's 'Swap' button feels tantalizingly close to what I am after.
After sleeping on this for a bit, I came up with some stronger vision for what I wanted and went ahead and viddled something up. Feels a bit like bad programmer hubris as I know somewhere there must be a tool that already does this and much better, but what can I say, guilty as charged. :)
Attaching two screen shots of the tool in action.
Tool shows the original image on the left and the color swapped image on the right.
There's a small window that show's three rows of colors.
First row is the colors in the original image.
Second row shows the corresponding colors in the swapped image.
Third row shows colors loaded from another image or palette file.
First you click anywhere on the first two rows to choose a color.
Then you click on the third row to set what color your chosen color will be swapped to.
The idea is to make it quick/easy convert an image a different palette. So you load in the image, the load in the target palette, then setup a mapping from colors in the original image to colors in the new palette.
In the first screen shot, I have taken the Knight from russpuppy's RPG set (https://opengameart.org/content/rpg-tileset) and converted him to a Sega Master System palette.
In the second screen shot, I've converted him to a NES palette.
On the todo list is a way to save a mapping once you've set it up. And a way to bulk apply a mapping to a bunch of sprite files at once.
OGA doesn't really have a way to post tools, but if anyone thinks this might be interesting or useful for them, I'd be happy to slap together an installer and make it available for download somewhere.
@SleepProgger: GUI Toolkit? Lol, don't I wish! Everything you see there is strictly homebrew. More programmer hubris I suppose, it just seemed faster to toss something together with what's already in my engine then to go find a toolkit and get it up and running, even though I know that's probably not really true...
@DawnBringer: While I've got you on the horn, is there a canonical home for your famous (and wonderful!) DB16 and DB32 palettes? As a side project to this, I am endevouring to compile a set of popular color palette's along with analysis from your Grafx2 toolkit (also wonderful!). Figure I'd post them as a series of entries on OGA. Googling DB16 and DB32 I've only ever found them in message board posts, which works well enough but I thought I'd ask if you'd ever put up an official page for them or anything.
opengameart itself hosts many good tutorials:
https://opengameart.org/forums/tutorials
This stuff all looks so great! You guys are really tempting me to jump in even though it goes against all my better judgement! Have an idea percolating, we'll see if it boils over...
general.png all the way! but then again, I grew up on pixel art and for whatever reason, my eyes can just never get enough of it!
There's something charming and interesting about general.png to me, whereas ghrl.png just seems a bit flat and bland.
That said, I can see that ghrl.png is technically better executed than general.png. As Reemax pointed out, the arm and leg in general.png are positioned a bit funny.
I'll also second Reemax's comment that you should pick the style that's easiest for you because you'll need a lot of art for a finished game, especially an RPG. Although, I'll add that for the same reason, you should probably also pick the style that you like the best, since you'll be spending alot of time with it!
Good luck! and keep us posted on your progress!
I have to say this is one of the very few issues where I respectfully (very respectfully ;) disagree with bart.
There is no stated license for the preview image. That could imply 'all rights reserved', but it could just as easily imply that the preview is distributed under the same license as the work. That certainly wouldn't be an unreasonable assumption for someone to make.
It's also not unthinkable that someone might grab a preview image and use something from it without realizing that it wasn't part of the actual submission and not covered by the same license.
I think just some clarifying language on the submission form and the site FAQ would be very helpful.
If the previews aren't distributed under the same license as the submission, then that should be stated clearly somewhere.
Playing on the different societal norms between the two time periods is definitely an interesting direction. My only concern would be that it strips some of the agency out of the characters but I'm sure you could write it in such a way that it hits both points, ie the characters in the two timelines make different decisions, those decisions are in part driven by different societal norms around them.
You're right about Doom, he definitely deserves his own movie! :)
I guess I was asking how it fits into the character archs and dynamics. The existence of two timelines, one where the FF succeed and one where they fail immediately begs the question why? What's different between the two time lines? If the only difference is that Reed magically succeeds in one and fails in the other, well, that seems like a) a wasted opportunity for some good character driven storytelling and b) alot to ask audiences to sit through just the further the plot.
To me the obivous path would be for the group's squabling and petty differences to get the better them in 1968 (perhaps a fight with Ben is what triggers Johnny's rash behavior) whereas in the modern era they find a way to pull together due to some specific 'putting the good of the team ahead of myself' decisions on the part of the characters. This would explain to the audience why one team succeeded and the other failed and re-enforce the family dynamic that's at the core of the FF.
Well just my two cents ;)
My only other thought would be that you find a way to work Doom in there. Perhaps as a background thread that comes together at the end to setup the next picture.
Pages