[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [freesci-develop] Introduction and Question About ScummVM Integratio
From: |
Christoph Reichenbach |
Subject: |
Re: [freesci-develop] Introduction and Question About ScummVM Integration |
Date: |
Tue, 3 Jun 2008 12:09:11 -0600 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Hello Sami,
welcome to the project, and apologies for the late response! I will
try to give you more timely responses in the future.
On Sat, May 31, 2008 at 07:11:21PM -0700, Sami Zerrade wrote:
> Generally, this means replacing any platform-specific calls with invocations
> of ScummVM's OSystem methods. In some cases (video and audio drivers, for
> example), the existing abstraction allows this to be done cleanly. It's
> presently not as clear how to proceed with file IO handling, as the existing
> code sort of assumes FILE* usage.
To my recollection, FILE * and its API functions are standardised as
part of C89. (FreeSCI has historically targetted C89, though we have
recently discussed migrating to C99). Thus, FILE * is not at all
platform-specific beyond the `C89 platform'.
However, I am not at all opposed to a migration if there is a real
problem that would be solved by that. I would be curious to hear
about the problem first, though.
> Current suggestions include implementing a new structure to encapsulate
> FILE* pointers and ScummVM, or using two separate files that are decided
> between at compile time.
If such a change is needed, I propose making the decision statically
(i.e., at compile time) as the dynamic approach seems to offer no
benefits but requires additional type conversions. (For all the
practical use cases I can think of, there is no need to be able to
switch file representations at run-time).
The easiest solution to me then seems to be the introduction of a
file abstraction API (by refactoring the existing header files) with
two underlying implementations, one relying on the one we already have
in scicore/tools.c (plus extensions as needed) and one relying on the
ScummVM mechanisms, with a flag triggering which one we use.
-- Christoph
- Re: [freesci-develop] Introduction and Question About ScummVM Integration,
Christoph Reichenbach <=