AGS 3.3.x/3.4.0.0 Developer Discussion

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

Previous topic - Next topic

monkey0506

I'm still a little bit confused. It seems that in order for structs to even work, they would have to know the relevant types and offsets of the members, but you're saying that's not the case? >:(

Calin Leafshade

The point is that they don't know at runtime.

Crimson Wizard

Quote from: Calin Leafshade on Mon 21/07/2014 07:37:56
The point is that they don't know at runtime.
Yes,... this... basically is what I tried to explain with 20 lines of text :).

Since it is engine that is responsible for creation and deletion of dynamic objects, it needs to have enough info about their contents. In regards to custom user structs - currently it does not have enough.

monkey0506

Quote from: Calin Leafshade on Mon 21/07/2014 07:37:56
The point is that they don't know at runtime.

Oh...duh. (roll)

So since the compiled program basically just deals with chunks of raw memory, and the members are then offsets from a parent address, essentially we need an additional step to say, "Before you free up this memory, derefence this offset and free up its memory too," right?

Calin Leafshade

Yes, you need a way to crawl the reference tree and free all child objects (and their children).

Essentially what CW is talking about is the beginnings of a form of type reflection which would be great, especially if exposed to scripts somehow :">

Crimson Wizard

Quote from: Calin Leafshade on Tue 22/07/2014 17:26:39
Essentially what CW is talking about is the beginnings of a form of type reflection which would be great, especially if exposed to scripts somehow :">
^_^

Crimson Wizard

#106
I will probably be merging custom display resolutions code into 3.3.1 in a short while, and as an alternative approach I am considering removing "winsetup" from engine code completely and replacing it with stand-alone cross-platform program that will run on all desktop systems (Windows and Linux at least).

This time I'd like to use the ideas by Snarky and others about how to make a useful GUI to setup custom resolution (without the dreary "slider" thing for window scaling I made in the "experimental CR" build).

I'll be frank and honest, telling that I don't really want to spend much time and effort on writing an uber customizable setup with skins etc at this time (it has been said several times that game devs can make their favorite setup program themselves :tongue:).
I am leaning towards FLTK for portable gui and SimpleINI library for portable INI reader/writer.

The FLTK is not the best-looking GUI, but it is very simple and has minimum dependencies. In the end, it may be used as an example for making other setup programs.

I would like to know if anyone else is/was working on "portable winsetup" meanwhile. Maybe there's already such program? I recall someone expressed a will to make one, but I never heard if he finished it.
Thing is that as soon as I get free resolutions code into AGS, the old winsetup will become practically useless and will need a rewrite anyway, so I would not want to wait too long.


-----------------------------------------------

On a second, minor, issue, I am starting to think that this may be not 3.3.1 but 3.4.0 release, considering what breaking new features are and will be added into it (user structs & free resolutions alone). I think I chose slightly incorrect way to continue development again. I guess we should have made two branches - for 3.3.1 and 3.4.0 and generally work in 3.4.0, but merge some lesser changes and fixes into 3.3.1 (merging 3.3.1 into 3.4.0 periodically), or something like that.
But this may be difficult to do without clear roadmap (which I don't have).

Calin Leafshade

Would it not be better to leave winsetup in for legacy purposes and instead, implement an in-engine solution?

Currently the engine has in-engine solutions for save, load and quit dialogs. Why not gfx settings?

The advantage of this is that it easily allows users to override the functionality and you don't have to maintain any GUI lib.

BigMc

You could also consider Phoenix as a GUI toolkit. It's simple and uses the native widgets on each platform. Don't know how it compares to FLTK but I know that byuu writes very clean code.

Crimson Wizard

#109
Quote from: Calin Leafshade on Wed 06/08/2014 15:39:00
Would it not be better to leave winsetup in for legacy purposes and instead, implement an in-engine solution?
Because
a) There still may be need to set up options before launching the game. Some settings may cause game simply not start up, or crash - in exceptional cases, etc.
b) Implementing in-engine controls will require more time to design and implement the customizeable system. Also, at the time being I cannot predict how well the AGS will react to changing these parameters during the game.
c) At this moment I can't tell how much more will I work on AGS, therefore I am trying to stick to things that I know will work.

