AGS Development > Engine Development
Thoughts on refactoring and futher improving the engine
Crimson Wizard:
Here are my thoughts on possible continuation of the hypothetical branch of AGS that would merge JJS's portable version and refactored one.
I wanted to wait till I clean my branch a bit before posting this, but that takes time and also monkey_05_06 told me he wants to work on that too; so it goes here.
Before anything else I want to state following:
1. Unfortunately I am not aware of development process in official AGS 3.2 branch. I only know that Tobihan merged it into JJS's rep some time ago, but that was only Editor code.
2. My own branch is based on JJS's one and has practically everything JJS and Tobihan made, except for maybe few recent commits. I planned to merge their code at every stable stage, but after last changes I made to my branch I am not sure I will be able to do so with the same ease, since code structure changed too much (on other hand, it is perhaps worth trying automatic merge to see what happens ;)).
Recently things became somewhat messy there because of rushed splitting large source file, but I am working on cleaning things up right now.
It does compile and seem to work as expected (i.e. without any changes to program execution). On Windows - that's it. Haven't tested on other platforms that are supported by JJS branch.
3. I asked JJS and Tobihan to tell their opinion about merging our branches; so far I got response from Tobihan who agreed to check and fix linux compilation for my branch.
I haven't got answer from JJS yet, and I would really like to hear from him.
Links:
Adventure Game Studio "organization" on github:
https://github.com/adventuregamestudio
contains JJS's branch:
https://github.com/adventuregamestudio/ags
My own branch:
https://github.com/ivan-mogilko/ags-refactoring
Following is not a "big plan", but rather thoughts on most immediate things needed.
Organizational
Obviously there should be a feature and bug tracker.
Using forum threads is not a good idea, since they tend to become messy and off-topic too fast.
JJS has one for his own branch: http://jjs.at/tracker/
Does the offical AGS branch have it?
What may we use?
Some place to discuss practical coding problems. I know this will sound snobish, but I am a pragmatic man and I realize that doing this on forums with public write-access will make it mostly off-topic chat eventually as well.
Code design documentation.
Administrative
Since there will be alot of ideas thrown in eventually, I believe we must determine the criteria which would allow us to split all such ideas and feature proposals into three categories:
- Ones that change engine/editor too much to be implemented into version 3.* and should be left aside until better times (AGS 4).
- Ones that could be implemented into 3.* without breaking backwards compatibility.
- Ones that could be implemented into 3.*, but are too exotic or not as useful to average game creator to be part of engine core, and thus should be rather made as plugins.
Code-wise
Code-style is to be determined. I do not think it should be thoughtlessly applied to existing code, since that will increase amount of work needed to merge changes from other branches, but as we rewrite parts of it we should use code-style.
Following are changes that I would really like to see made to AGS engine:
1. Separating platform-dependent and low-level code as much as possible (and reasonable) from engine core.
There should be no #ifdef WINDOWS_VERSION or #ifdef ALLEGRO_BIG_ENDIAN scattered all around the code as it is now.
I belive, there should be no raw FILE or BITMAP type references in the engine core as well. I hate to include allegro headers in almost every unit only because one of the function it needs to be known has BITMAP or RGB in parameter list.
Probably writing interfaces for some kind of "serializer" or abstract drawing system will improve things.
2. Substituting raw static and dynamic arrays with classes. That could be either STL or AGS own utility classes.
String class too, perhaps.
//--------------------
EDIT: Oh, right, how could I forgot...
Important thing is to decide whether to propose refactored branch as a merge candidate to official 3.2 or not.
Ofcourse it needs more testing, but with changes made only to code composition and not to program execution it does not make whole new version of AGS, like 4.0.
I would suggest to aim for version 3.3 or something like that, which would include refactored code + some of the most wanted additions to engine.
JJS:
--- Quote from: Crimson Wizard on 20 Jun 2012, 09:46 ---Before anything else I want to state following:
--- End quote ---
1. Everything that was in the 3.2.2 dev branch of the SVN was merged. It was all editor changes and I am not aware of official engine changes.
2. I don't think merging is hard since large code changes are mostly in the platform specific code which is untouched by the refactoring. The engine changes are usually very small.
3. If by merging you mean that the main branch switches to the refactored code: Not sure if this is beneficial at this stage. But I will also test the changes on the other platforms.
What we could do is creating a refactoring branch directly in https://github.com/adventuregamestudio if that helps.
Organizational:
Github has a bug tracker. It would be the best choice imho since it is closest to the source code.
Code-wise:
1. YES. The various platform defines really make the code error prone. For example I was hunting some drawing error that stemmed from an innocent #ifdef MAC_VERSION hidden somewhere. I think #ifdefs should be rewritten so that they focus on a specific task/property instead of a platform. E.g. having a define for RGB vs. BGR color order.
Existing platform specific methods should also be used, e.g. for delaying the execution there is a method in the platform class but still Sleep() is used in various places and has to be separately redefined for non-Windows platforms.
Crimson Wizard:
--- Quote from: JJS on 20 Jun 2012, 10:23 ---3. If by merging you mean that the main branch switches to the refactored code: Not sure if this is beneficial at this stage. But I will also test the changes on the other platforms.
What we could do is creating a refactoring branch directly in https://github.com/adventuregamestudio if that helps.
--- End quote ---
My primary intent is to make this more open and easier to find so others could join in and collaborate eventually.
So, I would totally agree if there will be a separate branch in adventuregamestudio for now.
--- Quote from: JJS on 20 Jun 2012, 10:23 ---Existing platform specific methods should also be used, e.g. for delaying the execution there is a method in the platform class but still Sleep() is used in various places and has to be separately redefined for non-Windows platforms.
--- End quote ---
Well, my idea in general is to limit the amount of modules that "know" they are using something platform-specific. If a code uses a symbol without having to "worry" whether it is a Windows function or some defined alias with extra tweaking, it should be ok, I guess.
AGA:
There is a project tracker built into the forums, it's just that until now no one except moderators could see it. I was waiting for the moderators to take a look at it and sign off, but no one ever did!
Assuming this seems vaguely fit for purpose I'd be happy to set some people up as project administrators so they can fiddle with the options. I don't really pay any attention to AGS dev though, so who do people think should be in charge? There is the option to have multiple projects at once, so you could have one for each engine fork, each IDE fork and so on, with different admins (and access / visibility levels) for each.
monkey_05_06:
Based on the thread that I started some time ago, Dave Gilbert, m0ds, and myself stood out as candidates for overseers of AGS as a whole. Myself, Wyz, and JJS were all nominated for technical lead. Others who have check in rights like Calin Leafshade and ProgZMax would also probably be good to have added there. Interesting that this is built into the forums. That actually improves things a lot I think. We should work on copying over the old bug/feature tracker and maintaining it. ;)
Navigation
[0] Message Index
[#] Next page
Go to full version