AGS 3.3.x/3.4.0.0 Developer Discussion

Started by Gurok, Sun 09/02/2014 08:45:13

Previous topic - Next topic

RetroJay

Hi Monkey_05_06

My chief gripes with AGS 3.4 are as follows.

1. I find the Win setup to be an odd beast. Games that run in 640x480 that used to run full screen on my monitor now do not, unless I stretch the screen which has strange effects on the graphics.
   Also trying other resolutions and settings cause my game to look fuzzy. (This was the main reason I reverted back to Draconian).
2. The white screen when scripting really draws on my eyes and I find properly indenting my script to be awkward as there is now no border, after the line number, as a guide.
   (The second reason I reverted back to Draconian). Also when trying to edit script I keep, for some reason, clicking those bloody minus signs, condensing my script.
3. As I mentioned to CrimsonWizard, a short time ago, there are still some sound issues. The sound panning and sound with scaling doesn't work.
4. Two separate windows to click between for properties and events. Is this really necessary or just a gimmick. (I found I kept wondering where things had gone until I remembered I had to click one pane
   or the other.)

Apart from these gripes I did not actually receive any error messages. ;-D
I know that you may find these things, I have mentioned, trivial but things that were working fine before are being overcomplicated now on 3.4. (Just my opinion though.) ;)

Yours.
Jay.



an_epileptic_monkey

Quote from: RetroJay on Wed 11/03/2015 19:49:55
...
4. Two separate windows to click between for properties and events. Is this really necessary or just a gimmick. (I found I kept wondering where things had gone until I remembered I had to click one pane
   or the other.)
Things like these seem 'trivial' but can have a huge effect on workflow. I often do not have a mouse, but have to use a trackpad or touch screen and so this is a pretty big deal for me, too!

My question is, how far off is 3.4 official? Is it far enough away to consider suggestions for layout modifications and more keybinds for keyboard-centric developers? Or is the plan to push 3.4 out as soon as current features are ironed out?

monkey0506

#222
I don't think layout modifications would be off-the-table yet, so long as there's no need to introduce whole new classes or libraries.

The issue of the Events pane being "hidden" inside the Properties pane is something that is (in my experience, anyway) extremely common. The only IDEs I've really used for any type of GUI development have been Visual Studio (C++ and C#) and Eclipse (Java) (Edit: That is, the official WindowBuilder plugin for Eclipse). Both of these IDEs have the same behavior, where there is a Properties pane with a button you click to access the Events for the selected item.

It may be possible to allow dragging that out to a separate window/tab. Probably the best person to ask about that would be tzachs. But in any case, I don't really find it "gimmicky" so much as I find it familiar...

Snarky

Also, contrary to what RetroJay's post implies, this is not a new part of the 3.4 UI. I'm almost positive it's been like this since the introduction of the C#-based editor, if not before.

nims

Hi,

I was pointed towards this thread by Crimson Wizard (thanks!) so I would like to add something to this discussion.

See: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51997.0 for the background.

I am playing with the alpha version now, in Full HD, and then I noticed scaling artefacts etc. My "simple" solution would be to set the game resulution to 1920 x 1020 instead of 1920 x 1080 to avoid scaling in windowed mode. The screens becomes scrollable because I am still working with 1920x1080 images, but that actually works quite nice!

So my suggestion would be that some kind of setting should be there, for which you can say if a room must be scaled, or scrollable in case it doesn't fit the actually game resolution.

Crimson Wizard

I have a 2 weeks vacations starting from the next week, during which I will be less on forums, but I hope to finally work on the mouse sensitivity issue again, and maybe some other things.

Crimson Wizard

#226
Regarding the further development; I must accept that as my own organizational failure again, that the 3.4.0 is taking a little long already (and getting little big), and there certainly were things that could be released earlier. Additional problem is that we have particular features introduced, but not complete (they either have annoying bugs, or simply not working as they should in all aspects yet).

Therefore, the decision I am proposing is this:

1. We slow down on adding features to 3.4.0 now; preliminary deciding which extra features it still might need. By features I mean completely new stuff, not fixes of something that does not work well (enough) - that's a separate question. We should not go too far with these. I will note the ones I believe should be added, or at least considered, below.

2. To improve the usability of 3.4.0, and therefore let people use new wanted features with less fear, we might focus on fixing the worst of the known problems first. I suggest developers should scan through the changes they were working on in the past time and see if anything requires fixing. I will make couple of notes regarding these below too.

3. When considering on adding a feature or a fix, we need to examine whether it could be added on top of 3.3 branch instead.
It is difficult to make a strict rule here, but I think that it may go to the next 3.3.* release if:
a) it does not depend on any of the changes made in 3.4.0;
b) it does not belong to same distinct group of features as introduced in 3.4.0 (like the lots of new script commands made by Gurok);
c) it does not require a big rewrite of the existing code, - this is something we do in 3.4.0.
d) critical fixes (program crashes etc).

