Layout Code

[Joseph K]

Hey guys,
I've been working on the Layout classes (glue between display and
game data) and have a few problems left. Part of it is the lack of
input, part is some abstraction I'm wrapping my head around. I committed
the code to my fork on GitHub and submitted a pull request to Steve's
repository. It compiles and sort of breaks existing test cases
(commented out). However, it is not yet well tested. Some notes:

Some things I did:
CabrioDataTypes are where I'm defining enumerations. Including an
ImageType enumeration based on Pieter's list in another email. I put
these in a central location to allow to expand/contract these things as
needed.
ImageType is used as part of a Map tied to quads within Game and
Platform to minimize duplicate structures (Why have multiple "game"
classes?), and to make it easy to get a particular image type to display
the quad for. Platform is used for the higher level with backgrounds and
such... It'll probably get moved.
LayoutBase is intended to be an abstract class that we can define the
list display layouts within. I started defining LayoutGrid, but hit a
couple mental roadblocks.

I'd like some feedback, so feel free to pull from my repository... or
just poke through it.

Thanks,
Joseph

[Pieter Hulshoff]

Joseph,

I'll try to have a look at it this week, and give some feedback. This may be a good time to integrate my menu structure, since it defines how one transverses through the menu structure, handles game selection, and how to get the game parameters.

Kind regards,

Pieter

[Joseph K]

Pieter,
Sounds like a great time to get started integrating our code. I think each side will provide some interesting test cases for the other. I'm going to do some touch up and more commenting tonight. Though I don't want to get too carried away until we really know the parameters.

Speaking of comments. Wet may want to start going down the road of doxygen. It'll help us keep tabs on what is where and make it easier to visualize dependencies.

Can you send me a link to you stuff? (You can send directly and not bother the list if you'd like)

Regards,
Joseph

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Pieter Hulshoff]

On Monday, November 3, 2014 3:42:01 PM UTC+1, Joseph K wrote:

Can you send me a link to you stuff? (You can send directly and not bother the list if you'd like)

I have a fork, just like you: https://github.com/phulshof/cabrio2
:)

PS: I'm still only capable of posting from gmail; posting directly on the Google group gets my posts swallowed by the system.

[Pieter Hulshoff]

It looks like a good start, Joseph. Looks like a very good time to have a look at integrating my code, since it impacts the class structure you currently use.
With regards to the datatypes:
- What is screen?
- Why have a background type rather than an image type? A background's just an image at the deepest level, isn't it?

[Joseph K]

On 11/09/2014 07:10 AM, Pieter Hulshoff wrote:

It looks like a good start, Joseph. Looks like a very good time to have a look at integrating my code, since it impacts the class structure you currently use.
With regards to the datatypes:
- What is screen?

short for screenshot. I suppose I could be more explicit.

- Why have a background type rather than an image type? A background's just an image at the deepest level, isn't it?

I was enumerating all of the image types, thus the association with a particular quad. It makes the code really simple:

Platform.GetImageByType(ImgType::Background);

returns null if no association is there.

The background is a bit of a special case, and I'm not sold on Platform containing imagery just yet... it doesn't make sense for list by genre.


My thinking is this was a good generic way to create that association for game displays. Just need to tie in the positioning of the various image types with the list to be displayed. So, we can loop over the enabled images somewhere, pull them and position them by "type". I even included a means to leave the render list alone until the selected game changes, limiting memory read/write and some computational overhead.

--
You received this message because you are subscribed to the Google Groups "Cabrio FE Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cabrio-fe-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Maddison]

On 3 November 2014 00:37, Joseph K <jcko...@cs.unm.edu> wrote:

Hey guys,
  I've been working on the Layout classes (glue between display and game data) and have a few problems left. Part of it is the lack of input, part is some abstraction I'm wrapping my head around. I committed the code to my fork on GitHub and submitted a pull request to Steve's repository. It compiles and sort of breaks existing test cases (commented out). However, it is not yet well tested. Some notes:

Wow, hoped to get a proper look at this before now but have been a bit under the weather the past week. I think we're on the same page with the Layout parts, that looks to be shaping up nicely :)

 

Some things I did:
CabrioDataTypes are where I'm defining enumerations. Including an ImageType enumeration based on Pieter's list in another email. I put these in a central location to allow to expand/contract these things as needed.

Enumeration keeps it nice and simple for now but eventually I'd like to have a configurable alternative. One of the problems in 1.0 is that the image types are hard-coded so any new ones need code changes.

 

ImageType is used as part of a Map tied to quads within Game and Platform to minimize duplicate structures (Why have multiple "game" classes?), and to make it easy to get a particular image type to display the quad for. Platform is used for the higher level with backgrounds and such... It'll probably get moved.
LayoutBase is intended to be an abstract class that we can define the list display layouts within. I started defining LayoutGrid, but hit a couple mental roadblocks.

I'd like some feedback, so feel free to pull from my repository... or just poke through it.

Only other feedback I have is that the platform and gamelist stuff ought to be in (or around) the Layout layer to keep the lower level rendering stuff as clean as possible.

Hopefully I'll get a chance to look more in depth this evening or at least later in the week. I'm still working on the images/textures part of the renderer and have a few changes in mind to tidy things up when it's working.

Cheers,

Steve