Messages

Time for a little random guessing:

It sounds like tooltips cannot go left of the primary monitor. I don't know what coordinate system Windows uses for multiple monitors, but if the left edge of the primary monitor is 0, maybe the tips cannot go into negative X ?
If so, it's not an unsigned versus problem, or the tooltips would be invisble (they'd go the zollion-th monitor at the right). Maybe they are clamped to 0? (or to the left edge of the application?)

[all]

Does it matter if it's uncommon for users?

All users care about is if the numbers go upwards. We don't make formal releases for dev releases anyway so most users will just use the stable version.

Do you honestly believe that given a choice between 3.5.5 and 3.4.2, all users will pick 3.4.2?

Even if you have a few users making the wrong choice, you will end up with mess explaining to them they picked the wrong one, with a difficult explanation about odd and even numbers, etc.

Projects like a kernel are different; they have looooong development times, and many distributions (red-hat enterprise, centos, etc) stick to the last stable for 7+ years.
Also, unlike a user application like AGS, people don't generally install kernels themselves, they pick whatever their distribution provides. That means the public for a kernel is much more professional than Joe average Window user.

After reading your older post about branches http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0, I think 'develop' itself should not have a version number at all, you could use 0.0.0.<git-hash> if you need to build it.

This is the question of public version, not naming the branch. The branch can be named in any way which is convinient for developers; and if developers make some build for themselves, they can again call it as they please. However here we discuss the version as seen by users; and release version should have clear meaning for them. End-users don't know what "git-hash" is, how will they know this version is the next beta or whatnot?

I am aware of that.
I see a build of 'develop' as something for developers. It's generally useful to be able to build such a thing 'out of the box', that's why I attached a weird but unique number to it.

For public versions, I proposed to name it "next-version"-betaN, where "next-version" is the 2-number prefix of the last release, with the second number incremented by 1 (3.4 -> 3.5, 4.9 -> 4.10), and "N" incremented by one with each release.
Number would be assigned in a release branch.

Sort of this:

Code: text

       2.6.5     3.0.1                 3.7.1
        *---------*---------------------*--------
       /         /                     /          
------*---------*---------------------*------------* -> go on with development
     2.6.4      3.0                   3.7

This is possible, although AFAIK was never used in AGS before, usually all bugs are fixed in the next version (if they still apply).
Since this is now open source project things may change.

Ah yes, you'd forward-port the fix to the newest releases too. That would make sense.

I wonder what 3.5.2 is, a stable WIP version???

I know projects do even/odd numbering, but I have never seen it applied at sub-number level yet. I believe most users will not understand that 3.4.3 is a WIP, and they should instead download 3.4.2. The usual idea is "higher number  == better".


Why not make unstable versions explicit?  3.4.2-beta1 (or -wip or -rc or -dev), 3.4.2-beta2 ... to release 3.4.2, with updates or fixes 3.4.2.1 , 3.4.2.2 etc.
After 3.4.2, develop 3.4.3-beta1.  You could use different suffixes for different goals, 'beta' or 'wip' for just an intermediate version, 'rc' for a test build of the next stable (ie no big new things will be added before the release). Don't know if you need that, it may add very little, yet adds to the complexity of releases.

After reading your older post about branches http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0, I think 'develop' itself should not have a version number at all, you could use 0.0.0.<git-hash> if you need to build it.
A version number (like 3.4.2 or 3.4.3-beta1) should be decided in the release branch, where you (in my opinion) can pick any number bigger than what you have already released. For example, if a huge new feature is added after 3.4.3-beta1, you could jump to 3.5-beta1 or even 4.0-beta1 (assuming you always have 2 numbers at least). Another option is to make such number decisions just before the next release, and not before (ie keep 3.4.3-betaX no matter what is added). That may be easier for the release process and less confusing for people to follow.

