Messages

I'm pretty sure the engine is not currently capable of running under 64bit even if it compiles. There are too many int to pointer conversions and stuff.

Getting a 64bit compliant version of the source should be of high priority in my opinion. (mainly for linux)

I'm not talking about compiling AGS as 64 bit application. With -m32 it is compiled as 32 bit application and that works on 64 bit Linux if 32 bit copies of all required libraries are there.

I also had a brief look into making AGS 64 bit compatible, but gave up quickly. My interpretation is the following. There's some guessing involved, but that's how it makes sense to me. The AGS scripting language has something like pointers (or needs pointer features for addressing stuff or whatever). They are based on 32 bit numbers and implemented by casting the numbers to pointers, and doing pointer-like stuff in C. The numbers are no real pointers pointing to memory, but only make sense in the AGS context.

If you would want to cast the 32 bit numbers to 64 bit pointers and back, that means you have to know exactly which pointers are AGS pointers and which are real C pointers. That's where it got too hard for me, because I don't know the code well. However, I would highly recommend not to make this even uglier by continue using pointers, but to implement the AGS pointer features properly without abusing C pointers.

The -m32 flag in the makefile was at the wrong position. I moved it and now it builds on 64 bit for me, but of course it blows up when linking if you don't have the 32 bit versions of the required libraries available.

Hi,

I recommend to use the engine that is maintained by JJS. It plays AGS 2.50 - 3.21 games and there is already a Mac OS X makefile:

https://github.com/adventuregamestudio/ags

Just open a thread in this forum to discuss/ask how to compile it, should not be hard. Maybe ask JJS.

* I think the wiki should be the central information repository of the project to both developers and game makers. Offline documentation could be generated easily, permissions to make certain pages by a special group (like "documentation team") could be done and offline documentation can be generated in many ways.

How to handle the offline documentation is discussed here.

It doesn't even work on Ubuntu 12.10 yet. It will work on Ubuntu 12.10 when it ships, but never on Ubuntu 12.04. That error message means your dpkg version is too old for that.

I created a prototype to show that the Wiki can also be used to create something that can replace the chm. It's similar to output Monsieur OUXX created. These things are called "WebHelp".

I exported the articles from the Wiki as DocBook XML, which can be used to create WebHelp output. It's not polished, images are not included, etc but for that it would have to be polished in the Wiki. Since the content of the Wiki is outdated anyway, it may be best to reimport the whole documentation from scratch. As I already said, I don't think that the API reference should be generated from Wiki articles, but from source code comments.

Here is the download link to the prototype: http://netload.in/dateiQ3Q32BuD7k/wiki-webhelp.zip.htm

Why do you want to change away from .tex now? If you want the documentation source to be simple files (and not a Wiki or source code), TeX is a very good format for that. And it shouldn't be difficult to remove the tex2rtf specific stuff and use it as input for a different HAT.

I bet that line was written by should-have-gone-to-bed-a-long-time-ago Steve. Should better have left a Post-it for regular Steve.

Of course to manage everything there would have to be categories of help, both standard and user created. 

Why do you want to split between standard and user created? That means the standard one gets less updated and users will start something new instead. And there will be overlaps. Why not one good documentation where everyone can contribute?

EDIT: Ok, for modules, but that is another problem than making contributing to the main documentation easier.

Do you mean you can open projects using Mono on Mac OS X?

Every Wiki can export to offline formats.

But for the API reference a Wiki is no good choice. The reference has to be edited at the same time as the code, otherwise the developer forgets it. On the other hand the reference must be available for multiple AGS versions at once, including the development version.

Is it easy to programmatically open a help page (using a simple URL) on a given keyword? as you know, that's how the Editor's code does it at the moment, using Windows' built-in functions for .chm files. Old but efficient: You highlight a word, then you press F1, and then boom, the help opens directly on the right page.

There's already a search function included in the Natural Docs pages. It should be easy to hook into that with a link including a keyword.

But I'd like it even more if there was a way to add useful articles (I learned all about the way you write functions as part of a struct by looking how SSH's modules did just that, for example) quickly to the helpfile. Can that be done, and would it make sense?

That is called a Wiki. Transfering the documentation to a Wiki and maintaining and using it from there is also an option.

It is advisable to generate the documentation of the scripting language from proper source code comments with a documentation generator like Doxygen or Natural Docs.

The thing with AGS is that the manual is not a "source code documentation" per se.
There are also plenty of hand-written articles (let's call them "white pages") about many topics. Is Doxygen designed for that?

I know. It is possible, but it seems to me that separating the API reference and using something more suitable for the white pages is the common approach.

And even when it comes to the classes documentation, I'm not sure the help is generated from the source code. It might be just typed in the .tex file. And in this case it might not be such a bad practice, as otherwise it would mean that the documentation should be typed deep into the C++ compiler...just for a few AGS sript functions... not very handy to edit.

It is in the .tex file now, but it should be moved to and then generated from the source code. It's the easiest way to keep the docs up to date and it encourages proper comments, because the developer knows that his comments end up in the documentation. Typed deep into the compiler? The compiler is completely unimpressed by comments. There are more than 100 script functions and right now the reference looks like this. For comparison, something using Doxygen and Natural Docs.

EDIT: The Doxygen example looks like overkill, but OGRE has a massive API. I could image something like the Natural Docs example would work nicely for AGS. I don't know if Doxygen can be configured to produce something similar.

Please use something open source and cross-platform. It is advisable to generate the documentation of the scripting language from proper source code comments with a documentation generator like Doxygen or Natural Docs. Right now the documentation is generated from a TeX dialect that is only understood by the tool tex2rtf. tex2rtf was (as far as I know) only used by wxWidgets until recently. They migrated to Doxygen by adding the capability to output Doxygen syntax to tex2rtf. [1] I haven't found this code yet, but it was done by Hajo Kirchhoff [2], who could be asked for it if Doxygen would be considered.

[1] http://www.litwindow.com/Knowhow/wxDoxygen/wxdoxygen.html
[2] http://www.litwindow.com

It can be built on any 32 bit Linux by just installing the dependencies and running make. See the same instructions that describe the Debian package building.

It should also be possible to install 32 bit libraries and the program on a 64 bit Fedora, but googling for Fedora multilib I don't find much. If you figure it out, let us know!

It would be good if on Linux also only a file in ~/.config/ags would be evaluated. And maybe allow overwriting of some of the options by the config files that come with the games at some point? Alternativly introduce a new config file for game directories with a different name to allow for game specific settings.

EDIT: Or even better, first evaluate a file in /etc and then the one in ~/.config/ags

That crashes here too, but the Linux version works. (With the installed engine of course.)

Let's not get distracted by details yet. First we need at least to know what sonneveld and JJS think about having a main repository.

I don't think it's really feasible -- unless you're a 55-years-old Russian programer who also produces code for a nuclear power plant and/or a rockets factory and/or Jurassic Park.

That's racist. I think a 55-years-old Spanish programmer who also produces code for a nuclear power plant and/or a rockets factory and/or Jurassic Park could also do it.

It should work, JJS provides daily builds for Windows. Maybe it's time for a thread "AGS engine Windows port"?