Messages

Defaulting to case-sensitive file system might probably be a right thing to do, although I wonder if it's possible to force AGS to treat filenames as case sensitive on case-insensitive system. Probably I am speaking about virtual filesystem here...

The other direction is feasible too (being case-insensitive on a case-sensitive file system). Either move implies you need to read the actual file and directory names from the disk, and check them against what the user supplied. Forcing case-sensitive means the user must type it exactly right; allowing case-insensitive means accepting other names that differ in case only. The latter (being case-insensitive) may be more user-friendly from the perspective of a windows user I think.
It does have the problem that a case-sensitive file system could have more than one file that matches, eg "ABC" and "AbC"; I think it would be fair to warn about it in that case, as these never come from a case-insensitive file system.

The generic approach is quite involved, if you only fix or check paths just before opening files, you probably get a long way already.

Other problems could be the "\" vs "/", and the "X:" drive things, but that may have been covered already. More subtle, unix and windows have a different set of allowed characters in a filename, unix allows anything but / afaik, windows tends to get very upset  with characters like ":", there may be more such characters.
Note that I assume not passing paths through shell or any environment variable or so, as in that case you get quoting and escape mess.

Yes, this is also a problem. I think for game data files there again must be a fixed line ending (unix style?). For temp files like logs AGS could use system default linebreak maybe?

Another solution is to accept any combination or \r and \n as a line-ending; if you get the same character a second time, it's a second line-ending ie \n\n or \r\n\r\n. I don't know what Mac does nowadays, but if it dropped using purely \r (ie it uses \n or \r\n or \n\r), you could consider \n to be "the" newline, and \r as discardable whitespace.

I would suggest to first define what you want from documentation, then consider the format and place of the source, then consider how to get there from what you have now.

"what you want" would include
- online/offline (both I think)
- purpose of the documentation (what does it contain, what can you learn from it)
- up-to-date-ness of the documentation (how bad is it if it runs behind a year or more)
- users of the documentation
- editors of the documentation (who for what parts mostly)
- try to come up with more properties that you desire from the documentation

best pilot: Twesty (number 1)
best flying device: Hobo (number 2)

The first question is imho what do you gain? What new things can you do by switching?
The immediate second question, what about the entire installed base? You can ditch the old format, but euhm, I think some people have a few files here and there

Oh, sorry, I am clearly not up-to-date with AGS release numbers.

I understand all trouble comes from keeping branches alive for a long time

Could you explain one bit though please? If you update 3.3, the users would have to install a new version too, right?
Why is upgrade 3.3.x.y -> 3.3.x.(y+n) feasible, and upgrade to 'latest stable' not feasible?

Currently I am looking for any opinion on possible flaws in this method, because it happened few times in the past when I screwed up and had to fix core features.

The danger of the strings, especially if you take the 'used features' route that I seem to have proposed, is that the same string should always have the same meaning.

The questions that thus arise, what if you have to modify a old feature when it touches a new feature? Does the old feature get a new string? If so, can you still load the 'old string' feature? What if the game file doesn't use the new feature?
Tbh, I don't see an easy answer here, it may give rise to very subtle bugs.

As for your versioning number system, the 3.3.XXX number system basically makes versions for each major release independent (such as major release 3.3). You will need a XXX number for each previous major release that you support. While it is some work to do for a release, tables are not likely to become very big.
It all becomes a bit magic though, a user has no simple way to query the set of supported version (or you have to add that), so loading a data file into a newer version becomes a bit of a Russian roulette, although with a much less deadly end if it fails.

Using the complete version number as format eliminates the magic additional XXX, which is probably a Good Thing(tm), less numbers to get confused with, but the Russian roulette is not really solved, I think. You still need to know what versions of previous branches are understood by each version.

In all, I think it's quite complicated.


Did you consider dropping the change of data file version numbers within a released branch? For example, if 3.3.1 (First public release of the 3.3 branch, as I am not sure my number is actually correct.) has data file version 43, all 3.3.x versions (x >= 1) will have 43 as data file version.
Obviously, that will block certain changes, in particular, adding new features becomes impossible. It will lead to shorter life times for the various branches I think (At least, it will not make them longer.)

