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.
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
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
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?
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.
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.
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
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?
Ok, no worries. If you prepare an example sprite done this way and I am sure I can figure out how to make the rest of them, so once I narrow down on main color palette I can start translating them to that
@VonBednar keep the number of colors per tile to 4 or less and we can do lighting exactly like on that Brogue example
This overprinting idea of @adekto is a good idea, but it is not needed. The idea with a tilemode is that it goes over the screen once and draws all tiles as needed on the go. There is no idea in drawing the same areas of the screen many times, because it is the addressing that is slow, not the pushing of the data. So make 4-color tiles if you need them, use any 4 colors you want per tile, and we can reduce intensity per tile on the fly if needed.
Ok, so as long as I have <=4 colors inside a sprite I am in the clear? That would be awesome news!
I am shooting for a 16, possibly 32 color basic palette (so most stuff would use only those colors). Then we can generate shadows/light and such on top of that and add more colors. I can easily create ramps for shadow/illumination if that would help.
Edit: fixed the wording so it is more understandable.
Edit2: Would it be ok to have a different basic palette by tilesheet?
The color information needs to be in a separate palette. This is because I want the tile system to be usable in many games, not just this.
If @VonBednar comes up with a palette that has 32 colors, 4 ramp values each, it will be a beautiful palette to use, because we can then use values from ramps according to the amount of light & visibility per tile.
So each tile uses the 00,01,10,11 for pixels of 4 different colors + there is a table that points each tile to an index in the 256 color palette. Each index has 100%, 75%, 50%, 25% value of the same color, in 4 consequtive entries. Then, using an ofset of 0…3 the correct colors are used in drawing the tile. In this way, a 4-colored tile can be “faded to black” in 4 steps, which is more than enough for our purposes.
I hope I am able to explain in an understandable way
[quote=“wuuff, post:512, topic:275”]
