[Scummvm-devel] Broken Sword 2.5

Paul Gilbert paulfgilbert at gmail.com
Sun Aug 1 00:43:40 CEST 2010


On Sun, Aug 1, 2010 at 8:08 AM, Johannes Schickel <lordhoto at gmail.com>wrote:

> On Sat, Jul 31, 2010 at 9:07 PM, Eugene Sandulenko <sev at scummvm.org>
> wrote:
> > Hi Team,
> >
> > Recently I got sources for fan game Broken Sword 2.5. The sources were
> > passed under full GPL 2.0 license which means that we can use them as
> > is.
> >
> > Thus, I have a question. What do you guys think about adding support for
> > this game? Any objections?
> >
> > Short info about it:
> >
> >  - The game is free (http://baphometsfluch25.de)
> >  - Written in C++ (sometimes a bit over-engineered, though)
>
> Do they use exception handling? I think we have that disabled,
> especially since a few of our ports would not support this at all. So
> if they would do that I guess some of our ports won't be able to
> support it, unless we change the code to do more C like error
> handling.
>

Based on my review/work so far, exceptions are only used insofar as to throw
fatal errors. These are being replaced with standard ScummVM error() calls,
so it won't be an issue.


>
> >  - The engine is under 20k lines of code
> >  - With Lua coupled together the engine is under 35k lines of code  -
> >    The scripts are Lua-based (2.6 MB of them in the game data :) )
>
> Do we plan to have the Lua sources in ScummVM for that too, or will we
> use an external LUA reference for that?
>

Since Residual is the only other game I'm aware of with a similiar Lua
implementation, it'll probably stay within the Broken sword 2.5 engine.
Although if other games in the future also make use of it, who knows. :)


>
> >  - There is some little amount of OpenGL used for SFX which will be
> >    eliminated
>

Actually, Sev likely meant 'GFX' here. The release notes state "Furthermore
there is a library called "glsprites" in the "util" project. This is a small
library I wrote that renders 2D sprites using OpenGL. It is released
as GPL along with the rest of the code.". I haven't actually looked at it,
but Sev already thinks that it should be easy to convert to use the generic
graphics backend.



> >  - Main hero is drawn with vectors
> >  - The engine runs 800x600 24-bits (I think it could be squized into
> >    16-bits)
>
> I thought our current "true color" API in OSystem is designed to allow
> backend conversion. Then again I think we specifically ruled out 24bit
> colors, i.e. only allowed 16bit and 32bit storage. So does this engine
> use 32bit for storage of a pixel internally? Or does it really use a
> 24bit per pixel? If that is not the case I would probably say we
> should go with unchanged graphics and let the backend worry about the
> real pixel depth it uses (and thus the conversion). That should allow
> us to transparently support the "real" color depth later.
>

My cursory review of the GFX indicates that it does use a 32-bit colour
buffer internally.


>
> >  - The code is well commented... in German (the function names and
> >    variables are all in English)
>
> Sounds fine.


Yes; thank goodness the *methods* weren't also in German. ;)


>
> >  - Original engine has every library incorporated into engine (almost
> >    260k lines of code). Examples: zlib, libvorbis, libogg, libtheora.
>
> I hope we won't do that though ;-).
>

Yes, the plan is to do all possible refactoring right at the start, rather
than having a project added that duplicates several already existing
libraries. To that end, the project isn't actually yet fully compilable
under ScummVM - we're currently gradually going through the source files and
making conversions, including:
- Changing the formatting to ScummVM conventions
- Doxygen-ifying comments
- Translating German comments to English - lots of copying and pasting into
Google Translate :)
- Converting standard C++ constructs to ScummVM equivalents - this includes
things like std::vector->Common::Array, std::string->Common::String, and so
on.
- Completely replacing some of the support classes where necessary with
'ScummVM versions' that will use the ScummVM library.


>
> >
> > Dreammaster and me already started work on it, but would like to
> > continue work right in the trunk.
> >
> > So what would you guys say?
>
> Personally I am all for doing this in trunk. Furthermore I have to say
> I am really surprised that we nowadays would do that in trunk, from
> the discussions in the past it always looked like people were
> suggested to do that off trunk. I am really thrilled about that.
>

My only concern with putting in the trunk is that if it gets done
immediately, do we, and can we, disable Buildbot from trying to compile it?
There will obviously be a lot of errors until the basic reworking (as per
above is complete).

// Johannes
>
>
Regards,

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20100801/2333566a/attachment.html>


More information about the Scummvm-devel mailing list