[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