I think I am getting it, but aren’t we over complicating things? Would the buffer be more memory efficient than double indexes?
Why won’t we just store the colors under indexes 0-X (X is our total number of colors I will use to make tiles, right now we are aiming at 16 or 64 if we include the secondary colors).
Tiles would be made with indexed colors. So when you read them, they have the colors already baked in.
When they go into light/dark we just changed what color this tile displays. Instead of color [3][2], it would change to [3][3]. This would also give us to what colors are displayed, instead of letting the system do it, which might end up making some ugly colors.
…
You are the programmer, if you say the color generating by code will work, I trust you. Just let me know how I need to store the palette for you to use effectively, and how should I make my tiles
the problem with the color[x][y] is that it mutliplies the memory amount
ech color is 2 bytes in size, x16 colors x4 gradiants thats like 128 bytes
wile with the optimized on the fly gradiant thing i can give you 64 colors with that memory and even have more then 4 gradiant depths
Can you control how you will generate the gradient depth for each color? Because some of the 64 color palette secondary colors have been hue shifted by a little to make a more interesting color. I am just worried we might end up with a lot of muddy colors if we just change RGB or HSL by X amount on each color.
theres to concept of hue with this so no, there is a way to do it but it ends up needing more data that im trying to save so it would not be easy to do
there other problems with the weights on these values of light, like if the light source is one tile ofscreen it wont be evaluated, there is no concept of raycasting atm in there so it lights up trough walls
first iteration on these hole thing will probbely only be the player thats the light source
im sorry man but sacrefices have to be made to fit all the tiles in and have room for all the diferent ai and mechanics
this is why facing of enteties isnt in the game
but is 16 colors not enugh? technicly you get 17 due to the optimization (since black is default 0)
problem with the 256 idea is that it isnt considering the amount of aditional logic we are adding
we got a memory limit and the amount of features is allot, so trying to optimze whenever posible if sorta a thing at all ends. it would help adding features later witout having to redo allot of code
I think we should shoot for around 150 tiles, many of which will share logic, things that you can bump to initiate a quick a “choose your own adventure” bit (I will explain how it should work in design doc later today). This way we can have a single basic logic and stream the text from SD card, which will save us some memory.
What I am aiming for is single paragraphs (in a font smaller than the fantasy one, but bigger than the one on the bottom of the screen) and two choices in a pop-up window. Some text might have some procedural generation in it.
And when you choose one of the choices, it shows the outcome text and fires up a simple function (player.hp-=10, If player.charisma + Rnd(20) > 20 then gold+=100 or spawn.ghost at player.X, player.Y+1) things like that.
Edit, if you are familiar with boardgames like Arkham Horror, basically a text like they have on a card for a single location (e.g Falcon Point below)
This 16 color palette does not have a smooth transition (the code will take care of that). Here’s the basic 14x14 floor slate in light, medium and dark (default) using only colors from the 16 color palette. A darker than default color would have to be just black. Shown at 2x.
And here’s how that would work in game (not great, the shifts are too drastic)
Is that what you need, or do you need me to create ramps similar to the extended 64 color palette I had before?
Thanks! That’s enough for my little test.
And yes that’s shift is too drastic. if palette will be adjustable by code that will allow some good effects, but at the moment there no way to test it. @jonne tell me here that it will be implemented. Do you know what idea he refers to?
My original idea of 64 colors (basically 16 colors + 1 lighter + 2 darker for each of the 16) followed something closer to what @jonne had in mind (indexing the colors).
After all, we are far away from 256 tiles (we are at around 100).
(the code will take care of that). Here’s the basic 14x14 floor slate in light, medium and dark (default) using only colors from the 16 color palette. A darker than default color would have to be just black. Shown at 2x.
