Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moving to AGS 4.0 #448

Open
ivan-mogilko opened this issue May 29, 2018 · 45 comments
Open

Moving to AGS 4.0 #448

ivan-mogilko opened this issue May 29, 2018 · 45 comments

Comments

@ivan-mogilko
Copy link
Member

@ivan-mogilko ivan-mogilko commented May 29, 2018

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jun 1, 2018

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?

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 1, 2018

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?

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jun 1, 2018

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.

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 1, 2018

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.
Probably it may be possible to restore it without overwriting new one, and make a switch in the game settings, or config, or even as a compilation flag.

Do you know actual games broken by this? If so, could you open an issue please?

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jun 1, 2018

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.

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 2, 2018

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:

  • Update README with new information about game support and ways to contribute.
  • Test that existing 3.4.1/3.4.2 projects may be imported and run correctly (assuming they do not use any legacy features).
@sonneveld

This comment has been minimized.

Copy link
Member

@sonneveld sonneveld commented Jun 5, 2018

@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?

@sonneveld

This comment has been minimized.

Copy link
Member

@sonneveld sonneveld commented Jun 5, 2018

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?

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 5, 2018

@sonneveld ,

I think if the new pathfinder code isn't part of a 3.4 release, it might be worth reverting it.

New pathfinder is a part of 3.4.2 version which was already released for public testing.
I was thinking it might be possible to not completely remove it, but instead introduce a switch. The switch could work, for example, like this:

  • if an old game is run, it uses old pathfinder by default, or new one if there's an explicit overriding config option set.
  • if a new game is run, it uses new pathfinder.

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.

What new features are planned for AGS4?

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.

how are we going to ensure new features are complete before going into master

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?

@AlanDrake

This comment has been minimized.

Copy link
Contributor

@AlanDrake AlanDrake commented Jun 5, 2018

We should discuss new features somewhere to make a list and value their merits and implementations.
In the backburner I have a couple of things like the blend mode property, which I'd rather delay until we have SDL2, and a few scripting functions that I don't feel are ready enough to be merged.
For the moment, I'd rather to focus on cleaning and refactoring.

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jun 5, 2018

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.

@ivan-mogilko ivan-mogilko added the ags 4 label Jun 6, 2018
@sonneveld

This comment has been minimized.

Copy link
Member

@sonneveld sonneveld commented Jun 6, 2018

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.

@monkey0506

This comment has been minimized.

Copy link
Member

@monkey0506 monkey0506 commented Jun 6, 2018

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.

@rofl0r

This comment has been minimized.

Copy link
Contributor

@rofl0r rofl0r commented Jun 8, 2018

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.

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jun 8, 2018

I think Squirrel 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...

@jdiperla

This comment has been minimized.

Copy link

@jdiperla jdiperla commented Jun 8, 2018

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 8, 2018

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?

There was already a working Lua plugin for AGS (at least one big game was created with it), and experimental C# plugin for AGS.
I believe it might be possible to provide a proper plugin API to substitute script interpreter in the engine.

@SuperDre

This comment has been minimized.

Copy link

@SuperDre SuperDre commented Jun 8, 2018

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jun 8, 2018

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 camera.destination.x = 200;, and the engine does the rest, that probably isn't worth integrating a language which was never designed to be embedded.

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 9, 2018

Regarding use of Lua plugin:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=38765.msg613652#msg613652
http://www.adventuregamestudio.co.uk/forums/index.php?topic=47316.msg635916#msg635916

If we end up with camera.destination.x = 200;, and the engine does the rest, that probably isn't worth integrating a language which was never designed to be embedded.

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.

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jun 9, 2018

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.

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 9, 2018

Oh, it was not clear to me that all that referred to update speed.

I would also prefer to have access to low level functions, but per rendered frame, not at the speed of the game logic.

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"?

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 9, 2018

Oh, I think I got it. You mean, the speed at which minimal "step" is happening in AGS game, like animation delay ticks?
It's hard to say how easy that would be to do, but imho the rate of the script update event and THAT game speed should be separated.

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jun 9, 2018

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.

@tzachshabtay

This comment has been minimized.

Copy link
Member

@tzachshabtay tzachshabtay commented Jun 9, 2018

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.

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 9, 2018

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.
I also recall seeing couple of games that also had pretty smooth side scrolling, like "Nelly Cootalot" and "Resonance".
It seems that viewport issues may be related to various things, depending on what you are trying to achieve. E.g. how smoothly character moves, whether you are updating before game update in rep_exec or after in late_rep_exec, and so on.

PS. I added a suggestion to separate event frequencies into #450

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jun 10, 2018

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.

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jun 10, 2018

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

@AlanDrake

This comment has been minimized.

Copy link
Contributor

@AlanDrake AlanDrake commented Jun 10, 2018

Alright, I'll take care of the removal of the legacy audio support.

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jul 12, 2018

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.

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jul 12, 2018

Is there any way I can get the ability to tag my own issues with "AGS 4"?

I gave you write perms to this project, my impression is that's only way. Please check if you may work with labels.

@jeancallisti

This comment has been minimized.

Copy link

@jeancallisti jeancallisti commented Jul 18, 2018

I find Squirrel to be an interesting suggestion (I had never heard about it before), here is why:
I've always been repelled by languages with unusual syntaxes, like Lua, while knowing too well that C# is a bit too complicated for complete beginners.
Squirrel seems to be as flexible as Javascript while being sligthly more rigorous, like C#.

@jeancallisti

This comment has been minimized.

Copy link

@jeancallisti jeancallisti commented Jul 18, 2018

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.

@messengerbag

This comment has been minimized.

Copy link

@messengerbag messengerbag commented Jul 18, 2018

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).

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jul 18, 2018

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.
Internally they will all be floats of course.

EDIT: Hmm, what am I thinking... perhaps fixing script to be able to do implicit conversions could be easier.

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).

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.

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jul 18, 2018

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.

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jul 18, 2018

Does sub pixel rendering offer anything over just running the game at a higher resolution (so you have more pixels)?

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).

@rofl0r

This comment has been minimized.

Copy link
Contributor

@rofl0r rofl0r commented Jul 18, 2018

also keep in mind that floating point calculations are a lot slower than integer calculations, especially on non-x86 hw.

@messengerbag

This comment has been minimized.

Copy link

@messengerbag messengerbag commented Jul 18, 2018

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.

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.

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jul 18, 2018

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?

@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jul 19, 2018

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).

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 :).

@messengerbag

This comment has been minimized.

Copy link

@messengerbag messengerbag commented Jul 19, 2018

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?

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).

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 :).

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.

@AlanDrake

This comment has been minimized.

Copy link
Contributor

@AlanDrake AlanDrake commented Jul 19, 2018

I would add a player.floatX and player.floatY that return the internal values while .X and .Y return the integers.
I'd really like to turn coordinates to float so we no longer have to use hacks to make the character move correctly at small zooms
The snap to pixel could be an option.

@morganwillcock

This comment has been minimized.

Copy link
Contributor

@morganwillcock morganwillcock commented Jul 22, 2018

With regard to the Editor:

  • am I okay to remove legacy settings that wouldn't apply to 3.4.1 games?
  • to try replacing AGS.Native, I'd like to add unit tests. Would there be any objections to using xUnit (this is the only one I've used, but perhaps something else is better suited)?
  • presumably it is okay if whatever replaces AGS.Native doesn't handle legacy settings?
  • should all of the above go into the master branch?
@ivan-mogilko

This comment has been minimized.

Copy link
Member Author

@ivan-mogilko ivan-mogilko commented Jul 22, 2018

  • presumably it is okay if whatever replaces AGS.Native doesn't handle legacy settings?
  • should all of the above go into the master branch?

Yes, this is according to the plan.

I don't think starting a big rewrite in ags3 branch would be a good idea.
Since we are still adding some stuff to ags3, we'd need to merge it later, but we've been through this kind of task before, so I believe it's manageable.

BTW, I was planning to make next merge right after fixes to the Room Editor UI (#482).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.