[Kde-games-devel] kdegames maintainer list update

[Matthew Woehlke]

Johannes Bergmeier wrote:
> On Monday 08 December 2008 18:19:43 Matthew Woehlke wrote:
>> Johannes Bergmeier wrote:
>>> Oh I should read all mails before replying. My other mail suggest a
>>> possible solution. I hope that doing 4 or 15/16 frames and blending them
>>> is better than creating 46 different frames for each type of tiles with
>>> all possible animations.
>>>
>>> And I hope that my problems with sending mails are now solved and this
>>> mail goes where it should in the thread.
>> Alas, I didn't follow that explanation. Any chance for a visual mock-up?
> 
> Ok, here it comes. The circles are the tiles. The squares are the sprites to 
> render. The green sprite demonstrates how KSame works currently. The blue and 
> red sprites demonstrates how Blocks and highlights are drawn in KSudoku. I 
> think the graphic is enough demonstration. The only disadvantage: The blue and 
> red sprites need to be rendered separately even when they cover the same area.

Ah. Yes, one of the assumptions I listed; probably OK for KSame. I 
wouldn't want to use it in something like kapman, though, but that's 
partly because I had the idea to draw "thin" and "thick" walls 
completely differently, which this wouldn't allow.

Let's see, you need total-interior, plus corners, plus inverted corners, 
plus straight edges... 1 + 4 + 4 + 4 = 13 tiles? I think that's right. 
Like I say, the main disadvantage is you can't use different graphics 
for a single piece versus a 2x2 block.

(I also just realized, you *can* use an aligned-tile system to do 
SGF^1-like blocks by hacking the adjacency calculation to not form 
concave edges. That also reduces the interesting tiles to 10, but what I 
am really thinking about is that your 13-offset-tile system, an SGF-10 
system, and a 47-tile system can all be implemented as subsets of a 
511^2-tile system. It would be very interesting to write a 511-tile 
engine that can support themes of all the types we're discussing. 
Possibly as an abstract class with a factory to create the appropriate 
subclass based on the theme.)

(^1 Super Gem Fighter, in which 2x2 or larger blocks combine using a 
nine-tile system with different graphics from single pieces.)

(^2 The "problem" with your system is that it is incompatible with a 
47-tile system, in that your offset tiles are possibly drawing on top of 
what would otherwise be an empty aligned tile. IOW, considering aligned 
tiles, you need to care about tiles adjacent to pieces, as well as tiles 
containing pieces, which brings things to 9-bit instead of 8-bit. Of 
course, it's only the engine that needs to care about that; a 13o theme 
would still only have 13 tiles that need to be drawn by the artist.)

Hmm... so, theme options are '1' (no connectivity), '13o' (yours), '10c' 
(SGF-like), '47', '256' and '511', and possibly others. And a generic 
511-engine could handle all of them transparently. That would rock ;-). 
And it would be usable by, at least, KSame, Kapman, and KGr. Maybe 
KSudoku? ...and I think KSquares and KAtomic.

For the various colors, I think you'd just do separate passes.

> I hope this is easier to understand.

Yes, thanks!

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
   -- from a story by Feech