Hi,
What would be ScummVM's policy regarding engines (projects) that are split into several DLLs? Is one of the engines already doing that? Is it a problem if one engine appears as two projects in the solution?
The reason I'm asking is because we'd like to have: on the one hand, a core library providing some basic services, that could be enhanced progressively (to read all the file formats of Cryo: Dune, KGB , Dune CD, etc.) -- it would be dealing with the complexity of all Cryo file formats and compression systems along the years ...and on the other hand the engines deidcated to the actual Cryo games.
[adding an engine] splitting my engine into several DLLs
Moderator: ScummVM Team
-
monsieurouxx
- Posts: 80
- Joined: Fri Oct 19, 2007 5:48 pm
I can only speak for myself and my view. You would have to post this to scummvm-devel for the attention of the Core Team for a definitive answer...
However based on the codebase, we do not split engines down into multiple library/DLLs as this makes life difficult for the engine plugin system.
The solution for the issue you are describing has been one of three choices:
1. For standard formats (Graphics - JPG, PNG, BMP, Sound - WAV, ADPCM, Compression - ZIP), we have decoders for this in the common, graphics and audio shared core library of OSystem and we add to them as needed.
2. For game specific code where multiple engines are supported and the various formats vary, we duplicate the loading routines for each engine ie. See CinE and Cruise for an example.
3. For game specific code where multiple engines are supported and the formats are very similar, and the game code varies slightly, we use a single engine with multiple sub-engines for each game ie. See AGI, SCI, Groovie, Parallaction, SCUMM, Mohawk and various others.
I would suggest that you should probably baseline on option 3 and then you can always compile to disable the subengines selectively... see --enable-engine=scumm,scumm_7_8,he etc.
However based on the codebase, we do not split engines down into multiple library/DLLs as this makes life difficult for the engine plugin system.
The solution for the issue you are describing has been one of three choices:
1. For standard formats (Graphics - JPG, PNG, BMP, Sound - WAV, ADPCM, Compression - ZIP), we have decoders for this in the common, graphics and audio shared core library of OSystem and we add to them as needed.
2. For game specific code where multiple engines are supported and the various formats vary, we duplicate the loading routines for each engine ie. See CinE and Cruise for an example.
3. For game specific code where multiple engines are supported and the formats are very similar, and the game code varies slightly, we use a single engine with multiple sub-engines for each game ie. See AGI, SCI, Groovie, Parallaction, SCUMM, Mohawk and various others.
I would suggest that you should probably baseline on option 3 and then you can always compile to disable the subengines selectively... see --enable-engine=scumm,scumm_7_8,he etc.
Re: [adding an engine] splitting my engine into several DLLs
Having your engine split will not work. Furthermore, using (external) libraries directly in your engine will not work either. Thus, you cannot have one part of your engine has some external library and then have your engine in ScummVM use that.monsieurouxx wrote:What would be ScummVM's policy regarding engines (projects) that are split into several DLLs? Is one of the engines already doing that? Is it a problem if one engine appears as two projects in the solution?
-
monsieurouxx
- Posts: 80
- Joined: Fri Oct 19, 2007 5:48 pm
That's for our internal development process. It's usually not the same people working on the game engine and on the file format/decoding.
The people working on the game engine don't care about the file formats. And vice versa: the "nerds" working on the file formats and decoding algorithms don't care about the game engine. The more autonomous the latter can be (working on the files versions, unpacking methods, documentation, etc.) the better it is for us.
The people working on the game engine don't care about the file formats. And vice versa: the "nerds" working on the file formats and decoding algorithms don't care about the game engine. The more autonomous the latter can be (working on the files versions, unpacking methods, documentation, etc.) the better it is for us.
-
dreammaster
- ScummVM Developer
- Posts: 559
- Joined: Fri Nov 04, 2005 2:16 am
- Location: San Jose, California, USA
As previously mentioned, separating things by DLLS aren't really a good long term plan for ScummVM engines, particularly given that DLLs are specific to Windows, and wouldn't compile on other systems.
However, there's no reason why, if you really need separation of teams, you couldn't maintain separate project files in whatever IDE you currently use, with one project using a stubbed dummy interface class version of files/classes another team is working on. For example, you could set up a "I/O project" that includes all the extra decoders that ScummVM doesn't already have for one group to work on, and then have a main "engine" group calling a stubbed version that returns dummy raw data.
However, there's no reason why, if you really need separation of teams, you couldn't maintain separate project files in whatever IDE you currently use, with one project using a stubbed dummy interface class version of files/classes another team is working on. For example, you could set up a "I/O project" that includes all the extra decoders that ScummVM doesn't already have for one group to work on, and then have a main "engine" group calling a stubbed version that returns dummy raw data.
-
monsieurouxx
- Posts: 80
- Joined: Fri Oct 19, 2007 5:48 pm
Nope. Nothing to do with AGS.
I'm actually recollecting memories from the previous attempt at reverse-engineering the Cryo engines: at the time I painfully discovered that there are really two completely different approaches to managing old technology (I'm talking about unpacking algorithms and stuff).
Some were very (too) liberal, while others were purists beyond what you can imagine (one guy wanted to keep the original assembly x86/MS-DOS routines. No C/C++.) Our failure came from a management/goal issue rather than the skills of programmers.
To answer your question: Our team was 5+ core people (including your wonderful md5 who provided great help -- and whom I supremely upset by screwing up with the SVN repository), and more remote contributors doing some research on file formats.
Anyway, wanting DLLs is overkill. as long as the source files are properly split (solution 3 previously mentionned), everything will be OK.
I'm actually recollecting memories from the previous attempt at reverse-engineering the Cryo engines: at the time I painfully discovered that there are really two completely different approaches to managing old technology (I'm talking about unpacking algorithms and stuff).
Some were very (too) liberal, while others were purists beyond what you can imagine (one guy wanted to keep the original assembly x86/MS-DOS routines. No C/C++.) Our failure came from a management/goal issue rather than the skills of programmers.
To answer your question: Our team was 5+ core people (including your wonderful md5 who provided great help -- and whom I supremely upset by screwing up with the SVN repository), and more remote contributors doing some research on file formats.
Anyway, wanting DLLs is overkill. as long as the source files are properly split (solution 3 previously mentionned), everything will be OK.