Hi guys I'm starting the design of a new little game engine and I was assuming the game engine as a DLL and then build a project for the game that would use this DLL and output an EXE file.
But then I read about the latest ID Tech Game Engines and how they do it the other way around. (http://fabiensanglard.net/doom3/index.php)
It's not really explained why though. I have the feeling it has something to do with modding as only the Game (DLL in this case) was open to the public for quite some time while the Engine (EXE) was closed source.
But I would like to know if there are other reasons for this.
As fas as I know the DLL project should have all the reusable code. The normal project should be the application, which would reference the reusable DLL. This way you can build a framework in the DLL project that can be used for any of other future projects.
The other only reason I can think of is that AFAIK only the name of the DLL is recorded in the program file, no text or data so if the Game is potentially bigger than the Engine, it could make the executable size smaller.
[EDIT]
I have thought of another reason to have it this way: The Engine is an EXE so it could be that it could be used without a Game DLL? Like for tools such as CAD or scripting?
If you are using a library in an application e.g. a game, then you have an app with an EXE with zero or more of its own DLLs consuming a library with one or more DLLs.
If you have a generic environment loading elements that customize it's behavior, thus making it a specific game, then you have an environment with an EXE and zero or more DLLs which uses configuration to load various DLLs and configuration files to determine its behaviour.
Either easy, you should probably have more than two assemblies in your application.
E.g. one (the EXE) for loading the main config and modules and connecting them all, one for the main UI, one for the graphics, one for the physics, one for the AI and etc.
Related
I'm working in a VB.NET application using Visual Studio 2017.
I'm using a lot of images in my project and if I follow the instructions that I've found in the Internet (add images to a resource file) the executable ends up weighting more than 300MB. This is a huge problem because when I want to send updates to the users they have to download every time 300MB instead of just a few KB, and perhaps some additional images.
I would prefer the images to be stored separately from the executable, in the same folder, but this does not seem to be possible because using the resource file and building a release version they all get eaten inside the executable.
(Note that I need the images to show while working on the designer module, so it is not an option to load them all through code using image.fromfile, which would do exactly what I want)
Can someone point me in the right direction? Thanks a lot in advance.
You can create a separate class library project in the same solution. A class library project is compiled to a DLL. Include the image resources in this library project and add it as project reference to the main project.
If the image resources don't change, you don't need to re-distribute this DLL.
A trick that could enable you to use these resources at design time could be to use satellite assemblies for culture specific resources (I never tried it so). In your case you would have only on single culture.
See:
Locating and Using Resources for a Specific Culture (MSDN)
Localizing a Windows Application with Satellite Assemblies (article uses C# but should be the same procedure for VB).
How to Localize Windows Forms and Change the Language at Runtime
I have a few different projects that all get mixed and matched into different types of solutions.
For projects, I currently have
EngineProj: c++, built as a .lib
GameProj: c++, built as a .exe
EditorProj: c++/clr, built as a .exe
For solutions, I currently have
Game: c++, built with EngineProj and GameProj
Editor: c++/clr, built with EngineProj and EditorProj
This has worked great for games. I have been able to make a few different game solutions that keep reusing the shared EngineProj.
The Editor solution has EditorProj build a .exe with a WindowsForm object called EditorForm. This is used to edit generic game data that is common for all game solutions.
Now, though, I want to be able to do the same thing for my Editor that I do with my games. I want to be able to make game specific versions of the Editor that reuse as much project setup and code as possible. Here is what I am working towards.
For projects, I am planning
EngineProj: c++, built as a .lib
GameCoreProj: c++, built as a .lib
GameExeProj: c++, built as a .exe (a very thin and small project)
EditorCoreProj: c++/clr, built as a .lib
EditorGameExeProj: c++/clr, built as a .exe
For solutions, I am planning
Game: c++, built with EngineProj, GameCoreProj, and GameExeProj
GameEditor: c++/clr, built with EngineProj, GameCoreProj, EditorCoreProj, and EditorGameExeProj
I am having troubles getting my GameEditor solution to come together.
The idea is for EditorCoreProj to provide the same EditorForm that EditorProj did; only in a .lib instead. EditorGameExeProj would then build with GameCoreProj.lib and EditorCorProj.lib. EditorGameExeProj would support a new WindowsForm object that derives from EditorForm, but implements new features unique to the needs of GameCorProj.
Various forms of unresolved externals have been plaguing me for a couple days now.
It seems that my issues stem from the fact that EditorCoreProj is a c++/clr project.
I read many articles and tried many different approaches, but eventually I found some reading that suggested that making a .lib would never work. It sounds like c++/clr .libs are not supported.
So, then, I tried making EditorCoreProj build as a .dll. For hours, I tried to get EditorGameExeProj to import the .dll. I read that maybe I need to tag everything for export and import. That sounded like a lot of work, and so I started just making some test solutions. However, that continually resulted in unresolved externals, too.
I am pretty new to making a .dll; I have always preferred .libs. Maybe I am just encountering newb issues with .dlls. At this point though, I have spent a couple days trying to get this setup.
And so, finally, my question.
Am I headed in the right direction? Maybe there is something much easier I should be doing?
Thank you for your time
I ended up sticking to the plan, and got everything working. I don't know if there was a better route to take, but this does full-fill all of my needs.
I have a class library dll that loads AutoCAD scripts from a network folder. However I need a way to ensure the class library can be updated silently. With Windows Form applications I would just use a ClickOnce Deployment and then use Application.Restart, however as this has to be a Class Library (as it is an AutoCAD addon) this doesn't seem to be possible.
What's the best way to handle this?
This is not possible with AutoCAD plugins because the DLL is loaded in the AppDomain. This 'silent' update is possible only with C++.
You can go the TDD way which is good practice. Here is a handout on the topic because TDD in AutoCAD is not that easy because of the above mentioned problem.
You can try to develop you algorithm in your own classes in order to have better TDD experience. Then transfer it with DTOs to AutoCADs transaction.
Some developers have 2 (or more) DLLs with AutoCAD code: the 1st main DLLs loads on AutoCAD startup, check for updates, download and install. The 2nd DLL actually contains the commands that will be demand loaded when the user run the command.
I recently built a solution that allows reloading the same copy of a .dll into AutoCAD.
Check out my blog with the full solution:
http://www.cadwiki.net/blogpost/How-to-reload-a-.dll-into-AutoCAD
I come from a Mac background. I developed games with Xcode and Objective-C frameworks.
Recently I moved to Windows and decided to use VB.NET for a while. It is cool.
Here is my intention:
I want to develop a Windows platform game. The game is rather complex, and I will need some kind of "engine" or "editor" to be able to edit my levels and properties easily. The idea is that I can build most of the game with this editor and then the editor will compile the project files and resources into one .exe file for gaming.
Fortunately, I was able to create my editor with VB.NET. I am able to edit levels and such. However, I am not sure about the "compilation" part to create a .exe file and play the game.
Basically I am at the point of designing the "Compile" button in my editor. But I am clueless. I could not find much documentation regarding this topic.
My editor has all variables and information the game needs to run.
I assume that this .exe file is like another VB.NET project (produced by my editor) that will basically take the data it comes with and "run" the game loop alright.
Any ideas, links, etc? Thanks.
**Note: my game is a 2d game with, probably, a vast amount of sprites and such.
Visual Studio is a fantastic IDE for development of Windows apps. Compiling the project is pretty simple. You just compile and it gives you an exe that's in the .NET Framework. Microsoft also has XNA Game Studio to help with game design if you want to look at gaming frameworks for .NET.
Also, you can take files from your editor if they generate vb.net and use the vbc compiler command to compile them into libraries, executables, whatever you like. The command could be something like this:
vbc /reference:Microsoft.VisualBasic.dll File.vb
Here's a link to the .NET command line compiler for VB.NET.
I'm not entirely sure what you mean here. Are you saying that you have an editor (something like a level or map editor?) for your game, and that you want the output of this editor to be embedded into the exe for your actual game application when it compiles?
If that's the case (or something similar to it) then you'll first want to consider how to persist your data to file. Then you could manually add files you've created as embedded resources. Or better yet, create a file type that holds as many 'levels' or 'maps' as you need and embed that. This way as you create more they will just get added to that file and you won't have to keep adding more embedded resources.
Windows still use DLLs and Mac programs seem to not use DLL at all. Are there benefits or disadvantages of using either technique?
If a program installation includes all the DLL it requires so that it will work 100% well, will it be the same as statically linking all the libraries?
MacOS X, like other flavours of Unix, use shared libraries, which are just another form of DLL.
And yes both are advantageous as the DLL or shared library code can be shared between multiple processes. It does this by the OS loading the DLL or shared library and mapping it into the virtual address space of the processes that use it.
On Windows, you have to use dynamically-loaded libraries because GDI and USER libraries are avaliable as a DLL only. You can't link either of those in or talk to them using a protocol that doesn't involve dynamic loading.
On other OSes, you want to use dynamic loading anyway for complex apps, otherwise your binary would bloat for no good reason, and it increases the probably that your app would be incompatible with the system in the long run (However, in short run static linking can somewhat shield you from tiny breaking changes in libraries). And you can't link in proprietary libraries on OSes which rely on them.
Windows still use DLLs and Mac
programs seem to not use DLL at all.
Are they benefits or disadvantages of
using either technique?
Any kind of modularization is good since it makes updating the software easier, i.e. you do not have to update the whole program binary if a bug is fixed in the program. If the bug appears in some dll, only the dll needs to be updated.
The only downside with it imo, is that you introduce another complexity into the development of the program, e.g. if a dll is a c or c++ dll, different calling conventions etc.
If a program installation includes all
the DLL it requires, will it be the
same as statically linking all the
libraries?
More or less yes. Depends on if you are calling functions in a dll which you assume static linkage with. The dll could just as well be a "free standing" dynamic library, that you only can access via LoadLibrary() and GetProcAddress() etc.
One big advantage of shared libraries (DLLs on Windows or .so on Unix) is that you can rebuild the library and its consumers separately while with static libraries you have to rebuild the library and then relink all the consumers which is very slow on Unix systems and not very fast on Windows.
MacOS software uses "dll's" as well, they are just named differently (shared libraries).
Dll's make sense if you have code you want to reuse in different components of your software. Mostly this makes sense in big software projects.
Static linking makes sense for small single-component applications, when there is no need for code reuse. It simplifies distribution since your component has no external dependencies.
Besides memory/disk space usage, another important advantage of using shared libraries is that updates to the library will be automatically picked up by all programs on the system which use the library.
When there was a security vulnerability in the InfoZIP ZIP libraries, an update to the DLL/.so automatically made all software safe which used these. Software that was linked statically had to be recompiled.
Windows still use DLLs and Mac programs seem to not use DLL at all. Are they benefits or disadvantages of using either technique?
Both use shared libraries, they just use a different name.
If a program installation includes all the DLL it requires so that it will work 100% well, will it be the same as statically linking all the libraries?
Somewhat. When you statically link libraries to a program, you will get a single, very big file, with DLLs, you will have many files.
The statically linked file won't need the "resolve shared libraries" step (which happens while the program loads). A long time ago, loading a static program meant that the whole program was first loaded into RAM and then, the "resolve shared libraries" step happened. Today, only the parts of the program, which are actually executed, are loaded on demand. So with a static program, you don't need to resolve the DLLs. With DLLs, you don't need to load them all at once. So performance wise, they should be on par.
Which leaves the "DLL Hell". Many programs on Windows bring all DLLs they need and they write them into the Windows directory. The net effect is that the last installed programs works and everything else might be broken. But there is a simple workaround: Install the DLLs into the same directory as the EXE. Windows will search the current directory first and then the various Windows paths. This way, you'll waste a bit of disk space but your program will work and, more importantly, you won't break anything else.
One might argue that you shouldn't install DLLs which already exist (with the same version) in the Windows directory but then, you're again vulnerable to some bad app which overwrites the version you need with something that breaks your neck. The drawback is that you must distribute security fixes for your app yourself; you can't rely on Windows Update or similar things to secure your code. This is a tight spot; crackers are making lots of money from security issues and people will not like you when someone steals their banking data because you didn't issue security fixes soon enough.
If you plan to support your application very tightly for many, say, 20 years, installing all DLLs in the program directory is for you. If not, then write code which checks that suitable versions of all DLLs are installed and tell the user about it, so they know why your app suddenly starts to crash.
Yes, see this text :
Dynamic linking has the following
advantages: Saves memory and
reduces swapping. Many processes can
use a single DLL simultaneously,
sharing a single copy of the DLL in
memory. In contrast, Windows must load
a copy of the library code into memory
for each application that is built
with a static link library. Saves
disk space. Many applications can
share a single copy of the DLL on
disk. In contrast, each application
built with a static link library has
the library code linked into its
executable image as a separate
copy. Upgrades to the DLL are
easier. When the functions in a DLL
change, the applications that use them
do not need to be recompiled or
relinked as long as the function
arguments and return values do not
change. In contrast, statically linked
object code requires that the
application be relinked when the
functions change. Provides
after-market support. For example, a
display driver DLL can be modified to
support a display that was not
available when the application was
shipped. Supports multilanguage
programs. Programs written in
different programming languages can
call the same DLL function as long as
the programs follow the function's
calling convention. The programs and
the DLL function must be compatible in
the following ways: the order in which
the function expects its arguments to
be pushed onto the stack, whether the
function or the application is
responsible for cleaning up the stack,
and whether any arguments are passed
in registers. Provides a mechanism
to extend the MFC library classes. You
can derive classes from the existing
MFC classes and place them in an MFC
extension DLL for use by MFC
applications. Eases the creation
of international versions. By placing
resources in a DLL, it is much easier
to create international versions of an
application. You can place the strings
for each language version of your
application in a separate resource DLL
and have the different language
versions load the appropriate
resources. A potential
disadvantage to using DLLs is that the
application is not self-contained; it
depends on the existence of a separate
DLL module.
From my point of view an shared component has some advantages that are somtimes realized as disadvantages.
shared component defines interfaces in your process. So you are forced to decide which components/interfaces are visible outside and which are hidden. This automatically defines which interface has to be stable and which does not have to be stable and can be refactored without affecting any code outside the component..
Memory administration in case of C++ and Windows must be well thought. So normally you should not handle memory outside of an dll that isn't freed in the same dll. If you do so your component may fail if: different runtimes or compiler version are used.
So I think that using shared coponents will help the software to get better organized.