Skip to main content
gamedev.net
🔒 Locked

Delphi objects or DLL?

Started by Sly Nov 9, 2000 at 2:18 AM 9 replies 600+ views
Original Post
Sly
Sly
With my game engine, I am at the point where I am trying to decide whether I want to keep the Delphi objects exposed, or move the whole thing into a DLL that can be used by any other language out there. What do you think? Objects or DLL? I am leaning towards the DLL at the moment.
Steve ''Sly'' Williams Tools Developer Krome Studios
risingdragon3
risingdragon3
quote:

I am leaning towards the DLL at the moment.



Go for it, tho'' if you do, then you won''t be able to use properties, and you will have to use the standard C calling conventions. If you want to allow all languages to use it. Which is the whole point, otherwise you would just keep it as Delphi Objects. Right?

------------------------------
BCB DX Library - RAD C++ Game development for BCB
Gunner
Gunner
Excellent question Sly,

Funny this topic popped up, i was wondering pretty much the same thing.

Also,
Is there a speed difference in having your procedures in a DLL as opposed to directly have them in your program ?

Anyone know ?

Thanks,

Gunner.
SiCrane
SiCrane
Speed hits from using a DLL:

-Slightly slower load time (nothing noticable unless every single function is in it''s own separate DLL).

-Slightly increase binary size, which leads to slightly worse cache performance (not appreciable) and slightly increased chance of page faults (or slightly increased memory requirements).

-Depending on how the DLL is used, it might incur an additional pointer indirection in function calls which costs maybe an extra clock cycle every function call. (So don''t use an external DLL function in a tight loop.)

So really it doesn''t really matter, just don''t create a new DLL for every function, and you probably will never notice anything different. (And don''t forget to rebase your application/DLLs together)
ggs
ggs
Answer : packages.
The power of direct interfacing with an object but in a DLL
Eric Grange
Eric Grange
ah... cross-langage compatibility... if this is the aim, what about COM ? This may look a bit tricky at first, but:
- object-oriented look and feel
- easily imported in any decent compiler

Eric Grange
http://glscene.org
---Eric Grangehttp://glscene.org
Sly
Sly
Answer : packages.
The power of direct interfacing with an object but in a DLL


And restricts the library to Delphi and BCB only. I want wider usage, particularly Visual C++. And I believe packages will require BORLNDMM.DLL if I am not mistaken.

ah... cross-langage compatibility... if this is the aim, what about COM ? This may look a bit tricky at first, but:
- object-oriented look and feel
- easily imported in any decent compiler


COM objects must be registered with the system before they can be used, right? That can get messy. I will keep it in mind though.

I like the clean interface of a DLL. The DLL just has to reside in the application directory and that''s it. No registration, any development environment can use it, etc.



Steve ''Sly'' Williams
Tools Developer
Krome Studios
risingdragon3
risingdragon3
quote:

I want wider usage, particularly Visual C++.


Hmmm how are you going to implement the interface DLL <-> App? Are you going to write it in Delphi (of course)? Then how are you going to have C++ interfaces (header files)? You can get BCB to give you auto - generated C++ headers that you can modify slightly into interface headers that VC++ can use. Also if you want other languages to be able to use it, you will have to use stdcall as well as staying away from properties I''ve already said this, but hell one more time doesn''t matter

------------------------------
BCB DX Library - RAD C++ Game development for BCB
Eric Grange
Eric Grange
>COM objects must be registered with the system [...]

Yes, but auto-registration is easy to do and can be easily integrated into an installer.

>I like the clean interface of a DLL [...]

DLLs have issues of their own like versioning (do I have the right version of the DLL ?), the standard sdtcall interface is more suited for non-OO langages like C...

Both COM and DLL will require you to cripple your engine in some manner, by limiting design/interface choices and possibilities. Directly exposing objects won''t.

haha, the old "legacy support" vs "RAD & performance" dilemna is upon you, good luck.



Eric Grange
http://glscene.org
---Eric Grangehttp://glscene.org
marco
marco
Hi Sly!

It''s an tricky question, but you''ll probebly would like to use it for the future other language u use so...

I think you should go for the DLL! With the DLL, other language can use it and so on... and the speed shouldn''t be a problem with the computers that are and are coming.

Good Luck! And tell us all when your game will be out so we can get a look at it... maybe there will be an demo version out?
(for PC platform)

Regards,
Marco.

Ps. Thx for updateing turbos site
ME

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.