Post by: Gurok on 09 Feb 2014, 08:45
I've been tinkering around with the AGS source for the last week or so. I'm mostly concentrating on some bugs that affect me, but I think they'll also benefit the community at large. Under Crimson Wizard's advice, I've also started back/forward/sideporting some of the changes in the Draconian edition to a format suitable for mainline AGS. Here are some things I am going to try to get into AGS 3.3.1. I'd like your feedback, comments, criticism, etc. I would appreciate code reviews, but I'd also just like general advice like "that's not important" or "we wouldn't want x option to work that way". I may change the target version for these, rethink them a bit or just scrap them completely.
Vsync for Direct3D
https://github.com/gurok/ags/compare/vsync (https://github.com/gurok/ags/compare/vsync)
This is something that Alan v.Drake implemented in his fork, but it was hard coded. The real problem with Direct3D and vsync is that it needs to be initialised before the game starts. Here's what I did to solve the problem:
There's now a new option in winsetup.exe called "vertical sync".
If it's checked, the game starts with vertical sync turned ON.
In DirectX 5 mode, the game can still toggle this setting with System.VSync.
In DirectX 9 mode, the System.VSync property becomes read-only.
Code Regions
https://github.com/gurok/ags/compare/code_regions (https://github.com/gurok/ags/compare/code_regions)
This is another thing I grabbed from Alan v.Drake's work. He added some directives to allow you to wrap sections of code arbitrarily, e.g.
#region
if(something)
{
...
}
#endregion
You could then fold the code to show or hide these regions. Useful for large, hard-to-maintain global scripts.
Software Sprite Scaling
https://github.com/gurok/ags/compare/software_sprite_scaling (https://github.com/gurok/ags/compare/software_sprite_scaling)
This was a common complaint when I was reading through a thread by Dave Gilbert about releasing commercial games with AGS (http://www.adventuregamestudio.co.uk/forums/index.php?topic=48795.0;nowap). In Direct3D mode, the sprite scaling uses the screen's resolution and not the game's. Nothing breaks immersion like pixels of different sizes. I thought about fixing the Direct3D implementation. The thing is, by the time sprites end up at the Direct3D, we have next to no information about what their "real" size should be. It turns out the code path for software rendering of sprites is still available to Direct3D, it's just not being used. This patch provides a new option in General Settings called:
Force software scaling and flipping
When set to true, it will tell AGS to use software scaling, regardless of whether Direct3D's "superior" hardware accelerated scaling is available.
For, Break, Continue
https://github.com/gurok/ags/compare/for_break_continue (https://github.com/gurok/ags/compare/for_break_continue)
This would be the first baby step towards making AGS a more C-like language. I read a thread a while ago where CJ mentioned that for() and do and things like that were just duplications of while(). I don't agree that we should be limited to only using while statements. There's something to be said for the readability that comes with a standard set of control statements. That's why I'm proposing three new commands:
for([initialisation]; [check]; [increment])
{
...
}
continue;
break;
This would be the first step toward a more expressive AGS scripting language. I know there have been efforts to introduce LUA in the past, but this is something that can work immediately. In the future, I would plan to introduce more statements, like switch() and do, as well as struct parameter passing.
Technically speaking, the jumps for all of these commands already existed in the AGS code. There's a slight modification (some two phase parsing) needed to parse the increment of a for loop, but nothing more than what happens when calculating the jump for a while loop. I also refactored the parsing of assignments (first part of a for loop) to allow for this change.
This is a change that I think would need some serious testing. Everything it generates is stuff other commands generate (JZ, JMP, MOV, LITTOREG, etc.), but it's possible to seriously screw up a compile if some of the code is wrong. The good news is, if there are bugs, you can just remove the for, continue and break statements from your code and everything should function as before.
In terms of efficiency, continue is very efficient if it eliminates a check e.g. if(continue == true). Break involves the same number of jumps as a normal loop termination. There was no way to eliminate the second jump required. The for loop should be about as efficient was writing out a similar while loop by hand, e.g. x = 0; while(x < 10) { ... x++; }.
Portrait Positioning
https://github.com/gurok/ags/compare/portrait_positioning (https://github.com/gurok/ags/compare/portrait_positioning)
Here is my unanswered thread about this problem:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=49927.0 (http://www.adventuregamestudio.co.uk/forums/index.php?topic=49927.0)
The positions for character portraits are sticky because AGS has no idea of who was talking before the current character once the speaking character has actually changed. My solution was to implement a two object "stack" of actively speaking characters. That way, if a character speaks, moves and speaks again, AGS still knows to whom that character was speaking and can use the relative position of the character to determine which side the portrait should be on.
If the speaking character is the first character to speak when entering a room, AGS takes a guess at which character they're speaking to by grabbing the first character it can find. I thought this could be a bit smarter, so I made it assume the character speaking was talking to the player first (if applicable), then try any random other character in the room.
This is a bit of a personal bugbear as X-based positioning for character portraits is unusable for me right now.
Text Window GUI Padding
https://github.com/gurok/ags/compare/text_window_gui_padding (https://github.com/gurok/ags/compare/text_window_gui_padding)
This is one of the first things I proposed to CW and it's looking like 3.3.1 will be the release this makes it into.
It's very simple. Currently, text window GUIs put an amount of padding around the text in them. It turns out that this padding was a hard coded 3 pixels. This change adds a new property called "Padding" to text window GUIs and allows you to adjust this value (default is 3). I can't believe there haven't been any other complaints about this. It basically makes it impossible to make tight speech windows.
--
I'm currently focused on porting the stuff from Alan v.Drake that's still relevant. I might add to this discussion when I've got a list of the new scripting commands he added. Some of them will need to be discussed. People tell me to check the bug tracker. I've had a look there, but I also need to pick and choose things I can actually do. A lot of those tasks seem enormous and I'm only just finding my feet in the AGS source.
P.S. CW, is this the sort of discussion you were after?
Post by: Calin Leafshade on 09 Feb 2014, 11:07
I think the thing that almost everyone is most interested in is struct parameter passing.
My suggestion for actual object creation can be found here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46157.msg620208#msg620208
Post by: Gurok on 09 Feb 2014, 11:47
Post by: Snarky on 09 Feb 2014, 13:51
These look like fine improvements. I personally really appreciate vsync and for-loops. (And yeah, if we could pass pointers to custom structs, that would simplify coding by about 1000% percent.)
I do wonder about this bit, though:
Software Sprite Scaling
https://github.com/gurok/ags/compare/software_sprite_scaling (https://github.com/gurok/ags/compare/software_sprite_scaling)
This was a common complaint when I was reading through a thread by Dave Gilbert about releasing commercial games with AGS (http://www.adventuregamestudio.co.uk/forums/index.php?topic=48795.0;nowap). In Direct3D mode, the sprite scaling uses the screen's resolution and not the game's. Nothing breaks immersion like pixels of different sizes. I thought about fixing the Direct3D implementation. The thing is, by the time sprites end up at the Direct3D, we have next to no information about what their "real" size should be. It turns out the code path for software rendering of sprites is still available to Direct3D, it's just not being used. This patch provides a new option in General Settings called:
Force software scaling and flipping
When set to true, it will tell AGS to use software scaling, regardless of whether Direct3D's "superior" hardware accelerated scaling is available.
Is it not possible in D3D to simply "merge" the background + all the sprites and stuff onto a single texture in the game resolution, and then scale up that texture to the screen/window resolution, all with hardware acceleration? I don't know that much about 3D programming, but that seems like the "right" way to do it.
Post by: Calin Leafshade on 09 Feb 2014, 13:54
A better solution would be to have a RenderTarget of the native game resolution, do *all* drawing to that and then draw that RT to the back buffer.
That way you can still utilise filtering of various kinds and it still make sense with regards to the native res.
Post by: Alan v.Drake on 09 Feb 2014, 14:50
- Alan
Post by: Gurok on 09 Feb 2014, 15:04
Well, my D3D driver handled scaling just like that. Are you doing this via software so you can apply non-shader filters afterwards ? I always wondered if it's faster to get a bitmap from the d3d surface and then feed it to the filter and back. Shaders would still be better tho.
- Alan
I'm doing this because I didn't know you'd implemented better scaling. If your D3D driver did scaling as Snarky described, then maybe it's better to kill off my proposal and browse through the Draconian fork instead.
I actually thought there were complications involved with rendering to 320x200 and then upscaling it. I'm pretty sure I've seen some AGS games that are 320x200 but have high resolution fonts. Don't know how they work, but that was part of my concern. Also, I did it this way because the patch was minimal and it was relatively easy to do so (not so good reasons, I know).
I have heard there are some problems with filters in direct 3D, so maybe that's another reason to allow software scaling. But at the moment, I'm getting the strong impression that I should just ditch the current effort and do it the "proper" way.
I am looking at passing structs, Snarky. No fancy class keyword or allocation on the heap, but passing them in seems doable.
Post by: tzachs on 09 Feb 2014, 15:35
For loops are a welcome addition, and text window padding especially has been a pain. While you're working in that area, maybe you can look into having the line & character spacing also configurable (not only in text windows, but in Say commands as well) which would also help make some fonts more readable.
Post by: Snarky on 09 Feb 2014, 16:11
I actually thought there were complications involved with rendering to 320x200 and then upscaling it. I'm pretty sure I've seen some AGS games that are 320x200 but have high resolution fonts. Don't know how they work, but that was part of my concern. Also, I did it this way because the patch was minimal and it was relatively easy to do so (not so good reasons, I know).
Yeah, in earlier versions of AGS it was possible to make a 320x200 game and then set it to run in 640x400, which made the fonts display in twice the resolution. Some games (notably the Blackwell titles) took advantage of this. That feature-slash-bug was removed in recent versions, though (3.0, maybe?).
There's been some talk about allowing mixed-resolution games in a more deliberate way. (Perhaps an option to render fonts in a separate layer in the native screen resolution? Or a way to define certain graphical elements as being pre-scaled...) CW seemed to think it would make the graphics rendering code very messy.
(If we're talking feature requests, by the way, it would be cool to have the option to place sprites and text at non-integer coordinates. That would make smooth scrolling look better. Also higher resolution on sprite transformations like scaling and rotation: only having whole-percent and whole-degree accuracy makes these operations pretty jerky.)
Post by: Crimson Wizard on 09 Feb 2014, 17:04
(If we're talking feature requests, by the way, it would be cool to have the option to place sprites and text at non-integer coordinates.I must remind (again) that in AGS everything is interwined and one problem is usually blocked by another. It is of utmost importance to find the blocking issues, plan and resolve them first.
This, for instance, will require changing Plugins API, because current one has inner data of many engine types exposed.
Also, - providing compatibility hacks for old games that change object coordinates by writing directly to memory address.
I also urge you (practically beg) not to get every idea in one pile (again), regardless of how cool and wanted it is.
My belief is that the milestones for the next major version should be defined first (considering blocking issues too), and the work continued in a more advanced "develop" branch. As for 3.3.1 version, it should receive only minor updates that do not require changing the code much.
Post by: Radiant on 09 Feb 2014, 18:41
I also urge you (practically beg) not to get every idea in one pile (again), regardless of how cool and wanted it is.That's a good point. How about, instead of placing six ideas in one thread, we open six separate tickets in the Bugs And Suggestions Tracker?
Quote
My belief is that the milestones for the next major version should be defined first (considering blocking issues too), and the work continued in a more advanced "develop" branch. As for 3.3.1 version, it should receive only minor updates that do not require changing the code much.I agree that's a good approach.
Post by: Crimson Wizard on 10 Feb 2014, 07:26
- Code regions
- Portrait positioning
- Text window gui padding
- Vsync
If I understand correctly, there were no objections against these? These changes seem pretty simple ones.
I really hope Gurok tested them, especially the ones with padding and portrait positions (that all alternate options still work properly). :)
But since we are talking about development branch, it won't be a big problem if there are bugs there. I may merge them right away, then we may have the first test build.
Additionally, I can merge the long waiting feature branch by Alan v. Drake with his new script commands (extended Character.ChangeRoom function, etc):
Code: Adventure Game Studio
- void Character.ChangeRoom(CharacterInfo *chaa, int room, int x, int y, CharacterDirection direction);
- int Object.IsInteractionAvailable();
- int Hotspot.IsInteractionAvailable();
- int Character.IsInteractionAvailable();
It bothers me that IsInteractionAvailable() returns "int". Since the return value is not used in binding script to engine, maybe it will be possible to change it to "bool" and still have compatibility with Draconian games.
EDIT: hmm, after rechecking the old branch, I think it will be easier to remake all them, because there's some excessive code in there (like ChangeRoom function have an "old-style" duplicate).
Post by: Gurok on 10 Feb 2014, 08:12
Portrait positioning only applies to really specific cases. The code I changed is after a series of checks that go a bit like this:
if(using_sierra_style_portaits)
if(not_using_full_screen_ones)
if(using_portrait_x_positioning)
...
Text Window GUI padding applies to all text windows. I tested speech and Display("") windows thoroughly. Both with border graphics and without. Is there anything else?
For, continue and break is the one I'm most concerned about. For a while, I accidentally had my for loop behaving a bit like a "yield" statement. It would quit the function and the next time you called that function, it would resume from that point. Finally tracked it down to a missing continue statement in cc_parser. That's why I'm concerned about merging that branch for now (at least until I've had more time to test it).
Post by: Crimson Wizard on 10 Feb 2014, 10:53
How to fix: assign default value with member declaration instead of base constructor:
Code: C#
- private int _padding = 3;
Remember that you can do "ammend commit" thing to fix already existing commits, and "force push" to update your remote branch (Never do that in master, because that may cause conflicts with other people's work, but temporary feature branches are OK).
EDIT: Hmm, I forgot another case: importing a 2.72 project. It is done in a separate function in agsnative.cpp. We need to test that too.
Post by: Gurok on 10 Feb 2014, 11:25
REPLY TO EDIT: I believe this is already covered in my changes to read_gui:
if (GameGuiVersion < kGuiVersion_331)
guiread[ee].padding = TEXTWINDOW_PADDING_DEFAULT;
But that's a good point. I haven't tested it against 2.72.
Post by: Crimson Wizard on 10 Feb 2014, 11:34
Post by: Gurok on 10 Feb 2014, 11:41
Post by: Crimson Wizard on 10 Feb 2014, 11:42
Is there a convenient link to 2.72 so I can do testing against it in the future?
All here: http://agsarchives.com/engine.html ("Other builds" list at the right side).
EDIT: tested with fixed 2.72 import, it's working and padding = 3 for text windows.
Post by: deltamatrix on 13 Feb 2014, 16:36
Post by: Calin Leafshade on 13 Feb 2014, 18:36
If you need that then I suggest the AGS Lua plugin.
Post by: Crimson Wizard on 17 Feb 2014, 09:04
Maybe you could make a test build and let people try it out meanwhile? You need to distribute only Editor & Engine binaries (dlls and exes), they may be manually copied over 3.3.0 folder.
The code changes in case anyone's interested to review: https://github.com/adventuregamestudio/ags/pull/121/commits
Post by: Monsieur OUXX on 19 Feb 2014, 16:00
But pretty pretty please consider fixing the Undo-History :~(
To be honest this is driving me nuts, because at some points I can't remember what I did to break the game. Only that now I can't undo my way out of this mess ;)
Yes, for me this is a no-go for upgrading to 3.3.0. I tend to do tests by changing parts of the code, then undo the changes. If the undo history is gone, I'm done for.
Post by: monkey0506 on 19 Feb 2014, 16:26
Code: Adventure Game Studio
- /*/
- // Original code -- COMMENTED OUT
- int a = 42;
- float b = 3.14;
- String c = "blah";
- // ...
- /*/ // don't mess with this ;)
- // New code -- NOT COMMENTED
- int a = 314;
- float b = 5.7;
- String c = "whatever";
- // ...
- /**/
Code: Adventure Game Studio
- /**/
- // Original code -- NOT COMMENTED
- int a = 42;
- float b = 3.14;
- String c = "blah";
- // ...
- /*/ // don't mess with this ;)
- // New code -- COMMENTED OUT
- int a = 314;
- float b = 5.7;
- String c = "whatever";
- // ...
- /**/
By changing a single character (the asterisks on the first line) you can toggle between the two blocks of code.
Post by: Crimson Wizard on 19 Feb 2014, 17:03
Also, have anyone tried to use source control with AGS? There's even a plugin api for that.
Post by: Monsieur OUXX on 19 Feb 2014, 17:49
You could test your code by doing this:
Nope. It's not a matter of replacing an entire section of code with another one. It's a matter of modifying a bunch of small parameters inside the code, and continualy testing what the changes did.
Anyway, just sayin'. For me it would be disastrous not to be able to revert after I inadvertently broke something at some unknown point. It's only an inconvenience for me, others will do great.
Have anyone tried to use source control with AGS? There's even a plugin api for that.I can't wait for that to fully mature. I'm very excited.
Post by: Crimson Wizard on 19 Feb 2014, 18:10
I can't wait for that to fully mature. I'm very excited.But you can use any version control system right now. For scripts, at least.
BTW Git is good for experiments, because it allows to quickly switch between branches.
Doing what you say with Undo sounds like a wrong thing to me anyway.
Post by: Monsieur OUXX on 20 Feb 2014, 11:13
Doing what you say with Undo sounds like a wrong thing to me anyway.
OK guys, you win, I'll stop being stubborn and switch to 3.3.0. I'm very attracted to source control and re-importing sprites from original source.
Post by: Crimson Wizard on 20 Feb 2014, 11:26
OK guys, you win, I'll stop being stubborn and switch to 3.3.0. I'm very attracted to source control and re-importing sprites from original source.I was not forcing you to use 3.3.0 :), in fact the non-working undo is something I would be concerned about as well.
Regarding source control, I mean it can be used normally without connection to AGS. You may just make a repository out of the game project folder.
I don't know how source control API works myself.
Post by: fireapache on 22 Feb 2014, 05:17
Just a sugestion! :wink:
Post by: monkey0506 on 22 Feb 2014, 06:23
Post by: Monsieur OUXX on 22 Feb 2014, 19:04
I may take a look at it later and see if I could come up with anything.
Please do it. AGS needs collaborative development.
Post by: Gurok on 23 Feb 2014, 07:26
Please do it. AGS needs collaborative development.
AGS and the AGS Git repository both!
Post by: Crosco on 27 Feb 2014, 19:32
The "for()" statement would be a nice-to-have feature. (I can't say why I didn't missed it so much.)
To having pointers as member variables of structs would be fantastic!
OK guys, you win, I'll stop being stubborn and switch to 3.3.0. I'm very attracted to source control and re-importing sprites from original source.I was not forcing you to use 3.3.0 :), in fact the non-working undo is something I would be concerned about as well.
Regarding source control, I mean it can be used normally without connection to AGS. You may just make a repository out of the game project folder.
I don't know how source control API works myself.
Crimson is right. A version control system will resolve your problem to determine which code lines you changed. And, it will allow you to keep a history of all your changes.
I installed a subversion repository on my machine (using TortoiseSVN) and added the project folder as trunk as Crimson also mentioned.
The repository also allows you to branch and try out another AGS version.
Post by: Gurok on 10 Mar 2014, 05:48
I've found some more low-hanging fruit. It's pretty easy to lift the static restrictions on extender functions such that you could do this:
Code: [Select]
static function DoIt(this Character *, int a)
{
Display("I did it! %d", a);
}and then in your module header, this:
Code: [Select]
import static function DoIt(this Character *, int a);and then later somewhere in your code, this:
Code: [Select]
Character.DoIt(3);The trouble is that
a) "this" is not defined for a static extender function
b) the syntax is a bit ugly
"This" being undefined is not such a problem because the compiler picks that up anyway. If I were to tidy up the syntax (which I could), do people think this might be useful? Something like this might be possible for the syntax:
Code: [Select]
static function DoIt(extends Character, int a)or this (which is the nicest I've thought of so far):Code: [Select]
function AbsInt(static Maths, int value)Though I am open to suggestions.
Post by: Gurok on 10 Mar 2014, 06:25
Code: [Select]
switch(x)
{
case 5:
Display("Five");
case 6:
Display("Six");
default:
Display("Default");
case 7:
Display("Seven");
}translates into lots of jumps. Pseudo-assembly follows:
Code: [Select]
# Switch statement
jmp condition1:
exit:
jmp 0
condition1:
evaluate_expression("x == 5");
jz condition2:
code1:
Display("Five");
jmp code2:
condition2:
evaluate_expression("x == 6");
jz condition3:
code2:
Display("Six");
jmp code3:
condition3:
# No jumps or evals
code3:
Display("Default");
jmp code4:
condition4:
evaluate_expression("x == 7");
jz 0
code4:
Display("Seven");
end_of_statement:With the 0 addresses being filled in as "end_of_statement" after the switch statement is fully parsed
Might need some temporary 0 addresses for lines like "jmp code2:" too
But with this, a break statement just becomes:
Code: [Select]
# Break statement
jmp exit:I haven't coded the above yet, but that is what I plan to do. Comments welcome.
AGS script is a single pass compiler, so there are a lot of cases where jmp 0 is used temporarily. A few variables about how things are currently nested (almost to the point of having a second pass) are stored to help fill in the blank addresses later.
Side note: Passing structs as parameters is more complex than I first thought and might take some time.
Post by: monkey0506 on 10 Mar 2014, 07:30
As to switch statements, I don't understand these things well enough to know any better, but you've said that it's a rather complicated solution, might there be a better way?
If you can figure out passing struct instances by reference as well then everyone can finally stop complaining about how horrible AGScript is.
Post by: Gurok on 10 Mar 2014, 08:55
Syntax as follows.
Module:
Code: [Select]
function AbsInt(static Maths, int value)
{
if(value < 0)
value = 0 - value;
return(value);
}Header:
Code: [Select]
import function AbsInt(static Maths, int value);Example call:
Code: [Select]
int x = Maths.AbsInt(-3);https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...331_static_extender_functions (https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...331_static_extender_functions)
Better warning for function delcaration inside a struct
https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...bugtracker_function_in_struct_error_msg (https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...bugtracker_function_in_struct_error_msg)
http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0 (http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0)
--
I should probably listen to CW's advice and stop piling features into this thread. It's just every time I look at the scripting engine (and this weekend I spent some time looking at for/break/continue), I see things which could very easily be made better.
Post by: Crimson Wizard on 10 Mar 2014, 15:06
Side note: Passing structs as parameters is more complex than I first thought and might take some time.
You might need to make a new type of dynamic object manager in the engine that handles user structs.
Post by: Gurok on 10 Mar 2014, 15:17
You might need to make a new type of dynamic object manager in the engine that handles user structs.
Yes, that is what I fear :D. Right now, switch...case seems easier. Also I've been trying to fix general bugs, but I find myself drawn to the script compiler.
Post by: Crimson Wizard on 10 Mar 2014, 17:29
For passing reference you will need just a wrapper which knows the type of data ("user struct reference"), address and size, and you may "simply" use RuntimeScriptValue for that.
Dynamic creation of user structs is different thing. You might have a look at how strings and dynamic arrays are created: there's a special assembly command for that. But this would be a completely new feature.
Post by: Gurok on 10 Mar 2014, 22:16
Is it possible for me to close issue 503? http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0
I'm going to make a new thread, "AGS 3.3.1 - Test Build" with a changelog and download link tonight.
Post by: Crimson Wizard on 10 Mar 2014, 22:56
Is it possible for me to close issue 503? http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0I don't think it is correct to close issues in AGS tracker before at least some public release is made. But that's my opinion.
Post by: Gurok on 10 Mar 2014, 23:06
Is it possible for me to close issue 503? http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0I don't think it is correct to close issues in AGS tracker before at least some public release is made. But that's my opinion.
Oh right, yes. Sorry. I agree. A bit too hasty by me there.
Post by: Gurok on 13 Mar 2014, 08:37
;
As a valid AGS Script statement. How do people feel about this? At the moment, the compiler rejects it.
Pros:
- More C-like
- Allows for neat for/while loops that repeatedly call an iteration function
- A good placeholder when you need to fill in the if() part of an if/else later on
Cons:
- Allows users to possibly make errors by accidentally terminating a for/while loop with a ;
Post by: Radiant on 13 Mar 2014, 08:58
Post by: abstauber on 13 Mar 2014, 10:14
since you're currently working on 3.3.1, would it be too much to request this feature:
Only these two functions are missing to make dialogs completely controllable via keyboard which is what I'd like to do:
Code: Adventure Game Studio
- Dialog.SetActiveTopic(int option)
- Dialog.StartTopic(int option)
Currently you can only start a complete dialog by script and the only way to highlight a dialog topic is via mouse-over.
If it's not too much work, I'd be really happy to see this in 3.3.1
Post by: Gurok on 13 Mar 2014, 10:56
Only these two functions are missing to make dialogs completely controllable via keyboard which is what I'd like to do:Code: Adventure Game Studio
Raise a bug tracker suggestion for these.
I understand Dialog.StartTopic() as I've run into that limitation myself. What would SetActiveTopic be for?
I raised a suggestion for the scripting changes I think I'll be able to do (not closures or function pointers or outlandish stuff like that). In some ways, I think this topic was a bit of a mistake, but it's been good to gather feedback.
I think your second function is doable at some point, abstauber. I don't know about the first.
Post by: Crimson Wizard on 13 Mar 2014, 11:12
I am not sure about "Topic" word. Other functions use "Option" (compare with Dialog.GetOptionText, Dialog.GetOptionState etc).
Post by: Gurok on 13 Mar 2014, 11:20
I think "Active" is the one selected (highlighted).
I am not sure about "Topic" word. Other functions use "Option" (compare with Dialog.GetOptionText, Dialog.GetOptionState etc).
Yeah, that's what worries me. As far as I remember, dialogs run without really having the concept of a selection. They only have a mouseover state. Unless he means "choose this choice for the player" like how the 0-9 keys behave currently.
Post by: Crimson Wizard on 13 Mar 2014, 11:26
Of course this will only work if you write all the other handlers for custom dialog rendering too.
"StartTopic" (or RunOption, whatever) might be still required though.
Post by: abstauber on 13 Mar 2014, 12:20
So simply setting the highlight by a number would be way more convenient.
And yes - dialog Option makes much more sense than topic :)
Quote
Raise a bug tracker suggestion for these.Will do.
edit: but I can't. Do you need a special role for this?
Post by: Gurok on 17 Jun 2014, 23:55
I haven't coded this yet, but I was thinking something like this might work for passing structs without needing to manage them:
Header
Code: [Select]
struct Point
{
import static Point *Create(int x, int y);
import float DistanceTo(Point *target);
int X;
int Y;
};Module
Code: [Select]
static Point *Point::Create(int x, int y)
{
Point instance;
instance.X = x;
instance.Y = y;
return(&instance);
}
float Point::DistanceTo(Point *target)
{
int dx;
int dy;
dx = this.X - target.X;
dy = this.Y - target.Y;
return(Maths.Sqrt(IntToFloat(dx * dx + dy * dy)));
} Example Usage
Code: [Select]
float myFunction()
{
Point a;
Point b;
a = *Point.Create(3, 3);
b = *Point.Create(6, 7);
return(a.DistanceTo(&b)); // 5.0
}Too complicated?
Post by: Crimson Wizard on 18 Jun 2014, 12:25
This looks like a very bad idea. You are going to return an address to object, allocated on stack. Besides, there's no '&' as "take address" and '*' as "dereference" operators in AGS... and for a reason: AGS was made as a Java/C#-like language, and you are suggesting to "downgrade" it to C-like language.Code: [Select]static Point *Point::Create(int x, int y)
{
Point instance;
<...>
return(&instance);
}
}
I still believe that managed user structs is an only proper way to go.
And, yes, I am back... I was away, then busy, then ill :-X. Now trying to finish unfinished business...
Post by: Calin Leafshade on 18 Jun 2014, 12:43
The pointer syntax in AGS is a weird anachronism as it is and shouldn't be expanded.
I think it would be better to move towards true object references.
AGS does have a way to add arbitrary structs to the object pool via the plugin interface. Is it a huge deal to simply expose this to the script env?
Post by: Crimson Wizard on 18 Jun 2014, 18:08
To have a managed user struct you need an object that will describe it. Possibly, it only needs two properties: size of struct (in bytes) and pointer to data (array of bytes).
Then, you need a manager class that would handle such objects to integrate new type into AGS (manager class and object class could be the same).
Then, it's only a matter of making two additions:
- "new" keyword which would allocate object of desired size on heap and assign to reference; one may look into how script strings and dynamic arrays are created.
- if proved necessary, extend "access member" operation to ensure that it works well with the new type.
BTW, I think, dynamic array type may be a good example to how managed object and manager classes should work, principally.
Post by: Gurok on 18 Jun 2014, 23:14
This looks like a very bad idea. You are going to return an address to object, allocated on stack. Besides, there's no '&' as "take address" and '*' as "dereference" operators in AGS... and for a reason: AGS was made as a Java/C#-like language, and you are suggesting to "downgrade" it to C-like language.Code: [Select]static Point *Point::Create(int x, int y)
{
Point instance;
<...>
return(&instance);
}
}
Yes, I know the object's allocated in stack memory, but it *kind of* would have worked for unmanaged structs as long as there were never pointers to them.
Anyway, yeah, looking into getting the "new" keyword working properly now. I've been messing around with things for about a day now and I feel /slightly/ more informed. There's a surprising amount that's already built. If you declare a struct as managed, you can have pointers to it and it compiles. You just can't do anything useful with it. So you're right. The "new" keyword is like the missing puzzle piece. Thanks!
Post by: Calin Leafshade on 18 Jun 2014, 23:19
Post by: Crimson Wizard on 01 Jul 2014, 11:08
I made this patch (applied on develop-3.3.1): http://www.mediafire.com/download/g2wnuyfqzodn89l/0001-Script-managed-user-object-support.patch
It adds user object support to the engine. Unless I miss something, this is about all what is required for the Engine.
The compiler needs:
1) support for creating managed user objects, e.g. via "new" keyword. I made new "SCMD_NEWUSEROBJECT" command for that (takes one argument - the size of struct in bytes).
2) "legalize" usage of user pointers (MyStruct *p) so that they could be used in similar way as built-in classes (Character*, etc).
The access to object contents is performed same way as you do for internal variables in built-in structs (legacy scripting).
I don't know compiler well, but you seem to be able to get around it.
Let's try this...
EDIT: found a bug, reuploaded patch... (same link).
EDIT2: reuploaded second time :tongue:.
I did not realized that the command should take 2 parameters: register number (to save new pointer) and struct size.
Post by: Crimson Wizard on 01 Jul 2014, 13:14
It. Works.
Final patch for Engine: http://www.mediafire.com/download/g2wnuyfqzodn89l/0001-Script-managed-user-object-support.patch
Test patch for compiler (breaks managed arrays, but this is for test): http://www.mediafire.com/download/0safjx7itsh118l/0001-Compiler-TEST-creating-user-object.patch
Proof :D:
monkey should be happy. No more Lua, mwh-mwhahah. (kidding)
TODO:
1) proper compiler patch (I really hope Gurok will make one, I made this test rather intuitively).
2) support for array of user objects.
3) test all possible cases.
Post by: Gurok on 01 Jul 2014, 13:40
One more TODO... I was going to change the compiler to allow structs to have functions with the same name, e.g.
Code: [Select]
managed struct MyStruct
{
import function MyStruct(int a, int b);
}It's a simple patch, replace "(towrite != in_struct_declr)) {" in cs_parser.cpp with "(towrite != in_struct_declr || sym.stype[last_time] == SYM_VARTYPE)) {"
And the "MyStruct" function would act as a constructor, e.g. x = new MyStruct(3, 4);
Then it's just a matter of parsing a function call after each new statement is parsed.
I'll have a look at your new Editor patch before I start on a proper branch, CW. This is so cool.
If you've seen the part where it parses an array, I think that's the right place to put the managed struct stuff too. It's just a matter of having an if() statement like...
If the symbol following the var symbol is not "["
... managed struct creation code ...
else
... dynamic array creation code ...
end if
Anyway, really exciting! Awesome work, CW.
EDIT: Saved games (serialisation/deserialisation) would be one of the first things I'd like to test. Anyway, I'll get to work on this, sorry! :D
Post by: Crimson Wizard on 01 Jul 2014, 13:56
Regarding serialization, all managed objects work via same interface, so its only a matter of writing/reading memory properly. In the case of "user object" it simply copies N bytes.
Post by: Snarky on 01 Jul 2014, 14:09
Post by: Calin Leafshade on 01 Jul 2014, 14:11
I will be releasing some modules for this!
I think a constructor would be great and a destructor might be cool (?)
static methods should already work right?
Do properties work? I forget what AGS calls them.. attributes i think.
Post by: Crimson Wizard on 01 Jul 2014, 16:08
I suspect that compiler needs to handle special case there.
Post by: ddq on 01 Jul 2014, 17:40
Post by: monkey0506 on 02 Jul 2014, 04:58
Properties fail to work for some reason (unresolved import with weird error message).
I suspect that compiler needs to handle special case there.
Actually, they work fine (http://meleepta.x10.mx/ags/3.3.1-Attribute-Test.rar) (download my test case). Since you're working with a user-defined type, the user also has to define the accessor methods. I've used extender methods so the accessors don't show up as normal member methods, but it is apparently working! :) And just in case anyone hasn't seen it, the attribute tutorial in the wiki (http://www.adventuregamestudio.co.uk/wiki/Keyword:_attribute) is probably a good place to start.
The one issue I did have was with a static method returning a new pointer to the user type. The compiler complained that the "Size of identifier does not match prototype":
Code: Adventure Game Studio
- managed struct UserObject
- {
- import static UserObject* Create();
- };
- static UserObject* UserObject::Create() // apparently doesn't work! "Size of identifier does not match prototype"
- {
- }
Other than that, this is pretty useful and exciting stuff. Thanks for taking the time to look into it. :=
Post by: Gurok on 02 Jul 2014, 13:48
https://github.com/gurok/ags/tree/331_new_user_struct (https://github.com/gurok/ags/tree/331_new_user_struct)
Just a minor tidy up and monkey_05_06, your example should now compile. Not sure if the way I've fixed the bug is correct though. Going to possibly revise it in the future.
It relates to forward declarations. They don't know the size of themselves. That's fine, but all pointer declarations should have a size of 4.
While testing, I made a pointer to a test struct with two ints and the size of its type was 8 (or 0 at the time of declaration). 8 is correct for the size when calling SCMD_NEWUSEROBJECT, but not the size of the pointer. It looks like we need an if() statement to see whether it's a pointer somewhere and change its size accordingly. I'll have to investigate.
You should now be able to create an array of your managed struct too.
I haven't implemented constructors, but I'll be adding them after I fully investigate this pointer issue. And possibly clean up some other areas.
Post by: Crimson Wizard on 02 Jul 2014, 13:56
(I know, I am a great formalist)
That patch I made could work as a commit on its own. It will even bear my name on it :=.
(if something will go wrong everyone will know who is responsible :tongue:)
While testing, I made a pointer to a test struct with two ints and the size of its type was 8. I believe this should be 4. 8 is correct for the size when calling SCMD_NEWUSEROBJECT, but in all the cases I saw, it looked like pointers were always 4.I think you are confusing the size of struct and size of "pointer" (managed handle)?
Post by: Gurok on 02 Jul 2014, 14:12
May you please make separate commits for changes in Engine and Compiler? Because they are, in fact, separate programs.
That patch I made could work as a commit on its own. It will even bear my name on it :=.
(if something will go wrong everyone will know who is responsible :tongue:)While testing, I made a pointer to a test struct with two ints and the size of its type was 8. I believe this should be 4. 8 is correct for the size when calling SCMD_NEWUSEROBJECT, but in all the cases I saw, it looked like pointers were always 4.I think you are confusing the size of struct and size of "pointer" (managed handle)?
Oh right, yes, I'll fix up the commits soon. Sorry. I would actually be happy if you made a branch and I sent you patches to fix things.
Yes, maybe you're right. I just had a look at some of the other managed types (Character *, Object *) and they seem to report their struct's size too.
Post by: Crimson Wizard on 02 Jul 2014, 14:20
I would actually be happy if you made a branch and I sent you patches to fix things.You can make pull requests to separate feature branches too. Or, it is what you actually mean?
But this really does not matter who makes a branch.
Post by: monkey0506 on 03 Jul 2014, 05:46
monkey_05_06, your example should now compile.
It relates to forward declarations. They don't know the size of themselves. That's fine, but all pointer declarations should have a size of 4.
I can confirm that your fix does allow it to compile. The explanation also makes sense, as does the solution. :)
You should now be able to create an array of your managed struct too.
I can also confirm this is working, though it took me a second to realize that I'm now responsible for creating the objects in the array too (simple enough to handle with a "CreateArray" function). Now if only we could have dynamic arrays as struct members... (roll)
I haven't implemented constructors, but I'll be adding them after I fully investigate this pointer issue. And possibly clean up some other areas.
This will definitely be helpful as well. :)
Post by: Crimson Wizard on 08 Jul 2014, 23:56
http://www.mediafire.com/download/bo3d6c6y6a5hexw/0001-Engine-managed-user-script-object-support.patch
BTW, allows user objects of 0 bytes to 2 GB size. There's a reason why I used signed integer as "size" type (explained in comments).
This means "own" size of struct. You can allocate more size by putting pointers to other managed objects inside the first one.
Post by: Crimson Wizard on 11 Jul 2014, 18:09
After considering this for a while, I made a decision to not use the "develop" branch as a base for the future release, but instead start extracting commits by thematical groups to other branches, like develop-3.3.1.
Why: "develop" branch contains lots of various changes, some of them are ready, others still in "alpha" stage and require some extra work to make them finished; and these changes were made in random order, that makes it impossible to make partial merges (e.g. with 3.3.1). Also, there are even such changes that are not needed anymore, and would be reverted anyway. Some things made in haste and fixed for numerous times, etc.
This branch is a result of a very bad planning from my side. Also, back then I could not predict how far will 3.3.0 and 3.3.1 versions evolve.
I made a full list of commits in "develop" and grouped them thematically. I can already see which ones could be useful for 3.3.1: primarily cleaned up (refactored) code and some utility functions. Thus at least some of that code will get into real use at last.
The difference between develop and develop-3.3.1 (https://docs.google.com/document/d/1OiM9cp6Cp2_MgCKjgfMjIYizwtmLsmjzBW9lpcXlXHY/edit?usp=sharing)
Commits by group (https://docs.google.com/document/d/1ECsrZEuM_Dsc706SmVrj_qdsaFP1gW66FzeigUIqKvw/edit?usp=sharing)
I know that there's another branch based on "develop", the "multi_room_edit" by monkey_05_06, but its commits can be extracted same way when time is right (or simply rebased, since he practically was editing only one file). Same goes for any other work made on top of "develop" by anyone other (if there is some).
Post by: Gurok on 13 Jul 2014, 06:05
https://github.com/adventuregamestudio/ags/pull/165 (https://github.com/adventuregamestudio/ags/pull/165)
I wasn't able to get constructors working in a satisfactory manner without making the code look like Frankenstein's monster. I will attempt this again in the future. I have reasoned that it's not crucial for 'version 1.0' of user-managed objects, and we have enough to test as it is. We can introduce constructors at a later date and enforce bracket notation (e.g. n = new MyStruct() ) only when a constructor is present in the struct.
Regarding the implementation of constructors, I welcome anyone else to try. To be done properly, I think it will need serious refactoring.
Post by: Crimson Wizard on 13 Jul 2014, 10:51
I wasn't able to get constructors working in a satisfactory manner without making the code look like Frankenstein's monster.I +1 this. When I was testing monkey_05_06 addition that allows managed arrays in structs, I noticed that there's another piece of code that creates global/local arrays, it looked 98% the same, but was located in separate function.
<...>
Regarding the implementation of constructors, I welcome anyone else to try. To be done properly, I think it will need serious refactoring.
Post by: Crimson Wizard on 13 Jul 2014, 16:28
Because they do not know how to remove reference count from managed objects inside them when they are disposed themselves.
I will check how common structs work, but I suspect this is done by compiler (when local or global struct is deallocated).
For dynamic arrays it's not a problem, because they store only one type, and know what it is exactly.
This problem is far more complex than anything else related to managed structs. I will need to think more about this.
E: The dumb way is to have a list of offsets for all managed handles inside struct. In any case this means that script interpreter must support some kind of "type description".
Post by: monkey0506 on 13 Jul 2014, 18:01
Post by: Snarky on 13 Jul 2014, 18:33
But again, I'm not the one doing the work, so take this for what it's worth.
Post by: Crimson Wizard on 13 Jul 2014, 18:39
I'll see if the user objects can be made work without much hassle...
Post by: monkey0506 on 13 Jul 2014, 18:52
Post by: Calin Leafshade on 13 Jul 2014, 20:56
Replacing it would be better in the long term because we get all the advantages of a popular, off-the-shelf library but it would take a lot of work.
Post by: Gurok on 14 Jul 2014, 01:53
E: The dumb way is to have a list of offsets for all managed handles inside struct. In any case this means that script interpreter must support some kind of "type description".
Speaking of dumb ways... if you can't solve it, the half solution you proposed on GitHub seems reasonable to me. Disallow non-built-in managed struct pointers inside managed structs. We could then enable them at a later date when we've figured out how to manage them. I know it cripples managed structs, but there's already so much functionality provided by passing in and returning struct pointers. I'd hate to see it shelved. Crippled managed structs also don't do anything bad. They don't box us in for future development.
If AGScript is replaced by a Java-based language, I will stop contributing to AGS development.
Hear, hear. I don't think anyone who contributes really wants that.
Regarding AGS script, I'm not in favour of replacing it for the time being. AGS script isn't just the language, it's the VM too. We aren't reinventing the wheel. We inherited a project that (for better or worse) reinvented it and we're uh... reinventing a few spokes. Ewww, terrible analogy. Point is that AGS script is 90% there.
Post by: monkey0506 on 14 Jul 2014, 02:40
Post by: Crimson Wizard on 14 Jul 2014, 07:08
Speaking of dumb ways... if you can't solve it, the half solution you proposed on GitHub seems reasonable to me. Disallow non-built-in managed struct pointers inside managed structs. We could then enable them at a later date when we've figured out how to manage them. I know it cripples managed structs, but there's already so much functionality provided by passing in and returning struct pointers. I'd hate to see it shelved. Crippled managed structs also don't do anything bad. They don't box us in for future development.Well, if you think that's proper; you then need to fix the compiler appropriately, and reopen/remake the pull request.
Post by: Gurok on 14 Jul 2014, 07:21
Well, if you think that's proper; you then need to fix the compiler appropriately, and reopen/remake the pull request.
I just want to make sure I understand the problem correctly.
Post by: Crimson Wizard on 14 Jul 2014, 08:28
I just read your GitHub note again. I believe I need to restrict them so that they can't include any pointers.BTW, we need to recheck if any of the existing managed structs contains pointers... if some do, then some alternate solution should be invented.
For instance, we may allow pointers in structs declared as "builtin".
Regarding universal solution. Here's a raw sketch:
1. "Type info" object is created for every basic type (int, float, pointer) and every user-declared managed struct. Type description tells object size and useful info. For the time being we need an array of offsets for pointer types in structs (letting engine know which pointers this object has).
2. When any object is created with new, compiler tells not the size of struct, but an ID of type info, letting object know which struct it represents.
3. We may even make dynamic arrays work the same way: make the "create object" command pass extra "number of elements" parameters. Type info is one of the basic types (int, float or pointer), so array will know how to deal with elements too.
This will require increasing "script data format" number (I recall there's one); the compiler must write the "type infos" chunk, and engine must know how to read it.
Don't know about compiler, but I don't think this should be terribly difficult for engine.
Post by: Radiant on 15 Jul 2014, 14:17
I really don't mean this as discouragement or criticism, but I wonder if all the energy put into hacking the scripting language might not be more usefully spent on other parts of the engine. The fact is that AGS Script isn't that unique, and we might be better off simply adopting a standard one with an existing compiler than having you spend so much effort trying to improve what we have.That strikes me as a very bad idea, as it would throw out backwards compatibility with all existing games and ongoing projects, as well as invalidate most of the skill that our community members have developed with using the scripting language.
The AGS scripting language works, and has worked well for over a decade, and we've got a database of nearly two thousand games to prove it. There's absolutely no good reason to replace it by some arbitrarily chosen "more popular" scripting language.
Post by: Calin Leafshade on 15 Jul 2014, 14:38
There's absolutely no good reason to replace it by some arbitrarily chosen "more popular" scripting language.
Speed and upstream support seem like the most obvious ones to me.
Post by: Snarky on 15 Jul 2014, 17:05
- Improved documentation and more/better scripting tutorials "for free". Beyond very basic scripting, AGS doesn't really offer much help for learning, and many important features are not even clearly documented – at least in the most in obvious locations (for example, any time I need to export/import variables or declare struct members functions I have to go find an existing script that does it; neither is properly explained in the manual). Of course, our documentation could be improved, but that's just making more work: in addition to reinventing the wheel we also have to explain it!
- Better code debugging/analysis tools.
- More appeal to new users. It's all well and good to say that you've been using it for ten years and it works fine for you. But we also want to attract new developers, and a home-rolled scripting language is not exactly a selling point.
- Ability to use standard libraries and code samples.
- (Speculatively): Ease of porting. While AGS is clearly the bestest engine in the world, for various reasons some poor deluded sods occasionally decide that they'd rather use a different engine after all. (For example: Nelly Cootalot 2 in order to target more platforms.) Scripts written in a standard language could potentially be easier to port, particularly if the new engine use the same one (otherwise there are cross-compilers). This could be an argument for Javascript, which Unity3D supports a dialect of.
- As a consequence of this, using a standard language might make AGS more popular as a game prototyping tool.
At the same time, I agree that it's important to preserve as much of people's scripting expertise as possible, and make it as easy as possible to port ongoing projects (not to mention existing modules!), so I would favor a language with a syntax as similar as possible to AGS Script. That would probably be AngelScript or C# on Mono, although Javascript is also superficially similar. As to monkey's reaction, none of these options are Java-based.
Post by: Radiant on 15 Jul 2014, 20:46
Speed and upstream support seem like the most obvious ones to me.I've seen zero evidence that AGS has speed issues. In fact, I've done all kinds of crazy scripting within AGS (including writing first-person maze games and platformers) and based on this experience I'd suggest that AGS's speed is fine.
What Calin said. There's also (depending on the choice of language):The thing you're overlooking is that AGS's scripting language isn't some weird arbitrary custom design. Rather, AGS's language is, for the intent of learning it, pretty much identical to C++, one of the most commonly used languages in the world (granted, there are some C++ constructs that AGS doesn't support, but nothing that would be used by somebody learning how to program). This also means it's very close to C, C#, PHP, and JAVA; meaning that any novice programmer familiar with any of those can pick up AGS almost instantly, and can use tutorials and coding samples for any of these languages. By constrast, LUA is known to substantially less people.
As far as I've seen, AGS ports just fine to Mac, Linux, and Android already, so I'm not sure what else you'd want to port it to. And I'm not sure why anyone would want to use AGS as a prototyping tool; it's an engine for creating games, not a prototyping tool.
Now I grant that it would be nice to use better debugging tools and be able to import standard libraries, but converting AGS to some other language won't actually accomplish that. Rather, I'd be curious to see what specific examples of debugging and libraries people would need. I'm willing to bet that simply creating these would be way easier than swapping out AGS's scripting language to something else.
Overall, you're suggesting a huge sweeping change, requiring huge time investments with clear and obvious drawbacks, for only hypothetical benefits. That's not a good tradeoff.
Post by: Calin Leafshade on 15 Jul 2014, 21:51
I've seen zero evidence that AGS has speed issues.
The core engine dev team even admit there are speed issues. The compiler has absolutely no optimization at all which is especially noticeable in tight loops.
Post by: Radiant on 15 Jul 2014, 22:11
The core engine dev team even admit there are speed issues. The compiler has absolutely no optimization at all which is especially noticeable in tight loops.Ah yes, that same core engine team that states above that they'll quit if AGS changes to a different scripting language. Sorry, I don't see how you have much of an argument here; hundreds of game developers and 100000s of game players have no issue with AGS's speed.
Post by: Crimson Wizard on 15 Jul 2014, 22:17
Now, wait a minute... monkey_05_06 is not a "core engine team", he is a single person with his own opinion :). Also, I do not recall he ever mentioned slowness of AGS script.The core engine dev team even admit there are speed issues. The compiler has absolutely no optimization at all which is especially noticeable in tight loops.Ah yes, that same core engine team that states above that they'll quit if AGS changes to a different scripting language.
I had though, and my opinion is different (I am not saying "opposite" btw). Well, at least I would not quit just because of different scripting language. I guess monkey has his own long history with AGS Script, so he is sensitive when it comes to this topic.
Post by: Calin Leafshade on 15 Jul 2014, 22:52
Reference:
The AGS compiler, AFAIK, has no optimisation and uses no advanced CPU instructions.Unfortunately, that's true. It produces very formal sequence of instructions, mimicing how real x86 processor (IIRC) works: putting values to registers, getting them back, calculating, putting result to register, getting it back once again for other use, etc, etc., and every action is processed separately. I think it does at least about 3-5 things more than needed (http://www.adventuregamestudio.co.uk/forums/index.php?topic=47320.0) per each primitive operation.
This "formal sequence" makes things like loops very very slow.
I have benchmarked this and I reckon the Lua plugin, which has an extra layer of abstraction to deal with, is about 5-10 times faster depending on what you're doing (loops mainly).
Also this thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47320.0
So when talking specifically about the speed of AGS script, it is you that has no argument here, my friend.
When it comes to replacing AGS script, I am broadly for it but I understand that it's simply unlikely to happen due to the time involved.
Post by: Snarky on 15 Jul 2014, 23:11
Speed and upstream support seem like the most obvious ones to me.I've seen zero evidence that AGS has speed issues. In fact, I've done all kinds of crazy scripting within AGS (including writing first-person maze games and platformers) and based on this experience I'd suggest that AGS's speed is fine.
AGS clearly has speed issues. Whether the scripting language is the real bottleneck in most practical situations is admittedly more of an open question.
Quote
The thing you're overlooking is that AGS's scripting language isn't some weird arbitrary custom design. Rather, AGS's language is, for the intent of learning it, pretty much identical to C++, one of the most commonly used languages in the world (granted, there are some C++ constructs that AGS doesn't support, but nothing that would be used by somebody learning how to program).
Like for loops? (At least until the upcoming version.) Switch/case statements? Classes? And on the other hand, how many "pObj->method()" expressions do you see in AGS Script? Yes, AGS Script roughly resembles C++, but there are plenty of differences, and anyone trying to use a C++ tutorial to learn AGS Script isn't going to get past "Hello World!"
You can make an argument for AGS Script being less intimidating to newbies than Lua (though it is very popular for game development), but that argument doesn't really stand up against the other alternatives mentioned.
Quote
As far as I've seen, AGS ports just fine to Mac, Linux, and Android already, so I'm not sure what else you'd want to port it to.
http://unity3d.com/unity/multiplatform
The point wasn't about AGS supporting more platforms, but making it easier to move game logic between AGS game builds and builds in other engines.
Quote
And I'm not sure why anyone would want to use AGS as a prototyping tool; it's an engine for creating games, not a prototyping tool.
A game prototyping tool. I can see ways in which it would come in handy, but it's a pretty speculative use-case, so let's not argue about it.
Quote
Now I grant that it would be nice to use better debugging tools and be able to import standard libraries, but converting AGS to some other language won't actually accomplish that.
Well, switching to a standard language would allow us to use off-the-shelf tools and libraries, so it would accomplish that.
Quote
Rather, I'd be curious to see what specific examples of debugging and libraries people would need. I'm willing to bet that simply creating these would be way easier than swapping out AGS's scripting language to something else.
Perhaps the handful of specific features or libraries I could mention off the top of my head would be easier to reimplement (for example, let's start off with a library for handling database connections, proper XML parsing, graph layout, a comprehensive physics engine, a more advanced parser, an agent-based AI library, and better gesture/drawing recognition...), but that building every feature and library that would be useful for an adventure game would be quicker than slotting in a different scripting language I find highly doubtful. That's sort of the crux of the argument: While switching to a standard language may be more work up front, trying to compete with popular, well-supported languages on features, tools, libraries and performance is an insurmountable task, and no matter how much work people put into hacking it, it's still not going to be as good. (No offense to the engine devs, but without a large, expert, dedicated team focusing solely on the scripting language, it's just not.)
The same way AGS shouldn't rely on its own home-brewed graphics library or audio library, it really shouldn't have its own home-brewed scripting language. The only reason it does is legacy, and while it will no doubt be with us for quite a while still, it would be better to start the planning for its replacement earlier rather than later, in my opinion.
Post by: Radiant on 16 Jul 2014, 00:01
I have benchmarked this and I reckon the Lua plugin, which has an extra layer of abstraction to deal with, is about 5-10 times faster depending on what you're doing (loops mainly).That's really not the point. Just because certain things can theoretically be faster doesn't mean that AGS has speed issues. If you want pure speed, go program in assembly code. The question is whether AGS is fast enough for what it's meant to do (i.e. run adventure games, and possibly other games) and the answer is a resounding "yes".
Look, if you're going to make a case for fundamentally rebuilding AGS, start with practical arguments. As in, find some people who've been working on a large scale adventure game, and ask them what their actual issues were, and if they managed to create a game anyway despite the lack of a "switch" command. Ask if any of their players found that their low-resolution games were running inordinately slow on contemporary computers. Ask whether they found AGS hard to learn, and if they'd have had an easier time if its script had been based upon Turbo Pascal. Get a view of the real issues, not of hypotheticals.
Post by: Crimson Wizard on 16 Jul 2014, 11:19
Interpreters mainly do their internal job, their only connection to engine is registered engine API.
Post by: Calin Leafshade on 16 Jul 2014, 11:37
Post by: monkey0506 on 20 Jul 2014, 04:08
Post by: Crimson Wizard on 20 Jul 2014, 09:32
I'm trying to understand why. The engine already has reference counting and garbage collection for the built-in managed types, including DynamicSprites and dynamic arrays. These pointers can be included as members of user structs, which only exist as one instance, but are still cleaned up by the garbage collector. There are no known issues with pointer members of user structs. So where is the discrepancy when it comes to managed (dynamically allocated) user structs? Shouldn't the reference counts for pointer members still be updated, and the relevant objects freed if their reference counts reach zero? :-The problem is in changing reference counter.
The difference between two struct types - the ones "statically" and "dynamically" created - is that those statically created are "managed" by compiler. Compiler knows when to destroy them, and what to do with their data. IIRC when a struct instance is deallocated (deleted from local stack or global data), all reference's counts are decreased, but this is done by compiler (it writes certain script commands), because compiler knows the structure of data, it knows WHAT to decrease.
Dynamic arrays "know" that too, because they contain only one type of data (and specifically aware if this is pointers).
For dynamic user object implementation in the engine, there's no "structure", there's only a data chunk of given size. In order to know if this data contains references and where they are located in this chunk we need some kind of "type description".
Basically, this is it.
Here I explained how this may be done (for example):
http://www.adventuregamestudio.co.uk/forums/index.php?topic=49969.msg636492665
EDIT: Another possible way is to invent some kind of automatically generated destructor (created by compiler), which will do same work, but as a part of byte-code.
The compiler does not know WHEN to dispose object, so this will require engine to run a generated byte code by given address, or something.
EDIT2: I support the first solution. Furthermore, I'd even support changing how compiler/engine manage stack and global data, so that compiler would just tell engine which variable to dispose, and engine knew how to do that, instead of emulating x86 "pop stack" operations... (but this is another topic).
Post by: monkey0506 on 21 Jul 2014, 02:19
Post by: Calin Leafshade on 21 Jul 2014, 07:37
Post by: Crimson Wizard on 21 Jul 2014, 08:26
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.
Post by: monkey0506 on 22 Jul 2014, 17:20
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?
Post by: Calin Leafshade on 22 Jul 2014, 17:26
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 :">
Post by: Crimson Wizard on 22 Jul 2014, 21:05
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 :">^_^
Post by: Crimson Wizard on 06 Aug 2014, 15:27
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 (http://www.fltk.org/) for portable gui and SimpleINI library (https://github.com/brofield/simpleini) 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).
Post by: Calin Leafshade on 06 Aug 2014, 15:39
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.
Post by: BigMc on 06 Aug 2014, 15:43
Post by: Crimson Wizard on 06 Aug 2014, 15:55
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?
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.
Post by: Calin Leafshade on 06 Aug 2014, 16:00
Your other points are fair.
Also I agree that native widgets are better.
Another option is the Wx set which uses native widgets.
Post by: Crimson Wizard on 06 Aug 2014, 16:13
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.
Post by: Radiant on 06 Aug 2014, 16:54
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!
Post by: selmiak on 06 Aug 2014, 18:58
Post by: Calin Leafshade on 06 Aug 2014, 19:23
Post by: Alberth on 07 Aug 2014, 07:06
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.
Post by: Crimson Wizard on 07 Aug 2014, 08:49
Post by: Alberth on 07 Aug 2014, 11:30
Oops, sorry
Post by: Crimson Wizard on 10 Aug 2014, 21:41
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:
Post by: Gurok on 24 Aug 2014, 07:50
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.
Post by: Crimson Wizard on 24 Aug 2014, 11:57
https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...331_runtime_type_information?expand=1This is very nice, I am going to check this out today.
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.Just being curious, why was it bumped? I probably missed this.
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.
Nevermind, I think I got this.
Post by: Crimson Wizard on 24 Aug 2014, 13:41
1. RTTI should not be stored in Script objects, but in a global struct, or inside a global object. By "global" I mean not necessarily literally 'global' in C language, but the one persistent and accessible all the program time.
Why: the managed object must keep the reference to Type, - either a pointer, or numeric Id, - all the time until its deallocation. If it is a pointer - we can't tell if the script we took this reference from will be available when the managed object is destroyed. If it is a numeric id - the managed object class does not have any reference to current (or any) Script (and should not have, because its illogical), therefore it won't know where to take type info from.
Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts
I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.
1b. You must not change how existing script commands and their arguments work, i.e. SCMD_NEWARRAY, because thus you will break compatibility with older scripts.
You may only do the compiler / serialization part. I can take care of the engine part after the compiler will be saving proper data.
2. Maybe we should start using std::vectors for expanding arrays, otherwise we will have to write "expand" function for every new type/array we put into program.
We are moving towards converting all the code to C++ anyway.
3. I have a thought that maybe we should allow to call "new" on any struct, even ones without "managed" keyword, because there's really no difference. What makes it managed is whether it is created on stack/global data or with "new" keyword. I would like to hear what others think about this.
EDIT: I investigated a bit more, and I see that the sym table actually stores only symbols from currently compiled module + the headers it includes. Something has to be done with this.
The problem is, that the object may be allocated in a room script, and then assigned to global variable. If we assign an Id of a type stored in the RTTI table of a room script, then we may loose this info after room was changed.
This means that the best way to achieve what we need is to keep a global sym table.
EDIT2: There's still a chance that, since module headers are always included in one order, the ids of types declared in upper headers will remain the same... meaning it can work, for starters.
Still this implementation would require managed object to lookup the "current script" for type info when it is about to deallocate, which is not good.
Post by: Gurok on 24 Aug 2014, 14:04
The issues I found:
1. RTTI should not be stored in Script objects, but in a global struct, or inside a global object. By "global" I mean not necessarily literally 'global' in C language, but the one persistent and accessible all the program time.
Why: the managed object must keep the reference to Type, - either a pointer, or numeric Id, - all the time until its deallocation. If it is a pointer - we can't tell if the script we took this reference from will be available when the managed object is destroyed. If it is a numeric id - the managed object class does not have any reference to current (or any) Script (and should not have, because its illogical), therefore it won't know where to take type info from.
This is really hard, but I'll try. Copying the type information to the managed object when it's constructed would also solve the problem.
Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts (I guess this is what it does now?).
I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.
This feels a bit wrong to me, only because a game author would need to take this into account. e.g. He/she might need an alternate object management system just in case script_rtti.dat is deleted. I would prefer that we incorporate it into the main output file or add a flag when managed user objects are used so that the resultant game won't start without the script_rtti.dat file present.
1b. You must not change how existing script commands and their arguments work, i.e. SCMD_NEWARRAY, because thus you will break compatibility with older scripts.
Oops. I take it I screwed up with the changes to read the size of the object. :-[ I'll fix that. Where/how should we embed the ID of a type in the compiled script then?
EDIT: My feeling was that we could pass the ID instead of the size to SCMD_NEWARRAY and SCMD_NEWUSEROBJECT, but use the file format to determine how it behaves (if < 90, treat it as size otherwise treat it as an ID)
You may only do the compiler / serialization part. I can take care of the engine part after the compiler will be saving proper data.
2. Maybe we should start using std::vectors for expanding arrays, otherwise we will have to write "expand" function for every new type/array we put into program.
We are moving towards converting all the code to C++ anyway.
I can use those. No problem.
3. I have a thought that maybe we should allow to call "new" on any struct, even ones without "managed" keyword, because there's really no difference. What makes it managed is whether it is created on stack/global data or with "new" keyword. I would like to hear what others think about this.
Ummm, that might get messy when people wonder why they can't return a struct created on the stack. Or wonder how to convert from stack variable -> heap variable. I kind of like the object management system the way it is. It's clunky, but it alleviates potential problem areas.
Post by: Crimson Wizard on 24 Aug 2014, 14:08
Copying the type information to the managed object when it's constructed would also solve the problem.That would, but that's a clumsy solution. It's like copying virtual table to every instance of a class instead of referencing one via pointer.
No, no, you seem to misunderstand what I mean. The script_rtti.dat will be inside game package, as well as all the other files.Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts (I guess this is what it does now?).
I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.
This feels a bit wrong to me, only because a game author would need to take this into account. e.g. He/she might need an alternate object management system just in case script_rtti.dat is deleted. I would prefer that we incorporate it into the main output file or add a flag when managed user objects are used so that the resultant game won't start without the script_rtti.dat file present.
Every script is a separate file too, and deleting them would screw the game anyway.
Game author would not need to worry at all, because this file will be added to final package automatically.
"Game data version" only refers to main game data inside the game package (ac2game.dta) - the one that describes the game generally.
EDIT:
EDIT: My feeling was that we could pass the ID instead of the size to SCMD_NEWARRAY and SCMD_NEWUSEROBJECT, but use the file format to determine how it behaves (if < 90, treat it as size otherwise treat it as an ID)That's possible, but I was thinking that in the future we won't need to use SCMD_NEWARRAY at all, SCMD_NEWUSEROBJECT could take care of arrays too (with some more info maybe). In such case SCMD_NEWARRAY will be used only for older scripts.
Post by: Gurok on 24 Aug 2014, 14:13
No, no, you seem to misunderstand what I mean. The script_rtti.dat will be inside game package, as well as all the other files.Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts (I guess this is what it does now?).
I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.
This feels a bit wrong to me, only because a game author would need to take this into account. e.g. He/she might need an alternate object management system just in case script_rtti.dat is deleted. I would prefer that we incorporate it into the main output file or add a flag when managed user objects are used so that the resultant game won't start without the script_rtti.dat file present.
Every script is a separate file too, and deleting them would screw the game anyway.
Game author would not need to worry at all, because this file will be added to final package automatically.
"Game data version" only refers to main game data inside the game package (ac2game.dta) - the one that describes the game generally.
Okay, let me try building a global table instead and get a commit up when I think it's ready for review again. I have a better idea of what to do now.
Post by: Crimson Wizard on 24 Aug 2014, 14:18
EDIT: I was thinking about this more... that might be actually not easy to work with global RTTI table, because the Editor does not recompile all scripts every time, neither keeps them in memory. Some idea is needed here.
One of the possible solutions is to keep RTTI tables in every script as you do now, but with type names (string ids). Engine might have a map of types (with string as a key) and add types to global table as scripts are loaded.
When user object is created, engine will map script own type index into global string key.
Not the perfect solution, but may work for starters.
Post by: Gurok on 25 Aug 2014, 02:28
We can't really do a global table because each room is a separate compilation unit. We could perhaps serialise the script-specific table as we are now, but read it back when producing final output (regardless of whether the room was compiled) in order to create a global table. Seems cumbersome and difficult to do. I much prefer the suggestion you made of using a string at runtime. Perhaps the struct name with a script name as a qualifier, e.g. GlobalScript::Weapon
One thing I'm not clear on. To make my proof of concept work, I substituted a type ID for the "size" parameter in SCMD_NEWUSEROBJECT. This allowed SCMD_NEWUSEROBJECT to correctly identify the type of the object it was creating. How do you propose we pass this information to SCMD_NEWUSEROBJECT when the primary type identifier is a string?
EDIT: Regarding my last question, would you be happy if we:
- Use the script-specific type ID only when an object is created
- At that point, create an entry in the global type table using the true name of the type (e.g. GlobalScript::Weapon) if it doesn't exist
- Have the destructor use the global type table to find the type info when deleting the object?
Because I think that could work. I hope that's what you were getting at and I'm not completely off track.
EDIT:
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.Just being curious, why was it bumped? I probably missed this.
I think I bumped it when new commands (do, for, break, continue) were added. In retrospect, it was probably not a file format change, but it would have been weird to have an earlier interpreter open it.
Also, I need to look into how exported types are loaded when a script is compiled. It's my understanding that the script compiler loads all previously exported symbols and then compiles the script (making it possible for a type ID to refer to types declared in previous modules). I'm not sure if my new "rtype" field gets populated at that time, however.
Post by: Crimson Wizard on 25 Aug 2014, 09:04
We can't really do a global table because each room is a separate compilation unit. We could perhaps serialise the script-specific table as we are now, but read it back when producing final output (regardless of whether the room was compiled) in order to create a global table. Seems cumbersome and difficult to do.There's an alternative to keep RTTI in a project folder all the time (same as room CRMs are kept in project), and read it in memory before any compilation.
Update it when a script is compiled. Since type ids have script module tag in them, program will know which types to update / remove (if module was removed). Then save it back to file.
One thing I'm not clear on. To make my proof of concept work, I substituted a type ID for the "size" parameter in SCMD_NEWUSEROBJECT. This allowed SCMD_NEWUSEROBJECT to correctly identify the type of the object it was creating. How do you propose we pass this information to SCMD_NEWUSEROBJECT when the primary type identifier is a string?What I suggest is to use solution consistent with function binding. Function binding works this way: every script has a list of functions it uses, and to call them it puts their local index in the byte code. Engine uses this local index to look up in the local table and find function name, under which it is registered in global table.
Similarily, regardless of whether we have a global RTTI, or a table in every script module, the numeric id will mean the index in local types array. This will be array of either full type descriptions, or only their names.
In any case - use numeric id to acquire string id from module's array of types, then this string is used further to find persistent type description from global table.
If we keep type infos in the module, the global table must be filled on script load, to get the types prepared.
EDIT: Regarding my last question, would you be happy if we:You mean - does not use it for arrays?
- Use the script-specific type ID only when an object is created
I guess we would actually need them for arrays too, because arrays may store user objects. This is not allowed now, but if we make this, it may be.
However, my idea was to merge SCMD_NEWUSEROBJECT and SCMD_NEWARRAY at some point in the future. The SCMD_NEWUSEROBJECT could take two arguments: a type id, and number of elements. If second arg is > 1, then array is created.
In such case SCMD_NEWARRAY will remain for backwards-compatibility only.
The problem here is that we need to somehow distinct array of pointers to struct and array of structs. I guess this is where "managed" flag may come of use. But I'd rather think a bit more about this.
Post by: Crimson Wizard on 27 Aug 2014, 20:30
Telling this just in case.
Post by: Gurok on 27 Aug 2014, 23:57
@Gurok and others, unfortunately I was pretty busy lately, and will be even more busy in next 5-10 days on my job (we are having deadlines here too :)), so if you post new variant of RTTI feature I may not be responding for some time.
Telling this just in case.
Not a problem, CW. We are all busy with other commitments and jobs. I find it hard to squeeze in time too.
Post by: Crimson Wizard on 08 Sep 2014, 22:54
(I should have probably done this much earlier).
Are there any objections to this? If not I'll just create a new "develop-3.4.0" branch right where "develop-3.3.1" now is, and the latter may be safely deleted a bit later when everyone gets updated.
Post by: Gurok on 08 Sep 2014, 23:42
I have a proposal to rename our development branch to 3.4.0 now, because it has bigger features now (improvements to scripts mostly), and probably will have more, while X.X.N+ versions are meant for very minor improvements and fixes. I was supposed to release a new update to 3.3.0 containing restored letterboxed mode and few other hot-fixes, now I am thinking about actually calling it 3.3.1, and using 3.3.2 number if more hotfixes are required.
(I should have probably done this much earlier).
Are there any objections to this? If not I'll just create a new "develop-3.4.0" branch right where "develop-3.3.1" now is, and the latter may be safely deleted a bit later when everyone gets updated.
No objections from me! Makes a lot more sense than the 3.3.0 Hotfix N approach.
Post by: Gurok on 10 Sep 2014, 13:53
Firstly, in the development branch, I've found a problem with the most recent commits for D3D9 front buffer / back buffer stuff. I have a game project with sprite 0 set to:
http://i.imgur.com/ADz2Dtm.png (http://i.imgur.com/ADz2Dtm.png) (don't ask why)
The editor fails to load it, complaining that it can't find sprite 0. If I try to run the game data file with the most recent engine, I get a similar error on startup. This doesn't occur when I go back to a commit before 67de2af. Haven't fully investigated it yet. (I'm not asking you to fix it! Just documenting it!)
Secondly, my current large project has too many scripts (according to AGS):
(http://i.imgur.com/9ZPRjcP.png)
I have exceeded MAX_SCRIPT_MODULES. I couldn't believe the error when I saw it. I don't think I'm doing anything wrong. I've got 1 module per extension (e.g. Mouse, Character), and a few extra modules for custom things in "Library", 1 module for each inventory item, global object, character and GUI. Okay, so I'm a bit of a neat freak, but is that an unreasonable way to organise things? (Might be the wrong forum.)
I checked your earlier 3.4.0 branch and there's no mention of MAX_SCRIPT_MODULES as a limit. I think increasing this from 50 to 200 would be sufficient for my needs. We could look at removing the limit in the future.
I monitored memory usage. With max=50, my RAM usage is 30.7MB. With max=200, my RAM usage is 30.8MB. I don't think upping the limit is a huge concern.
Edit: If my request isn't unreasonable, here's a pull request for that script module limit: https://github.com/adventuregamestudio/ags/pull/179
Post by: Crimson Wizard on 10 Sep 2014, 14:07
The biggest problem I met were room areas limit, that could not be safely removed without completely changing savegame format.
Post by: Crimson Wizard on 10 Sep 2014, 15:34
Post by: Gurok on 11 Sep 2014, 11:06
Edit: I can PM you my game project on request, but it's pretty big!
Edit 2: I just submitted the pull request for removing the 50 script limit. Ohhhhh yeah!
Post by: Crimson Wizard on 12 Sep 2014, 21:08
Post by: BigMc on 19 Sep 2014, 18:30
I have a proposal to rename our development branch to 3.4.0 now, because it has bigger features now (improvements to scripts mostly), and probably will have more, while X.X.N+ versions are meant for very minor improvements and fixes. I was supposed to release a new update to 3.3.0 containing restored letterboxed mode and few other hot-fixes, now I am thinking about actually calling it 3.3.1, and using 3.3.2 number if more hotfixes are required.
(I should have probably done this much earlier).
I don't like these +hotfix version numbers. Why don't you increase the third number for every minor release? It's not like there are not enought numbers, after 3.3.9 there's still 3.3.10 and people don't really care if the changes are minor or very minor. Having a release hotfix-2, then update-1 and then hotfix-3 means the versions cannot be sorted. That makes every Linux package maintainer crazy and also other people won't know if update-1 or hotfix-3 is higher.
Post by: Crimson Wizard on 19 Sep 2014, 19:01
I don't like these +hotfix version numbers. Why don't you increase the third number for every minor release? It's not like there are not enought numbers, after 3.3.9 there's still 3.3.10 and people don't really care if the changes are minor or very minor. Having a release hotfix-2, then update-1 and then hotfix-3 means the versions cannot be sorted. That makes every Linux package maintainer crazy and also other people won't know if update-1 or hotfix-3 is higher.
This is true, I just got carried away with this. Sometimes I am getting fixated on using some "scheme" and cannot leave it.
And people around seem too shy to make me stop :tongue:.
I will call next hotfix 3.3.1, and put an explanation in the topic so that people know that it is not Gurok's 3.3.1, but a further update of 3.3.0.
Post by: BigMc on 19 Sep 2014, 19:30
Post by: Crimson Wizard on 19 Sep 2014, 19:40
And while we're at it... Since you are releasing preview binary releases (alpha,beta,rc..), I think it would be a good idea to give them also proper version numbers. The approach that is most compatible with sortability of versions is to give odd numbers to development versions and even numbers to stable releases, e.g. call the development branch now 3.5 and let that turn into the stable release 3.6. This approach is for example used by Allegro and the Linux kernel.Hmm, we are doing this, just changing the last (fourth) build number before every update (using odd numbers for development branch). Is not that enough?
I am afraid that unlike developers most common users will be confused if main numbers will be jumping between release versions, will look for intermediate versions etc.
Post by: BigMc on 19 Sep 2014, 20:01
It's all pretty clear isn't it?
I think most users get AGS from the homepage where only stable releases are found or not?
Post by: Crimson Wizard on 19 Sep 2014, 20:17
Look for example at the Allegro homepage: http://alleg.sourceforge.net/
It's all pretty clear isn't it?
Don't we have same thing know, there's 3.3.0.* with hotfixes and 3.3.1.* in development? Is there a big difference?
E: I need to think a bit about this....
I think most users get AGS from the homepage where only stable releases are found or not?I mean, we will have to explain why the previous version was 3.4 and new one suddenly 3.6. Your examples are both low-level developer tools, and AGS is a common user product.
Post by: BigMc on 19 Sep 2014, 20:38
Post by: Gurok on 20 Sep 2014, 02:02
Post by: Crimson Wizard on 20 Sep 2014, 02:03
As for "another 3.4.0", I doubt it is really used for any project right now. It was an experimental build with temporary name.
Post by: monkey0506 on 20 Sep 2014, 04:15
I mean, we will have to explain why the previous version was 3.4 and new one suddenly 3.6. Your examples are both low-level developer tools, and AGS is a common user product.
I agree with this. I think that in general the way the versioning is controlled now is appropriate. The way it's worked thus far, the first version number has actually corresponded exactly to major editor revisions (e.g., complete IDE rewrite). The secondary version number is generally increased when there are major changes to the editor or engine (script API changes, major bugfixes, etc.). The tertiary version number is then reserved for more minor changes, minor bugfixes, minor feature fixes, and the like. This all applies directly to the public release version numbers, and I think it works very well. The fourth version number being used to differentiate between development revisions (using even numbers for stable releases) also serves its purpose.
That being said, it may not be immediately obvious how the versioning works. Is this actually documented explicitly anywhere?
Post by: BigMc on 20 Sep 2014, 09:40
The way it's worked thus far, the first version number has actually corresponded exactly to major editor revisions (e.g., complete IDE rewrite). The secondary version number is generally increased when there are major changes to the editor or engine (script API changes, major bugfixes, etc.). The tertiary version number is then reserved for more minor changes, minor bugfixes, minor feature fixes, and the like. This all applies directly to the public release version numbers, and I think it works very well.
That would all stay the same with the scheme I proposed, except that builds coming from a development branch would have the secondary version odd (and maybe a beta, rc, wip or whatever suffix to clarify) and builds from a stable branch have an even secondary version. Both increase once the development branch turns into a stable branch, i.e. a new major stable version is released.
Post by: Crimson Wizard on 20 Sep 2014, 15:22
The fourth version number being used to differentiate between development revisions (using even numbers for stable releases) also serves its purpose.It appears to me that it's not used that properly; in fact I started to use it so after incorrectly understanding BigMC's suggestion when he made it first time (about a year ago).
That being said, it may not be immediately obvious how the versioning works. Is this actually documented explicitly anywhere?This might have been mentioned in few topics, I found an indirect reference here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0
And also this was the very first thread we discussed version numbers:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=47581.0
//-----------------------------------------------------------------------------
Now, I took some time to think this over, and I should say that I saw logic in what BigMCs suggestion. Of course, that may be uncommon for AGS users.
Following is my IMHO.
What do we need version for? To let people know their order and meaning (major change, minor change).
Every public release, whether alpha, beta or final, should have distinct version visible to users (i.e. no hidden numbers, internal tags).
If we are working on version 1.2 and make beta releases, we must change version somehow, for example add the third number: 1.2.1 is first beta, 1.2.2 is second beta, and so forth.
When we release a final/stable version, we need to somehow emphasize that this is the next stage of a program, not WIP/beta anymore. If we just increase auxiliary number one more time (e.g. make it 1.2.3), we won't achieve this, because it will blend with WIP versions.
For the very first alpha/betas developers often use numbers starting with 0 (e.g. 0.5.1); however, this can hardly work for the next versions.
AGS has a tradition of X.Y.Z stable releases (generation, major, minor), but also has the fourth number, which was used only for internal purposes. In the times of SVN repository this number was probably equal to SVN revision (commit) number. Today it lost its meaning, because:
- in Git there's no commit number, there's commit hash (which lets to identify particular commit, but, unfortunately, does not tell anything about its order);
- public releases require a change of one of the "public" numbers;
- developers and repo users does not need this "internal" number either, because they know which commit they used to build the program.
- when there are at least two branches, both of which may have public updates, it is impossible to have a single sequence of "revision" numbers in a proper order.
//---------------------------------------------------
The conclusion:
1. Version should visibly change at every public release. By "visibly change" I mean that the end-user should be aware of numbers, and their meaning and order should be clear to him/her.
2. We would benefit from distinct change in numbers when WIP version changes to stable version.
3. The fourth version number lost its meaning and should be either removed, or utilized differently.
4. The upcoming 3.4.0 version may be the starting point of introducing new version numbering (whichever is chosen).
//---------------------------------------------------
What is the solution referenced by BigMC? It is to make the version number increase every time we move from stable to WIP and back to stable. For example:
3.4 is stable version and 3.4.* are stable version updates
3.5 is a WIP version and 3.5.* are WIP updates; when 3.5 is completed, it is changed to stable 3.6.0, and next WIP is 3.7.0 (started simultaneosly).
Optionally, if we are using three numbers for stable release and fourth number for updates:
3.4 is a major stable version and 3.4.0.* are stable version updates
3.4.1 is a minor WIP version and 3.4.1.* are its updates. When 3.4.1 is completed, it is changed to stable 3.4.2, and next WIP could be 3.4.3.
3.5 is a major WIP version (same as above), which will end as 3.6, the next major stable version.
What are alternative solutions? I know only one: stable version updates follow up WIP versions, for example:
3.4.0 is the alpa, 3.4.1, 3.4.2 are betas, 3.4.3 is the first stable release. This won't cause "jumps" between stable releases, but change between WIP and stable will be less distinct. Whether it is a problem or not is a subjective question, IMO.
EDIT: if we use fourth number, then, for example, 3.4.0.0 -> 3.4.0.4 are betas and 3.4.0.5 is first stable. This keeps the first three numbers the same as end-user would expect, and utilizes fourth number as "developer update". But it must be included to package name.
Actually, thinking more about this, I like four-numbers sequence better.
What do you think?
Post by: Alberth on 20 Sep 2014, 16:53
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.)
Post by: Crimson Wizard on 20 Sep 2014, 17:22
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 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 ?If a bug is found in older version, and the users using it can't rightly update to bigger version (for example, it has some compatibility problems), then there's another branch created, e.g. "2.6.5", branching from last 2.6.4 commit in "master"; the bugs are fixed there, and the 2.6.5 update is released. The changes from 2.6.5 can then be merged to latest master.
(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.)
Hypothetically, if there are other intermediate versions that have to be updated, similarily we may branch out of correspoinding point in history and merge the fixing branch there.
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.
Post by: Snarky on 20 Sep 2014, 17:44
As for Alberth's objection about people "not understanding" that a later version isn't always better, it's common for open source projects to have a link to a stable release (which is what the default download button gives you) as well as to a wip version (whether it's called a beta, a development branch or whatever) with a higher version number. As long as they're clearly labeled and the default is set correctly (and the stable release doesn't lag the beta by too much), it shouldn't be a problem.
Post by: Alberth on 20 Sep 2014, 18:19
I am aware of that.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 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:Ah yes, you'd forward-port the fix to the newest releases too. That would make sense.Code: Text
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.
Post by: Crimson Wizard on 20 Sep 2014, 18:26
Post by: Crimson Wizard on 21 Sep 2014, 13:26
Although I honestly see a certain benefit of BigMC's suggestion I am being held back by the consideration that this will be very uncommon for the most users of AGS.
My own personal opinion is to continue using same versioning scheme for now, but include fourth number to the public release (package) name as "development number" and reset it to 0 every time we change any of the first three. This way people would be able to clearly see the progress when we release intermediate WIP versions.
Of course, the "stage" releases, even fixing or updating existing versions, should have the third number changed (at least).
If we need to underline that the public release is WIP, we may add something to its package name (alpha, beta, rc), and stop doing that as soon as it reaches first stable version.
If later we will see that there are clearly problems with distinguishing between WIP and stable releases, we may consider using BigMC's suggestion, starting with 3.5 (which, conveniently, is a proper number for WIP version).
Regarding this
Number would be assigned in a release branch.Thing is that we start making "intermediate" WIP releases for public early in development, and we must number them somehow. IMHO choosing next "big" number (i.e. 3.5 after 3.4.* was released) is a logical thing.
(The highest number means "generation", and it rather supposes that we have rewritten a huge part of program from scratch. Such changes can't be applied on WIP branch with additions to previous version, because that makes little sense).
As for minor numbers, idea originally was to start developing them only when there's a need to quickly update one of the previously (recently or not) released version. Currently we have a "3.3.1" WIP, which is incorrect, and is actually my mistake breaking the rule I've proposed myself, and we plan to change it to 3.4.0.
Previously we've had a situation when we had 3.2.2 WIP version that was merged with more features, and we decided to not release 3.2.2, but change it to 3.3.0, and that is how it was finally released.
Post by: Calin Leafshade on 21 Sep 2014, 15:58
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.
Post by: Alberth on 21 Sep 2014, 16:09
Does it matter if it's uncommon for users?Do you honestly believe that given a choice between 3.5.5 and 3.4.2, all users will pick 3.4.2?
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.
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.
Post by: Crimson Wizard on 21 Sep 2014, 16:16
Also, unlike a user application like AGS, people don't generally install kernels themselves, they pick whatever their distribution provides.Well, to be honest, for AGS most people do install the version referenced from main website page. And when we post WIP versions on forum we warn that these are WIP.
I can't be sure whether they do or do not care what numbers are there...
E: Damn, I am too meek :). Now Calin made me doubt once again.
Post by: Retro Wolf on 21 Sep 2014, 16:25
I also remember talking to Adeel around the time of the second hotfix, he didn't know there was one.
We both spend a stupid amount of time on these forums.
Please don't take this as ungrateful, I appreciate the amount of work that goes into supporting this software.
Post by: Crimson Wizard on 21 Sep 2014, 16:26
These hotfixes need to be advertised better. I didn't know there was a third hotfix until I just happened to need to redownload AGS.Yes, this was my mistake, we will have a version change every time these are made from now on.
I also remember talking to Adeel around the time of the second hotfix, he didn't know there was one.
We both spend a stupid amount of time on these forums.
Post by: monkey0506 on 21 Sep 2014, 16:55
And that's about all that I can usefully say on that for now. :P
Post by: Crimson Wizard on 21 Sep 2014, 16:59
Post by: monkey0506 on 21 Sep 2014, 17:24
Post by: Sslaxx on 23 Sep 2014, 12:46
Ok, let's make current WIP version 3.4.0.0, keep incrementing 4th number as we make intermediate updates. When we will approach release branch, we may consider to change (increase) version, if it would appear that there's a problem with keeping it 3.4.Surely the fourth number could just represent hotfixes? So 3.3.0.3 is 3.3 hotfix 3?
Post by: Crimson Wizard on 24 Sep 2014, 18:28
Surely the fourth number could just represent hotfixes? So 3.3.0.3 is 3.3 hotfix 3?Right.
Just few thoughts on this new 3.4.0 version. I guess we have at least two core features that would determine it already:
1. Custom resolutions.
2. Dynamic user structs in script.
+ quite a few nice additions to both script language and API.
I believe that if we'd focus in completing these, we'll get a good "basis" for the next "official" release.
Other features of interest:
* Building game for multiple platforms;
* Try to fix/reimplement the threaded audio;
* ?
Regarding future development, and specifically full limit removal: there are many things that were either planned, or implemented in the experimental "develop" branch, that would require breaking backwards-compatibility. I mean savedgames format and (engine's) plugin API. If we won't change these, in time they will become a permanent headache.
The savegame format change would only hurt port-users, and only if they would migrate from older engine versions in the midst of playing particular game (which sould not normally happen).
Plugin API is a more serious task, also this will disable existing plugins for the new version. But regardless, I believe this must be done.
So, I was thinking, that maybe this 3.4.0 should be the last version that strictly maintains the backwards-compatibility.
Post by: monkey0506 on 25 Sep 2014, 04:54
* Building game for multiple platforms;
On that note, I have partially refactored building the data file out of the native code. I'll need to work on it some more (hopefully this weekend) and then I can incorporate it into the Linux build process which I've already streamlined into the editor code. It's currently not building correctly, though most of the data seems to be getting copied. Just need to review it and figure out what I've mucked up.
Post by: Gurok on 25 Sep 2014, 05:55
For 3.4.0, I have the following definites:
* Runtime Type Information table -- if I ever figure it out
* switch...case statement -- just need time to implement this, I know how the assembly should look
Aaaand lots of others in various states:
I would also like to present another tiny addition to AGS and see what others think. Currently in winsetup.exe, when choosing a language, the default is called Game Default. To me, Game Default doesn't tell the user anything about the language they're choosing. I would like to be able to optionally name the default language in the general settings of a project so that it could be listed in the dropdown like:
English (Default)
Deutsch
Magyar
What do you guys think? Is this silly? I would really like it because I plan to offer American English with British English as a translation (confusing at the best of times!). I thought I might be able to squeeze it in as we're overhauling winsetup.exe in 3.4.0 anyway.
Regarding limits, CW, can we merge stuff from the "no limits" branch of AGS where it won't break the save file and game file formats?
Oh, and monkey_05_06 I'm very excited about being able to target Linux from the editor! Would love it for 3.4.0
Post by: Crimson Wizard on 25 Sep 2014, 12:14
I think I'm late to the party with the version number thing but I'll give my opinion anyway. I don't think we need a fourth number. <...> When 3.4.0 is released, we can use the third digit for hotfixes. e.g. 3.4.1, 3.4.2, 3.4.3.Alright, we are getting confused again, and I realized I could cause it with my recent post, where I ... well, did something wrong.
Yes, right, as I said earlier, every public release of the stable version should have a new 3rd number. The 4th number is used for WIP intermediate releases, when the development takes longer times and we need to distinguish the stages when making demo/test releases. Practice showed that several people could use even those to compile their games.
Again: the 3rd number update means we reached next stable stage, while 4th number means we are still in the midst of development process, and the program may have incomplete things and features added for testing.
You could release 3.3.0 hotfix 4 as "3.3.2". We could mark 3.3.1 as abandoned. That way there's no confusion between it and the old develop-3.3.1 branch. It will just be like we skipped 3.3.1.If we care of confusion, this could cause more confusion by making people wonder why 3.3.2 does not have 3.3.1 features too. :)
But... alright. This has sense too. We would just need to add a comment about why the minor number was skipped.
* Custom speech rendering (like custom dialog rendering) -- would love it, but it's soooo complicated[/hide]Some design ideas here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48518.0
But that would require refactoring the speech functions very carefully.
I would like to be able to optionally name the default language in the general settings of a project so that it could be listed in the dropdown like:I agree, and I think this won't be complicated if you put the default language name in config file. For winsetup is not taught to read game data.
English (Default)
You could also add this to the game data too, so that it could be used with script API (i.e. ChangeTranslation would detect that you are demanding default language if you will pass its custom name).
Regarding limits, CW, can we merge stuff from the "no limits" branch of AGS where it won't break the save file and game file formats?That is what I was planning to do right after I finish with custom resolutions.
http://www.adventuregamestudio.co.uk/forums/index.php?topic=49969.msg636492480#msg636492480
I kept myself from doing this earlier fearing that this will cause merging conflicts with CR branch.
Post by: Crimson Wizard on 27 Sep 2014, 14:58
Maybe we could make a next alpha version from it. I'd rather have it tested tad more before merging my own pull request (https://github.com/adventuregamestudio/ags/pull/190). Of course, constructive critisism on code is welcome too.
Post by: Crimson Wizard on 29 Sep 2014, 11:38
Here's the commit I made a while ago with Custom Resolution dialog: https://github.com/ivan-mogilko/ags-refactoring/commit/f2e258124a9205725c565fda856313c0c3f811ac
Initially I wanted to use just Size for custom resolution property, but it was displayed as "Width=X; Height=Y" on General Properties pane, and I wanted it to be displayed as "X x Y" for aesthetic reasons.
Back then I was in a hurry and did not find better way than to create a new class, wrapping Size, and overriding "ToString" method.
Is there simplier way?
EDIT: I should probably ask differently. If I understand correctly, ToString is meant to display information on object state, rather than user-aimed text. How can make the property list display property value using some custom function rather than calling object's ToString?
Some attribute maybe? I am not very knowledgeable in this area.
Post by: Calin Leafshade on 30 Sep 2014, 10:13
then you need to decorate the property with the Editor attribute
I believe the sprite picker in the property grid is implemented this way.
Code: C
- class Foo
- {
- [Editor(typeof(FancyStringEditor), typeof(UITypeEditor))]
- public string Bar { get; set; }
- }
- class FancyStringEditor : UITypeEditor
- {
- public override UITypeEditorEditStyle GetEditStyle(ITypeDescriptorContext context)
- {
- return UITypeEditorEditStyle.Modal;
- }
- public override object EditValue(ITypeDescriptorContext context, IServiceProvider provider, object value)
- {
- var svc = (IWindowsFormsEditorService)provider.GetService(typeof(IWindowsFormsEditorService));
- if (svc != null)
- {
- using (var frm = new Form { Text = "Your editor here"})
- using (var txt = new TextBox { Text = (string)value, Dock = DockStyle.Fill, Multiline = true })
- using (var ok = new Button { Text = "OK", Dock = DockStyle.Bottom })
- {
- frm.Controls.Add(txt);
- frm.Controls.Add(ok);
- frm.AcceptButton = ok;
- ok.DialogResult = DialogResult.OK;
- if (svc.ShowDialog(frm) == DialogResult.OK)
- {
- value = txt.Text;
- }
- }
- }
- return value;
- }
- }
Post by: Crimson Wizard on 06 Oct 2014, 12:08
The class you need is UITypeEditor
then you need to decorate the property with the Editor attribute
I believe the sprite picker in the property grid is implemented this way.
I could not do this with UITypeEditor alone, because I need the property type to be Size, not string, and also I wanted to forbid user to type right in the property field.
I was able to do this with TypeConverter though.
Can someone check if it looks good?
https://github.com/ivan-mogilko/ags-refactoring/commit/742b9a47ac2a2516725be3823218179d1357cb88
I haven't had proper practice with C# for about two years now :(. Should reread some books perhaps.
For compatibility with demo CR builds I had to make a custom serialization selected by property name (didn't want to force all properties of Size type to use it). I think it needs some attribute to make a generic solution. I'll try this next.
Post by: Crimson Wizard on 16 Oct 2014, 14:00
I've already merged custom-res into 3.4.0 branch, there's just one minor issue that does not work well in the engine. I hope there will be next alpha release soon (maybe this weekend). It also contains unlimited controls on GUI for Knox :).
After this I am planning to devote time to further refactor/improve engine code, because there were already few wanted changes that could not be added easily because of complexity of the code.
Also look into fixing some old problems.
Regarding changing savedgame format. Earlier I mentioned that I would rather wait till another major version, but upon further consideration I realized that it won't hurt that much to make one in 3.4.0 (or simply extending save data made by this version if needed). Even if the 3.4.0 alpha is used to develop games, users won't be keeping savegames for a long time anyway, because their games are constantly modified.
Correct me if I missed something.
Post by: Crimson Wizard on 23 Oct 2014, 09:24
It is saved in the main project file. Now when I think about this, I find this somehow wrong, because it is not directly a part of project data, but description of its dynamic state (if you got my meaning).
There's already "Game.agf.user" file for storing user-related properties for the project (not sure it does anything, I think it is meant to save some data about integrated source control).
Could we create some kind of project state file in a similar fashion, and save project's dynamic state there?
I guess, if the file is not found, editor should always act as if LastBuildConfiguration is different from current one.
Post by: Gurok on 23 Oct 2014, 09:58
I believe that's the way the editor currently acts with regard to LastBuildConfiguration. I'd have to check.
I think it's just a case of moving it from one config file to another.
Post by: Crimson Wizard on 24 Oct 2014, 10:13
I'll take a look at this. Shouldn't be hard.The AGS serialization works in such a way that it saves every public property with "setter" into xml, without any other discretion.
I believe that's the way the editor currently acts with regard to LastBuildConfiguration. I'd have to check.
I think it's just a case of moving it from one config file to another.
If you would like to save property into different file instead, there should be some mechanism implemented, that would define the target config file for a property.
Alternatively, this property may be moved to a different class, that saves all of its contents to different config.
OTOH, when XML describes a property which no longer exists in a class, AGS raises "wrong version" error. Therefore, if any obsolete property is removed, such situation must be resolved to let open old projects.
Some time ago I made an attribute in case we would need to completely remove a deprecated property from some class:
https://github.com/adventuregamestudio/ags/commit/74d6f165e03b728006efc0b786518b044088f9bf
I do not know how you will deal with LastBuildConfiguration; but if you will want to remove it from the Settings class completely, you could use this attribute to suppress such errors, like this:
Code: C#
- [DeserializeIgnore("LastBuildConfiguration")]
- public class Settings : ICustomTypeDescriptor
E: I don't really have a big interest in designing editor code (engine is pretty much enough for me), so if anyone have better concept, please tell so.
Post by: Gurok on 28 Oct 2014, 12:26
Post by: Crimson Wizard on 28 Oct 2014, 21:06
http://www.mediafire.com/download/rd3dcx9kbq7k71d/test_audio_speed.zip
Could not resist :).
Thanks to Gord10 for this wonderful idea!
Post by: Gurok on 28 Oct 2014, 22:01
Post by: Crimson Wizard on 28 Oct 2014, 22:09
Hey CW, Game.agf.user is supposed to be used for "Interface to persist user-specific data to/from disk. This data will not be checked into source control". Does LastBuildConfiguration count as user-specific data or do you want a new file (e.g. Game.agf.state)? I am thinking that one non-source controlled file per project is really enough.I honestly don't know, just confused by the "user" suffix. IMO the project state and user settings are different thing, but I am not sure what this file was for. IIRC it was monkey_05_06's idea to create *.user file, maybe consult with him about this.
Post by: monkey0506 on 28 Oct 2014, 23:33
Quote from: Pumaman (http://www.adventuregamestudio.co.uk/forums/index.php?topic=34401.msg449765#msg449765)
Quote from: monkey_05_06Edit: BTW Chris, what is this Game.agf.user file that seems to have cropped up?
It's for storing any settings that are specific to you (the user of the AGS Editor) and not game settings.
At the moment it's only used to store source control information, but in future it might also contain which windows you had open when you closed the editor, etc.
Based on this, I would say it makes sense to keep this type of info in that file (since it's not really project data).
Post by: Gurok on 28 Oct 2014, 23:58
The .user file was not, in fact, my idea. 8-) It was implemented by CJ around AGS 3.0.2:Quote from: Pumaman (http://www.adventuregamestudio.co.uk/forums/index.php?topic=34401.msg449765#msg449765)Quote from: monkey_05_06Edit: BTW Chris, what is this Game.agf.user file that seems to have cropped up?
It's for storing any settings that are specific to you (the user of the AGS Editor) and not game settings.
At the moment it's only used to store source control information, but in future it might also contain which windows you had open when you closed the editor, etc.
Based on this, I would say it makes sense to keep this type of info in that file (since it's not really project data).
Oh fantastic. Thanks, Monkey.
Post by: BigMc on 31 Oct 2014, 21:44
If there are no version numbers reserved for development releases as in my suggestion then a version like 3.4.0.0 sounds like a stable release and all development versions before that can only be called 3.4.0.0-alpha1, 3.4.0.0-alpha2, 3.4.0.0-beta1 etc. Remember that version numbers should increase so you can't go back from 3.4.0.1-alpha1 to 3.4.0.0.
Also the tags don't have an "alpha" so they look like stable releases.
Post by: Crimson Wizard on 31 Oct 2014, 23:35
Mhh so now there are tags called v.3.4.0.0 and v.3.4.0.1 in the development branch. That's super confusing. What will be the version of the next stable release?It will be 3.4.0.something.
Also the tags don't have an "alpha" so they look like stable releases.Okay, I'll add alpha to them.
Post by: Gurok on 01 Nov 2014, 14:45
Post by: Crimson Wizard on 01 Nov 2014, 14:51
What's Release_MD in the build configuration list for the editor?It uses /MD compilation flag for Common and Compiler static libraries, which tells them to link runtime C++ library dynamically, as opposed to /MT which links them statically.
I had to change to /MD after we started to use STL, otherwise Common.lib caused linker errors when linking to AGS.Native.
/MT is still used for the engine.
Post by: BigMc on 02 Nov 2014, 07:51
3.4.0.0-alpha1
3.4.0.1-alpha2
You can get rid of either of the last two numbers. Either
3.4.0.0-alpha
3.4.0.1-alpha
or
3.4.0-alpha1
3.4.0-alpha2
would be fine. Or am I missing something? I like the last variant better.
Post by: Crimson Wizard on 02 Nov 2014, 13:27
Now the tags are:
3.4.0.0-alpha1
3.4.0.1-alpha2
You can get rid of either of the last two numbers. Either
3.4.0.0-alpha
3.4.0.1-alpha
or
3.4.0-alpha1
3.4.0-alpha2
would be fine. Or am I missing something? I like the last variant better.
The last number defines the consequent index of release. So it may be:
3.4.0.1-alpha
3.4.0.2-alpha
...
3.4.0.10-alpha
3.4.0.11-beta
...
3.4.0.25-rc
3.4.0.26-final
3.4.0.27-hotfix
Having all 4 numbers would be easier for me to understand its position in the history. So I'd rather keep it.
Post by: BigMc on 02 Nov 2014, 14:11
Post by: Crimson Wizard on 02 Nov 2014, 18:12
Ok but I thought we wanted to get rid of the final and hotfix suffices. So no suffix would correspond to a stable release.IIRC the problem I was addressing was that I was naming releases with suffixes only (e.g. 3.3.0-hotfix1, 3.3.0-hotfix2), instead of increasing visible version number.
As I see this, the numbers define unique index of the version, while suffix is an auxiliary description.
Post by: BigMc on 03 Nov 2014, 09:40
Post by: monkey0506 on 10 Nov 2014, 23:33
Is there any specific timeframe as to when the next alpha/beta version is expected? I know there's been some pretty significant changes since 3.4.0.1, so it would be good to have an "official" build for people to test out these new features. ;-D
Post by: Crimson Wizard on 11 Nov 2014, 01:10
Is there any specific timeframe as to when the next alpha/beta version is expected? I know there's been some pretty significant changes since 3.4.0.1, so it would be good to have an "official" build for people to test out these new features. ;-DNo, no specific timeframe, I am rather using "weight" of accumulated changes as a reference. And yes, I was going to make a new build, maybe in several hours.
Post by: Crimson Wizard on 11 Nov 2014, 11:37
How do I build the linux binaries for 32-bit and 64-bit? Maybe some instruction exists?
Can I take it from this archive (https://bitbucket.org/monkey0506/ags/downloads/3.4.0.2+linux.rar), or linux binaries must be rebuilt anew?
Post by: BigMc on 11 Nov 2014, 12:27
Post by: monkey0506 on 11 Nov 2014, 13:28
Post by: Crimson Wizard on 11 Nov 2014, 17:51
Yes, it's just the folders/files that the make_ags+libraries.sh script produces (copy the data folder, sans any game files). I can do a fresh build this afternoon if needed.Yes, please.
I am getting some errors for "cowbuilder" thing, I'll need more time to understand how all this works.
Post by: BigMc on 11 Nov 2014, 19:09
Post by: Crimson Wizard on 11 Nov 2014, 19:40
Which errors? Did you follow the instructions?I followed them up to the
Quote
# Create the (chroot) environments that will be used for building ags:I do not really understand what this means. Are they the exact commands I should type, or I must also add some custom parameters here?
# cowbuilder-dist wheezy i386 create
# cowbuilder-dist wheezy amd64 create
When I ran the first one, I get this:
Quote
ikm@ubuntu:~/git/ags$ cowbuilder-dist wheezy i386 create
-> Invoking pbuilder
forking: pbuilder create --logfile /home/ikm/pbuilder/wheezy-i386_result/last_operation.log --othermirror deb http://security.debian.org wheezy/updates main contrib non-free|deb http://ftp.debian.org/debian wheezy-updates main contrib non-free|deb http://ftp.debian.org/debian wheezy-proposed-updates main contrib non-free --debootstrapopts --keyring=/usr/share/keyrings/debian-archive-keyring.gpg --components main contrib non-free --debootstrapopts --arch=i386 --buildplace /home/ikm/pbuilder/wheezy-i386-base.cow --mirror http://ftp.debian.org/debian --architecture i386 --distribution wheezy --no-targz --extrapackages cowdancer
W: /home/ikm/.pbuilderrc does not exist
I: Logging to /home/ikm/pbuilder/wheezy-i386_result/last_operation.log
I: Running in no-targz mode
I: Distribution is wheezy.
I: Building the build environment
I: running debootstrap
/usr/sbin/debootstrap
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
E: Release signed by unknown key (key id 6FB2A1C265FFB764)
E: debootstrap failed
W: Aborting with an error
pbuilder create failed
forking: rm -rf /home/ikm/pbuilder/wheezy-i386-base.cow
Post by: BigMc on 12 Nov 2014, 05:08
http://marek.php5.sk/?p=150
Post by: monkey0506 on 12 Nov 2014, 05:51
Post by: Crimson Wizard on 13 Jan 2015, 10:14
For the last four or five years all I do is fixing old and usually ugly code. I do that on my fulltime job, and I do that in spare time with AGS. I feel like forgetting how to write a new and good one. Word "tired" can not describe this, I think "fed up" suits this best.
I am also not really good at working with low level code, like utility algorithms; I would really prefer using someone's library, but I have to hack the utility functions, like graphic ones, all the time in AGS. I feel like I am not doing what I wanted to.
I remember back in 2009 maybe, I wanted to make some games, but I wasn't able, and I have no free time now; while everyone around do that. So I grow even more jealous over time.
I know this may look like childish emotions, but I can hardly help myself.
:embarrassed:
Post by: Gurok on 13 Jan 2015, 12:27
I have honestly been sticking to the sidelines mostly because I want to speed along the release of the next version. I don't think I've committed anything recently that hasn't been a fix for a regression or a bug I've introduced. I would love to help with the magic pink transparency bug (which I assume is the cause of this tension), but I have no idea where to start.
Some people might say that the hardest part of making a game with AGS is just making a start. But I know for you it's more complicated. You feel a duty to the community to maintain AGS. It's true that without you it's harder, but if you need to take a break, please don't beat yourself up over it. And if you took a break to work on a game, I don't think people would greatly mind.
Post by: Crimson Wizard on 13 Jan 2015, 13:09
I would love to help with the magic pink transparency bug (which I assume is the cause of this tension), but I have no idea where to start.No, it is not a big problem on its own, I already know how to fix this.
But it just stresses me all the time that I am reimplementing something that is so common and might have been already implemented in much better way than I would be able to do.
Also the need to keep backwards compatibility always keep me wonder whether I must keep some buggy behavior to prevent breaking older games...
I really fail organizing the work process, and I keep postponing many breaking changes I was thinking of before, because I've lost belief in what I do here and reluctant to start new tasks.
Post by: Adeel on 13 Jan 2015, 14:38
Post by: Alberth on 13 Jan 2015, 21:03
Word "tired" can not describe this, I think "fed up" suits this best.Stop now is the only advice I can give you.
While it may feel wrong to give up, continuing isn't going to make it better.
Stop now, and do something else. Make a game (and just ignore all issues you encounter in AGS while doing that!), read a book, do nothing, write new shiny code in an unrelated project, whatever makes you happy again. Nobody in the community is going to be happy when you get fed up so much that you walk out (Including yourself is my guess after reading the responses, relieved yes perhaps, happy no.)
Once you cooled down enough to make sane decisions again, decide what you want to do, and if and how AGS fits in that. As you found out, the world has more problems and feature requests than you can manage. Heck, it has more than all developers in the world together can manage. There is no shame in choosing, it's essential to keep your sanity and happiness.
I survive by having 3 or 4 projects at most, and not playing a main role in all but one (anyone here for taking over FreeRCT? :D ) and jumping between them, but it's a personal thing. You will make a different choice, one that works for you.
Quote
and I have no free time now; while everyone around do that. So I grow even more jealous over time.You're a slave to yourself only.
Nobody has free time, they make it by not doing some things. I have time to write this reply because I don't enter or solve issues for a game script, I don't code the new worldgen window in OpenTTD, I don't code queuing in FreeRCT, I don't make tea, and several other things I can/should do. Other people making eg a game can only do that by not doing other things. You don't have free time, you make it.
Do I feel bad about not doing those things? yes.
At the same time I also feel happy being able to write this message, hoping it's of use to you. At the end it feels like a good choice, even if it is not a very productive one in terms of code or tea. This what it is all about, in my opinion.
Make choices based on what you want, rather than what others want, or what you think others want. Until they pay you, they don't own your free time. (I know it's way easier to say than to do, but you are really in control here. Nobody will come to your house and beat you up because you skipped a day or a week working on ASG, it's safe to do that, really.)
Quote
I know this may look like childish emotionsI think it's brave that you express it here in public. No need to feel embarrassed.
Quote
I can hardly help myselfHere you are wrong, you can make a different decision. I bet you hesitated before opening the new post window, typing the message, and pressing Post. Yet you decided to do it.
In the same way, you can hesitate yet decide not to code AGS for one evening. If that is too long, decide to stop coding an hour earlier than usual. That's how you help yourself. Stop doing bad things by deciding you don't do them. It's as easy and difficult as that.
(And here I am, hesitating whether I want the world to know I wrote this quite personal message...
Yet hoping you can use at least some of it, I decide to go ahead, type this line, and press Post.)
Post by: tzachs on 13 Jan 2015, 21:19
I don't want to make personal suggestions, your post feels more like blowing off steam than asking for advice, but on a practical level,
at least the bit about the stress you feel when making changes, this is something probably shared by all who touched the code.
A possible (albeit partial) solution for that would be to have a set of unit tests, which would give developers more confidence that they're not breaking anything.
Of course this would be a massive undertaking and will require maintenance of its own, and will probably take a lot of time until it bears some fruit,
so maybe we're better off staying at this junction, stressed out and overwhelmed. :~(
Post by: Atavismus on 13 Jan 2015, 23:47
Take a break, have some rest and some fun. :)
(we still have a common game doc ;))
@to the whole community:
We should launch a poll about keeping or not the backward compatibility.
To be true, I don't see why we keep it (I mean, people can do without it easily).
And I guess it will be far easier and faster for the dev team if we renounce to it.
What is your opinion guys?
Post by: Crimson Wizard on 14 Jan 2015, 00:22
And please, don't make polls just because I was depressed other day. It is not how these decisions should be taken.
Post by: abstauber on 14 Jan 2015, 07:34
Quote from: Crimson Wizard
I remember back in 2009 maybe, I wanted to make some games, but I wasn't able, and I have no free time now; while everyone around do that. So I grow even more jealous over time.Game creators and their games might bring a little happiness to a broader audience. But you engine coders make us game creators extremely happy :) It was like two birthdays stacked on each other, when 3.4.0.3 came out and included these dialog rendering improvements, a feature I've been hoping for since 2011.
Also if backwards compatibility is such a hassle, we should really discuss if it's still needed. I certainly do not need it.
Post by: Atavismus on 14 Jan 2015, 09:31
And please, don't make polls just because I was depressed other day. It is not how these decisions should be taken.Don't worry, it's not about you, it's about the engine.
I think about it since ages and even made a topic almost one year ago on the french forum.
http://adventuregamestudio.fr-bb.com/t2288-ags-et-retrocompatibilite-necessite-ou-frein-sondage (http://adventuregamestudio.fr-bb.com/t2288-ags-et-retrocompatibilite-necessite-ou-frein-sondage)
As abstauber said : "we should really discuss" about it.
Post by: Crimson Wizard on 26 Jan 2015, 10:05
The most interesting new feature that still needs to be complete is User Objects with managed pointers inside, which in turn requires adding RTTI to script data. I think that it should be a priority (in features field).
Other than that, I do not think that we need to add any major features there.
Gurok, you were working on that before. Do you feel like being able to continue?
I will be finishing few things I was planning, then I'll fully switch to fixing bugs and improving existing features.
Post by: Gurok on 26 Jan 2015, 10:14
- Support for variable declarations inside for loop initialisers (99% complete)
- Working out why AGD2's project has extra symbols when compiled under 3.4.0 (could be an unintended side effect of some other change)
To be honest, I've forgotten where I was up to, but I'll take a look at it during the week. I'm glad I saved the first pass in a Git branch.
I have been focusing on fixing bugs for some time now. I think most (90%+) of my recent commits have been fixes for bugs I've introduced :-[
Post by: Gurok on 29 Jan 2015, 03:42
Edit: To clarify, there will still be more pull requests incoming for regressions and/or bugs found by AGD2. I just don't have time to support even larger changes to the engine that I think would be required.
Post by: Crimson Wizard on 05 Mar 2015, 08:17
I need to make a list of draconian features that are still missing.
E: I was ill lately, so I stopped updating things, but I will be doing that again soon.
Post by: monkey0506 on 05 Mar 2015, 18:30
I have a week off of school, so I will try to take that opportunity to look at this.
Post by: arj0n on 05 Mar 2015, 18:36
Post by: RetroJay on 09 Mar 2015, 13:49
I have upgraded to 3.4.0 and thought that I may try to rebuild my game 'The Decorator' with it.
I understand that there are some changes to scripting commands but have I done this correctly.
Originally I had this.
Code: Adventure Game Studio
- SetSkipSpeech(2);
AGS 3.4 doesn't like this and the only thing I can assume it could be now is. :-\
Code: Adventure Game Studio
- Speech.SkipStyle = eSkipTime;
Is this correct?
Yours.
Jay.
Post by: RetroJay on 09 Mar 2015, 16:42
I have been working with 3.4 for the past week now and just don't like it. :(
I have gone back to 3.2.1 (Draconian) and feel as if I have just been reunited with an old friend. ;-D
Ok.
Forget what I said above, everything was just wrong with the world this morning and I decided to take it out on AGS. (roll)
3.4 is NOT horrible I just find it rather difficult to work with, at the moment.
I have decided to go back to 3.2.1.(Drac) though for now (sorry I just like it.) ;-D
I will check 3.4 out when it's officially released though.
Yours.
Jay.
Post by: monkey0506 on 11 Mar 2015, 18:27
There are definitely breaking changes, but the current version should be pretty stable by now in terms of actual bugs.
In an unrelated note, I've actually added compile errors to the DataFileWriter class (the new game compiler) for the instances where I had inadvertently removed them (too many dialogs, too many inventory items, etc.). I'm reinstalling VS 2008 right now (formatted the computer recently) so that I can rebuild and make sure that I haven't mucked anything up, then I'll put in a pull request for it.
Post by: RetroJay on 11 Mar 2015, 19:49
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.
Post by: an_epileptic_monkey on 29 Mar 2015, 22:30
...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!
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.)
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?
Post by: monkey0506 on 30 Mar 2015, 03:01
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...
Post by: Snarky on 30 Mar 2015, 09:24
Post by: nims on 12 Apr 2015, 12:39
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.
Post by: Crimson Wizard on 13 May 2015, 16:56
Post by: Crimson Wizard on 14 Jul 2015, 12:30
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 (http://www.adventuregamestudio.co.uk/forums/index.php?topic=44502.msg636515126#msg636515126);
+ 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.
Post by: Crimson Wizard on 14 Jul 2015, 19:20
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.
Post by: Crimson Wizard on 28 Jul 2015, 13:17
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.
Post by: Alberth on 02 Aug 2015, 18:07
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: [Select]
$ 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_REENTRANTIn 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.
Post by: Crimson Wizard on 02 Aug 2015, 20:42
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.
Post by: Alberth on 02 Aug 2015, 21:23