[Kde-games-devel] Questions about porting kolf

[Mauricio Piacentini]

Hi, Paul.

> I think I'm going to try porting the graphics to QGV, rather than KGameCanvas. 
> This is because I have already worked with QGV a little and in an earlier 
> thread Mauricio Piacentini said not to use KGameCanvas unless you understand 
> the differences (which I certanly don't!) or you have a good reason to and, 
> as far as I know, I don't. However, I have a couple of questions regarding 
> the suitability of QGV:

Well, go with what you know best. I am still seeing severe performance 
issues on some QGV-based applications, like the one I reported against 
lskat. It does not happen on all machines, apparently.
Honestly, I am done with QGV troubleshooting for now. I do not have the 
stamina to engage on this particular issue at this time, having tackled 
it during the KGoldRunner port. But if you go with QGV, and find any 
barriers later, then we are slowly getting a team of people that have 
experience with it (dimsuz for example), and you will probably have help 
handy if needed. Trolltech is also betting heavily on it, so eventual 
issues will probably be ironed out before KDE4 ships.
And in a worst case scenario there is always the possibility of a 
rewrite to KGameCanvas, this should be easy for simple applications.

> 2) In a private email, Mauricio mentioned that there had been a problem 
> porting kolf to QGV because QGV does not allow placing of canvas items inside 
> other canvas items. I don't know enough about QGV to understand this problem, 
> so could someone please explain it to me.

That was my understanding after following the previous messages by 
Dmitry, but I have not actually looked at the code. I am not sure you 
can put one QGV element inside another, and if this is really a requirement.

> 4) Do I need to think think about future graphical modifications when doing 
> the inital port to QGV? All the screen shots of games using SVG look awesome, 
> I'm not sure how to translate this style of kolf, but I'll probably want to 
> use some SVG graphics at some point. For now would it be best to just do a 
> basic port using the current graphics, or does changing to things like SVG 
> mean a fundamental graphical change that I'd want to start thinking about 
> now?

In general I believe you should tackle the port first, just get 
something working with the current graphics, but already considering the 
need to scale the view size. In the future it will be easy to plug SVG 
graphics into it if you already have scaling support in the engine, and 
resolution independence (presentation not tied to game logic, ideally).

> 6) Finally a very minor question, in kolf there seem to be many variables 
> whose name begins with "m_", but I can't see any connection between these 
> variables. Is there some naming convention that I'm unaware of?

This is part of something called the hungarian notation, a convention 
used by some C++ programmers or teams. It is mandatory on some 
companies, but not on KDE. m_ marks the member instances, g_ is used for 
globals, k for constants. This in theory makes it easy for you to 
identify the scope and type of a variable quickly. See

http://en.wikipedia.org/wiki/Hungarian_notation

Regards,
Mauricio Piacentini