Messages

When do you think is a good time to recommend people to use refactory? If there are no known bugs, why not now?

That was a bug in the saving code that I fixed now in the main branch (commit 205c56d693d903516b7b21beb454251e9489aabf). I don't know why it never caused problems on 32 bit.

One more reason to consider porting the engine to Allegro 5, which is inherently sub-pixel accurate.

Will you do the auto-formatting also for the Editor? In this case, tzachs changes should be merged in first.

Yes.

Also I am strongly considering switching development to the refactoring branch. The original code is a mess and it gets worse every time I hack something in. An additional benefit would be that the refactored code is actually used and therefore checked for errors.

Yay! Smells like progress.

Please use CC0 instead: http://creativecommons.org/publicdomain/zero/1.0/

Just saying that something is public domain is ambiguous and it's not clear if such a statement is valid always and everywhere. CC0 has the necessary legalese.

Nice, thanks!

You should probably mention the old and new versions of what was updated.

It's just lagging behind, but no changes that are important for Linux were added to main since the last merge.

What do SSH and you think about putting a short description about submitting on the blog? A mail address or form and maybe some words about what kinds of articles you would like to receive?

Ok, nice, then all that is needed is to tell people how to submit news. If that is welcomed.

Hi,

it's a great idea to integrate the AGS blog into the AGS homepage like it is already the case. But I have some ideas how this can possibly improved even further.

First of all, SSH and Dualnames (I think you're the ones running the blog), do you feel up to managing the AGS news, i.e. accepting and reviewing suggestions for articles for publication in the AGS blog? Example: a developer added new features or a new port to AGS and searches for testers. How can he make an announcement?

If you are, I propose a few step to encourage getting more news from the community into the blog and onto the AGS homepage.

First, it seems like AGS blog posts are selected by hand for inclusion on the homepage. Why not include every blog post automatically by software?
Second, there should be a link or form for submitting articles both on the AGS homepage and the blog.

What do you think?

I'd think a better strategy would be to make the Editor cross-platform first. Then making sure the GUI is sufficiently separated from the rest shouldn't be difficult. If sonneveld is right, making the Editor cross-platform is mostly a matter of splitting up ags.native into its C# and C++ parts (see http://www.adventuregamestudio.co.uk/yabb/index.php?topic=45990.0). He says he made some progress with that, but he didn't make that code public yet.

EDIT: After looking at your text some more it seems like what you want is to change the AGS project format rather than having a compiler. I agree that this is desirable.

Would it be possible to base this Editor branch on Alan Drake's one (the one that has programming facilitators, such as code collapsing, etc.).
That would be pretty much the ultimate edition.

I definitely hope we'll get there. Call me naive (and CW will probably yell at me for saying this  ), but I'm still waiting for CJ giving permissions to people and Alan among them...

Why don't you join the other developers on github? Alan is already there. As long as you agree that you both did good changes there really shouldn't be a problem.

I'd vote for suspending the file. It looks like the CD stuff is for Windows and Linux and should therefore go to platform and the rest is for everything and should go somewhere else, don't know where. If there is a need to separate 32bit and 64bit implementations one day, one can do it then with less retarded names than ags32bitosdriver.

Ok, good that bigend is now really just for bigendian systems. It will be included on all Unix systems nevertheless, because one does not have distinct makefiles for different endianness.

And the others are handled right that right?

all folders except ((platform and subfolders) except platform/base) -> for all platforms
(platform and subfolders) except platform/base -> depending on platform

EDIT: Since you just moved ifdefed stuff, the question comes to mind if the entire code should be eventually made ifdef-free and everything moved to the platform folders. Probably not before the branch builds on all platforms though.

EDIT2: And ags32bitosdriver has nothing to do with 32 bit. That's 32 bit as opposed to DOS. I mean, since there is no DOS support anymore, the contents should go into other files outside of 'platform'.

@BigMC, I've put all platform-dependent files into platform/<platform-name> folders. I believe the rest could be used for any platform. Except the code in obsolete folders- they should not be used at all.

Great! I commited changes that make it build on Linux again. There were some more Windows and DOS only files and I moved them. It should now be much easier to make it work on the other platforms. Is it something for the coding conventions that all files that are not intended for all platforms should go into "platform"? Also, aren't some of the files currently in the platform folders intended for all platforms and should therefore go somewhere else?

The alternative would be to switch to a cross-platform build system like CMake. This will certainly become the best option at some point, but folder based building may also do for now.

EDIT: BTW, http://gitorious.org/ags uses CMake, so their CMakeLists.txt's could be used as a starting point.

I just tried to build the refactory branch on Linux and the Makefile is quite outdated again. I saw that you tried to keep it up to date, but that's of course difficult without testing it. Is it possible to arrange the files into folders in such a way that most folders contain only files that are built on all platforms (say all but Common/platform and Engine/platform)? Then all the makefiles would just need a list of folders and a list of files from the platform folder.