ScummVM: Another status update
I have just posted this WIP to GP32Xtream so I figured I would copy it here.
Regarding the status of gpScumm, here is a little WIP. I have the ph0x’s/my code working well enough on the ScummVM 0.5.1 code base (and CVS code) but performance in some newer games is shockingly bad. Sam and Max and the non-LucasArts games are not really playable (slow or buggy) currently. I have just figured out tonight how (I think) to get it all to build using ARM ADS so if the performance claims are true that could lead to a healthy speed up of maybe even 5-8% over GCC. Other then that there are some fixes to the sound code, save code and a few general speedups/tweaks and little changes to the port, nothing too major. All the fixes that went into the core ScummVM engine from 0.3 > 0.5 are also in there (obvious really).
As soon as I can get most games up to a playable speed then I intend to chuck a public beta and source out of the door. I don't really see the point in releasing a version that is little better then what is already out (or in some cases much slower).
I am also working on adding OGG (libTremor) and MP3 (libMAD) support to gpScumm but a number of issues make that quite slow going, namely the lack of memory on the GP32 and the CPU cycles required to decode the MP3/OGG stream and the fact that fmOPL (the engine ScummVM uses for AdLib synthesis) is a CPU hog on the GP32 making it very hard to get game, MIDI and MP3 or OGG working in the 133MHz speed limit. I have no problem with overclocking but I am dammed if you will have to overclock the program just to get it to work.
Also, the fact that I am really not that good a programmer does not help. I am fairly sure I’ll get it working in the end (I have some great offers of help) but don’t hold your breath.
Regarding the status of gpScumm, here is a little WIP. I have the ph0x’s/my code working well enough on the ScummVM 0.5.1 code base (and CVS code) but performance in some newer games is shockingly bad. Sam and Max and the non-LucasArts games are not really playable (slow or buggy) currently. I have just figured out tonight how (I think) to get it all to build using ARM ADS so if the performance claims are true that could lead to a healthy speed up of maybe even 5-8% over GCC. Other then that there are some fixes to the sound code, save code and a few general speedups/tweaks and little changes to the port, nothing too major. All the fixes that went into the core ScummVM engine from 0.3 > 0.5 are also in there (obvious really).
As soon as I can get most games up to a playable speed then I intend to chuck a public beta and source out of the door. I don't really see the point in releasing a version that is little better then what is already out (or in some cases much slower).
I am also working on adding OGG (libTremor) and MP3 (libMAD) support to gpScumm but a number of issues make that quite slow going, namely the lack of memory on the GP32 and the CPU cycles required to decode the MP3/OGG stream and the fact that fmOPL (the engine ScummVM uses for AdLib synthesis) is a CPU hog on the GP32 making it very hard to get game, MIDI and MP3 or OGG working in the 133MHz speed limit. I have no problem with overclocking but I am dammed if you will have to overclock the program just to get it to work.
Also, the fact that I am really not that good a programmer does not help. I am fairly sure I’ll get it working in the end (I have some great offers of help) but don’t hold your breath.
By DJWillis On Wednesday, October 15, 2003 At 5:01 pm
There are no comments yet. If you want, you can leave your own response by clicking here.
There are no comments yet. If you want, you can leave your own response by clicking here.