"Are you happy with the executable size?
Do you like having the Runtime Library or prefer a Linker Style Library?"
i think these two kind of go hand in hand. properly implemented, a runtime can be small enough to pack with the EXE, but DBP's runtime is very, very large. having a statically linked library would probably reduce the EXE size drastically. think about it - how many hundreds of functions are there in each DLL? if you use one, do you need the whole thing?
"Do you want to see Object Orientation, and if so.. how?"
more than what there is now, definitely. type pointers with new/delete and passing byref would up the usefulness of types a hundredfold. come on TGC, you're C++ programmers - when's the last time you created all your classes on the stack and passed them byval? that's just bad programming practice.
"Do you prefer the Rotation Commands in DarkBasic v1.0 or Professional?"
i've never really had a preference for either, as i've never run into a problem with either. they work fine for me.
"Would you like to see a Pixel Perfect Collision Engine?"
no. i WOULD, however, like to see a 2d vector collision engine. you can't exactly do sliding slope collision and proper physics if all you know is that 2 objects are overlapping. if that never appears, it's easy enough to make one with NGC, too.
"Is Real-World Physics important to your games?"
sometimes. but that's why we have newton, ODE, and tokamak
they're already fully functional, no need for TGC to reinvent the wheel. an official wrapper would be nice, however.
"Would you like to have direct access to the Rendering pipeline?"
that'd be nice, but i'm not real sure how they'd implement it. besides, there's not much that you can't do now that making access to the pipeline would allow for.
some more.
- What other language features would you like to see?
along with the statically linked runtime, i'd like to see COFF support. that is, all DBP code is compiled to an actual standard COFF. this would make it possible to make TPCs that don't need DLLs, and would also enable users to use some libs that are designed for C/C++. but i don't want to be bothered with making sure i have all the libs for the runtime i.e. winmm.lib, d3dx9.lib etc. just libs that i want to add.
function pointers have already been mentioned, and they would help immensely with things like callbacks and general-purpose scripting engines (LUA). there are workarounds right now, but it would be so hot to write "SomeCFunctionThatWantsACallback &func".
byref, not just for TYPEs, but for all data types.
arrays in types. is it that hard to store a pointer to an array in a type?
more / better pointer support. typed pointers would be ideal, but that would probably make things a bit complex, especially if there's a byref system already in place. at the very least, we need an address-of operator.
i think the language itself really has been overlooked in the design of DBP. the engine has been written, rewritten, and updated constantly, but if you look at the list of language features / changes from DB1, it's pretty embarassing.
- TYPEs, rudimentary at best. darkedit had better types IMO.
- #constant. pretty useful, but messes up the line numbers in debug.
- more data types and "as." some data types are buggy, and there is not consistent support for all of them (no bitops on double ints?).
- strings longer than 255 characters. thank god.
- no variables with the same name as functions. broke a lot of my code, but for the better.
- very limited pointer syntax. it hasn't even been touched since DBP was released.
- very buggy debugger, to the the point of uselessness. CLI never works correctly, watch crashes, and step line numbers are screwed up by includes, #constants, etc.
and that's about it. compared to the list of changes the engine has undergone.. it's pretty ridiculous, don't you agree?
"when it's done" means "we have no idea, we forgot to do that; we were hoping you would all forget we promised <insert exotic promise here>"
