• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
July 15, 2020, 08:39:04 am

News:

Please use .png instead of .bmp when uploading unfinished sprites to the forum!


Recoloring In-Game (video)

Started by lirmont, January 20, 2014, 01:36:07 am

lirmont

Recoloring in Action



An early look at recoloring in-game. There are programming-related issues that need to be resolved as to the speed of what this is doing (note: no speed issues on the color replacement in the Sprite Remixer and should be no issues here later). I'll change the output resolution of the game window for future videos to avoid that terrible minification.

Xifanie

Impressive :O

The sounds were pretty loud in the video. I'm guessing it won't be that much of an issue when using it...
It seems to do what it's meant to do very well, but with those 3 axis all joining at the center, I'm worried about when you want to just increase/decrease saturation/colour/etc. just a little bit. I'm guessing one solution would be to drag and move the bar at any location so you can position it like you want.

I'm also curious as to how it would affect a sprite which has multiple colours, and not just white/black + shades of one colour.
  • Modding version: PSX
Anything is possible as long as it is within the hardware's limits. (ie. disc space, RAM, Video RAM, processor, etc.)
<R999> My target market is not FFT mod players
<Raijinili> remember that? it was awful

lirmont

Yes to the issues with exactness. One of the things I want to add in is panning. The code for that isn't part of the engine's default camera handler (and should be). With panning and closer zooming, you could pick close to the nexus without difficulty. Actually at the nexus is supposed to be a no-change choice, but, since you only see some part of the color (hue, saturation, or lightness), the actual color isn't displayed there usually.

The quality of the color replacement is mostly about the qualities of the pixel art itself. One of the problems I've encountered occurs when one color is used for more things than it really should be, like when exact skin tones are also used for hair. That limits your options for the automatic approach (which the one size fits all default option is). That wouldn't be an issue if the parts were separated on the actual sprite sheet, since the Sprite Remixer can organize changes to a sub-image (i.e. only changing color on a portrait). In the future, as the Sprite Remixer tool (where this functionality comes from) gets more interesting features, I don't see it being too much of an issue. Like the the Sprite Animator tool, I add features to it, then I port those features to the game implementation. One of the ones I want to do is color replacement presets (that you could create over in the Sprite Remixer and just supply to the engine). So, you might be able to pre-roll interesting character/graphical asset remixes (in addition to letting the player customize at will).