Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - morganw

Pages: [1] 2 3 ... 8
Thanks, I've applied the changes there. If anyone would like to play around with it, this currently builds okay with AGS selected as the only engine:

I've added a note to the top of the readme file, on how to generate a project solution in Visual Studio that excludes all of the other engines, basically just run the project configuration manually and give it the same engine options you would use for the configure script on another platform/compiler.
Code: DOS
  1. --disable-all-engines --enable-engine=ags

Building all/stable engines should be fine too, but it does take a while (for me at least) and uses quite a lot of disk space.

For things I really like (and for contrast): Game.DoOnceOnly

If you are defining global state, you may as well describe what you are doing it for at the same time. :)

Also, I think it might be more flexible to have a generic object hierarchy for rooms (and scripts attach to any object). So the room is just another object and a child of a game object - potentially you can get a reference from parent to set global properties or properties in another room. I think it would be pretty easy to disguise this as the current setup (global script is on the game object, room script is on a pre-built room object with no children) so people can stick with what they know if they prefer to.
Can you expand on this? I'm not sure I completely got what you're aiming for here. Can you also explain which use-cases are you hoping to solve (or make better) with this?
As an example, if you had three objects which you need to check the state for some kind of puzzle, rather than just put them in a room and store the state in the room script, you have a base level object (one that would be extended with components to become the other type of game objects) and encapsulate the object state and functions in there. The idea being, if you didn't want to use it you don't have (just use the pre-extended objects), but you could take an empty object and manually assign the components (bitmap, events hooks, scripts, etc). So the parent object might have a function to validate the position of its children which is used as the puzzle logic, but may also have a bitmap (perhaps the three objects are on a tray) or blit to its own surface (perhaps it is a magic tray), and also provide routing for events to propagate (can fire events into its children, pass-on events from its parent, or claim events). When the puzzle is solved, just deactivate the parent to stop all scripts and events on the children, so I guess I'm suggesting it as an option to prevent having lots of booleans and if statements in a room script or global script (but you can still do it that way if you want as that is just one parent and one child).

AGS gets character movement and animation right. Other engines I've used move a character at 60 FPS regardless of the speed of the animation. I think this is mostly due to laziness and lack of consideration at the point of design.
It would be good if you could optionally decide which scripts are on a fixed frame rate and which will wait for vsync (perhaps just capped at 60 FPS). So the viewport and mouse cursor could be smoothly moved, but game speed is still configurable. i.e. separate the game events from the engine events, so when using the RenderAtScreenResolution setting you can get the retro look with smooth scrolling and interface. Doing this is Unity is pretty difficult, normally you end up with spritesheet jitter and pixels changing in width as they scroll, I think you had to point the camera at a render texture to work around that which didn't use to be available in the free version.

Also, I think it might be more flexible to have a generic object hierarchy for rooms (and scripts attach to any object). So the room is just another object and a child of a game object - potentially you can get a reference from parent to set global properties or properties in another room. I think it would be pretty easy to disguise this as the current setup (global script is on the game object, room script is on a pre-built room object with no children) so people can stick with what they know if they prefer to.

Also, directory based project structure (sprite is just an image file) with YAML datafiles instead of XML (so people can read it with just their eyes). I think just letting the compiler pack the sprites would be a big improvement for a lot of people. As an example:
Quote from:
The engine is extremely artist friendly, with the ability to slide easily into a production line. All images are read from external files, so updating graphics is as easy as copying files in Windows Explorer. Simply replace the old frames in the directory, and they are automatically updated in the game.

I'm asking again : what's wrong with SharpDevelop?
Quote from: The SharpDevelop website
Supported operating systems: Windows Vista and later

Plus it looks like there are issues going past C# 5.
I wanted to use it at work to avoid Visual Studio licensing, but existing code was already using features of C# 6.

If you can fork fuzzie's scummvm repo to the AGS account and give me write access, I'll just reapply the changes there. Also that gives some visibility over what I'm doing, by people who might notice what I've misunderstood.

Do you want everything shifted to the Github account, and then I'll open issues if I have any more questions?

It didn't need much doing to it to build, after merging with with their master branch. I have found it is very hit and miss and which games will open though, it couldn't find the game data in a 3.2.1 game, and exited trying to load a font for a 3.4.0 game. According to the checks that it makes, version 3.2.1 was the highest version it supported. I guess it is also misreading the version number as I'm not seeing the error message that should appear for anything newer than that.

In terms of older game data being patched, in this all done on load?

i.e. in functions like this one
Code: C
  1. MainGameFileError  ReadGameData(LoadedGameEntities &ents, Stream *in, GameDataVersion data_ver);
  2. // Applies necessary updates, conversions and fixups to the loaded data

I guess that step one will be checking the existing data reader...

With the latest master merged against it it doesn't build, so I'll try to get working with the latest changes. Hopefully by doing that I'll pickup some ScummVM and AGS workings. I'm happy to shift everything into the AGS account if anyone else would also like to look at it.

It looks like it was updated in 2014, but it still build okay following the ScummVM build instructions (although the backend it built with was SDL, not SDL2, but I think this is just because the default renderer was still SDL in 2014). Out of the three games I tried, one got stuck on the menu screen (I think due to an issue with GUI buttons), one crashed (I think because it called SetGameOption), and one very recent game was not detected as an AGS game. This might be because I am missing the part of the code which would add function stubs into older games, but I think finishing this port may still be promising option, purely because the code is commented all the way through and missing/rough functionality is labelled.

Is there any engine documentation anywhere which could be used to help with identifying missing features, issues with what is already done, or give details of the game data format? If I can manage to get my bearings with everything (both AGS and ScummVM) I would be interested in trying to work on this.

I also think it would be best to stick with GitHub for the moment. It is still not clear what the direction of future development is, so it will be pretty difficult to predict that development, wiki, manual, or issue tracking will be improved by a change in tooling. In terms of SMF Project Tools, I don't know if someone was trying to keep the technical issues opened there in sync with the GitHub issue tracker, but to me it would seem more straightforward for technical issues to go to GitHub and script help issues to be covered by forum help (I imagine anyone offering help in the forum would probably be okay with having a Github account and using it to reference a forum post, if a problem needed to be raised as a technical issue).

I wasn't sure if it was intentional or not, but the download links here:
...still have the previous stable version linked.

Thanks for finding the messages, the to-do list page is still working so at least that gives a rough idea of what is missing. Unless anyone really thinks I should not, I'll try to contact her (starting with an apology for any previous hassle) to ask if she would be interested in looking at it again, or perhaps just providing some pointers if anything wasn't straight-forward. I'll also try building it at the weekend, to see what would be involved in testing it.

Engine Development / Re: AGS engine Linux port
« on: 04 Jan 2018, 20:47 »
Were you using the tag that expands to get the actual game directory?

Quote from: the manual
When specifying file path you may use special location tags:
$INSTALLDIR$, which allows you to explicitly read files in the game installation directory.

To cross reference the threads, I am suggesting this as a potential way forwards. I wouldn't like to claim that I'm some sort of official spokesperson, but I am happy to suggest what I think is a workable solution (everyone should feel free to point out issues I am missing... :))

Since the future direction is undecided and different people have different ideas about what would be best, perhaps in the short term it is best to concentrate on what exists now and how to preserve it. So I would suggest this 2 step plan:

- Get the existing ScummVM port working with current features
This gives a route to try and keep older games working, plus a replacement engine that could potentially work with the existing editor (potentially just the debug tools would need changing?). Someone has kindly done a lot of work on this already so this is perhaps the easiest way forward.

- Look at the situation again
If the ScummVM port can't accommodate the compatibility quirks for old games, at least there is now a working engine for games which are current which does not have the issues of Allegro 4. If it can have fixes for older games, that is a bonus (and if not anyone who has the source for their old game is free to upgrade it through the existing editor and get it working). You haven't asked ScummVM devs to add a continually developed engine that will get updated for new features, just one additional legacy engine (so very little rocking of the boat for everyone involved)

None of the above need impact Alan's AGS4 cleanup branch, someone suggesting their own engine as a replacement, or someone who wants to start from scratch. If the ScummVM backend looks good for continual development at this point, and there are no forthcoming alternatives which show advantages, there is now the option branch it and drop the compatibility quirks or speak to ScummVM devs about ongoing development and support. If anyone would like me to post/suggest this in another thread/forum, or try speaking to fuzzie about what was already done, please let me know and I will do so.

Because of ongoing discussions about rewrite, reimplementation on ScummVM, and a lack of direction in general, I think you would have a reasonable chance of switching everyone who is using AGS to your engine and Visual Studio tools if you pitched it as a direct replacement. There aren't many options for development which do not have tiered licence costs for revenue or building for extra platforms, and no-one else with an alternate open source engine has a replacement IDE ready to go. If you genuinely have got a working migration process for existing projects and were willing to open source the whole thing, perhaps you would consider that the user-base you would pick up would be of more value than trying to directly monetise a small number of users.

You can always go the route that 3DRad went. They added a forum where folks made suggestions for new features or bug fixes. The developer would then decide a price to implement each feature or bug fix and allow users to donate towards the feature or big fix they wanted. The feature or fix that would reach it's goal first would be implemented next. Anyone who donated would then receive an early release version of the software.
...and would perhaps combine nicely with the above.

Yes, although in the case of SCUMMVM they do not seem to differentiate between platforms for game support (compatibility charts do not say where a game will not run on a particular platform).
To argue against myself, there is a table which indicates some restrictions per platform: hopefully if this goes in the direction of 'must have feature x', they might be willing to only support it on platforms which had access to recent compilers / frameworks. There are also built-in debug tools, which look useful, including one which can record and playback game actions to check for breakages.

The example of potentially needing custom shaders is quite interesting, as Allegro 5 looks to have custom shader support built-in, whereas SDL/SDL2 require that it is handled manually per renderer, or you use some middleware to do it for you.

To be fair, that's the same issue as any engine may have when running on low-end systems. This is why having a way to turn off certain effects is important.
Yes, although in the case of SCUMMVM they do not seem to differentiate between platforms for game support (compatibility charts do not say where a game will not run on a particular platform). If the mindset is that all platforms are equal and then they are approached with a wishlist of features that would only work on a small subset of those, that could be fundamentally against what that project is trying to do. I may be entirely wrong though (and at some point old games will be games that use custom shaders).

It is worth bearing in mind that the vast platform support may limit adding features that wouldn't work on all platforms, unless such features are optional. Perhaps if they were treated as enhancements (i.e. a game is playable without custom shaders, but will look better with them) this may align more with SCUMMVM development, but I would imagine asking for new features for games that don't exist yet may cause objections.

Perhaps the best way to proceed would be to get a list of SCUMMVM funtionality, how that maps to what is needed for AGS 3.4, and what is missing from the more modern features people are asking for.

Pages: [1] 2 3 ... 8