Compiled ACS/Decorate
Compiled ACS/Decorate
I was wondering how compiled ACS works and how compiled decorate is going to work. If it's not too ridiculously complicated, I might be able to write a compiler or decomplier for one of these.
Last edited by justin024 on Sat Mar 18, 2006 5:14 pm, edited 2 times in total.
It seems someone has
Randy wrote:Q. If you really are doing this, you'd better not make me compile my DECORATEs before I put them in a wad!
A. The compiler will be integrated directly into ZDoom, so you will not need to perform any extra steps when you build your wad. Depending on how long it takes to compile the thousands of classes that I will be able to move out of the executable, there will probably be a facility for precompiling the data, but it will be an optional step, not a requirement.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49234
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
I hope Randy reconsiders his plans for an external DECORATE compiler. In terms of speed it isn't necessary (All the relevant code would compile without problems in a very few seconds and hardly add to the startup time) and it would mean giving up a lot of flexibility because you'd have to put a lot of knowledge about the engine into the compiler. In fact I'd even consider putting the ACS compiler into the game so that it can run levels with only a script in source form. It would massively ease the means to add new features to ACS.
- Bio Hazard
- Posts: 4019
- Joined: Fri Aug 15, 2003 8:15 pm
- Location: ferret ~/C/ZDL $
- Contact:
- Apothem
- Posts: 2070
- Joined: Sat Nov 29, 2003 7:13 pm
- Location: Performing open heart surgery on an ACS compiler.
That would rock!Graf Zahl wrote:In fact I'd even consider putting the ACS compiler into the game so that it can run levels with only a script in source form. It would massively ease the means to add new features to ACS.

- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49234
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
That's one reason. Another one is that an external compiler makes changes significantly more complex. For each small thing you have to maintain 2 projects - which is why I am quite hesistant to add ACS extensions to GZDoom. An internal compiler would solve this perfectly because you no longer depend on external tools for which countless versions exist (and experience shows that far too many users - even mappers - don't really bother to update them.)Bio Hazard wrote:Graf doesn't people making maps without SCRIPTS lumps.
With DECORATE it would be even worse because the system will be considerably more complex than ACS. Do I need to point to VavoomC for something that doesn't do what it is supposed to do because it compiles everything into a large monolithic block? What's the point of an externalized language if all you can do is recompile the entire game at once? With that we are no better off than with a source modification and the programming isn't simpler as well. True flexibility comes from being able to piece the separate parts together according to the user's needs.
You'd have to put in an empty BEHAVIOR lump that contains only a special marker. This would be necessary because otherwise all the editors out there would get problems.Also, how could the internal ACS compiler know when to compile the scripts? There will always be a BEHAVIOR lump.
Unless you want hexen to be distinguished by either BEHAVIOR or SCRIPTS