Also, what are "legacy reasons" to leave winsetup, when it will no longer will setup the program correctly, due to changes in how config works?

Quote from: Calin Leafshade on Wed 06/08/2014 15:39:00
The advantage of this is that it easily allows users to override the functionality and you don't have to maintain any GUI lib.
I am not going to maintain any lib. I want to write a small program that uses existing lib.

Calin Leafshade

#110
With regards to point B, AGS already has an inbuilt gui control system which is used by the aforementioned save, load and quit dialogue boxes. And the system would not need to be customizable just like the save/load dialogues arent. They can just be ignored and alternative systems implemented by the user.

Your other points are fair.

Also I agree that native widgets are better.
Another option is the Wx set which uses native widgets.

Crimson Wizard

#111
Of course, the in-engine settings may be added later, after it is investigated how well will they work.
Right now I want just to keep existing setup updated.

EDIT: wxWidgets have config file support too:
http://docs.wxwidgets.org/trunk/classwx_file_config.html
I understand it so that FLTK does not use native controls at all.

Radiant

Quote from: Crimson Wizard on Wed 06/08/2014 15:27:08
I will probably be merging custom display resolutions code into 3.3.1 in a short while, and as an alternative approach I am considering removing "winsetup" from engine code completely and replacing it with stand-alone cross-platform program that will run on all desktop systems (Windows and Linux at least).

I applaud this idea and wholeheartedly support it!

selmiak

but... will it still be WINsetup on linux systems? (wtf)

Calin Leafshade


Alberth

Quote from: Calin Leafshade on Wed 06/08/2014 19:23:17
linsetup obviously.
Mostly known as
Code: bash
$ ./configure
$ make
$ make install
  :P
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.

Crimson Wizard

#116
Umm, Alberth, we were speaking about configuring the game (graphics mode, sound, other options, like language), not the installation on disk.

Alberth


Crimson Wizard

#118
Preliminary work: https://github.com/ivan-mogilko/ags-refactoring/tree/feature-free-resolutions
Will make a formal pull request after I test few things more.

TODO:
1) new setup (may be a separate pull request);
2) backward-compatible fix for rooms of smaller size than game (strangely, were supported before AGS 3.*).

ALSO:
3) add custom resolutions (should be simple, just apply couple of existing patches), probably will be separate pull request, because it is technically not related.

RELATED (work for undetermined future):
4) fully working OpenGL renderer
5) make all gfx filters work in a common way (scale from one rect into another), and drivers perform final scaling if required. Currently software filters do both operations, while Direct3D filters don't do anything except for setting up some render parameters (real OpenGL filters do not exist).


... 6) maybe make a small adventure game. It's been a while since I tried. :tongue:

Gurok

I need some feedback on this:

https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...331_runtime_type_information?expand=1

Is it correct?
Is this enough information at runtime?
Can we build upon this to free relevant pointers when managed user objects are deregistered? (I don't know how to do this bit.)

The runtime type information currently presented is:
- total size of the object's type
- an array of offsets for any pointers to managed non-builtin objects contained within

Offsets tell you where the pointer is relative to the base address of the object. e.g. 4 -> pointer is at baseaddr+4

The file format version for scripts was bumped earlier in the 3.3.1 commits, so compatibility-wise the new chunk of info in script files should be fine.

I think this is a small amount of double handling. Is there an argument for dumping the symbol table (and ALL flags about objects) into each script and reading it back? I think not because with the structure of the symbol table, this would mean a long scan of all symbols to get info about the pointers inside a struct.

Sorry if this doesn't make sense. I was up all night trying to work out how best to do this. If this isn't right, it's at least a start.
[img]http://7d4iqnx.gif;rWRLUuw.gi

SMF spam blocked by CleanTalk