I have installed mercurial, which should 
allow me access to fedora core source
code.
But I don't yet know how to use it.

I am used to getting source from
a mirror, and that is what I have
done in the past.
However I also thought you could get
it from a yum install (the src rpm).

I am Not clear why they aren't there.
Maybe because their systems were compromised.

What I am wanting to do is to modify a
game or maybe even some screen savers.

[bperil@localhost kbounce]$ cd pics/
[bperil@localhost pics]$ ls
ball0000.png  ball0006.png  ball0012.png  ball0018.png  ball0024.png           hi48-app-kbounce.png
ball0001.png  ball0007.png  ball0013.png  ball0019.png  CMakeLists.txt         hi64-app-kbounce.png
ball0002.png  ball0008.png  ball0014.png  ball0020.png  hi128-app-kbounce.png  tiles.png
ball0003.png  ball0009.png  ball0015.png  ball0021.png  hi16-app-kbounce.png
ball0004.png  ball0010.png  ball0016.png  ball0022.png  hi22-app-kbounce.png
ball0005.png  ball0011.png  ball0017.png  ball0023.png  hi32-app-kbounce.png
[bperil@localhost pics]$ gthumb 
[bperil@localhost pics]$ gthumb .
[bperil@localhost pics]$ pwd
/usr/src/redhat/SOURCES/kdegames-4.0.3/kbounce/pics

I have installed the source rpm,
that was not available from a yum 
repository which may be due to the Fedora
intrusion.

I probably do not need to use mercurial to 
do what I want to do (which is study
kbounce and maybe modify it).

fun fun.
I was able to edit the kbounce game
so that i could change the backgrounds, 
etc.
To do this I modified a file that is
called default_theme.svgz
in the kde
/usr/share/kde4/apps/kbounce/themes

To modify this file I used the 
inkscape program which is great for svg files/


I am still not sure if the source that
I found was the same as was used
to build the kbounce that I run.

Years ago I made my own bounce factory
program
that I called 
little bouncey or some such (all in
C++)

I can still get this stuff to run with
wine as long as I have the correct
dll's.
They will not run on my windows XP system.

Here is a tree of the kbounce source:
[bperil@localhost kbounce]$ tree
.
|-- CMakeLists.txt
|-- Messages.sh
|-- RULES
|-- ball.cpp
|-- ball.h
|-- board.cpp
|-- board.h
|-- gameobject.cpp
|-- gameobject.h
|-- gamewidget.cpp
|-- gamewidget.h
|-- kbounce.desktop
|-- kbounce.kcfg
|-- kbounceui.rc
|-- main.cpp
|-- mainwindow.cpp
|-- mainwindow.h
|-- pics
|   |-- CMakeLists.txt
|   |-- ball0000.png
|   |-- ball0001.png
|   |-- ball0002.png
|   |-- ball0003.png
|   |-- ball0004.png
|   |-- ball0005.png
|   |-- ball0006.png
|   |-- ball0007.png
|   |-- ball0008.png
|   |-- ball0009.png
|   |-- ball0010.png
|   |-- ball0011.png
|   |-- ball0012.png
|   |-- ball0013.png
|   |-- ball0014.png
|   |-- ball0015.png
|   |-- ball0016.png
|   |-- ball0017.png
|   |-- ball0018.png
|   |-- ball0019.png
|   |-- ball0020.png
|   |-- ball0021.png
|   |-- ball0022.png
|   |-- ball0023.png
|   |-- ball0024.png
|   |-- hi128-app-kbounce.png
|   |-- hi16-app-kbounce.png
|   |-- hi22-app-kbounce.png
|   |-- hi32-app-kbounce.png
|   |-- hi48-app-kbounce.png
|   |-- hi64-app-kbounce.png
|   `-- tiles.png
|-- renderer.cpp
|-- renderer.h
|-- settings.kcfgc
|-- sounds
|   |-- CMakeLists.txt
|   |-- death.au
|   |-- reflect.au
|   |-- seconds.au
|   |-- timeout.au
|   |-- wallend.au
|   `-- wallstart.au
|-- themes
|   |-- CMakeLists.txt
|   |-- default.desktop
|   |-- default_preview.png
|   `-- default_theme.svgz
|-- wall.cpp
`-- wall.h

