Zandronum

New features include:

• enum declarations
• struct declarations
• region declarations
• Block scoping
• Optional function parameters
• && and || operators use short-circuit evaluation
• goto statement
• Format blocks

Check out the details page for information about the features.

The compiler is mostly compatible with existing ACS code. There are some differences. The logical AND and OR operators are now short-circuit. Variables that are created inside a block cannot be used outside the block.

Note that the compiler and the documentation are still in development, so you might stumble upon unexpected behaviour or inaccurate information.

Please give this compiler a try. Try experimenting with the new features. I'd appreciate any feedback you might have.

I'll update this thread as new developments arise. In the meantime, have a good one!

Download links (August 18, 2014 - Release 2):
Windows 32-bit (Click Raw to download)
Windows 64-bit

You can find the source of the compiler here:
https://github.com/wormt/bcc

Sample ACS code can be found here:
https://github.com/wormt/bcc/blob/master/test/jm.acs

Oh my god! Structures in ACS!!
DO WANT!

This is the future of modding. I have been testing this and it works well, this should be a replacement of acc for every modder.

Doomscript evolution?
Continue your work! Also, you should post this to zdoom.org forums.

---

I want some things:
1. "string1 + string2 + string3" as equivalent for strparam
2. c #define

Example:
3. #ifdef #endif #elif ....

Example:

---

Ok. next.

add this code to common.h to fix linux/unix compilation errors: and you should add CmakeLists.txt to your project (using cmake is better)

here http://pastebin.com/FwUnnvWR
or Makefile
Done.

Thanks, Monsterovich. I'll continue to improve this compiler.

Suggestion #1: I don't know. At this time, I'm gonna pass.

Suggestion #2 and #3: I built a mostly complete C preprocessor some time ago. Every existing ACS directive was processed by the preprocessor code somehow, along with your standard C directives like #define, #if, and #ifdef. I removed the preprocessor because I thought it worked too differently from the way people might expect their ACS code to work. For example, #libdefine worked exactly like #define; and #import worked like an #include, but would only load the file once. It was disappointing to see it go. You can find some of the preprocessor code in a previous commit.

Commit containing (unfinished) preprocessor code:
https://github.com/wormt/bcc/commit/dca ... 7f8c0b1d46

About the Linux compilation error. I only compiled the source code on my Linux Mint box, and I saw no error. So I have no idea.

I used Premake because I wanted something quick and simple. I have a few files to compile, so Premake was a nice solution. I'll see about adding that CMake file. I'm just not familiar with CMake.

Positron wrote: I used Premake because I wanted something quick and simple.

Makefile is simpler. (acc has it) CMake is useful.

---

Positron wrote: I only compiled the source code on my Linux Mint box, and I saw no error. So I have no idea.

Add this anyway, because linux compatibility.

Doubt anyone needs these, but here you have: Macintosh Intel (i386 and x86_64) binaries:
https://www.dropbox.com/s/r8vrxmduywuxr ... .06.15.dmg

Linux and FreeBSD binaries coming soon (of course if someone won't be faster than me).

Keep in mind that these binaries are nohow official, thus Positron takes absolutely no any responsibility for them. I do though.

I do not really know much on the subject, as I have not messed with any kinda source (kinda why I ask), so here we go:
It might be nice with all this new ACS functionality, but what about the source ports? Do they automatically know what to do with these things or do the devs have to work for this to actually work? In which case I would like to know the point.

The compiler converts the code to Assembly. Assembly is almost the machine code of the CPU, in PC case, x86.
ACC (also the BCC) compiles the ACS code to the bytecode (Assembly for Zandronum's ACS "CPU") - which will work on any ACS source port. The actual ACS functions are just "instructions". So if you use different compiler that produces same bytecode, it will be compatibile.

tl;dr: BCC is backward-compatible with ACC.

Did it have any sense?

It all stands clear now, I actually have expiriences looking into assembly code, so I understand what you mean in this case, and it was very nformative and clear. Thank you very much :D

Can somebody provide a Windows x86 build? I don't wanna to use a VM just for x64 build of bcc provided in the OP...

x64 only? Fufufufufufuffu!
Ok, I built it.
Download
I used my own cmake file here!

TY, Monsterovich!

I'm not a pro at script, but If I have understood, it's better that the common acc, so why not, good luck !

No new ACS compiler could change the fact that ZDoom doesn't allow us to reference things that don't have TIDs or didn't activate the script :(

But look at dem struct code support

This is a blessing! Must try asap.

Hi Positron, stumbled upon this project on the ZDoom forums and I must say I am very excited about BCC. Finally, there are some direly-needed features I desperately need (namely structs and enums) in an ACC compiler and the best thing of all (well, my current impression at least) is that BCC looks like it's pretty much ACC with extra features "tacked on" (as awesome as the other variants of ACC compilers available out there, I just cannot migrate because my ACS codebase would require heavy porting work to adhere to these compilers' vastly different syntax). So it seems perfect for my purposes.

(BTW, I don't mean "tacked on" as a bad term :) - maybe it's not the best word to use in this situation but I am actually happy that BCC appears to remain mostly compatible with normal ACC)

The projects I am working on contain a lot of code and I am pretty deep in the production timeline, so I just cannot afford to be set back to "port" my code to a compiler that is so syntactically different... BCC however, looks like I won't have to deal with that stuff!

I don't think I'm using any ZDoom-specific functions (ie something that won't build for Zandronum ACC)... I guess if there's something that won't build, I could run a diff between BCC and ACC and if the changes are small, possibly re-introduce said ZDoom-specific function and make my personal fork of BCC...

I haven't actually tested BCC yet, but I'm going to have to create a branch for my project to make sure my ACS codebase builds perfectly with BCC and possibly fix any tiny errors that might pop up... and then on to rigorous testing of my game to make sure every feature remains working. ;) Once that's done, I'm going to do some heavy re-write to my inventory system (second video) to make use of structs (you don't want to know how I hacked ACC to make this... using multiple global arrays and synchronizing them together to support the data struture I need for my items - UGLY!).

This went on longer than it should have - sorry you had to read all that. ;D Just wanted to say thanks for putting this out... can't wait to test BCC!

EDIT: Upon looking at BCC's source... this isn't really based off ZDoom's current version of ACC, is it? Hmm. That might be problematic for me then... I'm using ZDoom's ACC and heavily rely on it (for example, I use named scripts exclusively). I'm not sure what are the differences between Zandro's ACC and ZDoom's ACC but I imagine the gap to be big? Oh well - I'll get to test and see if I run into any problems.

For instance, named scripts DO work. I'm not sure if you wanted to know anything else.

If that Inverntory system is going to be online, man, it'll be badass O_o
maybe a global var [64][tot_cubes]; and other global vars would help here but, yep, it's a pain in the ass to use doom to create non doom things D: