Suggestion : Core engine separated from rendering engine

[Monsieur OUXX]

This continues the "Suggestion: Web engine" thread and broadens the paradigm.

At the moment the engine is not open source, only the Editor. That's fine. That's one thing.
Another thing: More and more people are pushing to have it work on several media, from Consoles to Web Browsers, etc. We have seen XAGE and even a Javascript proof-of-concept.
At the moment that forces them to rewrite everything from scratch. Then you have another AGS that's not AGS.

However, IF we assume that the engine goes open source...

...then I think one of the main things to do would be to gradually isolate the core engine from the rendering engine. Let's say, make AGS a DLL (that's just an example to make it clearer). That "DLL" would be in charge of the walk area calculations, inventory, dialogs, etc. But there wouldn't be any graphical output.

That way, you could then easily expand it back into several rendering engines, each using their own tehcnology/platform. That would really create opportunities for parallel coding: While some people would fix the core and expand the script language or whatever, some others would maintain the Web-browser plugin or the Xbox engine or the Hardware-accelarated-related details of the rendering, etc.

That already kind of exists as plugins, but the goal here would be to make pretty much everything from the core accessible easily and fast by the rendering engine, and also not to mix up the 2 sides.

I'm just throwing an idea. It might be the wrong forum. I apologize in advance if you think that's irrelevant or silly or doesn't make any sense, technically.


then again I'm really only posting this because I see so many people all frisky about "porting" AGS to pretty much anything that has a chip in it, but missing the "important" point, which in my opinion is the rendering entangled with the engine.

[Calin Leafshade]

Since AGS has two distinct rendering modes I would imagine this is already the case from a practical point of view.

In theory the actual rendering section of the engine should be really quite small.
All it has to do is iterate through the drawables and draw them to the screen so changing the renderer should be fairly trivial.

[Monsieur OUXX]

Since AGS has two distinct rendering modes I would imagine this is already the case from a practical point of view.

In theory the actual rendering section of the engine should be really quite small.
All it has to do is iterate through the drawables and draw them to the screen so changing the renderer should be fairly trivial.

Yep. I was just mentionning it, that's all. You never know what you'll find :-)

[deadsuperhero]

Alternatively, what about getting some documentation on the AGS API's, file formats, and so on and so forth? I think ultimately, this might make a straight-up from-scratch port seem a lot easier than trying to port it in Mono and graft a new interface over it...

Any word on when the code drop might be for the compiler and such?

[Sslaxx]

Alternatively, what about getting some documentation on the AGS API's, file formats, and so on and so forth? I think ultimately, this might make a straight-up from-scratch port seem a lot easier than trying to port it in Mono and graft a new interface over it...

Any word on when the code drop might be for the compiler and such?

Yes, there are three components - editor, compiler and runtime. At the moment though, for cross-platform purposes the most immediately useful next item would be the runtime, really. On another related note, separating out the compiler from the editor and/or runtime into its own executable would be useful in facilitating cross-platform use.

[Monsieur OUXX]

On another related note, separating out the compiler from the editor and/or runtime into its own executable would be useful in facilitating cross-platform use.

I'm not sure what you mean? Surely the compiler produces only some pseudo-code that's then "interpreted" by the runtime? So I think what you said in the first place is truer than ever: The runtime is the central point for corss-platform.

Anyway, all this chat is sterile as long as the code is not released.