GitHUb repo for 2.0

[Steve Maddison]

Seeing as it's going to be a rewrite, I went ahead and created a separate repo for 2.0:

  https://github.com/SteveMaddison/cabrio2

Nothing much of interest in there yet, but I added a few provisional issues for the MVP milestone (they will probably need tweaking a bit).

As I think I mentioned before, I'd like to use git flow to manage branches:

  https://github.com/nvie/gitflow

To this end you'll see that there's already a "master" and "develop" branch in the repo. The procedure for contributing is therefore:

  1. Clone the repo.

  2. Start a feature.

  3. Offer the feature branch as a pull request to the upstream develop branch.

Please feel free to add features to the issue list, I will try to manage them and group them together somehow where possible.

--
Steve Maddison
http://www.cosam.org/

[Pieter Hulshoff]

I'll have to dive into this a bit, since I'm not familiar with the git flow. I'm sure I'll figure it out sooner or later though. :) Are you creating accounts for us or can anyone check in changes?

[Steve Maddison]

On 8 October 2014 20:31, Pieter Hulshoff <phuls...@gmail.com> wrote:

I'll have to dive into this a bit, since I'm not familiar with the git flow. I'm sure I'll figure it out sooner or later though. :) Are you creating accounts for us or can anyone check in changes?

I guess for you chaps git flow isn't really important, I just need it to keep the upstream repo organised. The only thing contributors need to remember is to base their features on the "develop" branch.

The way GitHub works is that everyone can fork a repo (being git, you get a complete copy, including all history). You then clone that to your development machine (in essence this is a copy of the copy) and make your changes. Once you're done, you can push the changes back to your fork on GitHub, then offer them via a pull request back to the original repo. It takes a bit of getting used to if you're coming from centralised repos like Subversion.

So, short version: you can just sign up on GitHub get started :)

[Pieter Hulshoff]

I'm going to need some command help here. I committed the first version of the menu.hpp and menu.cpp files, but my push request gives me:
remote: Permission to SteveMaddison/cabrio2.git denied to phulshof.
fatal: unable to access 'https://github.com/SteveMaddison/cabrio2.git/': The requested URL returned error: 403

Could you give me a command set to execute to properly add my files to the system or is it something you need to change on your end?

[jcko...@cs.unm.edu]

I finally (gasp!) was able to pull down the repo and started working on a
little more C++-ification of the code.

The two big things I did:

1) Reworked GameList to use iterators instead of an integer offset. This
buys us a few things.. Iterators have increment/decrement and dereference
operators, the code is quite simple (no more getAt() and pointer hell). We
can now use any STL container, and the next/prev will just work. Less
bookkeeping, we are bound by begin() and end(). end() is technically just
past the last item, so end()-- is the actual last item.

2) Created a Singleton class that can be inherited from. We can now
publicly inherit from this class to turn any class into a singleton. No
more recycled code. As a bonus, if we decide to do a not-quite singleton
(e.g. limit instantiation count to 3, or a number of cores...), we now
have a centralized file to make those changes.

I haven't submitted the code because I haven't quite got the Singleton
class quite where it needs to be (compiler error).

I plan to keep at it for a while tonight. Once I'm done, I'll start
looking into the graphical side... where I expect another singleton will
be.

Regards,
Joseph

> --
> 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.
>

[Pieter Hulshoff]

On Monday, October 20, 2014 3:07:40 PM UTC+2, jcko...@cs.unm.edu wrote:

I finally (gasp!) was able to pull down the repo and started working on a
little more C++-ification of the code.

Github, always a new adventure...
 

1) Reworked GameList to use iterators instead of an integer offset. This
buys us a few things.. Iterators have increment/decrement and dereference
operators, the code is quite simple (no more getAt() and pointer hell). We
can now use any STL container, and the next/prev will just work. Less
bookkeeping, we are bound by begin() and end(). end() is technically just
past the last item, so end()-- is the actual last item.

You may need to have a look at my code too when the push process finally pulls through. I had some trouble getting iterators to work there, so I used uint for now. Feel free to upgrade my code accordingly. I'm open to suggestions about improvement as well. Do keep in mind that the current GameList may be replaced with the structure I'm working on.

[Steve Maddison]

Ah, looks like you're pushing straight to my repo. What you want to do is log in to the github web interface, browse to the repo and hit "fork". You then have your own copy on github you can clone to you local machine. As it's your copy, you can push to it too. It looks like you're using the right commands for these parts.

When you've got something pushed and want to submit it, you can use the web interface again to do a pull request from your fork to mine.

Let us know how it goes!

[Steve Maddison]

> On 20 Oct 2014, at 15:07, jcko...@cs.unm.edu wrote:
>
> I finally (gasp!) was able to pull down the repo and started working on a
> little more C++-ification of the code.
>
> The two big things I did:
>
> 1) Reworked GameList to use iterators instead of an integer offset. This
> buys us a few things.. Iterators have increment/decrement and dereference
> operators, the code is quite simple (no more getAt() and pointer hell). We
> can now use any STL container, and the next/prev will just work. Less
> bookkeeping, we are bound by begin() and end(). end() is technically just
> past the last item, so end()-- is the actual last item.

Nice, this sounds much better. I had a wrestle with iterators and ended up falling back to an integer index just to get it working.

> 2) Created a Singleton class that can be inherited from. We can now
> publicly inherit from this class to turn any class into a singleton. No
> more recycled code. As a bonus, if we decide to do a not-quite singleton
> (e.g. limit instantiation count to 3, or a number of cores...), we now
> have a centralized file to make those changes.
>
> I haven't submitted the code because I haven't quite got the Singleton
> class quite where it needs to be (compiler error).

Cool, like that.

> I plan to keep at it for a while tonight. Once I'm done, I'll start
> looking into the graphical side... where I expect another singleton will
> be.

Yep, I have a bit of an experimental branch going with the basics of an abstract renderer and a stub for an OpenGL implementation. I pushed an early version if you're interested, not sure if this is the right direction yet. I still need to go through the link you sent properly. Once we can get a basic quad on the screen with a position, rotation and texture the rest should start flowing nicely.

[Pieter Hulshoff]

Ok, I'll give that a try tomorrow to see how it goes. I had iterator issues as well, so I'll let Joseph have a crack at my code. What should I do with the menu xml examples? Perhaps a tgz file in the database or should we distribute those separately?

I plan to get a gold account at HS, and download the graphics files to see if we can set up some nice skins. Next step after that will be the videos. Any thoughts on support for flv vs mp4?

Kind regards,

Pieter

[Pieter Hulshoff]

Ok, I've forked the database, and added the menu files. I didn't include them in the makefile at this time, because I think Joseph should have a good look at them first before including them into the code. You may want to have a look at the class functions to see if they cover what you would like to do with a menu structure.

I have a few auxiliary files as well, like a small test and an example XML menu structure supporting the Atari 2600, Atari 5200, Atari 7800, MAME, Nintendo Entertainment System, Sega Master System, Sega Mega Drive, and Super Nintendo Entertainment System. What would you like me to do with those? I plan to extend them of course to include more systems, but I haven't gotten around to deciding which other systems to include. MESS supports so many...