being able to change the palette of a sprite

[pahp]

It would be great if we could change the foreground and background color of character sprites, while allowing us to keep custom "colorized" sprites. One approach might be to have a palette that is applied to sprites, so you could do color-cycling. Or a simpler approach might be to say that the "background" is anything of color #000000 and the "foreground" is anything colored #ffffff. Then, you could put a character onto a map either without color annotation (like ("X") -- in which case it would be black and white), or with color annotation, like ("X", 0xff0000, 0x00ff00) to put a "red X on green background". Or, maybe, for backwards compatibility, there's a "colorized map" and a "b&w map" and if you are using a colorized map you always have to specify color (but honestly, it'd be nice if the default were black and white).

More generally, being able to specify a palette for a sprite would be super useful, because you could reuse the same sprite in different ways simply by changing the palette. This is a super common technique in older console games (e.g., see how tetris uses this technique: https://www.youtube.com/watch?v=l_KY_EwZEVA). In old games, the palette for the whole screen is changed, but it seems like it would be easy to change the palette for sprites.

This would be super useful for games that want to reuse existing sprites with different colors -- for example, in the TRON game, we have "wall" sprites for all four colors. With palette changing, we could have one set of all sprites (horiz, vert, and the four "turn" sprites) and simply color them on use.

If finding a way to re-palette a sprite is too complicated, then another option (that is much less convenient) would be to allow selection between multiple sprite sheets.

The reason I'm asking, is because I'm thinking about ding a version of robotfindskitten: https://www.youtube.com/watch?v=JTWB0pFAfBU&t=166s

... and in this game, I need to be able to colorize basically any character.

Anyway, Jon, I would love if this option existed!

[derpferd]

Would this need to be done in a dynamic way? As in you can use any backend and foreground color at any time. This requires a different order of magnitude in terms of work compared to requiring the game to "preregister" the colors that will be used statically. This would allow the server to prerender the needed combinations of colors into a larger Sprite and reuse the existing draw logic.

[pahp]

I think it would be sufficient to limit people to pre-specified palettes that can be rendered at runtime. For example, I might make one with 16 different colors of all letters but with just a black background. If I wanted to use a special color for some purpose or whatever, I could do that pretty easily.

I think in practice (at least for the foreseeable future) people would only want a handful of palettes... but it's hard to foresee how people will use this. You could render bitmaps in CYLGame or do topography with gradients just using the all blank char as a pixel.

I think it would be nice if this could be backwards compatible -- e.g., we don't have to go back and fix all previous games to work.

On Wed, Nov 17, 2021 at 10:10 AM Jonathan Beaulieu @.***> wrote:

Would this need to be done in a dynamic way? As in you can use any backend and foreground color at any time. This requires a different order of magnitude in terms of work compared to requiring the game to "preregister" the colors that will be used statically. This would allow the server to prerender the needed combinations of colors into a larger Sprite and reuse the existing draw logic.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/UMDLARS/CYLGame/issues/68#issuecomment-971729538, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUPIKJ42MWHKAZJBSQ53ELUMPHYPANCNFSM5IHGTQIQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Peter A. H. Peterson, Ph.D. (he/him) Assistant Professor Department of Computer Science University of Minnesota Duluth

[pahp]

It might be nice if there is a straightforward way to be able to programmatically change which spritesheet (or virtual spritesheet) is being used... it sounds like maybe you're imagining making one larger sprite sheet... that could be fine, of course, but what I mean is that it'd be nice if I could select the sheet by name or by color in some way. For example, in code I might have something like:

WATER = char(247)  # the white version of the character

I'd like to be able to choose the green version of the WATER character simply and preferably mathematically. If the different spritesheets are combined, maybe that could be something like:

GREEN = 256
YELLOW = 512
WATER = char(247) + GREEN

Or even:

GREEN = 256
YELLOW = 512
WATER = chr(247)
map[x][y] = WATER + GREEN

It doesn't really matter if the code I'm writing here is correct, but the idea is that there should be a fairly direct way to select the palette (or sprite sheet, or sub spritesheet) to use where hopefully we can still call the character the same thing, rather than having to memorize a set of numbers for the different colors of the same character.

This is not essential of course, but it would be super cool!

[pahp]

It occurs to me that another solution would be to switch to individual sprites instead of a sprite sheet, and have the game creator be responsible for colorizing. Or, support multiple sprite sheets that the dev pre-creates. It only has to be dynamic if we are supporting arbitrary programmatic changes.

[pahp]

(individual sprites or sprite sheets with no, or a large, limit)

[derpferd]

I was thinking about a couple of solutions too. I think we should do a bit of design before implementing this (to get it right). I will document the current process as I think one of the requirements is backward compatibility. (hopefully over the next couple days.)

[pahp]

Yeah, I agree. It just occurred to me that "players" (programs) should be able to differentiate between a blue X and a red one, preferably by identifying it as an X and then its color.

On Sat, Nov 20, 2021, 10:54 PM Jonathan Beaulieu @.***> wrote:

I was thinking about a couple of solutions too. I think we should do a bit of design before implementing this (to get it right). I will document the current process as I think one of the requirements is backward compatibility. (hopefully over the next couple days.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/UMDLARS/CYLGame/issues/68#issuecomment-974755885, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUPIKOV64NLMU5CFYUUOKTUNB3RBANCNFSM5IHGTQIQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[derpferd]

Some context for this idea.

There are three main logic pieces that might be effected:

• Frontend Game "Player"
  • The Javascript and Python functions that actually do the drawing.
  • The current operation blits a splice from the large Sprite on to the frame buffer.
  • Link to Python code 1 2 and Javascript code
• Backend
  • The Backend APIs use a "char type" for drawing example 1 example 2 example 3
  • Python doesn't have a "char type" but is defined by the function, is_char
  • The actual frame buffer in the backend converts from chr to int internally.
• User Programs
  • If adding colors requires changing how do the user programs' logic.
  • Probably shouldn't be an issue considering we already have programs like pac bot that have different colored chars that map to the same variable when "sensed" by the program. https://github.com/UMDLARS/pac-bot/blob/master/game.py#L672

Random note: At one point CYLGame did support a "ColoredChar" but this was removed in e651c710.

[derpferd]

I think the best option here is to have a sprite registration process where you can create the sprites you will use through out the game. Right now, I am thinking that different colorings will need to be different character values opposed to attributes on a single char.

Current thinking on the break down of this task:

1. refactor the code to allow for arbitrary sized and shaped sprite images
2. add sprite registration process in backward compatible way.
3. add a two dimensional color sprite generator.

Sprite registration input:

• sprite image with size spec (char height & width and number of rows and columns of chars)

Two dimensional color sprite generator design Inputs:

• Base B&W sprite image with size spec
• List of background colors
• List of foreground colors

Output

• New sprite image with size spec
• List of chr values for background colors
• List of chr values for foreground colors

Such that WATER + WHITE_FG + BLUE_BG = the original water char colored with a white foreground and a blue background.

[pahp]

Would we still be limited to 256 chars? Because if each coloring is a different char, we could eat into our ability to display text. (In other words, we could do predefined colorings in the current sprite sheet approach but it's less flexible and still could eat into characters we want to use.)

Also, when you say arbitrarily sized, will we still assume that all sprites for a game are the same size and used in a 2d text-style grid as now? Or are we moving to a more positional approach? I like the simplicity of the sprites being in a 2d grid, personally.

On Sat, Oct 8, 2022, 11:27 AM Jonathan Beaulieu @.***> wrote:

I think the best option here is to have a sprite registration process where you can create the sprites you will use through out the game. Right now, I am thinking that different colorings will need to be different character values opposed to attributes on a single char.

Current thinking on the break down of this task:

1. refactor the code to allow for arbitrary sized and shaped sprite images
2. add sprite registration process in backward compatible way.
3. add a two dimensional color sprite generator.

Sprite registration input:

• sprite image with size spec (char height & width and number of rows and columns of chars)

Two dimensional color sprite generator design Inputs:

• Base B&W sprite image with size spec
• List of background colors
• List of foreground colors

Output

• New sprite image with size spec
• List of chr values for background colors
• List of chr values for foreground colors

Such that WATER + WHITE_FG + BLUE_BG = the original water char colored with a white foreground and a blue background.

— Reply to this email directly, view it on GitHub https://github.com/UMDLARS/CYLGame/issues/68#issuecomment-1272353040, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUPIKJ2ZUZ4TXIIFPXMPOLWCGOHRANCNFSM5IHGTQIQ . You are receiving this because you authored the thread.Message ID: @.***>

[derpferd]

Forgot to mention based on a preliminary check we should be able to handle up to 1,052,946 chars. So not limited to 256 but something to note is that the loading time of the website could be impacted as the sprite size increases.

I like the simplicity of the sprites being in a 2d grid with the same size for each character. When I said arbitrarily sized, I meant all the characters are the same size but the number of characters is arbitrarily as well as the number of rows and columns.