when I grep the code I will find out where
the svg files are read in.
This is using the Qt I believe.

 grep svg *
renderer.cpp:	: m_svgRenderer(), m_backgroundSize( QSize( 0, 0 ) )
renderer.cpp:    return m_svgRenderer.load( fileName );
renderer.cpp:    return m_svgRenderer.elementExists( id );
renderer.cpp:	m_svgRenderer.render( &p, "background" );
renderer.cpp:	m_svgRenderer.render( &p, id );
renderer.h:	KSvgRenderer m_svgRenderer;
[bperil@localhost kbounce]$ grep load *
gamewidget.cpp:    m_theme->loadDefault();
gamewidget.cpp:    if ( !m_theme->load( KBounceSettings::theme() ) )
gamewidget.cpp:	m_theme->loadDefault();
gamewidget.cpp:    m_renderer.load( m_theme->graphics() );
mainwindow.cpp:    dialog->addPage( new KGameThemeSelector( dialog, KBounceSettings::self(), KGameThemeSelector::NewStuffDisableDownload ), i18n( "Theme" ), "games-config-theme" );
renderer.cpp:bool KBounceRenderer::load( const QString& fileName )
renderer.cpp:    return m_svgRenderer.load( fileName );
renderer.h:	bool load( const QString& fileName );
renderer.h:	 * Checks if specified element is included in loaded SVG.
[bperil@localhost kbounce]$ 

That is the grep. Now, a style note of these pages: when I am doing htis kind of hacking I usually will be copying these little bash-shell snippits, greps and finds, into an Open Office document and then styling these as 'code-fragment'. So I need that same thing here.

At this point I probably will want
to take a snapshot of the source
as a way to maintain this, however
it is easy enough to recreate by reusing
the rpm.

Now is where I willopen op the files
indicated with the editor of my preference.

The editor that I choose is either 
ecclipse or kate, both of which are open source.

never used cmake before.
Here is what worked:

 sudo cmake CMakeLists.txt 

I was finally able to figure out cmake,
which really wasn't that straightforward
until after I spent a little bit of time
on it.

I used to like the readme files
that would tell you what to do.
Now those things seem missing.

Basically with cmake one needs to 
first run cmake from
a command line with the name of a 
*.txt file in it.

I was unable to get something
that Eclipse was able to understand.
Also didn't see anything that looked 
like a kdevelop file either.

here is what I did:
 sudo cmake CMakeLists.txt 
 cd kbounce/
 ls -otr
 make
  and then to run one must 
sude a shell command.

I should build all this somewhere else, so
that I am not down in the SOURCE,
though what does it matter, 
I am not installing what I am doing (though I could if I wanted to).

I modified the cpp files and then built with
a make and that was witnessed by
debug messages being spit out to the
console.

 After installing the source rpm
the source shows up as a gzipped-tar file
in the source directories and then
needs to be unzipped with a 
tar -xzf
 or some such command

To put this somewhere else I can copy
it to some local place and then 
untar it there.

Untarring in my local area also allows me to be
the owner of the files so
I don't have to use the sudo, which
is a much saner way to do things
that are from code cultivated from
the 'open-source' wilds.

I like the look of the make complete
with a percentage indicator.

Things have moved forward in the land
of build systems.
I am used to hand-rolled make
from long ago, and configure and
make configure, etc, all things
that were hard to learn at first,
but once one gets the hang of it
it seems easy.

This is yet another form of build which
is also easy.

OK, so now I have code in my home
for the open source project of interest,
in this case a simple kde game.

And what have I learned how to do?
Use cmake (yet another make).

