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 / DBP -> 100% machine code?

Author
Message
solo
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 6th Dec 2002 15:59
Link
What's the meaning of 100% machine code?
i've converted a C-language program that initiates an array
of 20000 elements with random values,
sort it and checks wether it is sorted -
into a DBP program.
I USED NO GRAPHICS AT ALL!
The DBP exe was 10 times slower than the C exe.
Is this performance typical to DBP?
Back to top
Profile PM Email
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 6th Dec 2002 16:10
Link
That just means that it's compiled, everything ends up as machine code, in face every .exe file is machine code, whether the source is inbedded into the exe like with DB1, or it's compiled into machine instructions like C or DBPro.

Thing is, DBPro executables will no doubt have baggage to setup all sorts of stuff for DX, memory handling, screen handling etc etc, which means it's not an ideal language fill, sort, and check an array.

The benefits of DBPro over C/C++ are not speed, but ease of development, that's why we can make little games in a few days that would take a month of headaches in C++.


Van-B
Back to top
Profile PM Email
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 6th Dec 2002 16:46
Link
Solo:

Yes, the compiler doesn't spit out blazingly fast code as yet. There's a few reasons, some of which Van has already mentioned. In order to keep the language safer for it's intended audience (from beginners up), there is some system baggage tied to various structures. Loops are good example of this. Loops are padded with win message handling already .. This safety comes at the price of speed...

Lee has already put in a place a sort of release mode, for the making the compiler not latch in any debug styled code into the resulting exe. This is of course much faster, but places the onus of user safey on us. This patch is not currently publicly available. Although ironically the Dbpro haven't really been optimized as yet. DBS want to get it stable first, then see about improving it's raw performance..

l8r,
Kevin Picone
[url]www.uwdesign.50megs.com[/url]
Back to top
Profile PM Website
solo
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 6th Dec 2002 16:49
Link
ok,
is it advisable to use DLLs+memblocks for data calculations/manipulations in C++,
and the visuality in DBP -
in order to create more than "little games"? i mean, real intense commercial games?

Back to top
Profile PM Email
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 6th Dec 2002 17:04
Link
I would'nt say so. The extra problems that memblocks and .dll usage might outweigh any speed benefits. DBPro is reasonably fast at logic calculations; the time would be better spent optimising your game logic to run as fast as possible.

My opinion is all.


Van-B
Back to top
Profile PM Email
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 6th Dec 2002 17:27
Link
Solo:

Personally, if your comfortable enough building some of your most recursive code segments into dll functions. Then sure you could improve the number crunching performance dramatically. Even generate code opt'd for various cpu types, which Dbpro doesn't do.. Although, it depends upon what your aiming to do.

For the sake of an example, lets say you prototype an RTS game (or something that requires some pretty recursive Ai overhead). If this proves too slow, after refining the method as much as possible in native Dbpro. Then the DLL option is always there. Although even if the DLL is 10->15 times faster, it's still not a magic solution. But it would be worth it..

As for making commercial quality titles yet, well, nobody really knows just yet..

l8r,
Kevin Picone
[url]www.uwdesign.50megs.com[/url]
Back to top
Profile PM Website
solo
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 6th Dec 2002 18:22
Link
well, i want to take the benefits of DB and mix with the
benefits of C++.
did anyone try to create a program in C++ that communicates with a thread of DB by memblocks?
(i mean a sharing of memory between 2 programs).

I think that its possible to run simultaneous 2 programs:
the first is the C++ exe that uses OOP and allocate memblock. This program should maintain the whole workflow
except the graphic side.
This exe activates a DB exe (as a thread, cause we don't
want the 'parent process' to wait until the 'child process' ends).
The DB(='child') draws the graphics, get the input devices coordinates and pass it to the C++ (by the shared emory)
and the C++ passes the new position of the graphics entities (again, through the shared memory).
Its not necessarily the speed that i gain here - but the design and the maintenance of OOP.

Back to top
Profile PM Email
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 6th Dec 2002 21:43
Link
Well, you can do it that way, but there are better ways ... like the one I'm working on at the moment.

As a demonstration of the techniques, I'm working on a tiling system in C++, in a 'Third Party Command' extension DLL that will call the image drawing routines in DBPro directly.

It will be at least another couple of days before I release it into the wild though, and will only run under Patch 3.1+.
Back to top
Profile PM Email Website
solo
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 6th Dec 2002 23:15
Link
IanM:
Third party commands are not running simultaneously as
my approach (DB doesn't support simultaneous processing).
Each time you call a DLL you must build and initiate
your C++ objects, while i want to keep the C++ program alive all the time...

Back to top
Profile PM Email
rapscaLLion
21
Years of Service
User Offline
Joined: 29th Aug 2002
Location: Canada
Posted: 6th Dec 2002 23:18
Link
ya, you could use C++ to do all the power-number-crunching, and DB for graphics... ie- a MMORPG, the graphics would be in DB, the client and all memory intensive numbers are done in C++.

Alex Wanuch
aka rapscaLLion
Kousen Dev Progress >> Currently Working On Editors
Back to top
Profile PM
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2002 02:28
Link
@solo: I thing you misunderstood me. I am calling DBPro routines with C++. As long as I serialise access to the DBPro commands, I won't have any problems - I'll just be using DBPro as a graphics/input engine, with all of my game code in C++. And it can be multithreaded if necessary.

So, 1 thread to access DBPro commands, other threads running the game logic. Is this not what you wanted to get running?
Back to top
Profile PM Email Website
solo
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 7th Dec 2002 12:19
Link
IanM:
I think i missed you somewhere...
do you call DBP routines within your C++?
you are the one that claims (from other post) that you
have no access within C++ to functions/variables of DBP.
The only way i see, and correct me if i'm wrong, is to
activate the whole DBP exe as a single black-box.
Whats the meaning of "serialise access to the DBPro commands"? I belive that we both mean the same, but i didn't get your whole idea.

Back to top
Profile PM Email
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2002 20:01
Link
Sorry, my other post was not clear - you cannot call your own functions or variables within DBPro (except for reading arguments passed), but it is possible to call DBPro's internal command functions, for example to paste an image to the current bitmap, or move a sprite.

Access to these functions would need to be serialised to ensure that the DBPro engine would not be crashed. ie they should not be accessed in a multithreaded way, only one thread should access the DBPro engine at any one time.
Back to top
Profile PM Email Website
solo
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Israel
Posted: 7th Dec 2002 22:34
Link
Thats interesting. could you send me a piece of code
that call an internal function? that would be a breakthrough for me.
can i use as internal function the 'create memblock'?
if so, the memblock could be the pipe between the C++
and the DB thread. isn't it?

Back to top
Profile PM Email
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th Dec 2002 12:23
Link
If that's all you want to do, then create your memblock within DBPRO and pass its address to your c++ function.

I'm still working on the other stuff, but if you email me, you'll be the first non-DBDNer to recieve the source and documentation ahead of general release.
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-04-30 15:25:34
Your offset time is: 2024-04-30 15:25:34