Open main menu

SCI/TODO

< SCI
Revision as of 20:54, 20 February 2009 by Clone2727 (talk | contribs) (Use C++ syntax highlighting ;))

The following list is taken from Max's mails to -devel:

  • Move everything into namespace SCI
  • Replace all uses of gint8, etc. by our native types, to get rid of the typedefs we use right now.
  • check for places that use char or unsigned char for boolean values, and change those to use type bool instead
  • more formatting fixes: TheSCI code puts return values on separate lines all over the place, e.g.

<syntax type="C++">

 int
 _vocab_cmp_words(const void *word1, const void *word2) {

</syntax>

Take care of that and other formatting issues.

  • change names of structs and how they are declare, e.g.

<syntax type="C++">

 typedef struct script_opcode_ {
      unsigned opcode;
      int arg1, arg2, arg3;
      int pos, size;
 } script_opcode;

</syntax>

->

<syntax type="C++">

 struct ScriptOpcode {
      unsigned opcode;
      int arg1, arg2, arg3;
      int pos, size;
 };

</syntax>

  • Fixing all warnings
  • change #define lists into enums
  • Rearranging the files under engines/sci: I.e. get rid of include/ subdir (just move its contents to engines/sci, at some point at least)
  • Converting stuff from "C pseudo classes" to real classes
  • Replacing various generic FreeSCI stuff by their ScummVM counterparts. E.g. don't bother to rewrite engines/sci/include/int_hashmap.h -- instead change code to use a HashMap<int, ...> etc.
  • Replace sci_gettime and sci_get_current_time by OSystem::getTimeAndDate and OSystem::getMillis
  1. You first need to find out which is used where: Des the code try to determine the current time? Use getTimeAndDate(). Does it try to measure something, regulate timing? Using getMillis. It is possible that some code actually really wants to get a higher resolution than milli seconds, in that case get back to us and let's discuss what to do.
  • Not specific to SCI, but: Replace "struct tm" in common/system.h (and places that implement/use it) by a custom struct, which would be a (partial) clone of struct tm, something like Common::OSystem::Time. That way, we wouldn't have to use <time.h> anymore anywhere.
  • Get rid of sci_sched_yield: This is used for two things:
  1. gfx/resource/sci_pic_0.cpp -> analyze why it is used here, find a way to replace it
  2. ./sfx/mixer/soft.cpp to implement ACQUIRE_LOCK -> replace ACQUIRE_LOCK and RELEASE_LOCK by using our mutex API. (And on the long run, replace the SCI mixer by our mixer :-)
  • In fact: Do use File, SearchManager, FSNode etc. instead of paths, fopen, etc.
  • Don't use fstat
  • const correctness in engines/sci/engine/savegame.c (this is a generated file, so change the source or generator, whatever is necessary)
  • change the many nice existing function documentation comments to use doxygen syntax
  • Turn code into templates in following files (now they generate code via #defines):
    • gfx/gfx_pixmap_scale.cpp
    • gfx/gfx_line.cpp
    • gfx/gfx_crossblit.cpp
    • gfx/resource/sci_picfill.cpp
    • gfx/resource/sci_picfill_aux.cpp
  • Check old FreeSCI-scummvm branch / repos by Jordi for change that could be salvaged, e.g. the files sfx/device/scumm-midi.cpp and sfx/softseq/scumm-adlib.cpp, or the modifications to the SCI debugger to use the ScummVM console, and stuff.
  • Replace the SCI sound mixer by Audio::Mixer
  • I just made a big commit where I started to overhaul the file handling in SCI. It's incomplete, and may cause regressions, but it is a start. The biggest chunk left to take care of is engine/kfile.cpp, and in there mostly handling of savegames (and possibly of writing to other files -- if SCI ever does that?). This needs to be switched to the savefile API. One problem there is that FreeSCI apparently stored saves as multiple files, grouped by a directory. Does anybody know whether the original Sierra SCI also did this? Our savefile API does not (and will not) support subdirs. Some ideas on how to resolve this:
  1. Fake subdirs by turning save_0/FILE into save_0_FILE. Or even better, into TARGET-FILE.0 or something like that.
  2. Revise the save/load code in SCI to put all those files into some kind of archive file.
  3. Maybe we don't need all those files? In a KQ4 save I made, there were only two files: state, and KQ4.id, which seems redundant (could be encoded into a header prefixed to 'state', plus the filename)
  • make the SCI tools compilable (to avoid bitrot, while we change code that they depend on), and finally usable again.