I still don't know how to use cmake to
generate files for an eclipse or KDE project
and have it work

It wasn't hard to import into kdevelop.
And I was able to open and edit and build,
but not run from with in there.

There is still the need to use a shell
command that sets up the shared libraries for
this.

I have modified some of the 
parameters in the game (constants
within the code)
and gotten modified behavior, more
lives, more balls, 
a much larger board.

I hacked around in the kbounce code
for quite a while and determined
that the code has major deficiencies
if the board size is large.

There are some very inefficient parts
where collisions are tested.

I hacked around trying to improve that
efficiency.

OK, so I have tracked down the problem
with kbounce and why it 'hiccups' upon
the wall collision.
Basically the code probably used to
cache the images (it says it does
in the notes) but when someone
wanted to 'upgrade' it to allow
for animated bitmaps (a laudible idea)
they took away that caching.

The notes even say that there is
a cache but no such cache exists.

If you defeat the rendering (don't ask
how) you can clearly see that the hiccup
is gone.  Why?  Because the bitmaps
are not being continuously reloaded!

So . . . what I need to do is
recreate the caching and then this
code will be useful again for doing
what it used to do.

There is a function:
  QPixmap KBounceRenderer::renderElement( const QString& id, const QSize& size )

which needs to use a cache.

Not sure if I need to call this function
in the same manner that it is currently 
called or to modify the resize function
to automatically generate the cached
bitmaps.

Alright, I spoke too soon.
Seems to be caching the images ok.

Must just be that the draw is slow.

OK, after much searching I have
found that the very call that is slow is
as follows:

  m_tilesPix->setPixmap( px );

The whole image is the pixmap, and
this just seems very large.
There is a passing of this large bitmap
and then a copying of it to the canvas.
So a 'sprite' is the whole board.
And that is why this is slow.

Here is the entity from the *.h file:
  KGameCanvasPixmap* m_tilesPix;

This is then created elsewhere, I am
trying for a more efficient way to do this.

And that means creating it elsewhere.

However, this doesn't seem to help because fundamental design flaw of
having such a large image created all
of the time, this is not correct 
buffering.

I am reviewing the various aspects of 
the kdegames canvas objects.

There does not seem to be a type
that takes a small bit map and allows
it to be tiled by reference to a map.
IE:  you send a list of all places
that this ought to appear and it is
drawn in all of the various locations
but not as a giant bit map, but with
a bitblt to the rectangle directly to
the canvas I would guess.

I don't know enough about this
architecture yet, but I do know
that the kbounce program doesn't
seem to use it in a efficient way.

OK, so I thought it through and
hacked it up for a while and 
fixed the problem with the
hiccup when kbounce is given a
large size.
Basically the idea of the 'underlayed'
'wall map', with a single giant

	KGameCanvasPixmap* m_tilesPix;
           
is not replaced by the super collosal array:
      // wall_tiles_Pix is a huge thing
	KGameCanvasPixmap* wall_tiles_Pic[TILE_NUM_W][TILE_NUM_H];

and I have set the numbers for TILE_NUM_W and TIME_NUM_H as follows:

#define TILE_NUM_H 250
#define TILE_NUM_W 400

