Messages

Does this problem happen in DX5, D3D, or both?

Do you still have the source code for the game that causes this? If you can upload and PM me the link, I can take a look and find the problem.

Hmm, that's annoying that it doesn't crash on your friend's computer. If you'd like to upload the game I can try it out and see if it crashes for me, but if not it can be very hard to track these things down.

Hmm, that's not good though, it should never crash the engine. If I get any time, I'll look into it.

1. yes it needs audio channels too

2. The GetManagedObjectAddressByKey function asks you to pass in a key, not an object

3. Pass the actual object as the first parameter

4. ah ok, I see what you mean

Strange, it might be related to your video card drivers somehow. If you switch from DX5 to D3D or vice-versa, does that help?

Sounds like a good idea -- unfortunately I'm very busy at the moment and don't have time to look at this with you.

I haven't seen scotch in a long time, I don't know if he still visits these forums but he may have moved on to other things.

1. The API needs exposing of the new Audio objects and Attributes (anything else?)

Good point, the AudioClip stuff should be exposed to the plugins.

2. BTW I've noticed that GetManagedObjectAddressByKey() never seem to return NULL, only addresses with 8 bytes increments.

When would you expect it to return null? Where did you get an invalid key from?

3. for GetScriptFunctionAddress() - which f() are considered "script functions"? those which are not instantiated object methods? like Room.foo() and Screen.foo()

You can use GetScriptFunctionAddress to get any of the built-in AGS script functions. For example, PlayVideo is a script function.
Character.Tint is a script function (though the struct member functions are requested as "Character::Tint" to GetSCriptFuntionAddress);

4. Could you PLEASE expose the managed objects' names?

What do you mean?

I presume you don't get this tint with other non-AGS games?

There was a bug in 3.1.2 and previous versions, where if you had a single sprite that was bigger than the size of the sprite cache (eg. a 25 MB sprite and a 20 MB sprite cache), it could get corrupt and crash like this.

This is probably the cause of your problem since increasing the sprite cache to 100 MB has fixed it for you.

As for the memory in task manager -- if it's reducing back to a normal level after you minimise the window, there's probably no problem. This can be normal, it doesn't necessarily mean that all that memory is in use but just that the system hasn't had time yet to clean up the memory.

Firstly, AGS already uses the VMR9 for PlayVideo when you're in D3D mode -- are you trying have a video playing as part of the game background, rather than as a full-screen affair?

In an AGS PlayVideo call, the normal rendering loop is disabled and a special DirectShow rendering loop is used instead, so the normal AGS events don't happen.

I haven't yet tried to combine DirectShow with Direct3D on the same canvas, so I'm not actually sure what my advice should be...

