Theme/skin concept for 2.0

22 views
Skip to first unread message

Steve Maddison

unread,
Oct 7, 2014, 3:38:06 PM10/7/14
to cabrio...@googlegroups.com
OK, so I've been thinking about how to handle the whole theme/skin thing which kind of works in 0.8 but isn't as flexible as it could be. I don't think there's anything particularly ground-breaking here.

The main point we hit on already is that themes can be defined hierarchically. The default theme serves as the basis and can be overridden by each "layer" in the hierarchy. The particular order would need to be configurable and would probably most logically follow the drill-down concept as configured by the user. An example would be default -> system -> genre -> game, where each layer is optional.

The individual elements of a theme are basically some images and the layout of a number of on-screen objects. These objects represent anything but are all based on a fixed set of programmed primitives (image, video, soundtrack, etc.). Some special types may be needed to implement an animated game selector, like a wheel or scrolling set of images. All elements have a position in XYZ space and a rotation in XYZ axis, both of which may be absolute (based on centre of the "world") or possibly relative to a higher level theme. Each may also have a transition effect (possibly separate ones for entry/exit) such as fade, zoom, slide in/out or a combination of these.

The associated files are located through the same hierarchy, so first check at game level, then subsequent layers, down to the default. Each layer can define a specific file or offer a directory to search for matches (like the current locations feature). Higher level themes can alter any objects and/or supplement them with their own. Each object can be animated in a script-like manner (rotate, translate, delay, loop, etc) so by layering up a few objects you could do pretty much anything.

That's basically all I can think of right now. I'm sure more will come up, along with some tasty little gotchas when it comes to the actual implementation. Please feel free to post comments, additions, etc.

Cheers,

Steve

Pieter Hulshoff

unread,
Oct 7, 2014, 3:50:15 PM10/7/14
to cabrio...@googlegroups.com
I agree with the general concept, with a few additions:

1. I propose 1 or 2 alternative options for each object, e.g.: show a video; if not available show alternative 1: a screenshot; if not available show alternative 2: a titleshot. Something along those lines.
2. Each object should be programmable with an offset to the current selected system/game. This way you can easily create any kind of gaming selection system, be it a wheel, a list, a card flip system, etc. As an example: show wheel image of the current game at location (800,500,50), wheel image of current game +1 at (800,700,50), etc.
3. Each object should be able to have a fixed size to which the original object is proportionally scaled. This way you can make sure that you get a common look independent of the resolution of your source images compared to each other.
4. I propose leaving the transition effects for version 2.1 or later; they're much harder to program.

Steve Maddison

unread,
Oct 8, 2014, 4:40:47 AM10/8/14
to cabrio...@googlegroups.com
On 7 October 2014 21:50, Pieter Hulshoff <phuls...@gmail.com> wrote:
I agree with the general concept, with a few additions:

1. I propose 1 or 2 alternative options for each object, e.g.: show a video; if not available show alternative 1: a screenshot; if not available show alternative 2: a titleshot. Something along those lines.

Good one, a sort of hierarchy in the hierarchy.
 
2. Each object should be programmable with an offset to the current selected system/game. This way you can easily create any kind of gaming selection system, be it a wheel, a list, a card flip system, etc. As an example: show wheel image of the current game at location (800,500,50), wheel image of current game +1 at (800,700,50), etc.

Sure, this kind of hooks into the "special types" for this kind of stuff. More generally, we can allow any object to be placed relative to any other (i.e. make the origin of translation and/or rotation the centre point of an other object, the default being the centre of the world/screen).
 
3. Each object should be able to have a fixed size to which the original object is proportionally scaled. This way you can make sure that you get a common look independent of the resolution of your source images compared to each other.

Forgot about that one, yes. Options for min/max width and height, fixed aspect ratio, etc. for all on-screen objects.
 
4. I propose leaving the transition effects for version 2.1 or later; they're much harder to program.

Sure, we do need at least one basic effect though (fade or fly-in/out) or it's going to look weird with stuff flashing on and off on the screen.

Pieter Hulshoff

unread,
Oct 8, 2014, 6:58:09 AM10/8/14
to cabrio...@googlegroups.com


On Wednesday, October 8, 2014 10:40:47 AM UTC+2, Steve Maddison wrote:
On 7 October 2014 21:50, Pieter Hulshoff <phuls...@gmail.com> wrote:
Sure, this kind of hooks into the "special types" for this kind of stuff. More generally, we can allow any object to be placed relative to any other (i.e. make the origin of translation and/or rotation the centre point of an other object, the default being the centre of the world/screen).

This will require an object ID for each object so they can be linked to each other.
 
Sure, we do need at least one basic effect though (fade or fly-in/out) or it's going to look weird with stuff flashing on and off on the screen.

Do we? Isn't that basically how things work in the current version? Running through the list isn't really animated; it just switches from the objects for the current game to the objects for the next.

Steve Maddison

unread,
Oct 8, 2014, 7:20:12 AM10/8/14
to cabrio...@googlegroups.com
On 8 October 2014 12:58, Pieter Hulshoff <phuls...@gmail.com> wrote:
 
Sure, we do need at least one basic effect though (fade or fly-in/out) or it's going to look weird with stuff flashing on and off on the screen.

Do we? Isn't that basically how things work in the current version? Running through the list isn't really animated; it just switches from the objects for the current game to the objects for the next. 

For switching between games it's not really critical, no. When switching focus (e.g. from category selection to game selection or back again) there is some animation involved to clear everything off the screen and present the new view.

Reply all
Reply to author
Forward
0 new messages