[Kde-games-devel] kdegames maintainer list update

[Matthew Woehlke]

Eugene Trounev wrote:
>> That only works if you want the insides of solid blocks to look the same
>> as the intersection of two lines, which is more limiting than supporting
>> all combinations (of which there are 46, if I counted right*).
> what do you mean here? As far as I know games of this type group elements by 
> common attribute, which usually is color. As far as the colors are concerned 
> there is no need for that many sprites.

You system (in the previous mail) assumes that

  #
###
  #

and

###
###
###

...have the exact same graphic in the middle.

You might be able to cut down on that number if you assume that the 
bottom-left corner of the center tile in

###
###
  ##

and

  #
###
  #

...is the same. Otherwise... there are 47 (note: 47, not 46; was off by 
one in earlier counting) possible tile combinations, and that's assuming 
that the center tile in

  #
  #


and

  ##
  #
# #

...is the same. If /that/ assumption isn't true either, then there are 256.

I've *done* this sort of graphics before. I'm not just making these 
numbers up. The only way to get less than 47 (and that's /per color/) is 
to add assumptions.

Don't get me wrong; I'm not strongly opposed to /doing that/ (especially 
since for KSame adding assumptions is probably a lot less detrimental 
than it would be in some other situations). I'm just trying to point out 
the inherent assumptions in the systems being proposed.

-- 
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