Moving to AGS 4.0 #448
Comments
|
Given the above plan and the separation between legacy functionality and what should be current, is it worth reverting the path finder change for "ags3" and only implementing it in the branch that is getting cleaned up? |
I guess this is possible, what are the issues with the new pathfinder? |
|
I'm pretty sure there is a large enough difference between the two that the final position of a character can be different; any scripts that are checking character position are going to potentially have different behaviour. Worst case, you get stuck in an infinite loop whilst waiting for a character to arrive. |
Well, this is not good. How come I did not think about this before. We need to restore old pathfinding then until there are ways to steadily replicate behavior with the new one. Do you know actual games broken by this? If so, could you open an issue please? |
|
I could see the difference on the MAGS game I was finishing, but I'd have to recreate the problem as I've changed the code to work around it. It was a check for distance, to bypass Character.FaceObject, when to match perspective the actual direction needed to be left or right, but Character.FaceObject would choose to face upwards. if (player.x + 100 < object.X)
{
player.FaceDirection(eDirectionRight);
}
else if (player.x - 100 > object.X)
{
player.FaceDirection(eDirectionLeft);
}
else
{
player.FaceObject(object);
}
With an object I was testing, on the new pathfinder I would always end up facing upwards, on the old pathfinder I would end up facing right. I've previously seen issues (a couple of years ago) with the old pathfinder, where it seemed the character would never reach the direction correctly. I think this is similar to the font scaling vs vertical offset, where all existing games are going to rely on the old broken behaviour, so the old pathfinding issues had never been fixed. I'll open a ticket when I can, but I think this sort of thing is a good example of why the legacy code should be dropped and what you have described above is a good idea. In fact I would support pretty much any level of breakage on AGS 4, if it would restore it as a contemporary tool. If it didn't load any previous projects, had a modified scripting system, and modified event system: I think there would be few complaints, given that there is no similar engine which doesn't have licensing or cost implications. |
|
Alright, I created ags3 branch at the latest commit we had, and then merged ags4 into master. What has to be done in nearest time:
|
|
@morganwillcock I think if the new pathfinder code isn't part of a 3.4 release, it might be worth reverting it. Do you have time to create a pull request to remove it or did you want me to have a try when I have time? |
|
For everyone in general: What new features are planned for AGS4? And how are we going to ensure new features are complete before going into master? |
New pathfinder is a part of 3.4.2 version which was already released for public testing.
E: To underline, it is not that big deal to keep it, since it does not impose any restrictions on saved data, but I'd rather do if it's feasible, since it really works faster than the old one. Plus there will be more people testing it.
Do not know if any were planned. I have some minor work in my personal repository, and few ideas I wanted to try after the situation around refactoring attempt is resolved to some degree. But nothing big atm. Or rather, I am not enthusiastic enough to make big plans.
Not sure what to say... same way as we do it now, requiring people do work in feature branch until it is tested and revised by other developers? |
|
We should discuss new features somewhere to make a list and value their merits and implementations. |
|
Having just made a game from start to finish (previously I've only ever worked on existing projects), I've now found a few things which I think aren't working properly, plus features that I thought would have been there but were missing. So I'm also keen on the idea of a list being somewhere, before I forget it all. In terms of pathfinder, it is probably worth checking that the problem is definitely with the old one, or at least validate the new one as correct, before implementing switching. If the new one did turn out to be incorrect, then eventually someone will want to introduce a third pathfinder and we'll start all over again. |
|
If the new pathfinder is slightly buggy, and ags3 will be left in maintenance mode, it might be better to just bite the bullet and remove it from the ags3 branch, leaving it only in master/ags4. |
|
My words probably don't carry much weight after I've over-promised and under-delivered too many times, but I'll just say my thoughts about this. When Chris Jones first open-sourced AGS, I petitioned the community pretty actively to get a communal effort in place to keep AGS development going. One of the things that I felt needed to be done was dropping backwards compatibility so that the engine could be property refactored into a totally clean codebase. Others argued that it should be done piecemeal. In the end, the crux of any OSS's development is the developers that are actually developing the code, so I don't mean to insult anyone's efforts. Rather, as I look back, I question why I never actually took the time to study the engine's code properly and figure out how it all fitted together. There's no accounting for the immeasurable benefit of @jjsat and especially @ivan-mogilko's contributions. Ultimately what I'm trying to say is I do believe that this is the right path for AGS's future. I'll even recant a stand that I once vehemently defended, and concede that "AGScript" as I've called it should also be replaced. The debate over that should take place elsewhere, but my personal thoughts to that end are that the recent portability improvements and easy yet powerful nature of C# make it a great candidate. I won't end my spiel with any promises that I'll just end up breaking, but I would like to thank all those who have consistently driven the development of AGS forward. This gives me hope that AGS will be able to continue on into the future. |
This comment was marked as abuse.
This comment was marked as abuse.
|
I think Squirrel is probably a close match for a direct replacement
|
|
If you are looking for user base input... Not that I have really done much
in AGS, but if I were too.. Squirrel script would be a better option for me
than LUA. I always found LUA to be difficult and complicated for a
simpleton as myself. Is there an option to allow two scripting languages
within AGS for the developer to chose from? Or would that just be too
complicated and stupid?
…-------------
Giuseppe DiPerla
Deep River, CT Congregation
Phone: 860-518-1500
Email: JDiPerla@GMail.com ; Giuseppe@DiPerla.com
Google Voice: 860-615-9428
On Fri, Jun 8, 2018 at 11:04 AM, Morgan Willcock ***@***.***> wrote:
I think Squirrel <http://www.squirrel-lang.org/> is probably a close
match for a direct replacement
squirrel's syntax is similar to C/C++/Java etc... but the language has a
very dynamic nature like Python/Lua etc...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#448 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB1wh1Z7MfaX9CkzdXX7TA0Bxpv0hgDOks5t6pJqgaJpZM4USHYX>
.
|
There was already a working Lua plugin for AGS (at least one big game was created with it), and experimental C# plugin for AGS. |
|
If you're gonna do a replacement, than choose C# as even most commercial game-engines are switching over to that, or something like javascript.
lua isn't much used anymore (to be honest, I only knew it from back when the first Cry-engine supported it).
But I agree, select a successful product, not go and try to create your own or a flavor which suits only 'you'..
…________________________________
From: rofl0r <notifications@github.com>
Sent: Friday, June 8, 2018 15:45
To: adventuregamestudio/ags
Cc: Subscribed
Subject: Re: [adventuregamestudio/ags] Moving to AGS 4.0 (#448)
concede that "AGScript" as I've called it should also be replaced
if you want to go into that direction, my recommendation would be to pick up an existing successful embeddable product such as lua, rather than trying to desgign and write yet another incomplete/buggy/underspecced language parser/interpreter/compiler.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#448 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABl1twewsVWLAL0tLYkXNsayw0jN0b4Kks5t6n_hgaJpZM4USHYX>.
|
|
Probably best to work out what will happen with the event handling before deciding on scripting options. I think (but may be wrong) that the existing Lua plugin was effectively reduced to a performance boost of AGScript, just a way to do more processing per step because the script processing is dictated by the configured game speed. Personally I'd suggest looking at separating input, render, and script events, and that will probably point towards a particular type of scripting language. If we end up with |
|
Regarding use of Lua plugin:
Hmm I would probably disagree, imo the benefit we get from some language is syntax, built-in capabilities, and being able to use popular "generic" libraries and it's not much relevant if engine exports high-level functions. (not sure what you meant by "never designed to be embedded") Also quite frankly I hope that regardless of high-level operations, it will also give access to low-level ones, so that any behavior could be customized. |
|
Yes, but if script access to low-level operations is restricted by the game speed, the engine will have to be making changes on your behalf to scroll a viewport or move a mouse cursor at 60Hz or greater. I would also prefer to have access to low level functions, but per rendered frame, not at the speed of the game logic. Having the viewport move by itself is an extreme example, but that is meant to raise issues with event handling and when/how a script would get access to move it manually, rather than be taken as a design suggestion. |
|
Oh, it was not clear to me that all that referred to update speed.
In other engines there is often a separation between render speed and game update speed. In that case you may subscribe to both render and update event. E: I still feel like may be not understanding what you mean quite well. Maybe we are thinking about different things? What do you mean by "speed of the game logic"? |
|
Oh, I think I got it. You mean, the speed at which minimal "step" is happening in AGS game, like animation delay ticks? |
|
Yes. I think the unique selling point of AGS is that the game runs at fixed frame rate (no delta time), which is why character movement always appears 'correct' (no moon-walking across the floor), but you would need to be working faster than (outside of) that if you want to smoothly manipulate the viewport. |
|
If the frame rate is fast enough (60 FPS) viewport scrolling should feel smooth even if it is in a fixed framerate, not so? I think the main problem that ags has in this regard is that there are no sub pixels. |
|
In my racing game made on AGS the game speed is default (40), yet the camera follows cars pretty smoothly. Someone even asked how did I make that, but frankly I did not do much, except for keeping all coordinates in floats and only converting when setting viewport. PS. I added a suggestion to separate event frequencies into #450 |
|
Potentially, could the built in timers be switched for 'event generators', and you have some by default (every render to the screen, every game step) and can also setup your own (global or per room). So if you want to do something on every 5th game frame you just look for the event instead of counting frames or continually resetting shared timers. Anyway that was just something that sprang to mind 5 minutes ago, what I actually wanted to ask was, can we add the removal of all legacy audio support to the to-do list? I'm pretty sure there are some bugs in the current audio system, and also some related inconsistencies on the ports, so looking at those would be easier when there is only one audio system involved. |
Yes, this is also something I'd hope to happen, but we need to make sure that new system API covers all use cases old one had, specifically being able to reliably reference clips by index (something you cannot do now, because index cannot be set by hand and IIRC may change when you reorganize clips in the project tree). Related talk: http://www.adventuregamestudio.co.uk/forums/index.php?topic=56079.0 |
|
Alright, I'll take care of the removal of the legacy audio support. |
|
Is there any way I can get the ability to tag my own issues with "AGS 4"? I wanted to open some issues where I think the solution is a change of behaviour (so most probably AGS 4 only for a fix). I could just include AGS 4 in the titles if no-one minds the possibility of renaming them, if they become relevant to AGS 3. |
I gave you write perms to this project, my impression is that's only way. Please check if you may work with labels. |
|
I find Squirrel to be an interesting suggestion (I had never heard about it before), here is why: |
|
Something that was very briefly discussed above, but not pushed through, is the sub-pixels capabilities. It's not something innocuous. Here, it has been devised only from the perspective of a smooth scrolling, but it applies to many aspects of the engine. The question that was asked in a previous comment was "can the viewport update keep up with the game's framerate?". Ivan said "yes", but tzachs implied that even if it's properly refreshed, then it can still look clunky on low-res games, because of the absence of sub-pixel capabilities. What that means is that it doesn't matter if the viewport can be refreshed fast enough : if the pixels are huge, then the move will look like clunky, like it's skipping frames. For history's sake, here is what I remember: Chris Jones once tried to introduce sub-pixel capability -- at some point, there were "room coordinates", "screen coordinates", but also some sort of absolute coordinates, ranging from 0.0 to 1.0 (or am I mixing up with ye olde Visual Basic? It's alzheimer, guys, I'm telling you). The important point is : this was attempted, then dropped because it was confusing people. In a way, it's still confusing people when it comes to game resolution settings : people get confused with the game's native resolution, the scaling, the physical screen's resolution, etc. What I'm trying to say is : I would love if there were sub-pixel capabilites (always been a supporter) but this will have to be dealt with carefully. |
|
I'm inclined to think that the Right Way to provide sub-pixel capabilities to devs is to represent all coordinates as floats. Some things would then need a "snap to pixel" (or "snap to grid", with customizable grid size) setting. The drawback would be that it would make all sorts of coordinate comparisons more complicated and error-prone (you couldn't just do "if(player.X == xval)", you would have to define a range of acceptable values). |
|
I wonder if there is a way to keep script API in ints with that. I am more than certain that a lot of users will be annoyed by having to use floats, especially knowing how int/float conversion is implemented in AGS Script. Only for the sake of throwing some ideas in, script API could duplicate existing coordinate-related properties and functions with floating-point counterparts, for example Object.fX and fY, Character.fWalkSpeed, and so on. EDIT: Hmm, what am I thinking... perhaps fixing script to be able to do implicit conversions could be easier.
Few engines I've seen provide a constant defining minimal difference between two floats, usually called Epsilon, and a function to compare e.g. FloatEquals(float, float). EDIT: Actually, script interpreter could use these implicitly when two floats or float and int are compared. PS. Oh, and of course, the big question is whether the backend library will support subpixels, or we'd need to program this functionality ourselves. |
|
Does sub pixel rendering offer anything over just running the game at a higher resolution (so you have more pixels)? You could apply pixel-snap / nearest neighbour rendering at a lower resolution for positioning, and just use the extra resolution when scrolling. |
As far as I understand, sub-pixel rendering is based on running in higher display resolution, otherwise you won't have those extra pixels to draw "fractions of pixels", so to say. We already have "render sprites at screen resolution" setting, which uses same effect but only for scaled sprites. To be able to add such effect just for moving sprites, or moving viewport, we need to keep sprite or viewport coordinates at least in subpixel resolution in integers (or floats, where, as I presume, 1.0 could mean 1 native game pixel size). |
This comment was marked as abuse.
This comment was marked as abuse.
This is not quite correct. You can position something on sub-pixel coordinates even if you're not displaying it in a higher resolution. (In fact, that's a big part of what "sub-pixel" means, at least to me.) This is accomplished through anti-aliasing, so if a sprite pixel is placed at the sub-pixel position x=7.25, then 75% of it is drawn to x=7 and 25% of it to x=8 (assuming bilinear interpolation). If you're simply offsetting low-resolution sprites by fractions of their pixel grid on a higher-resolution screen (as in Thimbleweed Park, for example), I wouldn't call that sub-pixel smoothing, but some sort of mixed-resolution processing. |
|
When I'd heard the term before, it was related to anti-aliasing, but I wouldn't have thought this would be good to implement smooth scrolling on a lower resolution. Wouldn't you get a shimmering effect as the anti-aliased object moved between offsets, and if it hits an actual integer offset it'll stand out as being bizarrely sharp and clear in comparison? |
Ah! Sorry, now I remember someone telling me about this in the past. Looks like I was the one who did not know what others are talking about :). |
It can lead to artifacts, for sure. It's not a magic bullet that fixes things in every situation. But there are definitely cases where it helps, too. For example, if you're rotating or scaling a sprite, you may need to place it at a sub-pixel coordinate in order to avoid jittering. There's a good example in the (old) intro to A Tale of Two Kingdoms, here. To your point, for smooth scrolling the blur can usually be played off as motion blur, while the shimmering is not that big a problem if there isn't a lot of high-frequency detail in the sprite (as long as details are at least 2 pixels wide, they'll always be rendered with at least one full-intensity pixel).
Well, both effects rely on having sub-pixel accuracy in positioning sprites, so you're not really wrong. As a game maker I would want to be able to turn them on and off individually, though. |
|
I would add a player.floatX and player.floatY that return the internal values while .X and .Y return the integers. |
|
With regard to the Editor:
|
Yes, this is according to the plan. I don't think starting a big rewrite in ags3 branch would be a good idea. BTW, I was planning to make next merge right after fixes to the Room Editor UI (#482). |
ivan-mogilko
added
res: in consideration
type: information
|
Closed too because it's old. |
First of all, sorry for the long post below, but I thought this has to be written to document what we are trying to do and why.
This is a continuation of #403, but the old thread became way too cludged with all the heated discussions, and options.
Preword
From the early days this open source project suffered from mixed goals and purposes. On one hand, the game making community desired AGS to improve and get additional functionality, on the other hand there was a significant number of game players, who wanted to play both modern and old AGS games using same engine and its ports. There had been an attempt to make AGS port for ScummVM, but it was not complete at that time, and so this engine was the only way to run majority of games.
When we just started, this problem was never properly discussed (in my memory at least, but I've joined late) and no concrete decisions made regarding solving it.
As a result, all the subsequent development was largely complicated by the need of maintaining backwards compatibility. It was not only supporting legacy features in the engine, to be able running old games without conversion, but also supporting loading old games into the editor in case game developer would like to import and continue their ancient project.
This was further aggravated by the very low number of contributors involved. (For example, initially my primary goal was to refactor the code, but I soon had to suspend that work in favor of doing other tasks.)
Current situation
Today the project development has practically stalled. There are some minor additions, as well as some refactoring made over time, but apparently no much interest in developing it further. There is a number of things AGS is lacking that are making it difficult to use in the modern enviroment, such as unicode support for example.
So its future is unclear.
Course of action
So, @AlanDrake's suggestion (#403) is to a) radically clear the code from the legacy support, b) refactor the cleaned code, so that it is potentially easier to develop further.
Then after that's done maybe get the legacy support back in a modular way, that won't impose any constraints on future development (although legacy support is very low priority from his point of view).
This approach has both pros and cons; the opposite method of gradually refactoring the engine while keeping all the backward compatibility intact also has pros and cons.
Personally I have very mixed feelings about it, but acknowledging the fact that the number of active contributors is very low, and program development is barely existent, it looks like there won't be any "good" way out of this situation, there will be trouble no matter what we choose; only difference is in the nature of the trouble (and number of people willing to cope with it).
To sum up, the idea is as follows:
We create a branch called, e.g. "ags3" (since the major version is 3). From now on and until further notice this branch will contain latest version of the engine and editor compatible with importing and running old games. This branch will allow only necessary fixes, and only updates that improve its perfomance. Also, naturally, any kind of backward compatibility updates.
The latest version in 3.x.x family is probably going to be 3.4.2, because there is already a WIP version of it released for public use & test. Note that it still is kind of rough at the edges in the Editor, where we implemented new navigation bar, so may need extra tweaks. These should still be made in "ags3" branch.
Current "master" branch becomes a place of a refactoring project, which first priority is to clean and refactor the engine code (possibly editor too where necessary). All backward compatibilities are cut, except for loading latest 3.4.x games. This branch is allowed to become unstable for some periods of time too.
In case there is a patch that is worth to be also added to ags3 branch, one of two possible methods is used: either patch is applied to ags3 branch, and then to master separately, or after its applied to ags3, ags3 is merged to master very carefully, to not bring unnecessary code there again.
People willing to contribute for running old AGS games are also encouraged to assist finishing ScummVM AGS port, started by @fuzzie, and continued by @morganwillcock. This project may be found here: https://github.com/adventuregamestudio/scummvm/tree/ags
We of course need to explain all this very clearly in the Readme.
What should be the closest goals of this rewrite?
IMHO, if we are doing such change to the code, than after this first step we must do second and actually refactor it completely (more or less), and also break any constraints that were restricting development (such as data format constraints, imposed by the old plugin API, for example). Because, although removing legacy code would make it somewhat easier, large portions of contemporary code is still very hard to work with.
In such case I'd propose to open a "refactoring master ticket" with a list of most outstanding necessary changes and remaining unrefactored parts for contributors to choose from.
We'd need to also discuss the overall structure of the engine code we are aiming at, to prevent erratic changes.
To give an example, considering the upcoming SDL2 port (by @sonneveld), we probably should aim to restructure main program loop to make it consistent with SDL's event queue.
Issue of the legacy code
First of all, the legacy support stays in the "ags3" branch. @sonneveld already mentioned that his goal is to complete SDL2 backend for 3.x.x version. If this is done, that would hopefully cover some of the issues we have with e.g. Linux port. So the legacy branch, although not developed further, would still exist as a way to run old games.
Hopefully, the ScummVM port will be also finished someday. I'll post the link again just in case someone wants to test/contribute to help it happen faster: https://github.com/adventuregamestudio/scummvm/tree/ags
Finally, if that would still be wanted, an option which remains is to get the legacy support back if/when the refactoring in the master branch is completed. If done correctly, that should not interfere with the actual development, and scare anyone away.
In such case the biggest question is how to find what functionality to restore. If we are merging ags4 branch into master, as suggested, then this merge commit would contain all or most information about what was deleted. Much of that code was already distinctly separated, or related to very particular legacy data structs, which makes it possible to understand its meaning with certain effort.
The text was updated successfully, but these errors were encountered: