Sorry your browser is not supported!

Note to mods: If this is on the wrong board, feel free to move it.



OpenDarkBASIC is a re-implementation of the DBPro compiler built on top of LLVM. The initial goal of this project is to be a drop-in replacement for DBPCompiler.exe with full support for the existing DBPro SDK and language. If we do our jobs, you should not notice any difference!

@dga has laid all of the ground work for interfacing with the original DBPro DLLs. As of this writing, OpenDarkBASIC is able to produce executables that use the existing DBPro engine. We aim to be backwards compatible with all existing DBPro projects.

It is a cross compiler, meaning, it it is possible to run the compiler on either Windows/Mac/Linux, and compile executables for Windows/Mac/Linux/Web (in theory). Because the DBPro DLLs only work on Windows, it'll be necessary, as a secondary goal, to add a new cross-platform SDK to support a modern graphics API so you can write games for all operating systems. Work on this has not yet been started, aside from some very primitive plugins for printing hello world.

Features
Cross Platform support
Compatible with the original DBPro language
Helpful error and warning messages
Optimizing compiler
Plugin framework for extending the language with new commands
Comes with an editor

In particular, I want to highlight the two main selling points of this project: Error messages and optimizations. A ton of work is being put into generating useful error messages. Example:


DBPro will happily compile this code and print 8. As most hopefully know, 5+3.5 is NOT 8.

OpenDarkBASIC will also compile this and print 8, but it will output some warning messages:



As you can see, it's warning you that the result of pos#+var1 is being converted into an integer. You can expect this kind of quality for all types of warnings and errors.

Optimizations: If you were to look at the disassembly of that code produced by the DBPro compiler, it would be longer than the height of your screen. The DBPro compiler may produce machine code but it does a terrible job at it.

OpenDarkBASIC is very different in this regard. Because we are using LLVM, we have access to the last 40 years of compiler optimization research. Here is the compiled code of OpenDarkBASIC, with and without optimizations:



As you can see, it's managed to delete all variables and call print directly with the value of "8".

What this means is: If you have written algorithms in in DBP such as pathfinding, collision code, or physics, chances are OpenDarkBASIC will be able to optimize them as efficiently as it would C or C++ code.

Progress

It's still in pre-alpha stage at this point and there is a lot to do. The good news is, it is clear how to do it. Here is an overview of the progress:

DBPro Language Support
- Command calls and plugin support
- #constant statements
- Variables
- Assignments
- Binary and Unary Operators
- - Arithmetic operators (+-*/^ mod)
- - Bitwise operators (<< >> || && ~~ ..)
- - Logical operators (< <= > >= <> or and xor not)
- - Increment/Decrement
- Scope specifiers (Global/Local)
- Functions
-- Standard functions
-- Polymorphic functions
-- Local/Global functions
-- Nested functions
-- Default arguments
-- Cross-file function calls
- Subroutines
- Arrays
- User-Defined Types (UDTs)
- For-Loops, While-Loops, Repeat-Loops, Infinite-Loops
- If-Then statements
- Goto
- Select/Case statements
Extended Language Support
- Matrix types and operators
- Vector types and operators
- Quaternion types and operators
- Imaginary number types and operators
Compiler internals
- Plugin loader
- - DBPro core command support
- - DBPro licensed plugin support
- - Command cache
- Code generation
- - Start and stop DBPro engine
- - Call DBPro commands
ODB SDK
Editor
DBPCompiler.exe wrapper

Downloads


Coming soon!

Curtesy of @dga: This is from his game Star Scape, compiled using OpenDarkBASIC:

Very much looking forward to this. DBP in all it's forms just broke on fresh installs of W10. DBP apps using 3D fail to launch due to some weird incompat between the ancient compiler/editor and the latest W10 updates.

I've also been having issues. I guess DX 9.0 is just too old.

Update: I was annoyed at how slow loading commands takes, so I implemented a command cache feature to fix this. Left is without the cache, right is with the cache. It's really not a fair fight



Commands are loaded by parsing the DLL files, and on my installation there are 91 plugins total. Due to how the DBPro language was designed, it's actually impossible to parse the syntax without knowing all of the commands ahead of time. That's why it's necessary to do this.

Interesting!
After DBProEx there were no attempts to update DBPro (compile speed, stability)
I also remember that Bored of the Rings tried to finish a multi-threaded version of the compiler, but it was never released.
So it is wonderfull that DBPro wil get improvement.
If you want Mac/Linux compatibility, you will need to switch from DirectX to OpenGL (like in AppGameKit), so all shaders will have to be rewritten.
And what about .dds textures? Will they still work with OpenGL?

Updates:

Conversions to boolean

This is necessary for if statements, because you need to tell if a value is "true" or "false":


Single-line if/else-statements:


Multi-line if/elseif/else-statements:


Inline if-statements


"Help" in Diagnostics

I did another pass on diagnostics so it's possible to insert suggestions into your code. I really like the idea of the compiler being able to give you suggestions on how to fix your code:





Yeah, it'd be necessary to either rewrite or heavily modify the DBPro plugins. Currently I'm focused on getting the original DLLs working. Later, when the compiler is feature-complete, I can think about adding support for other engines.

If anyone wants to work on compiling/updating the DBPro DLLs and integrating it into this compiler, feel free to contact me.

All the best of luck with the work on this. This will be great!

Thanks!

Updates:

Do-Loops, While-Loops and Repeat-Loops are implemented.

Loops are getting a small upgrade. I'm introducing the concept of named loops. The syntax looks like this:


Named loops fix one small but annoying situation: If you want to break out of both loops simultaneously, you can now use exit <name> or continue <name> instead of having to use goto or using an outer check. It's also possible to goto a named loop.

For-loops

For loops are a little special compared to the other loops. You can name your for loops if you want to, but if you don't, then their name defaults to the loop's variable. This means you can write:


This will break out of both loops when failure() returns true.

In addition, the continue keyword has the ability to override a for-loop's step behavior:


This is often useful when you are for example deleting items from an array while also looping over it:


These are still fairly new features so not all situations have been tested properly yet.

This is extremely welcome news! Looking forward to trying this out! It still seems like there's some core functionality to be added, however this kindoff calls for an entirely clean DBPro install along with the 9Ex version to bring the whole thing into Win11.
I am doing a few dlls myself, so if any action is needed to tweak those, that's absolutely doable as well.

Been working hard on getting my compiler to interface correctly with the DBP SDK. The initialization sequence is quite complicated, but after a lot of trial and error, I finally got it to start up correctly.

There are still a lot of finer details to iron out when making calls to the SDK, so not all commands work correctly yet. I still have to add support for commands that return strings, and commands that have out-parameters (such as "dim").

I also struggled quite a bit with getting LLVM to produce correct 32-bit machine code and compiling/linking 32-bit runtime libraries correctly (Looking at you CRT). Because the compiler itself is a 64-bit application but generates 32-bit applications, there are multiple stages involved.

Nevertheless, here is a small demo showing a more complex DBPro program first being compiled by the original DBP compiler, and then being compiled by OpenDarkBASIC:

Great news! It would be awesome to be able to work with DBPro code again!

Great news! Keep going. Congratulations

Got an update for you today: Variables and types. As you know, DBPro supports syntax for 3 types of variables, var# for floats, var$ for strings, and a plain old var for integers.

For ODB, I am introducing some additional annotations for types. The complete list as of now is:
- var? for booleans
- var% for words (16-bit unsigned integer)
- var& for double integers (64-bit signed integers)
- var# for floats
- var! for doubles (64-bit floats)
- var$ for strings

ODB will warn you as best as it can in situations where the types don't match. For example:



Not all types supported by ODB have syntax associated with them. You can declare variables as a certain type using the AS DWORD, AS BYTE syntax in these cases.

I'm also not 100% sure if the charactersI chose are a good choice or not, or whether I will add characters for the missing types.

Further, you can now use the same AS TYPE syntax to cast expressions. For example:



If you type c# = a * b# then ODB will warn you about implicitly converting a to a float. This way you get rid of the warning. (Or you can just disable these kinds of warnings, depending on your preferences for how strict you want the compiler to be).

Amazing work TheComet. I've recently gotten back into working with DBP for a hobby project, so something like this would be incredible to implement.

Today's update took quite a bit of re-thinking on how I solve type checking in my compiler, and how I organize the ASTs, but I'm very excited about this.

Functions get an upgrade compared to DBPro!

Polymorphic Functions

First off, I want to demonstrate the concept of polymorphic functions. Scary name, I know, but simple to understand. Some languages call these functions generic functions or template functions. If you create a function without specifying any types, like so:


Then the types of a and b are inherited from the call. In other words, sum(2, 3) will cause an integer addition, while sum(2.0, 3.0) will cause a float addition. Effectively, different versions of the same function exist in the program matching every version of how it is called.

You can see the behavior in this example, where I call sum(2, 3.0). This will create a version of the function with the signature function foo(a as byte, b as double) as double, and therefore it will create a warning because byte is converted to a double:


Partial Polymorphic Functions

This is when you fix the type of one function parameter, but not the other.


As you can see here, b will always be an integer, but a will inherit the type from the caller.

Function Return Type

If you want to fix the return type of a function, for example if you want it to always return a float, then you can add an as type at the end:


This means even though a is an integer, it will always be cast to a float when returned:


Cross-file Function Calls

Currently, function calls between multiple .dba files are a work-in-progress. It's a complicated issue because you basically need to jump back and forth between files as you solve the type information, and this gets more complicated when you compile in multiple threads.

Nested functions

I would also like to support defining functions inside functions:

Progress has been rather slow. I am in the process of adding support for User-Defined Types, and it has forced me to rethink how I handle types in general. Up until now a type was just an integer ID, but that's not enough to store UDTs. I had to create a new system that lets you store UDT declarations as part of the type info. I think I'll be able to show something for this pretty soon.

In the meantime, I added support for loading commands from external DLLs directly into the language. On linux, DLLs end with the .so extension:



There's a joke going around that as soon as you can open a window using raylib, that's the point when your language becomes a "real language". So hooray, DBP is a real language

The way this works is: Within the libraylib.so shared library, there is a function called void InitWindow(int width, int height, char* title);. During preprocessing, #load command tells the compiler what the function is called, what arguments it has, which library it needs to look for to find it, and maps it to a DarkBASIC command name "init window". From that point forth, you will be able to call init window x,y,"name" as if it were a DarkBASIC command.

This is very similar to how DBPro plugins already function, so adding this feature was straight forward. DBPro plugins already have the command list stored inside of them, so you don't have to go and load them explicitly from within DBPro.

What this means for OpenDarkBASIC is: It's now possible to use a game engine that was written for C or C++ from within DarkBASIC. I think that's pretty cool!

Well, almost. Currently, you can only import functions with primitive types like INTEGER, STRING, WORD, etc. There are a lot of C/C++ libraries that need you to pass structs around. Once I get UDTs working, that's when it'll become possible to call more complex functions from DLLs.