increased the ball size, fiddle with speeds (none of this is in a single place
nor is it attached to any 'configuration' menu

but i like the height and width of 125 by 400.

There is also the idea of having the wall
tiles of varied sizes depending on how the wall is 
'revealed'  There would be rectangles
which I could render with the object
that is for a tiled pix

ie: KGameCanvasTiledPixmap

There is a point when the effort to 
optimize is circumvented by new
ideas.  In this case
by creating the huge array of 'wall'
pieces as mentioned above, creating all
of these at the start of things (or
when we resize we need to make them
again, as they are all a different size)
and then from that we create them
up front, hide them, and then when we
want to show we just call the show for
that tile (instead of just flagging
and array that is later accessed for
the ability to fill in that tile, a much
slower process as it exists in
the alpha source currently.

If the arrays were to be even larger
than the tiled objects opitimizations
could be explored, or explored just
as an exercise.

Now I would like to be able to have the
game allow loading of different ball
and wall pictures so that the display
can be funner and more cutting edge.

I put the rules for collisions
back (by uncommenting code that I'd commented
out for development purposes) and the game
plays pretty much the same but with a
much larger area and without any klitch
when the walls fill in.

It is snappy and a much saner way to
do the walls.  Now the game can
get bigger and morph into something else.

Announcing Next Bounce

Announcing a fork from KBounce: BetterBounce.

BounceFactory 1.0

I have spent some time making it so
that there are random balls with
random sizes.  So the game is much more 
colorful and a slight bit more interesting.
I was thinking that I should try and make
the balls have different effects like
in breakout.

different game.

I've been screwing with bounce tonight
and discovered that it has a quirk
in the way that it does the 'bounce'.
Basically it has a very simple minded 
reflection algorithm that double checks 
for ball collisions (if balls might 
collide)
and has one of the balls collide 
first and call it's collide function when 
really it ought to have both.

Actually, what is done here is that the
ball is if'd out in the game code
and I un if'd it so that it will 'bounce'
Then I set up for 150 balls (which
is a little hairbrained, how you set the
starting number of balls.  There is 
a place in the code where they hard
code (level + 1) balls.  No constant
or #define used, but a hard coded 1.

I changed this to 150, to start with 
151 balls.

After a time (because I went to the 
bathroom) all of the balls migrated
over to the right of the screen and 
chained from top to bottom.

I should include a screen shot . . .

Also, all collisions are of rectangles.
There is a place in the code where a 
rectangle object is created and then
passed over to the 'collision' engine.
At this place there might be efficiencies
(that might prove substantial) by changing
this to a static class member.

I can't remember how that works in a class . . . if the variable is static
between different instances of the class
or if it is static only for that member.
In any case to solve this make it a 
class member object
and save yet one more stack created object
that gets recreated everytime through
this very heavily used piece of code.
Using extra memory is often a good way
to make code much faster.  In this case
it is possible that the folks who wrote
this original code didn't invisions
100's of 'balls' and having a collision
test between them all.

The code was neer designed to test for collisions between all the balls

Clearly the kbounce code was never 
designed to account for hundreds of af balls
and having collision tests between 
each ball.
first:  the ball collsions test is explictily if'd away (so ball collisions
are never tested).  I modified this.

Second:  the ball collision, as coded, calls a ball collide function, but only one.  It would be much more efficient to call two ball collide functions (there are two balls).  And then which do you call first?

And do you refresh the positions of all
the balls after collisions, after all things
have been tested?  Or do you update as
you go through each object in the 
foreach list? 

Seems that just observing how this code
is 'broken' in the way that it does not
resemble the way real balls would
collide.  Balls pertibate based upon
'expected' location.  IE:  where is the 
ball 'going to be' next time.  That is
a faulty assumption in some ways as the
question needs to be asked (if this really
is the question concerning some
future time) where will the other
object be as well. (The code may do that
I need to look at it some more).

Interesting code.  Screen shots maybe 
tomorrow.

Above we see the promised screenshots.

Notice that the top picture shows the 
balls all clumpped in a line from 
top to bottom of the screen.

When I reinstalled Linux with a new spin
the saved svg file got overwritten.

And I don't think that the install code
created an rpmnew file. pwd
/usr/share/kde4/apps/kbounce/themes
[bperil@localhost themes]$ ls -Z
-rw-r--r--  root root unconfined_u:object_r:usr_t:s0   default_2_theme.svgz
-rw-r--r--  root root system_u:object_r:usr_t:s0       default.desktop
-rw-r--r--  root root system_u:object_r:usr_t:s0       default_preview.png
-rwxrwxrwx  root root system_u:object_r:usr_t:s0       default_theme.svgz
-rw-r--r--  root root unconfined_u:object_r:usr_t:s0   default_theme.svgz.bak
-rw-r--r--  root root system_u:object_r:usr_t:s0       geometry.desktop
-rw-r--r--  root root system_u:object_r:usr_t:s0       geometry.png
-rw-r--r--  bperil root unconfined_u:object_r:usr_t:s0   kbouncbill.svg
-rw-r--r--  root root system_u:object_r:usr_t:s0       kbounce.svg
-rw-r--r--  root root unconfined_u:object_r:usr_t:s0   kbounce.svg.bak

I suppose that the new version of kbounce kde is out and that I oucld merge my changes into that:  or see if
they make the same mistakes as the version
that I used to do my modifications.

I am using Kdevelop as an editor to do this
project.  The other two choices are
kate and ecclipse.

I may have stated above that I used
an image editor to modify the file
that holds the svg data.  The objects
are labeled and the program uses the
labeled objects.

My friend, Barents, the artist, has a new
theme where he uses three shapes:  a square,
a circle, and an equilateral triangle.
He chooses one of the primary colors
for each one: red, blue, and yellow.

I can convert the bounce program to use
these kinds of shapes.

Well, interesting problem now.
I have a group of images that I have
saved within the svg file.
There are three triangles, three
squares, three circles.  Each group has
one of each color: red, blue, and yellow.

As I want to have the purest color as
possbile I chose the rgb for the red and 
the blue as the color model.
but for hte yellow I choose a color 
model of CMYK.  I suspect that the
issue with only red and blue or only 
yellow and blue, but not yellow, red and
blue is due to this mismatch of color models.

This is an interesting bug.

I will change the yellow to the RGB model 
and see if this solves the problem.

Well, what do you know!  Making the
color models the same solved the issue
with the colors being off.

OK, if I want to make a triangle, a square
and a circle, each of a different
color I need to modify the game to
guarantee this configuration.

Now I am thinking how to load the configuration
data so that the program will be what
the user sets it up to be.
a game such as kbounce really is
a simple entity in a lot of ways.  It
is not broken out into setup objects,
it doesn't have a full-featured INI file.
It doesn't allow for easily modifying the
game rules, or setting up of various
initial conditions.

Such a program is a classic 'toy program'

So what I am wanting to do is make it 
into an 'art box' kind of program.

It wouldn't be as full featured as a 
draw program.  but it would be
more complex than just a bounce factory.
What we would get is something that would
be useful as a screen saver and wouldn't
be the kbounce game anymore at all.

In many ways my java application for the
block puzzle is already close to being
the same thing as a java application
for the purposes of 'art box' program.

I can imagine the pieces that I need and
how to make this thing into something.
In the case of the block puzzle java 
application the images are stored as
bit maps (hard files) and not named
items within an svg saved file.

porting this to my notebook gave me
a little bit of a headache.
I had to reextract the tar
because he ssh'd version had bad paths

here is the command tht finally regenerated
the makefiles:

cmake kdegames-4.0.3/

It was a two step process.
 cmake CMakeLists.txt 

I get these errors:
couldn't create image from  "/home/bperil/pastedpic_11282008_202547.png"
couldn't create image from  "/home/bperil/pastedpic_11282008_203754.png"

so that things don't appear the same, bit
maps are different.  That must be how
inkscape does it's thing.  Pretty
scarey that inkscape leaves
things around like that so that
if you move the file to another machine you need all of the
subfiles that go with it.  

So now I have my modified kbounce on my
notebook so that I can show my friend.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   width="744.09448819"
   height="1052.3622047"
   id="svg4094"
   sodipodi:version="0.32"
   inkscape:version="0.46"
   sodipodi:docname="test1.svg"
   inkscape:output_extension="org.inkscape.output.svg.inkscape">
  <defs
     id="defs4096">
    <inkscape:perspective
       sodipodi:type="inkscape:persp3d"
       inkscape:vp_x="0 : 526.18109 : 1"
       inkscape:vp_y="0 : 1000 : 0"
       inkscape:vp_z="744.09448 : 526.18109 : 1"
       inkscape:persp3d-origin="372.04724 : 350.78739 : 1"
       id="perspective4102" />
  </defs>
  <sodipodi:namedview
     id="base"
     pagecolor="#ffffff"
     bordercolor="#666666"
     borderopacity="1.0"
     gridtolerance="10000"
     guidetolerance="10"
     objecttolerance="10"
     inkscape:pageopacity="0.0"
     inkscape:pageshadow="2"
     inkscape:zoom="0.35"
     inkscape:cx="-129.28571"
     inkscape:cy="520"
     inkscape:document-units="px"
     inkscape:current-layer="layer1"
     showgrid="false"
     inkscape:window-width="1920"
     inkscape:window-height="1091"
     inkscape:window-x="0"
     inkscape:window-y="0" />
  <metadata
     id="metadata4099">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <g
     inkscape:label="Layer 1"
     inkscape:groupmode="layer"
     id="layer1">
    <path
       sodipodi:type="star"
       style="opacity:1;fill:#ffff00;fill-opacity:1;fill-rule:nonzero;stroke:#ffff00;stroke-width:0.2552329;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
       id="first"
       sodipodi:sides="6"
       sodipodi:cx="31.428572"
       sodipodi:cy="98.076469"
       sodipodi:r1="279.85419"
       sodipodi:r2="139.92709"
       sodipodi:arg1="0.47734538"
       sodipodi:arg2="1.0009442"
       inkscape:flatsided="false"
       inkscape:rounded="0"
       inkscape:randomized="0"
       d="M 280,226.6479 L 106.92029,215.89239 L 44.368163,377.63135 L -32.857147,222.36218 L -204.20326,249.05993 L -108.34887,104.54626 L -217.14286,-30.494957 L -44.063151,-19.739452 L 18.48898,-181.47841 L 95.714291,-26.209241 L 267.06041,-52.906987 L 171.20601,91.60668 L 280,226.6479 z"
       transform="translate(-17.142857,217.14286)"
       inkscape:label="#path4104" />
    <path
       sodipodi:type="star"
       style="opacity:1;fill:#ffff00;fill-opacity:1;fill-rule:nonzero;stroke:#ffff00;stroke-width:0.2552329;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
       id="rotated"
       sodipodi:sides="6"
       sodipodi:cx="31.428572"
       sodipodi:cy="98.076469"
       sodipodi:r1="279.85419"
       sodipodi:r2="139.92709"
       sodipodi:arg1="0.47734538"
       sodipodi:arg2="1.0009442"
       inkscape:flatsided="false"
       inkscape:rounded="0"
       inkscape:randomized="0"
       d="M 280,226.6479 L 106.92029,215.89239 L 44.368163,377.63135 L -32.857147,222.36218 L -204.20326,249.05993 L -108.34887,104.54626 L -217.14286,-30.494957 L -44.063151,-19.739452 L 18.48898,-181.47841 L 95.714291,-26.209241 L 267.06041,-52.906987 L 171.20601,91.60668 L 280,226.6479 z"
       transform="matrix(0.9659258,-0.258819,0.258819,0.9659258,541.40113,211.47619)"
       inkscape:label="#path4106" />
  </g>
</svg>

above is simple code in svg generated
by inkscape.  There are two 'star' shapes.
the second one is rotated by 15 degrees.

notice the translate statement.  That is
the part that is different between the first
and the copy.
I need to know the parameters of this statement.

What I would like to do is to automate 
the effect of the ratation by generating 
the translation statement for cloned objects.

Would I do this within the code of the
game or tool that uses this or
would I prespawn and svg file with a 
different utility?  Are there sets of
utilities that allow for the manipulation
of these files?
The answer is, of course, yes.  XML is what
SVG is so use XML tools to modify and clone.

What documentation exists on the translate statement of svg?

as usual the W3C has it all!
God bless them!
Here is a url:
http://www.w3.org/TR/SVG11/coords.html#TransformAttribute

And the investigation leads to the
concept of transformation matrix outlined
here:

http://www.w3.org/TR/SVG11/coords.html#TransformMatrixDefined

So studying that one can find how to
create a transform.
Also there are other formats for the 
transform attribute which you can read about
on the first link.

now as the kbounce program loads in svg
can I then get the kbounce program to
apply the transforms for me?
There are various assumptions concerning
the kdegames bit map engine that one
must consider.  Having looked into
the inner details of kbounce I can
assure other programers that this is 
a very good kbounce program.  It is not
a robust 'generic game interface' as
it stands, though it is built on kdegames
which is solid enough for what it is.

It is not a bedrock real-time graphics
engine suitable for industrial and general
release.

But it is a pretty good little move
the bitmaps and make them bounce
kind of a game.

In any case the idea of transform the objects
after loading them allows for the ability
to have terser input files, simplifies
the generation of the svg for use of the
program.

So the scheme would be this:
  use inkscape or other draw program to
generate valid svg.
Then open that valid svg with your game.
Have the game grab the named entities 

and then generate multiple bit maps of these
with various values of rotation as needed.

The bitmap interface that kbounce uses
is the kdegames one.  Basically kdegames
tries to optomize the use of bit maps
so that if the same bitmap intializes 
hundreds of other bitmaps, if those ultimately are just hte same image the kde games interface doesn't make that many
copies.  I beleive it is only a copy on
write.  So if the bitmap does get modifies (which is never the 
case with kbounce) then a copy is made.

The flaw that I fixed in kbounce was that
the original game had one giant bitmap that represented the walls.  And then when
walls were added on this underlaying 
bitmap needed to be updated.
I modified the game so that wall tiles
are single bit maps which are predefined
at startup and preloaded.  When a wall is
shown all that has to happen is that the
'visible' flag is set for that tile and
then qt takes care of showing the bit
map.

Doing this makes the game faster
because the processing is done at
start time.  and even though there might be
an array of 400 by 600 bitmaps (each only, maybe, 4x4) those bitmaps are
all actually the same image so
the memory footprint does include
reproduced data 400x600 times.

Part of the point of this is tht this
is a very good underlying engine for
kbounce.  So the programmer interested
in modifying kbounce really doesn't
ahve to go into the inards of how 
qt does this.

In any case there are other issues with 
this toy program.  I am
already wanting to fork so that 
I have a program that is more for
what I am using it for these days.

And the addition of rotating elements is
part of what I want to do.

I added an enumeration to map the balls.
I created a case statement with a
case for each of the 6 various combinations
of balls in John's scheme.
And this only creates three balls.
It works well.  I am thinking of demoing 
this to John (because I already told
him about this).

above is a screen
shot of the modified
kbounce.  This shows the
six possible ways of
having three different
shapes, each of a 
different color:

One red
one yellow
one blue

One triangle
one circle 
one square

The above screen shot
shows 6 different
instances of kbounce
as so modified.

As I chose a random
selection of which of the
six variations to display 
at startup, I had to 
respawn until I got the
correct six.

The randomness . . . of this
was an interesting thing to observe.

It took a while to get all six.
At times I worried if there
were something wrong with my
random seeding . . . 

random means random, doesn't it?

I demoed the John's modification ideas
for kbounce to John this week.
He was impressed with it.

We just discussed some new ideas.

1.  The elements (balls) can be on top of each other and are semi-transparent and
 the colors mix.

2.  balls rotate, and when they hit each other
they don't just bounce but transfer angular momentum.

3.  balls bounce around inside of balls.


4.  John's idea.  The balls are so slow that
it is like watching the stars in the sky, the don't seem to move but over time you see that it is.