4. This might happen that someone would like to start working on a new feature, and find him/her-self having progress, but the feature may be too large or taking too long to add into 3.4.0 (since the proposal is to start "freezing" it) - in such case we may create a next development branch for 3.5, and even make an alpha release, if some users will be wanting to have them.
But that is a possibility; I would prefer we finish what we started first.


The features I would like to still put into 3.4 branch are:
+ Mouse sensitivity (I really hope to finish this);
+ Draconian features;
+ Fully working User managed structs (they would put AGS script up on a completely new level).
+ Sprite cache limit (was bugging several users in the past already).

Most annoying problems to fix:
+ Well, first of all is a new game compilation system (multiplatform), which has number of seemingly non-critical, but pretty irritating glitches (dedicated thread here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51289.0);
+ Some bugs in display resolution init were reported, I'd need to look into them.


A special note regarding ports (especially mobile ones and OSX, because Linux is more or less stable now).
I was asked about them number of times, and I must say this.
Unfortunately, I have a little knowledge of them, and did not have a chance to study their work. This will be impossible for me to do anything without learning how they work, which requires time, which I do not have much at the moment. Realistically, I would not be able to do anything here, at least not before we make a first stable 3.4.0 version.
That would be very fortunate if someone could dedicate him/her-self as a port maintainer to solve many questions asked in related threads and provide new builds regularly. OSX port requires special treatment, which I would not discuss right here (there is a lot to say, and I would like to speak only to someone who is ready to work on it).

Same with various documentation, manual etc, I probably won't be able to address these issues until stable 3.4. As you may see, my time I can dedicate to AGS is limited, and I find it very difficult to switch between tasks all time.

Crimson Wizard

I will spend some time reorganizing issues in the tracker now.
There is a useful option to display issues assigned for particular milestone. To access it go to "Bug and Suggestion Tracker" -> choose your project -> click on "Roadmap" button at the header.
You will see a list of available versions. Find the one you are interested with (e.g. AGS 3.3.5 or AGS 3.4.0) and click on the link. You shall see a filtered list of issues.

There is a bit of mess there with some obsolete versions right now, but I am going to clean that up.

Crimson Wizard

#228
By the way, regarding rewriting the setup program in a cross-platform way which was discussed some time ago.

I was going to write a simple application using a basic GUI lib (like FLTK, IIRC). The main reason I halted this "project" was a lack of free time, which I'd rather dedicated to actual engine improvement and release of the custom resolutions version.
However, there were also two bothering problems which would appear for any stand-alone application.

1. How to make setup program compatible with the engine, in the sense that it should display graphic modes and filters, supported by the engine?
Of course, it is possible to hard-code everything inside such application, but then we would need to update it whenever engine gains or looses a feature. Furthermore, we would have to resolve situations with backwards compatibility (like, what would happen if we put a newer setup with an older game)?
Ideally, setup should inquire engine about features it supports somehow. I was thinking even about such things as making them converse via a pipe, or temporary file on disk, or even make the engine output something int stdout.

Or moving particular parts of the engine into DLL to let setup load it and call its functions.

Maybe, I was not seeing some prettier solution here.

2. How to make setup program know which game were are configuring? Also, if the setup program has "Save & Run" button, how to make it run the program we want? What if there are several games in a folder? (not usual with AGS games, but still).


I was thinking this situation over recently, and suddenly realized that there is another option, besides stand-alone app: a plugin interface.

What if there were a plugin interface for setup dialog made into DLL?
a) the engine could run such setup dialog from itself when it wants (e.g. if the default config file is not found).
b) the engine could easily pass any information to such plugin (game title and parameters, supported gfx modes, featured filters, etc).
c) the engine could even pass some of the game resources (!) - such as sprites or audio - to setup program.
d) standartized API would make it simplier to write custom compatible and replaceable setup apps for game developers and other parties.

What do you think about this?


E: Cons?
a) you won't be able to run a setup without an engine present. (But would you need to?)
b) engine has to know how this setup dll is called. Or, search for any dll which supports plugin interface.
c) you can't use this setup-DLL with games made with older engine, obviously.

Alberth

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.


Crimson Wizard

Quote from: Alberth on Sun 02/08/2015 18:07:51
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.
By DLL I meant any dynamically linked object, not only Windows DLL. We have plugins made for Linux too, using same code, but ofcourse you need to supply open source code for those who would like to build themselves.
Not sure about mobile platforms though, they might have some format too, but they also may impose extra restrictions to program content. Anyway, they are less concern, because they already have launchers which set games up, and the resolution settings are mostly automated.

Alberth


SMF spam blocked by CleanTalk