On the other hand, it greatly simplifies your data file version management problem, and reduces the porting effort. (New features are not portable to an existing version. If you want them, please upgrade.)

Development time is a scarce resource, reducing complexity of the builds and releases may help.

With your strings listing features, do you list features used in the data file, or features supported by the AGS version used to create the data file?

[ChamberOfFear]

Alberth:

Afaik my problem is that you'd like to use a proprietary piece of software as foundation of an editor, software that runs only at a proprietary Operating System for development.

Its most likely not your fault that I am not getting the message. I think we must just not be on the same page really or maybe I am not explaining myself too clearly or my intentions for that matter. For years we used Visual C# to create the editor. Until last year, this was closed source. With the exception of this being open sourced at the moment, perhaps I might understand what you are trying to say if you explain this: "Prior to 2014, how is using B4J to create the AGS Editor any different than using Visual C#?" Wasn't/Isn't Visual C# a proprietary piece of software that runs only at a proprietary Operating system?

First the confusion of Visual C#. ChamberOfFear pretty much explained it all. You have to distinguish between programming language C# and Java, and tool implementations Visual C#, and B4J.

You should see the Java language and the C# language as equivalent, and the B4J software tool and Visual C# software tool as equivalent.

B4J can be used for development at Windows only, and deployed to several targets.
Visual C# can be used for development at Windows only, and deployed to Windows only, unless you take the C# source files, and use the Mono program instead, which allows development at several platforms, and deploys to several platforms.

Now in my view, the latter part is the crux. I have a free and open alternative to the Visual C# program, which makes that C# source code will survive if Microsoft for whatever reason decides to drop Visual C#.


Next, your question.

You are fully correct that C# was a very closed language. Mono existed long before 2014 though, but never mind.

If I would have been here when people decided to use C# for the AGS software, I would have written the same kind of posts that I am writing today. In my view, it's just plain stupid to tie yourself down to a commercial platform that you don't control. Both B4J and Microsoft will drop their product at the moment it doesn't give enough revenue. They will alter their course when it gives them more money. If a bunch of AGS software developers gets into trouble, well, you can buy our next-generation solution for $$$. You don't have money? Oh well, bad luck for you. Good bye.

However, I arrived here somewhere last year or so, and there was already a huge pile of C# code. It's pointless to try talking people away from C# at that point. The project will have to live with the decision to go C#.

@RickJ: I pondered about your remark, and I still think you are correct. However, if you want to make a nice cross-platform Gui application, there are not that many options available to you.
There is

• Java Very cross-platform, I think it should work, except the language is a bit meh. At least I constantly run into silly unsupported edge cases in the language that limit me in writing really nice solutions.
• C# Mono seems to get some traction now, but I think it's still almost unused language outside the Windows domain. No idea how good it is for Guis, but given its origin, there probably is stuff for Guis.
• C++ Good cross-platform support, language is complicated, and the big question is the Gui library. I think only the GTK and Qt libraries are useful to consider, personally, I'd go for Qt every day of the week.

None of the options is a clear winner imho.

Afaik my problem is that you'd like to use a proprietary piece of software as foundation of an editor, software that runs only at a proprietary Operating System for development.

I am baffled how you believe that to be of any use in an open source project, but I have said enough on that already.
I clearly fail to get that message across


How did you reach the conclusion that AGS has propietary file formats? Afaik they are just AGS-specific, and AGS is open source, hence the file formats would be open too.
Sure they are probably different from a general purpose format, but they're dedicated to AGS, so that's to be expected.

The only requirement is that one needs a format description, so you can write a loader and saver function for those files. Maybe eventually a different format is required, but that's a different matter.

Obviously, you cannot import a n AGS file loader from the Java library, it needs a piece of custom code, but that's not hard to write. You just read bytes from the file, and store them in some data structure, mostly.

<rant>
As for XML, euhm yeah. I am quite not a fan of XML to say the least, it's a big, overly-generic format, ASCII based (which sucks for inherently binary data such as images), and not at all readable. Loads of people believe it's the ultimate data storage format for anything, including writing programs in it. OMG, "<expr><add><literal>1</literal><literal>2</literal></add></expr>" versus "1 + 2".

The only thing going for it is that there are standard libraries for it, and loads of generic tools to rewrite, check, store, and what not. Most of that flexibility is however not needed at all.
</rant>

I can write a scanner and parser for a text file with LALR(1) grammar (which can handle most general programming languages, so quite robust) in about a day with standard scanner and parser generator tools, and then you have sane syntax tailored for the data that you want to store.
However, perhaps a binary format is much better here. All you need is a file format description, and the ability to read raw bytes from the file (and write them again, when you save a new file).

As for the other problems with respect to compiler splitting and porting, yeah, that sounds fine.

Ha

I always found it a great move by MS, develop your own language, so not only do you have users locked-in, you also get developers locked-in
How's that for ensuring your platform will never die?

But yeah, C# has the big disadvantage that a commercial company decides the direction, and has the lead in deciding what goes in, and how things interact with the system. It also means that non-windowsy systems will always be at a disadvantage.
On the other hand, there is Mono, and it seems to be working to some extent (never looked inot it). Mono will always be open I think. Thus if you use Mono as base implementation, you are probably fine? (No idea tbh, I haven't done C# yet, although I should try it one day.)

[Edit]

In my view, open source software should be open completely from day one, for any purpose that people may think to be useful, for any platform, by anybody, without needing to buy stuff from companies. Also, open source software should be rebuildable from the source by anyone, and anyone should be able to develop things further, again, without needing to buy anything.

An editor for AGS is a key piece of software for the AGS community. I don't know how much effort it contains, but it's man years to decades very soon. I don't want to risk having to throw that away just because of a license problem, or a problem on keeping it working as some key part gets lost, in say, 20 years. I have seen projects where many people invested a lot of time, but they forgot to allow free access (including further development!) to everybody else. As soon as they left (and everybody leaves at some point!) people remaining are stuck with a nice piece of work, but there is absolutely nothing you can do with it legally until a 100 years or so later, when its copyright expires.
(ie not unlike the current situation with the AGS system.)

To me, it seems better that you spend a year learning C#, or do things in plain java from scratch (ie anything that makes it truely open from the ground up at day 1), than to risk a decade of editor development by basing everything on an unknown commercial product that runs only at one operating system (for development).

But like Crimson Wizard, I cannot decide for you what to do. If you don't want to consider what happens after you leave (ie the only person that ever heard of B4J, and the only person that knows how to program in it), go ahead, have fun.


Edit: To clarify further, a thing like the AGS editor is not something you write and then you're done. People will continue to develop it continuously, until nobody uses the AGS software any more.
In other words, once you start with it, you're developing it further forever. Adventures have been around a few decades already, I don't see it end anytime soon, so a few decades easily to come. Therefore I believe it's crucial for the editor that it can be developed further without having any strings attached that you don't have in control, and may fail in 10 years from now.

3. - Is B4J free?

-Yes, completely. Nothing to pay. Can that change? Of course. But then again, Visual C# is not really free either. But according to the author of B4J, he does not intend to sell the product.

Please make a distinction between programming language and software tool implementation.

* C# is a programming language, originally designed by Microsoft, but its specification is open. It can be used anywhere. I can use a text editor like notepad or an open source text editor to write it. Theoretically, I can take its specification, and build myself a new compiler.

* Visual C# is an editor and compiler software tool implementation by Microsoft.

Programming languages are not always tied to a software implementation. I can develop and execute C# programs using an editor and Mono. I don't need Visual C# for it.
The programming language is the same everywhere, software tools differ in price and usage conditions.

4. - What platforms will it run on?

-B4J is intended to run on Windows, Linux, MacOS, Raspberry Pi and web browsers. However, the final compilation is made into a Java runtime. So really, any system that supports the latest Java Runtime can run apps made in B4J.

More importantly, what are the development platforms?

11. - Is B4A and B4i freeware?

I'll take "freeware" as "software you can obtain without paying money" here.

In general, the term "freeware" refers to its license conditions "you can do anything that you want with it". While this is obviously a proper open source license (it's known as WTPL), many open source licenses are more restrictive.

How much you pay for software, and what its usage conditions are, are two different things. You can pay for open source software, and you can get commericlal software without paying for it (eg trial versions, etc).

(answer to 11):
-No, those two are not. But once you purchase one license, you can make apps with that version of the software for as long as you would like and sell it. If you wish to update to a new version after your license expires, then you need to purchase a new license. Lets not forget.. To compile Native.dll, maybe I am wrong, you need to have a commercial version of Visual Studio to do.

12. - Is B4X open source?

-No, but neither is Visual Studio.

And here you go wrong. I don't have to use Visual Studio if I don't like Windows, or don't have money, or refuse to pay for software out of principle, or just hate the Visual Studio interface, or whatever reason I may have.

Visual studio is just one of the available options, but there are a zillion other options too. Maybe not as fancy, but they exist, and they are available for everybody without charge and they do the job.

I can decide that I like Visual Studio so much that I want to buy a copy of it. I am allowed to do that. However, it is not required. If I have no money, I can still write a C++ or C# program by using a different option. Instead of Visual Studio, I use a text editor and the g++ compiler, or the clang compiler, or the Intel compiler. If I like an IDE, I can use Eclipse. For the C# language I can use Mono. For plain Java, I can use the commercial Oracle version, or the free openjdk version.

Having free options available means I will always be able to run and modify the software, even when I am totally broke. This means a poor but genius child somewhere in Africa can use and modify the software, learn from it, and make himself a better future. This means my software lives even if Microsoft dies.


Now with B4J, it is different. I cannot do anything without a license. If I stop buying a license, or B4J dies, or decides to end this product, or raises its license prices by a factor 1,000,000, I am doomed. All my work down the drain, I can delete everything and start from scratch.

Hmm, let me try to explain it better then. Second attempt

An AGS adventure author takes his own sprites and makes rooms, and writes them to file. Then the AGS compiler converts that to runnable form.
There is no decompiler in this process, the author has his source sprites, and ideas of rooms, and enters/converts that to AGS format, and eventually to runnable format.

You say you want to also make an AGS editor. I would expect you support the same process as above, authors take their own sprites, and make rooms with your editor from ideas in their head. You store that information in a file and the AGS compiler will further process it.

The only point where you need a decoder is when you load a file that you wrote earlier (for the user to continue editing). However, as you wrote the code that makes the file, you know the format, and thus it should be easy to write a reader that loads the data back into the editor.
As for the format of those files, there should be writers and readers available in the source code, which you can study and replicate.

I don't see how you need a decompiler anywhere in the above process.

For me, a decompiler is a tool to rip a runnable adventure, without co-operation of the original author (since he will still have the generated files from the editor, which are a far better source then dcompiled data). I don't see why you need such a tool to make an editor.

--------------
As for B4J, does it run at all useful platforms?  Is it allowed to make software with it for commercial purposes (ie some AGS users write these games for a living). Does B4J come with a open source license? Major Linux distributions are into free software (free as in speech), and will want their own copies of the B4J software and everything needed to build it from scratch. They will want to give copies of it to all that want it, people should be able to extend your editor without needing to buy anything.
What happens to the B4J software when the company dies (open source software lives forever basically, eg the gcc compiler is 20+ years old, and still available, as it is all open source software. Very few companies survive that long, and you'll want to keep your editor alive even if the B4J company dies.

Notice that Visual Studio is just a plain compiler platform (I know it can do more, but that is the most important part of it). There exist other freely available compiler implementations in case Microsoft does weird things with its Studio, or in the (currently unlikely) case that Microsoft dies. In other words, no open source software dies if Visual Studio drops off the Internet, you can switch to another compiler, and live on.
How does this compare for B4J?

I don't have the needs that you have, but I would make a directory tree with 'topics', like contact names, site names, etc etc.

Inside each directory I'd make files of what I sent, of the form <date>_<description>.<extension> like in directory "forums/ags", make a file "20150808_ags_dont_forget_stuff.msg" with the text before I paste it. Rather than use the forum or whatever you're supposed to enter text in, write the text/stuff in your own file editor, and simply copy/paste from your editor to the site. That way you always have an exact copy of what you wrote. You could start off with some lines of context, eg what url precisely, who you wrote to, topic text, etc.

Date of the form yyyymmdd, as that sorts nicely (just look at the directory contents to get an overview of what happened when), and adding the date to the filename means I can move the file later without worrying about creation or update dates of the file itself.

Maybe you want to add the answers too.

For things I can/should do, I have a task manager. Some sort of "issue" tracker would work too.

Sounds good to me.

Sorry, but to make an editor, you need to decompile existing AGS data, and want to use a proprietary programming system?

Any person that needs an editor has sources available, why would you need a decompiler?

I am sure B4 stuff is the best stuff ever, but how is an editor written in a proprietary system going to help? Isn't lack of openness exactly why AGS in the current situation?

Running the engine to get information from it sounds good.
An alternative would be to supply a number of text files (or so) that have the information, but those can get lost, contain wrong information, etc.

As for cross-platform, plugin is also a good form of running the engine, I think. DLL won't fly cross-platform, Linux has .so files instead, no idea what android or mac uses. Depending on the meaning of "cross-platform" things may get a bit ugly.

Another form could be to add a few command-line flags to the engine, and have it spit out the relevant information. You see this a lot with *config programs for libraries.

Code: ags

$ sdl2-config -h
Usage: /usr/bin/sdl2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]

$ sdl2-config --libs
-lSDL2 -lpthread

$ sdl2-config --cflags
-I/usr/include/SDL2 -D_REENTRANT

In this case 'sdl2-config' is a script generated while building the sdl2 library. You can ask it for compiler and install settings, so a program needing libsdl2 can be configured with the correct parameters and paths for the system.
Obviously, you don't need to use a separate program, you can use the program itself too (libraries don't have an executable, so generating a script is a logicial next step). Also, since you get text in return, you can get any information you need, you just need to parse the returned text. As you control the text output as well, it's easy to pick a simple-to-parse format.

Even worse, the shared_ptr only works by creating one shared_ptr from the raw pointer and all other shared_ptrs are created as copies of a shared_ptr. ALX is generating new shared_ptrs directly from the raw pointers (as returned by the Allegro functions) - though these are generally the non-deleting crippled shared_ptrs.

C++11 does allow this by means of std::enable_shared_from_this, as explained in http://en.cppreference.com/w/cpp/memory/enable_shared_from_this .
It needs a special base class however.

Given the current problems of dropping Allegro 4, I'd think it would be useful to keep a clean separation between AGS and the graphics/input/... libraries, eg by having (probably) several interfaces, as already suggested.
In that situation, which library you actually use is not very relevant. One should be able to switch between Allegro, SDL, or any other library without much effort. (That is the entire point of having interfaces.)

So while picking a library must be done, that choice is imho almost irrelevant compared to making the interface(s) clean.
The question therefore is imho not what library to use, but how to make a clean interface design.

An important first step imho is to make it tangible. Flesh out the interface itself in terms of classes, methods, and functions. Document what the functions should do, and how they co-operate.
Try to refrain from writing implementation code (ie it's an abstract interface at this point, even if tomorrow it would be concrete). Code has a lot of details, and they get in the way of thinking at a higher, big-picture level.

An interface document is tangible, it can be read, commented on, and discussed. It's probably wrong at points (and will evolve), but it gives a concrete reference point to work towards. It also clarifies the scope and project boundaries for all involved.
Not sure about the form of the document. It can be a bunch of text files, a set of Doxygen html pages, a set UML diagrams, or an Office file.

Imho the primary goal of coding an implementation of the interface is checking whether the interface is correct. As a happy side-effect, you also get an implementation of the interface. If the interface is found to be wrong or lacking, step back to the high level picture, rethink the concepts without regard to the code you may have. Fix and document the interface as new reference point, then try again to code it.
Coding is cheap if you know what to code.

Picking a library can help you in checking the interface design, while coding.
If you use a library that you know, it reduces work but has the risk that you import library knowledge into the interface. Using a different library adds work in understanding the library, but it may make you think twice about the interface design, as it is relatively easy to check for yourself whether your known library would also fit in it. A third option would be to use 2 different libraries, and build an implementation against the interface for each library. Lot of work, but it pushes the interface to the limits, you cannot cheat without getting into trouble with the other library. Obviously, 3 or more libraries will push even harder at the cost of more work.