[Kde-games-devel] Ideas for QML support in libkdegames
Viranch Mehta
viranch.mehta at gmail.com
Mon Mar 4 13:10:46 UTC 2013
Hey all,
I spent last weekend working on differenct ideas for having QML support in
libkdegames - the main issue being the theme loading. I came down to two
designs:
====
*1. Use QDeclarativeImageProvider instead of KGameRenderer:*
Here we supply our KgThemeProvider(s) to the QML engine, which adds our
KgImageProvider with the supplied KgThemeProvider(s) to the QML context.
the KgImageProvider is a subclass of QDeclarativeEngine that talks to the
supplied KgThemeProvider to get path to svg and use QSvgRenderer to render the
particular spriteKey requested.
the trick with enabling changes in the images on theme update is to include
the theme name in source's value-
"image://myimageprovider/EgyptianTheme/Background". so whenever theme is
updated, source url will change and new image will be requested frm the
KgImageProvider.
Pros:
1. QDeclarativeImageProvider has inbuilt ability of caching and asynchronous
loading, so we can get rid of KGameRenderer altogether in QML ports.
Cons:
1. When game window is resized, sprites of new size have to be naturally
retrieved from the SVGs, but QDeclarativeImageProvider is not triggering a new
request, its resizing the pixmap from cache. we could overcome this by adding
dimensions to source string, change in which would trigger a new pixmap
request, but that seems over-usage of source parameter IMO.
*2. Make KGameRenderer a QML component*
Here we declare all our KGameRenderers in QML itself:
Renderer { source: "appdata/themes" }
The component internally will split source string with "/" and use the tokens
with KgThemeProvider to discover themes and load sprites from them.
The problem of missing default constructors in KGameRenderer and
KGameRendererClient are also fixed by implementing them :) I tried this and
doesn't seem to break anything.
Pros:
1. Graphics are polished as pixmaps of correct size are given by
KGameRenderer.
Cons:
1. The overall speed becomes little slow in comparision to Design1, as each
resize triggers a request for new pixmap.
2. we need to supply the underlying KgThemeProvider to KgThemeSelector to
change themes during gameplay. with above approach, we'll have to dig deep in
QML context to extract the KgThemeProvider object, which seems dirty.
====
Basically we have trade offs between performance+good-way-to-do-it and graphic
quality.
Ideas on these would be great.
Cheers,
Viranch
More information about the kde-games-devel
mailing list