- #GIMP COLOR PALETTE FROM IMAGE WITHOUT AVERAGING FULL#
- #GIMP COLOR PALETTE FROM IMAGE WITHOUT AVERAGING CODE#
But, I suppose this asset management is usually handled almost as well in a script file with the command-line stuff. and support for reading string data (filenames) in these preprocessor commands. This, well, probably needs a preprocessing loop added to the compiler if you don't have one for such things already. Then, once all that is working (or instead of changing incgraphic), I would consider adding a function to the language to bring these in at compile time (How slow could it really be these days?) which would also put the user in more control of things like variable naming. I felt that was a fine solution to the problem (albeit, a slightly different problem from this one). I recall needing to supply a palette image to ffmpeg when using it to generate animated GIFs with a limited palette. I suppose all this would also change the other inc* commands similarly. Or, perhaps, a new and optional command to index the palette image to a master IrfanView or Adobe palette file: It only needs to be done once per palette (or palette change) and not once per image, and I can create my own constants if I want.
#GIMP COLOR PALETTE FROM IMAGE WITHOUT AVERAGING CODE#
Personally, I think that users managing the indexing in code is a non-issue. This method has the caveat that you cannot create p1sprite1_colorX constants with it, so the user will need to set PxCx to the correct index values themselves - unless a third PNG/PAL/ACT index file were included to lookup the palette colors in (which may be too much for the user to make or manage correctly given all the 7800 palette variants out there). Similarly, 1-color and 12-color sprites could also be supported. If a color is then found in p1sprite1.png that does not exist in palette1.png, throw an error. Palette1.png would be a 4x1-pixel file with the first pixel being the alpha color and the next three being PxC1,2,3 in that order. Incgraphic p1sprite1.png palette1.png 160A Thus, use of incgraphic optionally becomes something like: Total freedom to work with their art assets in their reference color, and keep them that way.
#GIMP COLOR PALETTE FROM IMAGE WITHOUT AVERAGING FULL#
I believe most users will find that creating an extra palette.png for each of their design palettes, in their favorite paint or animation tool, at their favorite bit width (probably 8-bit with the full 7800 palette, or subset of that palette), will be far easier than converting their assets to indexed 2-bit PNGs all the time.
That way, 8-bit PNGs can be supported (and whatever other bit widths you care to support) instead of just the poorly-supported-in-3rd-party-tools indexed-2-bit PNGs. I don't know anything about 7800basic other than what I just now read (I was looking for something else) but, if I were handling this, I would modify incgraphic to accept an optional second PNG file to set the color order in the import. The discipline for keeping color indexes consistent will need to be somewhere. If you don't feed her images with consistent indexes, your graphics won't have consistent colors. Ignoring palette management will squander palette resources. Clever planning will allow your game to have a ton of apparent colors. One of the resources to be planned and managed in a 7800 game is the palette colors. With an anything goes import you'll need to tediously sort the indexes in a non-visual fashion in the source code with each and every "incgraphic" command, versus the current method of working up front with indexed source images and just keep color indexes consistent there.
when we see the player sprite facing away, it may have fewer colors for that frame, and the indexes will be different and the display of that sprite won't use your colors correctly. I could do a conversion from your various RGB sources to indexed on import, but then your MARIA images will have semi-random color indexes. Yep for me aswell would be great if 7800basic could read normal png,gif or jpg that any art package can output or a simple convertorMARIA holds its images in an indexed/palatalized fashion.
0 kommentar(er)
