[Kde-games-devel] ksokoban

Thu Aug 2 18:38:16 UTC 2012

Hi,

All I can offer is better adaptation of KSokoban to KDE4 (excluding 
images) and better look in bigger screen resolutions (recreating images 
in bigger resolutions in povray).
Your email suggests that you do not want to see KSokoban in kde-games.
I ported ksokoban to KDE4 because I use it and due to problems with old 
version KSokoban in new Linux distributions porting was neccessary.
I could take care of Magazynier but only for money because I do not use 
it and do not need it.
For me KSokoban, especially its graphics is the best from all known 
sokoban games.

So please confirm that you are not interested in KSokoban and I will not 
bother anymore on this list

W dniu 2012-08-01 03:21, Ian Wadham pisze:
> Hi Łukasz and Shlomi,
>
> On 31/07/2012, at 1:51 AM, Kantacki wrote:
>> Permissions granted
>>
>> W dniu 2012-07-29 21:38, Shlomi Fish pisze:
>>> On Sun, 29 Jul 2012 17:28:45 +0200
>>> Łukasz Kalamłacki <kalamlacki at gmail.com> wrote:
>>>
>>>> If you give me your sourceforge acount name I will grant permissions for
>>>> you for modifing the code.
>>> It's "shlomif".
>>>
>>>> This is OpenSource, so when you have something to add then go ahead.
>>>> What distribution did you use for compilation, I tested this on Debian
>>>> Squeeze na Wheezy and in both cases compilation went fine.
>>> I use Mageia Linux 3/Cauldron. Did you try doing "mkdir build; cd build ;
>>> cmake .. ; make" and it worked?
>>>
>>>> And the code which you mentioned is only for compatibility with MinGW32
>>>> compiler, for short term is fine, so when you have better solution for
>>>> WIN32 then go ahead with your modification.
>>> No, it's not the #define GETUID() getuid() is used on UNIX systems, and as a
>>> result caused the compatibility problem for me (because my UID changed). I did
>>> not intend to put my #if 1 #define GETUID() 501 change in the commit, but I used
>>> it to test the new system.
> You guys seem to be having fun … :-)
>
> Out of curiosity I installed Mercurial and cloned Shlomi's repository.  It compiled
> and built OK, but I stayed within the source tree.  And then it ran and up popped
> the ghost of the dear old KDE 3 KSokoban, complete with its purple background.
>
> Here's how it is, though.  What you are offering is KDE 4 and Qt 4 enabled ---
> that is good.  It looks, quacks and runs like KSokoban, but it is not the "whole
> KSokoban and nothing but KSokoban".  Take a look at the two data.c files and
> the file bin2c.c, in the levels/ and images/ directories.  The current build just
> "#include"s the data.c files, but the original began by building bin2c.c, then
> running the bin2c executable to *generate* the data.c files before the main
> build began.  The data.c files are compressed binaries of the levels data and
> image data (*.png files), in the form of compilable arrays of hex constants.
>
> I am NOT suggesting that you should reproduce that behaviour.
>
> In effect, the old code would "load" the levels and image files by building the
> whole lot into the compiled executable of KSokoban.  That is what I meant by
> saying it was going from London to Paris via Moscow.
>
> Nowadays, and also back in KDE 3 days (and even KDE 1 and 2 days), we
> would use QImage to load image files at run time and convert them to pixmaps.
> And we would use KStandardDirs (locate/find functions) to find where image and
> levels files have been installed before loading them.  What is more, since KDE 4,
> we would use SVG graphics files and a choice of graphics themes, rendering
> the SVG to the right size at run time (as the user resizes the main window) and
> allowing themes to be easily switched at run time.  Most KDE games work this way.
>
> KSokoban does have scalable graphics, but they are PovRay graphics and
> I do not think anyone in KDE uses PovRay now.  So the KDE 3 KSokoban used
> *.png files snapshotted from PovRay and relied on Qt's pixmap scaling features,
> AFAICS.  Actually, the quality is quite reasonable, but starts to get fuzzy when I
> maximise the main window on a 1440 x 900 display.  KSokoban comes from the
> era when 640 x 480 was the latest and greatest.
>
> If you would like to see exactly how things were in KSokoban before it was
> dropped from KDE Games, see:
>
>      http://websvn.kde.org/trunk/KDE/kdegames/?pathrev=660427
>
> That winds the KDE Games repository back to about 5 or 6 years ago and
> shows KSokoban still in it, with some of the KDE 3 to KDE 4 conversion
> already done.  We abandoned it at that point, because it was not going to be
> easy to meet the graphics requirements described above.  Note the contents
> of the various CMakeLists.txt files in the KSokoban tree.  I guess you could
> svn checkout revision 660427 of the KSokoban files if you wanted to go further
> with the old KSokoban code, with all its "C-isms", weird hex literals and general
> lack of comments --- not to mention direct use of fopen() and getuid().  It makes
> me feel I am back in the 90s and the Qt library has not happened yet … :-)
>
> Now lets have a look at Magazynier, see:
>
>      http://websvn.kde.org/trunk/playground/games/magazynier/
>
> I checked this out and compiled it within the SVN trunk environment of KDE Games.
> It runs OK, but needs a little work.  It is already themeable.  It has a reasonable theme
> (based on an ant pushing eggs into its nest) and a crude one (used for programming
> and testing, no doubt).  I expect other themes could be added if we can lure back
> some of our artists … :-)
>
> The code uses recent KDE Games, KDE and Qt classes, so it is very compact.  The
> graphics is already using QGraphicsView, QGraphicsScene and KGameRenderer,
> so it is very fast and clear.  The main things that needed doing, as far as I could see
> at a quick look, were more options for move-controls, a step-by-step animation for
> long-distance moves and provision of animation for short moves and turns.  There
> is a built-in A* algorithm for finding the shortest distance (using valid moves) from one
> point to another, but the move occurs all in one jump.  The ant points different ways
> (as would a fork-lift truck), but switches abruptly from one orientation to another
> when you ask it to move or push.
>
> The Magazynier code is not big on comments either, but I had no trouble reading
> it, because it is using library classes well known in other KDE Games.  Also, it has
> good separation of model, view and control and use of signals and slots.
>
> Comparing the code statistics, there are 35 source code files in KSokoban, totalling
> just over 5,000 lines as opposed to 15 files in Magazynier, totalling just over 2,000
> lines.  I know which one I would rather be maintaining … :-)
>
> So, Łukasz and Shlomi, if you really want to bring Sokoban back to KDE Games
> and are prepared to look after it for a year or two, I suggest you go with Magazynier.
> Also, as Albert remarked, you need to use KDE's standard repositories and tools,
> not Mercurial, otherwise we will have difficulty reviewing and accepting your work.
> KDE Games is still in SVN, but we are getting ready to move to git, where most of
> KDE now is.
>
> If you decide to work on Magazynier and polish it up for final entry to KDE Games,
> you should also, out of courtesy, write to the two previous authors (whose names
> and email addresses are in the source code) and ask for their blessing.
>
> All the best, Ian W.
>
> P.S. Why don't I pick up Magazynier myself?  I am tempted, but I am already looking
> after four games and mentoring on Google Summer of Code.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel