Messages

[SharpDevelop]

I'm asking again : what's wrong with SharpDevelop?

Supported operating systems: Windows Vista and later

Plus it looks like there are issues going past C# 5.
http://community.sharpdevelop.net/forums/t/22341.aspx
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++

MainGameFileError  ReadGameData(LoadedGameEntities &ents, Stream *in, GameDataVersion data_ver);
// 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:
http://www.adventuregamestudio.co.uk/site/ags/
...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.

Were you using the tag that expands to get the actual game directory?

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:
http://wiki.scummvm.org/index.php/Platforms/Overview
...so 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.

1)Is it only an emulator or game engine?

You could argue about what is an emulator vs reimplementation vs game engine, but in terms of AGS it would effectively be an alternate version of the runtime that can play a compiled game.

2) Can it solve mobile ports for AGS if port becomes ready?

Potentially. It isn't designed for releasing standalone games, but as long as you comply with licensing terms you could build a version designed to run a single game.

To be honest it does seem a missed opportunity; if you go into SCUMMVM forums and talk about making a brand new game they will suggest AGS, and if you are using AGS you will be looking for the platform support and developments of SCUMMVM. Personally I would like to think there was an opportunity to have a continually developed runtime using the SCUMMVM backend, that does not maintain backwards compatibility and can have a few more contemporary features. I am still waiting to see what happens with the AGS4 branch, however...

It looks like if you install Audacity, you should be able to see which MIDI devices you have available as playback devices in the preferences. I'm not sure if it sets the device for anything other than itself, but at least you would now if you still have a device to playback with.

It looks like at least some MIDI settings used to be in the user part of the registry; it might be worth checking that logging in with a new user account still has the same problem.

There was a recent Windows update which uninstalled the built in media player, perhaps that also removed the software MIDI device. If you have KB4046355 installed you should probably check that Media Player is still ticked in the list of optional Windows features (Control Panel / Programs and Features). Otherwise it could be that the default MIDI device number has somehow become changed, but the interface to configure that has been removed from Windows (you would have to find another application which can show you the MIDI out setting).