Difference between revisions of "User:Fingolfin"

Jump to navigation Jump to search
1,801 bytes added ,  19:30, 21 June 2007
Line 18: Line 18:
* get rid of getSavePath -> AFAICT it's only used for enhanced error/warning messages. So let's just finally add a Stream::ioErrorString methor or so, which describes the error that occured
* get rid of getSavePath -> AFAICT it's only used for enhanced error/warning messages. So let's just finally add a Stream::ioErrorString methor or so, which describes the error that occured
* at the same time might want to replace ioFailed() with an ioError() method which returns an error code, not just a bool
* at the same time might want to replace ioFailed() with an ioError() method which returns an error code, not just a bool
* add a method to remove a savestate  
* add a method to remove a savestate
* properly document listSavefiles
* maybe also one to rename a savestate (less important)
** reimplement DefaultSaveFileManager::listSavefiles
* replace listSavefiles with a better API (possibly function with same name)
** it should take a regex (well, allowing only "?" and "*" like in DOS)
** it would return a List<String> with all matched filenames
** reimplement DefaultSaveFileManager::listSavefiles to actual do more than returning "yes" for all and every filename
** update engines to use (and trust) the new API. With "trust" I mean that some engines currently double-check the results of it with openFileForLoading (and good that they do so, considering that right now the default savefilemanager does *not* implement it. *sigh*) 
* Consider replacing "const char *" usages with "Common::String". This might or might not be a good idea -- don't just do it blindly!
 


=== File code ===
=== File code ===
Line 27: Line 33:
* at the same time, finally change File to read-only, and add a DumpFile class, which can be used for script dumps, screenshots etc.; ports can simply provide an "empty" implementations if they don't support dumping large files
* at the same time, finally change File to read-only, and add a DumpFile class, which can be used for script dumps, screenshots etc.; ports can simply provide an "empty" implementations if they don't support dumping large files
* To enforce that no code uses fopen etc. directly, we could add our own #define's to scummsys.h to trigger errors in code doing it
* To enforce that no code uses fopen etc. directly, we could add our own #define's to scummsys.h to trigger errors in code doing it
*


=== GUI ===
=== GUI ===
Line 49: Line 56:
** document the semantics of sound handles and sound ids
** document the semantics of sound handles and sound ids
** cleanup the API (TODO: Be more specific)
** cleanup the API (TODO: Be more specific)
=== SCUMM ===
* Once the new SaveFileManager::remove method is there, add a "remove" button to the save/load dialog
=== Misc ===
* Remove the 'addDefaultDirectory' calls from runGame in base/main.cpp. Reason: Their presence causes an asymmetry between the "detect a game" and "run a game" use cases, as different files are "seen" in each case. This can lead to subtle bugs, and also causes ugly code duplication in the AdvancedDetector code right now (there to work around asymmetries like this one)
* Right now the SCUMM engine uses zlib directly. This causes problems when building plugins, as we have to link the SCUMM engine against zlib, so we have to hack the build system to do so. It also causes backlinking problems on e.g. Windows
** Solution #1: Let the ScummVM binary re-export the zlib API. Pro: Very clean and elegant, Con: Might not be possible on all targets (investigate)
** Solution #2: Create thin wrappers around all relevant zlib APIs, put those into a new file common/zlib.cpp, and make SCUMM use those
* add plugin API to fetch a fresh desc string for a given target ?!?


== Wish list ==
== Wish list ==
1,079

edits

Navigation menu