[adding an engine] splitting my engine into several DLLs

Ask for help with ScummVM problems

Moderator: ScummVM Team

Post Reply
monsieurouxx
Posts: 80
Joined: Fri Oct 19, 2007 5:48 pm

[adding an engine] splitting my engine into several DLLs

Post by monsieurouxx »

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.
digitall
ScummVM Developer
Posts: 1172
Joined: Thu Aug 02, 2012 1:40 pm

Post by digitall »

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.
User avatar
LordHoto
ScummVM Developer
Posts: 1029
Joined: Sun Oct 30, 2005 3:58 pm
Location: Germany

Re: [adding an engine] splitting my engine into several DLLs

Post by LordHoto »

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?
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.
User avatar
sev
ScummVM Lead
Posts: 2276
Joined: Wed Sep 21, 2005 1:06 pm
Contact:

Post by sev »

I really wonder why you could need that. Could you please provide a bit more information?


Eugene
monsieurouxx
Posts: 80
Joined: Fri Oct 19, 2007 5:48 pm

Post by monsieurouxx »

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.
User avatar
DrMcCoy
ScummVM Developer
Posts: 595
Joined: Sat Dec 17, 2005 1:33 pm
Location: Braunschweig, Germany
Contact:

Post by DrMcCoy »

Who is that nebulous "us"? Who and what are you talking about exactly?

Do you have a dozen people working on REing one engine or something?
User avatar
dreammaster
ScummVM Developer
Posts: 554
Joined: Fri Nov 04, 2005 2:16 am
Location: San Jose, California, USA

Post by dreammaster »

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.
User avatar
sev
ScummVM Lead
Posts: 2276
Joined: Wed Sep 21, 2005 1:06 pm
Contact:

Post by sev »

DrMcCoy wrote:Who is that nebulous "us"? Who and what are you talking about exactly?

Do you have a dozen people working on REing one engine or something?
Perhaps it is somehow connected with AGS?


Eugene
monsieurouxx
Posts: 80
Joined: Fri Oct 19, 2007 5:48 pm

Post by monsieurouxx »

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.
Post Reply