I see your point here. Play() can return null for other reasons (eg. if the audio file can't be loaded for some reason), but I actually agree that it should return a dummy channel if you are using No Sound, as you say.

Otherwise, I agree that this could cause a lot of games to crash if run with a No Sound setting.

What is the "Particle Systems manager" that you're using? I'm not sure what that might do to render the particles.

I did need the irrKlang.NET2.0.dll, and this Post-Build event caused me a problem:

E:\Code\ags\netedit\UpdateCPPVersion\bin\Release\UpdateCPPVersion.exe $(TargetPath)

Ah, sorry about that post-build event, I didn't spot that.
It's not important, it's used to synchronize the Native DLL version number with the other assemblies, but since you're not building the native dll it doesn't matter.

This is main website news, Pumaman. When is the main site going to reflect this?

I still need to release 3.2 officially to the website! Also the new rewritten website needs to be finished and released, I just haven't had time yet.

What would be the easiest way to compile this for Mono on Linux? Anything I should take into consideration?

You won't be able to, due to the Native DLL. If the source code to that was available, does Mono have a mixed-mode Managed & Native C++ compiler that could build it?

AGS has P/Invokes into WinAPI (kernel32, user32, winmm). It might be possible to use the Wine libraries, but I'd rather replace them with managed code.

The AGS Editor uses P/Invoke in some rare cases where I couldn't find a way of doing it with managed code. The Named Pipes exception that you mention is in .NET 3.5, but since I want the AGS Editor to continue to support .NET 2.0, we can't use this. (it would be feasible to just use that for a Linux port which would require a 3.5-version of Mono though, of course).

Hm, I've copied IrrKlang, removed the postbuild event and still cannot run it.

System.IO.FileLoadException was unhandled by user code
  Message="Could not load file or assembly 'AGS.Native, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)"

Try copying the msvcm80, msvcm90, msvcr80, msvcr90, Microsoft.VC80.CRT.manifest, Microsoft.VC90.CRT.manifest from an installed AGS 3.2 folder to your bin/Debug folder, that might sort it out.

Don't you want to set up some source control ASAP (where only you have permissions to rebase to the main trunk, and everybody else can create their branches and play around with it)?

As I said in my first post, I will set up some sort of CVS-type thing, but I didn't want to make everyone wait ages for me to do that before making the code available.

Hmm, I've checked the code and it does definitely seem to expect screen co-ordinates. Could the problem in that other thread have been due to something else?

I disagree.  Do you think that Mac/Linux users only want to play AGS games and not create them themselves?

Of course there are some people that do want to do that. All I'm saying is that, with AGS having a user base of 2260 people, considering that 1% of desktops run Linux and 5% are Macs, a Linux port would only cater for 22 people and a Mac port for 113 people.

Therefore personally, I don't think it's worth spending time on (for example) a Linux port of the editor that only 22 people will use. You may well disagree.

I think your underestimating the adoption value of would-be handheld developers. It's the chicken or the egg.

I don't think handheld devices are really related to this debate -- nobody is going to try and run the AGS Editor on a handheld device. The actual games themselves, are another matter -- porting the engine is a worthy goal.

But with most projects, the majority or entirety of the developer base are Linux users. Because many Linux users look for and take notice of opensource projects and support them because they emphasize and believe in the Copyleft movement. And most Linux users are extremely technical and proficient in programming. Every Linux user I know knows at least one programming language. But most know around 3-5. I use C/C++ and Python and Lua myself.

This is probably true.

I should just point out that I'm not opposed to somebody porting the editor code to Linux if they want to, I'm just trying to explain why it's not a big factor in my decisions surrounding the AGS source code releases.

You'll need to be much more specific about what exactly has happened and what you did...

[completely unsupported]

Following discussions in this previous thread, I have decided to go ahead and open up the source code for the AGS Editor.

It is released under the Artistic License 2.0; please read and understand the license before downloading the source code.

Some important points about this release:
* The AGS Editor source code is C#, built with Visual Studio 2008 and targetted to .NET 2.0. You should be able to compile it with the free Visual C# Express edition, but I haven't tried this.
* This source release does not include the source code to the AGS.Native DLL. This assembly is a mixed-mode managed and native C++ assembly, which has dependencies on various other libraries such as Allegro, ALFONT and Scintilla, which makes it relatively complex to compile. I will consider releasing the source code for this in the future.
* The editor uses irrKlang for audio previews, you may need to download this separately if you can't build the editor.
* The AGS.CScript.Compiler assembly has a half-finished re-write of the script compiler. Only the Preprocessor part of this assembly actually currently used; the rest of it is only half finished.
* This release is completely unsupported. Additionally, I will not provide support for any bugs or problems you have with a version of the AGS Editor that you built yourself, or problems with any games that you create with such a version.

Contributing changes:
* The "Standard Version" of the AGS Editor will still be controlled by me. This will be the version available for download on the website. However, I am looking forward to receiving fixes and improvements to incorporate into it.
* I may set up some sort of CVS at some point. For now, if you make any bug fixes or add any cool new features, please post your updated source code in this thread so that we can discuss adding it to the Standard version of AGS.
* I would prefer for the Plugin API to be enhanced so that minimal changes are actually required to the Core AGS Code, and that more functionality can be implemented by plugins.

Source code download:
http://www.adventuregamestudio.co.uk/AGSEditor-Source-3.2.0.103.zip

Have fun! Let me know how you get on, or if you have any problems compiling the code.

What use is the editor code if the compiler code is still closed?

because surely we cant actually change anything since the compiler still needs to understand what the editor does.

What use would the compiler code be if the engine code is still closed? There's no point being able to change the compiler if you don't have the engine source code, since it wouldn't understand what your new compiler had produced.

As monkey_05_06 says, having the editor source code effectively extends the editor plugin API to allow you to do whatever you want within the editor.

If you close source the native DLL wouldn't this be detrimental to using the editor on any other platform?

Personally I have no interest in seeing the editor on other platforms. The Mac/Linux voice always shouts very loud, but it is such a tiny proportion of real world users that in terms of the editor it's not something I think it's worth spending time on.

The engine is a different matter, and having Mac/Linux ports of the engine is a good thing so that the maximum number of people possible can play games that are created with AGS.

But all in all realistically for the engine to improve you have to either open source it.  Or give the code to a highly capable and motivated team of people.

As I have said, opening this editor code is a first step. It's an experiment to see if opening up AGS will lead to productive results, or just stagnate or make a mess.

If things go well, then I'll consider opening up the rest of the code too.

Would you decouple the compiler from the editor, in this case?

Well, initially I'm planning to release the C# editor code, but not the source for the Native C++ DLL which the editor uses; and since the compiler is part of the native DLL, the source code to that won't be released, to start with anyway.