[Kde-games-devel] Kolf hacking

[Stefan Majewsky]

Hey folks,

between much real-life work, I've found that the soft feature freeze is upon 
us next week. Time to get some stuff done! And I still have some unfinished 
work on Kolf 1 lying in my Git repository. I polished that a bit other the 
last two evenings, and I am coming to a point where I actually understand most 
of the code which I am modifying.

This is what have I done up to now:
- To reduce the possibility of breaking stuff, I've removed most dead ends and 
unused features which I found: the plugin interface, printing support, 
CanvasItem::fastAdvance.
- I've killed one of three class hierarchies. Items are not instantiated by 
some extra Object class (of which one exists per Item), but by a simple 
ItemFactory. (This idea has been tested in Kolf-NG.)
- Home-grown geometry calculations have, whenever possible, been replaced by 
QPointF and QLineF. Unnecessarily complicated code has been simplified, e.g.
> QPointF p1; ...
> /* before */ QPoint p2 = QPoint((int) p1.x(), (int) p1.y());
> /* after  */ QPoint p2 = p1.toPoint();
- Rendering is provided by KGameRenderer. To accomodate the advanced needs of 
Kolf, I've imported some classes from Tagaro (sum ~600 LOC) into the source 
tree. (This benefited Tagaro, too, because of the higher testing coverage.)
- Most importantly, I've ripped out all the coordinate handling code that's 
becoming obsolete because we're actually doing stuff The Right Way™ (i.e. 
using what is already available in QGraphicsView and Tagaro).

The removed and simplified code adds up to a difference of over 1000 SLOC, 
reducing Kolf's code size by about an eighth. (And I've only touched the 
rendering code up to now, I never had a look at the really complicated 
collision code.)

The problem which I'm having, is that my total diff against SVN head is 
already +1066/-2326 lines (counting only changes to Kolf's actual source code, 
the import of Tagaro classes is another +1023 lines). I think this size is 
impractical for ReviewBoard, nor do I think that you want to get these changes 
as the 37 separate commits I have made to my Git branch. How do we want to go 
about this?

During the hacking, I've made very small commits and tested changed parts as 
extensive as possible in the short time frame, to ensure that no regressions 
occur. The only regression I've noticed so far is that wall-ball collision is 
even worse now. (It's better in the sense that the ball seems not to get stuck 
that often anymore. It's worse because this is because of the ball just not 
interacting with the wall at all most of the time.)

In my local source tree, there is already a copy of the Box2D physics engine 
(which is usually statically linked, so no new external dependency). I have 
experimented with it in Kolf 2 and was quite satisfied with the results. I 
might be able to reuse some of the code from Kolf 2, yet quite some 
refactoring has to be done.

How do we want to go about reviewing? Shall I just commit this into trunk and 
hope that this fixes more stuff than it breaks?

Greetings
Stefan

P.S. Don't worry about the soft feature freeze which I mentioned in the 
beginning. I've put Kolf refactoring on the feature plan, so the hard feature 
freeze next month is what counts.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20101024/f8cf9a57/attachment.sig