Difference between revisions of "Sword25/TODO"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Add another gfx todo. One is gone)
m (Removed point for Vertex removal - I concur that just removing BS_ prefix is sufficient)
Line 6: Line 6:


* Audio support
* Audio support
* Get rid of BS_Vertex (use Common::Point)
** It may be more advisable to subclass Common::Point, as the vertex class has several methods, such as converting to/from Lua vertexes, that should remain associated with the class
*** In this case there is no point of refactoring then, and I can just rename BS_Vertex to Vertex. Thoughts?
* Get rid of tinyxml (I've checked, our parser should digest those xmls with no problem)
* Get rid of tinyxml (I've checked, our parser should digest those xmls with no problem)
* Look why package access is so slow (zip contents caching?)
* Look why package access is so slow (zip contents caching?)

Revision as of 11:17, 28 August 2010

Status

  • Engine starts and compiles scripts.
  • Game works, you may watch part of the intro (no FMVs) and first screen

TODOs

  • Audio support
  • Get rid of tinyxml (I've checked, our parser should digest those xmls with no problem)
  • Look why package access is so slow (zip contents caching?)
  • Get rid of Window classes. We handle that in OSystem
  • Enhance package manager to allow running with extracted data just like original did
  • Graphics:
    • Doublecheck color component order. What I had to do now is specify engine colorspace as BGRA8888 which is weird.
    • YUV->RGB converter for video (fmv/theora_decoder.cpp)
    • alpha blending (gfx/opengl/glimage.cpp)
    • scaling (same)
    • mirroring (same)
    • Vector image rendering. They used ogg for spline drawing, so we need to reimplement that (borrow from ogg/gimp/inkscape?)
  • Get rid of BS_SERVICE_TABLE (?)
    • because it is (a) ugly concept (b) implemented with global constructors. The worse approach would be to turn those into Singleton classes, but proper would be to remove the wrappers completely since we do not have multiple implementations of each service
  • Enforce our naming conventions, particularly for classes, methods and variables