2,051
edits
Difference between revisions of "OpenTasks"
m
a few typos
(→Many tasks with AGI engine: -- rename) |
m (a few typos) |
||
| Line 43: | Line 43: | ||
''Background:'' | ''Background:'' | ||
ScummVM | ScummVM runs on a great variety of platforms, ranging from full-blown personal computers running Windows, Linux, Mac OS X, etc., to game consoles, smart phones and PDAs (sorry, no support for toasters yet :). | ||
To achieve that, we have to provide abstract APIs for many things, like audio and graphics, user input, and general I/O. One particular area that needs to be covered are filesystems -- great differences exist with regards to this between the platforms we support. In fact, some of them don't even have such a thing as a filesystem. | To achieve that, we have to provide abstract APIs for many things, like audio and graphics, user input, and general I/O. One particular area that needs to be covered are filesystems -- great differences exist with regards to this between the platforms we support. In fact, some of them don't even have such a thing as a filesystem. | ||
Still, we need to access files: | Still, we need to access files: we have to find and load the game data, GUI themes, save states, config files and more (and also have to store save states, obviously). To compensate for the differences between our target systems, we introduced the FilesystemNode API. | ||
In its present state, it fulfills our absolute minimal requirements. However, the abstraction level it provides is flawed and likely should be overhauled / redesigned. Also, not all parts of ScummVM strictly use this API; there are still many parts of ScummVM which try to work with "paths" to access file data. | In its present state, it fulfills our absolute minimal requirements. However, the abstraction level it provides is flawed and likely should be overhauled / redesigned. Also, not all parts of ScummVM strictly use this API; there are still many parts of ScummVM which try to work with "paths" to access file data. | ||
| Line 93: | Line 93: | ||
There are much better ways to resample audio data. It should be band pass filtered and other things done to it. Code to do this exists out there. Integrate such code into ScummVM or roll your own. Make sure to keep resource constraints (CPU, memory) in mind. It should be possible to select which resample to use (the low quality but fast linear filter, or your high quality but not quite so fast fancy filter). | There are much better ways to resample audio data. It should be band pass filtered and other things done to it. Code to do this exists out there. Integrate such code into ScummVM or roll your own. Make sure to keep resource constraints (CPU, memory) in mind. It should be possible to select which resample to use (the low quality but fast linear filter, or your high quality but not quite so fast fancy filter). | ||
Furthermore, on some systems, ScummVM suffers from stutter even though there is plenty CPU power left. The problem here is latency (not throughput). That is, while we can generate data fast, we do so too late. The problem on these system likely could be fixed by using a double buffering approach, i.e. generate audio data | Furthermore, on some systems, ScummVM suffers from stutter even though there is plenty CPU power left. The problem here is latency (not throughput). That is, while we can generate data fast, we do so too late. The problem on these system likely could be fixed by using a double buffering approach, i.e. generate audio data slightly before it is requested to avoid latency issues. | ||
Finally, our AudioStreams currently only can have a single fixed sample rate. But for some usages (in particular, Amiga MOD players), it would be convenient to allow streams to change their sample rate on the fly. Adding support for this would be nice, but should not slow down streams which have a constant sample rate. | Finally, our AudioStreams currently only can have a single fixed sample rate. But for some usages (in particular, Amiga MOD players), it would be convenient to allow streams to change their sample rate on the fly. Adding support for this would be nice, but should not slow down streams which have a constant sample rate. | ||