Your questions about how many colors & other things require a bit of thinking and I will get back to you on it.
1 Like
Just a short thought I wanted to share with you all.
Columns and Coffins is placed at the first entries shown at startpage of the CGAJam. Could we have asked for better visibility in terms of placement? If this was due to our last minute upload, then letâs enjoy the time well spent on the last minute tweaks! 
1 Like
Didnât help my issue 
was your code somewhere to test?
Hate to bust your bubble but Iâm pretty sure theyâre diplayed randomly.
I have updated the design doc, we now have a core gameplay loop explained and most categories blocked in.
Outside of my previous question about color, I have another one:
Would it be helpful to make a spreadsheet that will include all sprites with their name/ID and attributes that will be used in game?
It shouldnât take me more than few hours, and could save us a lot of headaches in the future when we add new sprites.
Would something be more useful than a spreadsheet?
Ok, so the basic calculation goes like this:
Tiles is 16 wide, 12 high.
Means
- 192 bytes in 256 colors (1 byte per pixel)
- 48 bytes in 4 color mode
- 24 bytes in 2 color mode (basically 1 color + black)
For 256 tiles
49152 bytes in 256 color mode
12288 bytes for 4 color mode
6144 bytes for 2 color mode
In my experience, all Pokitto programs have been < 100 kB so far. So you can easily use at least 64 kB for tilesets.
So its kind of your call. If you think multicolored sprites are more interesting, and especially if you can keep it to 4 freely selectable colors per sprite, we have space for several full tilesets in the
game
Edit: and, if you want, you can have 256 different colored 2 color sprites, with 1 selectable bg color and 1 fg color per tile.
Edit2: and this is important (@adekto, @trelemar, @wuuff) if we do this (example 256 different monochromatic tiles) the display system has to be a custom tile mode. The normal hi-res mode (220x176 @ 4 colors) can not be used. This means also the UI has to be either made with tiles, or by using the DirectPixel and DirectBitmap methods that draw directly on the LCD without using the screenbuffer. There is no screenbuffer in a tiled mode.
1 Like
Iâm not sure if we need that much color among all the sprites. We can get a consistent retro aesthetic that still looks great with a lot less complexity if we use less colors. Plus, if we have to put everything as a tile, I assume that means issues with attack animations by sliding a tile, as suggested here:
That is not really efficient to do with tiles, right? Just some thoughts on that.
Also, @VonBednar , the design document seems to be coming along well. I was thinking about the premise. Some roguelikes seem to have an actual ending, even if it is quite difficult to reach. What if we had it so that the final objective is to serve Lord Mort with a court summons for tax evasion, but heâs deep at the bottom of his dungeons, on the 100th floor? Maybe in this world, court summons must be given in person, so heâs hiding in his fortress hoping no tax collector is strong enough to reach him. Every year, his monsters remodel his dungeon, which is why it changes every year. If we want themed dungeons, he could just have different phases where his tastes change (âthis year, goblins are inâ). I feel like this fits the comedy style weâre going for as well.
2 Likes
I also think we need undead vixens. Otherwise its a no-go. A dungeon with only dudes sounds a very sad dungeon indeed.
Edit: on a more serious note: the current graphics look really nice on the pokitto screen, because they are so tiny and crisp. If we go all âtechnicolor dreamcoatâ with rainbow colors, it does not necessarily improve the aesthetic of the game. I would even go as far to say that I would keep the number of colors very limited but perhaps play with shades of same colors to make the gfx even better
1 Like
A question on derect mode and 16x12
Soo we are only using 12x12 and i know bit wise theres no other way but
We can use the last nibles of every even byte to store color info of the 1 color sprites
Actually gives us 6 bytes for potential colour info
Its a wierd compressed format but might be usefull sine you can have a 2 color sprites with full rgb
1 Like
Wait. Are we talking about 16 tiles wide on tiles high? Because the sprites themselves are 14x14 px which gives us 15x12 tiles (resolution of 210x168). Am I missing something?
Sorry my mistake, you are right
1 Like
No worries, I am not planning any any rainbow skeletons and holographic zombies. In fact, I want most of the tiles to stay 1bit. There are only few exceptions that I think extra color would help.
Right now, the only things that I was considering are couple of the ornaments:
Excuse the jarring color combinations.
But, if it is only a handful (well maybe no more than 20) sprites all together, we can use this âoverprintingâ that @adekto mentioned somewhere (splitting the sprite into multiple by color and stacking them on top of another). I kind find it now, but there was a pikachu as an example.
The main reason I wanted more than 16/32 colors is this:
Brogue has a great atmosphere thanks to the extra color, and we can use color for field of view and such. Not to mention making water, lava or even foliage with shades and tints of the same color goes miles into breaking up visible patterns/tiling.
We wouldnât use as much color, but having like 64+ colors available from a base of letâs say 32 (rest would be shades) would work well I think.
1 Like
And now for the setting themed reply 
[quote=âwuuff, post:512, topic:275â]
What if we had it so that the final objective is to serve Lord Mort with a court summons for tax evasion
[/quote]
That is perfect! And the scroll of court summons can actually summon a court to him!
I like the idea of what is IN this year for dungeons and it is very much following the comedy style. And by using the âdungeon remodelâ we still get themed tilesheets and dungeon-generation algorithms for goblin caves etc.
But, I also like the idea of âchoosing jobsâ between dungeon runs. But than again, we can have the choice offered to the player, they choose one thing and the others are scrapped (other taxmen have picked up those jobs) and those can be different properties in Lord Mortâs portfolio .
As the goal grows after each run, we can start âcourt summons runâ once the goal is > like 5k or something.
Now I will stop spamming the thread and work on some stuff. I just wanted each idea to have itâs own reply to avoid super long responses.
my bad totaly forgot about 14x14
so recalculating the bytes are 2 horizontal 14 vertical
if its a 1bit image would map the horizontal to one and 3/4th of bytes
meaning we got 2 bits spare, times 14 vertical gets us like 3 and a half byte that we are technically waisting
if we prevent them from drawing we could use those for individual sprite colors in rgb
a thing about dirrect mode is we need to draw front to back so i think we need some sort of tile screen buffer so we know we arent drawing over the same tile sectors (would lead to flicker if that happens)
i think the hp bar has no overlapping parts, so i think that one needs hardly any conversion
menu system might be tile aligned though just to make it easier
1 Like
That sounds super efficient and waaaaay over my head If you can pull it off, letâs do this 
I think the flicker, if not too common, would not hurt (and actually be reminiscent of the zx spectrum)
Also, can we have some having a 3rd color like here by splitting it by color or something? I remember you doing something like that with pikachu.
yes overprinting is possible though the tiles are always bigger then you expect since we need to have additional masks in direct draw mode
no this is like way worse then zx spectrum i have seen this on oleds and lcdâs, its bad and needs to be avoided by all cost, if we have any flicker it will be all of the flicker!
Awesome. I would use it sparingly. Once you have some time, let me know how would you like me to prepare the tiles for overptinting.
Also, I posted this earlier, but do you think a spreadsheet of all the tiles to keep as a database would be helpful? We can store the pic, .c code and any other attributes (solid?) we need in it as a reference?
Yeah, then letâs see if we can avoid it somehow. If not, even 64 colors would suffice.