1,079
edits
Difference between revisions of "Sword25/TODO"
→TODOs
(→TODOs: Add remark about issues with savestate code) |
(→TODOs) |
||
| Line 19: | Line 19: | ||
** A major reason for slowness is that when finding a matching file list for a given file-spec, it currently scans the entire contents of the zip file index. When we correct the Zip file implementation to properly handle folders, this will speed things up, since since it will be able to traverse down to a specific folder, and only have to scan the files of that folder. | ** A major reason for slowness is that when finding a matching file list for a given file-spec, it currently scans the entire contents of the zip file index. When we correct the Zip file implementation to properly handle folders, this will speed things up, since since it will be able to traverse down to a specific folder, and only have to scan the files of that folder. | ||
* 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 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 makes it non-portable. In addition, the filenames | * 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 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"> | ||