Quote: "Also, and this one is key, it's interpreted (it doesn't compile in the way DBP does before running). This means for some things it can be a lot faster to code, test and be back coding again, where-as DBP could still be on the "compiling" stage. Granted these cases are few, but for games the size of say the Star Wraith series, I'd bet it's a serious advantage to them."
The machine code DBPro produces isn't even that good, I'd hate to see what kind of code it produces for it's virtual machine... The reason why the professional industry uses C++: It produces better code, faster with more flexibility. DBC nor DBP offers that. If you have a DBP statement, say: x=0+1+2+3, it'll actually encode that machine code:
mov eax, 0 ; would be better as xor eax, eax
add eax, 1
add eax, 2
add eax, 3
mov [x], eax
Even BlitzBasic will optimize that to:
Not only that, but all the error handling code that DBP throws in there is absolutely horrible, and your code is appended to the EXE as a file, rather than actually existing in the EXE itself. I've done statements as simple as: position=start+rate*100 and it'd resort to using the stack to do computations. Not only that, you'd see statements like this produced:
mov $L0, eax
mov eax, $L0
The result? The processor wastes time running that code that does absolutely nothing. You might as well through a dozen NOP instructions into the assembly for fun!
As an additional note: DBP can't even output machine code for floating point commands. It has to call it's core DLL for FPU management. Even things as simple as adding or multiplying. Even though intrinsics such as SIN, COS, ATAN, etc, can easily be implemented as outputting to machine code, it isn't. Converting from an integer to a float requires a DLL call, and much more horrible stuff.
Absolutely nothing is optimized. Not even a simple optimization like converting a MOV <xxx>, 0 to an XOR <xxx>, <xxx> is implemented. And yes, I've looked at the output assembly, turned off safety code, and did everything else I could to produce "tight" code, but it doesn't output any better. The array handling code is even worse than anything else.
If interpretation is an
advantage for you, then you're not doing things right. Under no circumstances should interpreted code be an advantage for a professional developer, with the single exception of a scripting language -- and even then, the scripting language is likely custom made, and builds to machine code on the fly.
Of course, that's looking at DBC and DBP as
professional languages, while they're clearly only meant for novices in the field of programming, and in rare cases, prototyping. So, I suppose it's good for people who don't know how to program and can't expand.
Cheers,
-naota