I am still puzzled by the 'master' branch. Suppose 2.6.4 has been released. It's on the master branch. Next I bring out 3.7, and then find a bug in 2.6.4. Where would 2.6.5 go? It seems to me the 'master' branch is making things complicated if you have several release branches in parallel. Is there anything wrong with just making a branch off develop for every major new version (say 3.4), and update that branch to 3.4.1 etc ?
(Just puzzling why the 'master' exists, from a release theoretic point of view, if you don't need the extra complexity, by all means keep what works for you.)

My Linux has other ideas about 'ln':

Code: bash

$ which ln
/usr/bin/ln

Hardcoded paths to system binaries is usually a bad idea.

You probably should use the link system call (see link(2)) to link a file, but if you really want to start a process for it, just let the standard search path find it for you, or setup a configuration utility like ./configure, to set the path to the program at configure time.

Edit: Oh, I just found out I do have /bin/ln as well, and it points to /usr/bin/ln. Your code would not fail thus at my system.

Another reason for having Allegro is the age of the software. It was written before 3D video cards with hardware acceleration were commonly used.

 

Oops, sorry

linsetup obviously.

Mostly known as

Code: bash

$ ./configure
$ make
$ make install

 
At Linux, you rarely find real setup programs like you do at Windows. One simply uses the standard development tools for building and installing the program.
Note that "installing" is mostly just copying files, there is no registry thingie that needs to be dealt with. Uninstall is just remove all copied files. You can install at a central place like /usr or /usr/local (by the superuser, to make it available for all users of the system), or inside a user home directory (for a personal installed copy).

The above command sequence configure/make/make install is quite normal for an install from source. Most Linux users however don't do that. Instead, Linux distributions normally build binary versions of all programs from the source code. They package the result in a .rpm or .deb file, which are distributed to all users with auto-magic updates etc. Users have package manager tools like "yum" (Red hat/Fedora) or "apt-get" (Debian/Ubuntu). There are also GUI versions of those programs. One can just select the package to install, and it will download the .rpm (or .deb), with all its dependencies, and install it.

The manual doesn't say anything about limits of the x/y position, it seems. Wouldn't this count as a bug (either in the Crop routine, or in the manual)?

But the "do" is a prefix for the statements ("do x = 1;" rather than "x = 1; do"), just like "while" a prefix is for the condition. (Technically the "while" is thus not at the end of the "do while" since the condition follows).

The only somewhat feasible alternative is probably "while ... do { ... }", like Pascal had. The parentheses around the condition after the "while" make the "do" unneeded in this case.

In all cases, the syntax would be different from what the zillion C/C++/Java programmers are used to, which seems to be a major source of inspiration for the AGS language. That makes it highly unlikely to happen.

The Sphinx quickstart program generates a Makefile or make.bat, which is why I added those to the PR. It's overkill in production, in the end it just runs a single sphinx command, which you can of course also directly execute.
Sphinx itself is written in Python afaik, so it should run at a system where Python is installed (no doubt Sphinx comes with install instructions, I didn't check, as my package manager provided it.

The other steps sounds doable too, although I wouldn't know how to pull a file from GH directly (I'd clone the git repository to the local machine instead). Uploading the result I would do with ssh.
A simple shell script may be enough. On the other hand, since you have Python installed anyway, a Python solution would also be feasible I guess.

A group of people could watch an ant going around in circles and each person will have their own views and opinions about it etc.

It's even worse than that, it even happens within single persons
I was stuck on ideas to improve performance of a program for 1/2 year or so. Yesterday just before going to bed, I realized that just changing my idea of what the program was doing, would give me sufficient leverage to make a nice improvement.

all the time people fit into different groups which have their own cultural/ beliefs etc you will never find utopia only a fair medium

Isn't this set of different groups utopia already? 

but why is there such a large space between these rooms???
Maybe I should explore a little bit more there :p

What do you mean? Are there too many corridors? In most cases there's one corridor between rooms of interest. Or do you mean something else?

Suppose the program normally draws new rooms with a little space between the rooms (say 1 cm or 1/2 inch or so). So as you explore, the program nicely draws an area filled with rectangular-ish rooms connected with each other, and a little space around every room.

Now you go 'south' from one room, and the program draws the new room 10 cm (or 5 inch or so) below the room you left instead of the usual 1 cm (1/2 inch). From the new room, if you go 'east' or 'west', it's again the normal small amount of space. In other words, there is a lot of empty space between two rows of rooms. What does this tell you?

1. Between rooms with only a little space, there is nothing in between any more (likely).
2. Between rooms with large amount of space.... well who knows, there might be something there?

In other words, just the position where a program draws rooms (if you draw each room at a fixed location at the screen) already gives clues to the player. If you make a map by hand, this will not happen.

Thanks for reminding!

Time seems a bit weird as constant. There are so many different kinds of time, so which one is it?
It looks more like interaction perhaps?

Depends on how much information you want to give away. If you draw rooms at fixed places, the coding shouldn't be too hard, but why is there such a large space between these rooms???
Maybe I should explore a little bit more there :p

Indeed, they added move thingies in C++11. Do do similar tricks with construction, where you can construct a new object directly in the container, ie

Code: cpp

std::vector<MyClass> v; v.emplace_back(constructor-args);

. Shared pointers do something similar with

Code: cpp

auto s = std::make_shared<std::string>("hi");

With C++11, you would do

Code: ags

std::shared_ptr<std::string>

for such strings
Threads is a good point though, I don't know what STL says about threads.

I am aware of previous STL versions being bad, the first implementation I used in 1997 required inclusion of strings as first #include, or it wouldn't work :p
Also, linkers didn't understand they could throw away duplicate and unused functions. That somewhat holds today as well, it's very easy to get a 1MB executable if you compile with debugging information.

I just use the containers and strings though, I never saw much use in the algorithms.


A few months ago we have switched to C++11 in my own project based on a wish from my fellow project member. For me it's an experiment to see what C++11 has to offer. We mostly use the containers, strings, and unique and shared pointers, which I find very nice.
We aim at desktop system currently, where only linux is actually working, so hardware speed and memory use are not that relevant for us.


My first reactions on your quotes was "How old is that?", "What did they try?", and "How big were the differences?". STL offers more functionality than you generally need, look eg at the methods of any container template. Also, it's generic code rather than special purpose code (not optimized for a particular use case). Both make that STL templates are bigger, slower, or both. ScummVM doesn't mention a date, and the link seems to refer to something of 2007, which makes the C++ compilers they used at least 7 years old, which is very old (at least at Linux).

Some people are just so obsessed with performance, that they would write everything as custom solution rather than accept 0.1% performance loss. In my book that counts as premature optimization. You don't rewrite code that is not the bottleneck, except in extreme cases.


For AGS, I don't know the right answer, but I'll give it a shot. I only know about Linux and some of its considerations. Anything outside that area (such as Windows libraries, or PSP/iOS etc) is not taken into account.

Under the assumption it consists of an editor, a compiler, and a runtime system, I'd say there is no reason not to use STL for the editor and the compiler. You don't do development at a small slow system.
For the runtime, it may be different. However, depending on how smart the compiler is, it may also be less needed.

Given that the software is functioning, and already exists for many years, there is no immediate need to do any big rewrite or conversion, I think. There are replacements available, and they work. Rewriting implementations won't give any progress in features, and may introduce new bugs. If you want to make a step towards STL or C++11 (ie there are no blocking obstacles for all platforms), a more likely scenario would be that you only allow use of STL or C++11 (that is, remove the restriction of not using templates, for example), and let time decide.

I needed some utility classes to continue work on AGS features (like custom resolutions and limits), - primarily hashmap, - so I wrote ones. But now, when I was about to push them, I started to wonder if I am doing a right thing rewriting what already exists. Does anyone remember why we decided not to use STL in AGS? Or did we? I think I've lost a track of reasoning there. When we started all this there was a talk about writing our own utility classes. Monkey wanted to do this, but after few months he told he can't. So I decided to do this instead, but wasn't that some kind of inertia, not rational thinking?

I wondered about that too, after finding two files implementing strings, but unilt until I actually understand the code, I assume it has a reason.

Indeed Hash Map is only included in C++11 library (as unordered_map), therefore we would need to move to C++11. This means we need to reorganize the way AGS is built. For instance, get rid of pre-built Allegro libraries for Windows and make everyone build them on their own from source code.
This will take some time... meaning other work will be delayed.

It seems to me that any switch is not going to happen at any short term, even if you can decide now you will make the switch. Given that you already have the classes, and the switch is thus not a pre-condition. I'd separate both issues, and implement what you want to make now without c++11, while discussing a switch like that. After the decision is "we will switch", I think you should start finding a path towards c++11. Your classes may get removed then again.

This all is extremely stupid, but I do not feel apt to decide such things. This all gets real results further and further, and I keep wondering if I'll ever finish what I started. I feel like I am rethinking same things over and over again, without being able to get to conclusion.

There are always bigger things in my experience. If you think far enough, you will get yourself in quick sand with every step that you try.
In my experience it helps if you focus on the most concrete next thing that needs to happen. Anything beyond that can wait until tomorrow.

Meanwhile there was talk about writing a "new AGS" by other people. I don't know, have they started? Maybe what I do will become irrelevant after a short while?

Rewrite from scratch is an often suggested idea, but the amount of work is staggering, and it remains to be seen whether it will give a better result. In addition, with a program being used by a community, you cannot just stop development and bugfixing the existing thing. If you do that for a few years, the community will die. People do not use a non-maintained program a few years with maintained free programs doing the same thing nearby (which I guess does exist in this case).

It bugs me that I could do alot more if I weren't so unsure of what is right way to do.

In my experience, nobody knows what the right way is. You can discuss it, and make nice plans, but only one minor change is needed to make all plans obsolete. In my projects I stopped planning ahead too far. I make changes only as much as needed to make the new thingie work for the one step I want to make 'today'. Tomorrow is a new day for deciding what to do next.
It never hurts to have a bit of a global high-level plan of course, but it should be high-level enough not to make abrupt changes.

[Edi]

By all means try it. That's why I did a quick and dirty partial conversion.

Restructured text is the basis. It is an ASCII text format, where you can express markup, links etc, a bit like todays Wiki languages, but it's way older. Restructured text is aimed at single file short documents, like enhancement proposals (eg Python PEPs). There is tooling to convert to various output formats.
Sphinx is an extension on top of restructured text. It is aimed at making larger documentation sites. For example, docs.python.org is built with it entirely. Html is of course an important output format, but it has other formats too. It provides a search box for the site as well. You can further customize the generated output with themes and CSS stuff (which I have no clue about, but I know it's possible).

I only have a Linux system, so my options for experimenting with documentation are limited, beyond "it works in my browser".
However, if I can be of further assistance, please let me know.

Edit: Created a proper conversion and a PR: https://github.com/adventuregamestudio/ags/pull/173