1,079
edits
Difference between revisions of "Sword25/TODO"
→TODOs
(→TODOs) |
(→TODOs) |
||
| Line 20: | Line 20: | ||
* Fix issues due to using libpng: The engine uses libpng. This will cause problems when building with dynamic plugins, as then either the sword25 engine then would have to be linked directly against libpng (which may not be possible everywhere), or the main ScummVM executable. But in the latter case, we get issues on systems that do not allow backlinking (such as Windows). The way we overcame this for other similar cases is to add a thin wrapper API around the library and put that into the shared code base (in this case, something like graphics/png.* might be appropriate). | * Fix issues due to using libpng: The engine uses libpng. This will cause problems when building with dynamic plugins, as then either the sword25 engine then would have to be linked directly against libpng (which may not be possible everywhere), or the main ScummVM executable. But in the latter case, we get issues on systems that do not allow backlinking (such as Windows). The way we overcame this for other similar cases is to add a thin wrapper API around the library and put that into the shared code base (in this case, something like graphics/png.* might be appropriate). | ||
* The save system of this engine currently partially bypasses the SaveFileManager API, by (abusing) the fact that the Lua engine allows creating files in arbitrary places (it exposes fopen, fread, fwrite etc.). This is used to create a 'config.lua' configuration file. This makes it non-portable. <br>In addition, the filenames used for the savestates ("0.b25s") do not comply with our naming conventions for engine savestates.<br> It should be possible to overcome all this, but it might require hacking the Lua engine; or we could try to replace some of the BS2.5 script functions with our own, dynamically. | * The save system of this engine currently partially bypasses the SaveFileManager API, by (abusing) the fact that the Lua engine allows creating files in arbitrary places (it exposes fopen, fread, fwrite etc.). This is used to create a 'config.lua' configuration file. This makes it non-portable. <br>In addition, the filenames used for the savestates ("0.b25s") do not comply with our naming conventions for engine savestates.<br> It should be possible to overcome all this, but it might require hacking the Lua engine; or we could try to replace some of the BS2.5 script functions with our own, dynamically. | ||
* PersistenceService::saveGame and PersistenceService::loadGame contain code to (de)compress the save data using zlib. But we already compress savegames using zlib, so now we end up compressing them twice. Unless we need to do the compression to be compatible with saves from the original, we should get rid of this in-engine compression. If we can't get rid of it, we should add code comments that explain the reasons. | |||
* The following commented out code used to be in kernel/scummvmwindow.cpp; I am keeping it here in case there is still something in there that needs to be handled (which I can't tell right now). | * The following commented out code used to be in kernel/scummvmwindow.cpp; I am keeping it here in case there is still something in there that needs to be handled (which I can't tell right now). | ||
<source lang="cpp"> | <source lang="cpp"> | ||