Gleed2D Updates - Lets Discuss

[epochofentropy]

Steve,

I'm working on a new libGDX-based game, and have elected to use Gleed2D as the level editor. There's a number of enhancements to Gleed2D that I would like to contribute without forking it as a completely new project.

I was curious how welcome you would be to large updates to Gleed2D going forward. I understand the need to keep it backwards compatible with the current XML structure.

More details on updates I will be doing is forthcoming.

[SteveDunn]

Hi there,

I would love some updates to Gleed2D! I have recently been doing some major refactoring of the code to support 'containers'. A container is like a 'layer', but you can have 1 or more per layer and each container has 1 or more items and also attributes such as rotation, origin, and scale. It gets interesting when you have a container within a container.

I needed containers for my game. In a typical 'tail what wags the dog' situation, the tool has now taken longer to do than my game!

To differentiate this tool from the original GLEED2D, I have renamed it 'Oglr' (https://github.com/SteveDunn/oglr) (Open Generic Level editoR). The version on GitHub has pretty much identical code to my Gleed2D on github, but with things renamed. I haven't pushed my container changes yet as they're not quite ready.

I'll add you to both projects. It'll be nice for someone else to look through the code, spot any issues, and keep it fresh!

Cheers,

Steve

On 24 March 2014 14:15, Epoch of Entropy notifications@github.com wrote:

Steve,

I'm working on a new libGDX-based game, and have elected to use Gleed2D as the level editor. There's a number of enhancements to Gleed2D that I would like to contribute without forking it as a completely new project.

I was curious how welcome you would be to large updates to Gleed2D going forward. I understand the need to keep it backwards compatible with the current XML structure.

More details on updates I will be doing is forthcoming.

Reply to this email directly or view it on GitHubhttps://github.com/SteveDunn/Gleed2D/issues/40 .

[epochofentropy]

Steve,

Thank you for adding me as a contributor to Gleed2D and oglr!

How much latitude for changes are you comfortable with for Gleed2D? There's clearly quite a few issues with the editor and there's also quite a few new features that I'm working on adding. Cleaning up the code and fixing the issues may require refactoring large swathes of the code base.

Depending on the features of oglr, I might be interested in contributing to that too. But, for the time being I'm going to focus on the Gleed2D code base. To keep updates to oglr easier, it may be prudent to make the oglr repo a private fork of Gleed2D, but renamed. Then changes to Gleed2D can be pushed there with ease. That's your call though.

[SteveDunn]

Hi there,

You're very welcome - glad to have someone else that's interested in the project! I'm happy for any changes. I refactored a lot of the original code and 'componentised' a lot of it. There's still a lot of code that needs attention though.

Re. Oglr: the code is already quite a bit different from Gleed, but it's functionally the same. I don't know that the effort to track changes between the two is worth it (quite a lot of the code now lives in different folders/namespaces). It would be great to take Oglr forwards, but I understand if you want to continue with Gleed.

Cheers,

Steve

On 27 March 2014 00:01, Epoch of Entropy notifications@github.com wrote:

Steve,

Thank you for adding me as a contributor to Gleed2D and oglr!

How much latitude for changes are you comfortable with for Gleed2D? There's clearly quite a few issues with the editor and there's also quite a few new features that I'm working on adding. Cleaning up the code and fixing the issues may require refactoring large swathes of the code base.

Depending on the features of oglr, I might be interested in contributing to that too. But, for the time being I'm going to focus on the Gleed2D code base. To keep updates to oglr easier, it may be prudent to make the oglr repo a private fork of Gleed2D, but renamed. Then changes to Gleed2D can be pushed there with ease. That's your call though.

Reply to this email directly or view it on GitHubhttps://github.com/SteveDunn/Gleed2D/issues/40#issuecomment-38755506 .

[epochofentropy]

Steve,

I've created a Google Doc with the things I'm planning on working on, roughly sorted by priority.

https://docs.google.com/document/d/1nJpkcGR2OoOQPHG9HmPozcuHiC9FUu02SgDu3KjL-PA/edit

Other than the name change to distance it from the CodeProject version, is there any specific reason to have Oglr separate from Gleed?

[SteveDunn]

That's a great list! The tool will be much better with those in place. Would be nice to have those as Issues in github and reflected on Trello. I'll be happy to chip in on some of them

Re. the name change: I did this to differentiate it from the old tool as a lot of people still search and hit the original tool page instead of the new one. I also think the "Open" bit in Oglr implies that the tool is open for plugins etc.

On 29 March 2014 21:04, Epoch of Entropy notifications@github.com wrote:

Steve,

I've created a Google Doc with the things I'm planning on working on, roughly sorted by priority.

https://docs.google.com/document/d/1nJpkcGR2OoOQPHG9HmPozcuHiC9FUu02SgDu3KjL-PA/edit

Other than the name change to distance it from the CodeProject version, is there any specific reason to have Oglr separate from Gleed?

Reply to this email directly or view it on GitHubhttps://github.com/SteveDunn/Gleed2D/issues/40#issuecomment-39008976 .

[epochofentropy]

Fair enough, I'm seriously considering that a name change would be a good idea. Gleed seems to have a bad rap, and after a few dozen more hours work the tool here will be substantially different.

There's an feature that I've come across that may introduce a breaking change though, and wanted to run it by you to see how much it will impact your work.

Currently all of the Texture objects are saved with a ScaleX/ScaleY which defines their width in the world relative to the actual Texture's pixel dimensions. This presents a problem though with games that have multiple texture resolutions for different devices.

To address that, I was going to add a width/height attribute to the Texture object, which would be the principal driver of the object's world width. ScaleX and ScaleY would essentially be deprecated, or updated as a component of the Width/Height.

This would clearly break any previous implementation without having an option in the serialization routine that saves/loads in the previous format.

Thoughts?