zt-bcc (Zeta Group BCC) is a continuation of Positron's BCC with bugfixes and some new features, along with proper SLADE support.
It's an alternative ACS code compiler for ports supporting ZDoom ACS, featuring many extensions over vanilla ACS, but still keeping almost 100% compatibility with it, to make projects easy to port over and take advantage of all the new features.
Some of the features over regular ACS include:
*Structures
*Enumerations
*Namespaces
*Preprocessor
*Strong types
*References to objects (limited support) and functions (full support)
*Block scoping
*Optional function parameters
*Logical-AND (&&) and Logical-OR (||) are short-circuited
*foreach loop
*Nested functions
*Message-building blocks, for more dynamic prints and text formatting
zt-bcc now has libbcs, a standard library of it's own. This currently provides malloc/realloc/free, dynamic array functions, and C-style printf functions.
If you find any bugs, please post about them here or on the Github repository for the project.
Check the project wiki for documentation on zt-bcc's features and usage. And also how to set SLADE up to use it.
Download: https://github.com/zeta-group/zt-bcc/re ... .0-alpha.2
Source code: https://github.com/zeta-group/zt-bcc
zt-bcc: Maintained BCC fork - v0.10.0 alpha 2
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
-
- Posts: 823
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
zt-bcc: Maintained BCC fork - v0.10.0 alpha 2
Last edited by TDRR on Mon Dec 02, 2024 2:55 pm, edited 2 times in total.
-
- Posts: 823
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: zt-bcc: Maintained BCC fork - v0.9.0
This is zt-bcc, a fork of BCC, that supersedes BCC-SLADE since it accomplishes the same purpose better, and then does some more.
Changes compared to BCC 0.8.0:
*Added #pragma raw define on/off, which allows enabling/disabling C-like preprocessor macros.
*Added #pragma raw include on/off, which allows enabling/disabling preprocessor include (can appear at almost any point in the file).
*Preprocessor directives are now case insensitive like the rest of the language.
*Fixed broken runtime assert message (was supposed to be tinted red originally, but the code for it was buggy).
*zt-bcc can now be used with SLADE to compile BCS code. Doom Builders should work too, but currently untested.
*Removed ACS/ACS95 compilation modes. If needed, BCC 0.8 or ACC can still be used for this purpose.
*zcommon.bcs should be up to date with all new Zandronum, GZDoom and K8Vavoom functions.
Source changes:
*Removed all non-standard functions (hopefully).
*Fixed all warnings, at least when compiling under MSYS2 with MinGW.
Changes compared to BCC 0.8.0:
*Added #pragma raw define on/off, which allows enabling/disabling C-like preprocessor macros.
*Added #pragma raw include on/off, which allows enabling/disabling preprocessor include (can appear at almost any point in the file).
*Preprocessor directives are now case insensitive like the rest of the language.
*Fixed broken runtime assert message (was supposed to be tinted red originally, but the code for it was buggy).
*zt-bcc can now be used with SLADE to compile BCS code. Doom Builders should work too, but currently untested.
*Removed ACS/ACS95 compilation modes. If needed, BCC 0.8 or ACC can still be used for this purpose.
*zcommon.bcs should be up to date with all new Zandronum, GZDoom and K8Vavoom functions.
Source changes:
*Removed all non-standard functions (hopefully).
*Fixed all warnings, at least when compiling under MSYS2 with MinGW.
-
- Posts: 823
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: zt-bcc: Maintained BCC fork - v0.10.0 alpha 1
An alpha release. I still intend to do more with this before a full release, but here's a preview of the changes so far.
Changelog:
-Added libbcs.bcs. Currently provides malloc/realloc/free, dynamic array and C-style printf functions.
-Added zcommon.acs, which simply imports zcommon.bcs.
-Nullable array/struct references can now be cast to/from int, allowing some rudimentary pointer arithmetic.
-"::" is now the namespace separator. [Positron, for BCC]
-Added "lengthof()" operator. [Positron, for BCC]
-Deprecated ".length()" array/string member functions. [Positron, for BCC]
-Deprecated "." as namespace separator. [Positron, for BCC]
-"lengthof()" can take in structure references now.
-Diagnostic messages are now written to stderr instead of stdout.
Changelog:
-Added libbcs.bcs. Currently provides malloc/realloc/free, dynamic array and C-style printf functions.
-Added zcommon.acs, which simply imports zcommon.bcs.
-Nullable array/struct references can now be cast to/from int, allowing some rudimentary pointer arithmetic.
-"::" is now the namespace separator. [Positron, for BCC]
-Added "lengthof()" operator. [Positron, for BCC]
-Deprecated ".length()" array/string member functions. [Positron, for BCC]
-Deprecated "." as namespace separator. [Positron, for BCC]
-"lengthof()" can take in structure references now.
-Diagnostic messages are now written to stderr instead of stdout.
-
- Posts: 823
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: zt-bcc: Maintained BCC fork - v0.10.0 alpha 2
Another alpha release. This has a very big focus on references/pointers and brings zt-bcc more up to par with GDCC in that aspect, including great benefits like using world/global arrays for dynamic memory allocation, interoperability with modules using pointers written with GDCC and more flexibility improvements like that.
-Added pointer types, same syntax as references but using `*` instead of `&`/`?`.
-Added support for references/pointers into world/global arrays. Example: (`int[] world:10* test;`)
-Added `void` array nullable reference/pointer type. This type can be implicitly converted to any other reference/pointer type.
-Added `internal` keyword to replace current `private`.
-Added `PTR_SPC` macro to libbcs. When defined before including libbcs, it's pointers and functions will use the world/global array specified. Example: (`#define PTR_SPC global:42`).
-Added `alloca` to libbcs, which will automatically free the memory after one tic.
-libbcs `malloc` will now return `0` when appropriate.
-libbcs memory allocation will now display an error when out of memory.
-libbcs local heap size is 4x bigger by default (65536 words).
-libbcs errors/warnings are now colored.
-Deprecated `private` keyword for object visibility (except when applied to namespaces).
-Added pointer types, same syntax as references but using `*` instead of `&`/`?`.
-Added support for references/pointers into world/global arrays. Example: (`int[] world:10* test;`)
-Added `void` array nullable reference/pointer type. This type can be implicitly converted to any other reference/pointer type.
-Added `internal` keyword to replace current `private`.
-Added `PTR_SPC` macro to libbcs. When defined before including libbcs, it's pointers and functions will use the world/global array specified. Example: (`#define PTR_SPC global:42`).
-Added `alloca` to libbcs, which will automatically free the memory after one tic.
-libbcs `malloc` will now return `0` when appropriate.
-libbcs memory allocation will now display an error when out of memory.
-libbcs local heap size is 4x bigger by default (65536 words).
-libbcs errors/warnings are now colored.
-Deprecated `private` keyword for object visibility (except when applied to namespaces).
-
- Posts: 2047
- Joined: Mon Aug 11, 2003 1:50 pm
- Location: Waveney, United Kingdom
Re: zt-bcc: Maintained BCC fork - v0.10.0 alpha 2
I have to say this is incredibly cool
But I think the lack of replies is probably because its too advanced for most people to use; for everything but map manipulation we have ZScript and there's a lot of that which you can do with ZScript, especially as you can now create your own sector effectors, in the style of Duke 3D's, to add to those already in the engine. For everything else, ACS is probably sufficient and those like me with C and C# experience feel right at home in ZScript and ACS, and don't really need a C++ modeled language. If years ago, RH had extended ACS into actor control instead of developing ZScript, this would have been truly awesome.
But I think the lack of replies is probably because its too advanced for most people to use; for everything but map manipulation we have ZScript and there's a lot of that which you can do with ZScript, especially as you can now create your own sector effectors, in the style of Duke 3D's, to add to those already in the engine. For everything else, ACS is probably sufficient and those like me with C and C# experience feel right at home in ZScript and ACS, and don't really need a C++ modeled language. If years ago, RH had extended ACS into actor control instead of developing ZScript, this would have been truly awesome.
-
- Posts: 823
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: zt-bcc: Maintained BCC fork - v0.10.0 alpha 2
I appreciate your observation, but I think it's kinda missing the point. This isn't really meant for GZDoom, even though I do make sure to keep compatibility with it whenever possible in this fork. Yes, GZDoom does have ZScript. However, Zandronum, Eternity, K8Vavoom*, and likely other ports, do not, but they have perfectly good ZDACS interpreters that can use compilers like this one and DavidPH's excellent GDCC. I don't even use GZDoom myself, but I'm posting the project here because it may still be useful, and there's people that develop mods for other ports here (and even post them here as well).MartinHowe wrote: ↑Mon Dec 02, 2024 5:40 pm I have to say this is incredibly cool
But I think the lack of replies is probably because its too advanced for most people to use; for everything but map manipulation we have ZScript and there's a lot of that which you can do with ZScript, especially as you can now create your own sector effectors, in the style of Duke 3D's, to add to those already in the engine. For everything else, ACS is probably sufficient and those like me with C and C# experience feel right at home in ZScript and ACS, and don't really need a C++ modeled language.
As an aside, yes, plain old ACS is probably enough for map scripting. I still do find myself missing type safety, enumerations, foreach loops and the automatic optimizations alternative compilers can give, even in those simple cases. It just makes writing code easier and faster, and BCC intends to be 100% compatible with plain old ACS, so there's a quick and painless upgrade path for anyone that'd like to start using it.
*yes, K8Vavoom has a ZScript-like language, and that's from long before ZScript even came to be, but the developer wants people to use DECORATE+ACS since they're more well documented and standardized.
-
- Posts: 2047
- Joined: Mon Aug 11, 2003 1:50 pm
- Location: Waveney, United Kingdom
Re: zt-bcc: Maintained BCC fork - v0.10.0 alpha 2
Good point. I'd completely forgotten about MP as I only play single, so yeah, Zandronum; for other ports that can run ZDoom ACS code, I guess this gives much of the power of ZScript. It's hard to forget that despite having virtually taken over the post limit-removing world, there are other options than GZDoom.
-
- Posts: 823
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: zt-bcc: Maintained BCC fork - v0.10.0 alpha 2
It's alright. That's something that over the years I've come to realize is, unfortunately, quite common.