Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / A built-in LOD, and a DarkGDK question

Author
Message
Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 6th Oct 2010 08:54
Hi guys,

(Fortunately?) i've spotted that there is a cool built-in LOD system in DBPro, where it doesn't just switch between stages but also fades into the next by playing with transparency. So i won't look for other solutions if it is a pro/fast method, and won't slow down my game if used for a few hundred units/level elements. Have anybody used it at large yet, what do you think?

I'm thinking about kinda experiment and build my game engine in Pro, and when i'm ready, converting it to GDK because i saw it is nearly twice as fast, and even much more faster at some things. My question is that can GDK do everything DBPro can do, or is there anything has been left out so i found myself in trouble when converting? Is GDK as up to date as DBPro? Hasn't it been abandoned or something? (please don't say i should write the code already for GDK, i know, and i would do it if i could, but currently i'm just playing with the idea of learning that language...)
Dodga
16
Years of Service
User Offline
Joined: 12th Dec 2009
Location:
Posted: 6th Oct 2010 10:22
All I can say is converting is gonna be a pain.
Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 6th Oct 2010 11:05
O-OH!

( )
Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 6th Oct 2010 11:09
Well i was being funny, anyways, evidently... though if you have all the system and its dynamics of your game tested and working, it shouldn't be so hard to reaccomplish everything in a new language, ESPECIALLY if it is basically the same but looks differently written down.

I won't sit down and word by word translate, i'm gonna (though if i choose to, cus i still don't know if i should, somebody please answer my questions up there...) work from scratch keeping all the previous experiences in mind.
Morcilla
23
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 6th Oct 2010 11:41
DGDK Lod functions are working fine as far as I know. However I haven't tested it with that large amount of objects that you state (I really haven't tested it at all, I just talk by what the others say in the DGDK forum).

I don't think you are going to have much trouble converting from DBPro to DGDK. All DGDK functions are more or less up-to-date.
Latest version is DGDK 7.4, just one small step behind DBPro.

I hope TGC updates DGDK in the near future (instead of producing more games ), as now DBPro 7.5 is a stable version, isn't it?

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 7th Oct 2010 07:41
don't confuse yourself that DGDK is a language on its own. Your code is written in C++, and it uses the DGDK libraries.

C++ Is nowhere near the same as DBPro. It can be very similar if you're just sticking to procedural coding, but the beauties of C++ lie in things not necessarily present in DBPro (OOP=inheritance, polymorphism; you can have full control over memory management/pointers; operator overloading; function overloading; different methods for handling arrays and like objects; different system for declaring variables, etc.)

What makes sense is to program in C++ using DGDK, what also makes sense is to prototype in DBPro then program in C++ using DGDK, what doesn't make sense is to write the same code twice in two different languages, one of which you don't know (correct me if i'm wrong 'bout that. I dun rly know)

Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 7th Oct 2010 08:39
Maybe not a good idea for a pro to write code twice, but i'm not so confident about my knowledge to say i just jump into C right awaaaay!

Anyways, all DBP commands are present with "db..." as the first two letters, aren't they? It seems to me that it is DBP with the availability of C stuff... am i wrong?
Morcilla
23
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 7th Oct 2010 11:09
Quote: "all DBP commands are present with "db..." as the first two letters, aren't they?"

True, although some 'low level' functions that traditionally have optimized algorithms in C/C++ are not there. Talking about things like Load Array or Save Array.

Quote: "It seems to me that it is DBP with the availability of C stuff... am i wrong?"

That's completely true if, like Neuro Fuzzy said, you're just sticking to procedural coding.

I do not really understand why people try to do the DBPro-->C++ jump, as that is nearly impossible or very difficult, as it is a change in programming philosophy.

It is much more natural to do the DBPro-->C jump and then the C-->C++ one.
So, it is up to the programmer to use all those fancy OOP fetures or not.
In the same way, you can program C language using memory pointers or not.
With C/C++ there are many advantages present, but it is not mandatory to use them all at once.

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 7th Oct 2010 11:18
C isn't C++

its not DBP with the availability of C++ stuff, its C++ stuff that can access the same commands in DBPro.

Any time you would use a DBPro native function, you just have a db prefix. Any time you would use anything else, you do it in C++. The biggest problems for me switching straight from DBPro to C++ were:

There's no primitive "string". There's just an array of chars. (a char is a byte representing an ascii character)
Arrays are of fixed size - which means inserting anything requires deleting the array and creating a new one - to do this you deallocate then allocate the memory.
The concept of a "global" is a bit different, as variable scope is important.
All variables have to be explicitly declared.
Include files and compiler options have to be taken into account.
There is no strict equivalent of a UDT (Generally "struct"s are used, but those can have methods and properties same as a class)

...and that's stuff just to convert straight DBP to C++/DGDK. The real cool stuff in C++ comes with Object Oriented Programming. For example, If you have the following declaration of a class called "vector2":


If you had a vector2 called "ABG", you could say this:

vector2 MyNewVector2=ABG.normalized();



Of course, it's too much to handle just having stuff thrown at you like I'm doing

Try taking a look at some code you've already written, and try converting that code and compiling it.

Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 7th Oct 2010 11:46 Edited at: 7th Oct 2010 11:47
Uh, i'm far away from the situation arguing about C or C++, should i have said there "not Dark BASIC"...

I don't have no philosophy behind "from DBP to C" or "from DBP to C++" as i'm completely unaware of what's the difference between the two, but i guess they are similar thus the similarity in their names, so i just called them like a bunch as "C".

Morcilla called this a "jump" and how strange it is, well, don't tell me it is a more stupid thing to do to master some language, and then trying to master an other one, THAN trying to learn a hardcore stuff like C++ to begin with..

And in my case, this 'some language' just happened to be BASIC and not C.

Thank you all for these nice comments.

Login to post a reply

Server time is: 2026-07-22 03:51:26
Your offset time is: 2026-07-22 03:51:26