Difference between revisions of "Tony/TODO"

From ScummVM :: Wiki
Jump to navigation Jump to search
m (Added some comments to two of the points)
(fixed anim issues)
Line 4: Line 4:
  
 
The engine needs the following points to be fixed / implemented:
 
The engine needs the following points to be fixed / implemented:
* only 555 mode is supported
+
* only 555 mode is supported (fuzzie has a patch to make the whole thing run in 565 mode, but ideally it should cope with both)
 
* It is not possible to type upper-case letters in savegame names. This is because the engine uses key codes (which make no difference between upper and lower case) and keeps track on its own when Shift is pressed. (Caps Lock doesn't work at all.) However, the _keyDown[] entries for the shift keys get cleared before the actual letter key is handled. See input.cpp and KEYPRESS() in game.cpp. This seems needlessly complicated.
 
* It is not possible to type upper-case letters in savegame names. This is because the engine uses key codes (which make no difference between upper and lower case) and keeps track on its own when Shift is pressed. (Caps Lock doesn't work at all.) However, the _keyDown[] entries for the shift keys get cleared before the actual letter key is handled. See input.cpp and KEYPRESS() in game.cpp. This seems needlessly complicated.
 
** Agreed. At the time it made connecting the original code to ScummVM easier. For the long run we should refactor it out in favour of using standard ScummVM events directly.
 
** Agreed. At the time it made connecting the original code to ScummVM easier. For the long run we should refactor it out in favour of using standard ScummVM events directly.
Line 12: Line 12:
 
* Slight "pop" noise when pausing/un-pausing the music by opening/closing the options dialog. Maybe in other cases as well.
 
* Slight "pop" noise when pausing/un-pausing the music by opening/closing the options dialog. Maybe in other cases as well.
 
* Changing the music volume doesn't seem to affect the music that's currently playing. Should it?
 
* Changing the music volume doesn't seem to affect the music that's currently playing. Should it?
* Some animations are missing, like
 
** The bush should be moving when Tony changes into the costume to enter the park.
 
** There should be a small cloud of dust when the children run from the clown.
 

Revision as of 21:05, 7 September 2012

Following points need to be tested:

  • BE portability
  • Game stability in Russian, Polish, Czech

The engine needs the following points to be fixed / implemented:

  • only 555 mode is supported (fuzzie has a patch to make the whole thing run in 565 mode, but ideally it should cope with both)
  • It is not possible to type upper-case letters in savegame names. This is because the engine uses key codes (which make no difference between upper and lower case) and keeps track on its own when Shift is pressed. (Caps Lock doesn't work at all.) However, the _keyDown[] entries for the shift keys get cleared before the actual letter key is handled. See input.cpp and KEYPRESS() in game.cpp. This seems needlessly complicated.
    • Agreed. At the time it made connecting the original code to ScummVM easier. For the long run we should refactor it out in favour of using standard ScummVM events directly.
  • Some sound effects seem too loud. Do they get their volumes set properly? (It's also possible that we handle volume wrong. See convertVolume() in engines/agos/sound.cpp for some notes about how DirectSound does it, for instance.) Also, it seems that FPStream::setVolume() is sometimes (often?) called when the sound handle isn't active, so the volume isn't set. Does this cause any problems?
  • The "iris" transition is slower in ScummVM than when I play the game in the original interpreter. (This makes it much more obvious that Tony doesn't appear in the sewers until after the transition has finished when falling through the floor.)
    • The original game iris transition relied on an elliptical draw area in DirectX itself, hence it could be rapidly updated. For ScummVM, we implemented a similar, but simpler circular (rather than ellipsoid) transition. Currently, transitions are done doing full screen updates each frame - if we could calculate the affected areas of the screen between changes in size of the circular area, we could speed up the transition significantly, whilst still having it smooth.
  • Slight "pop" noise when pausing/un-pausing the music by opening/closing the options dialog. Maybe in other cases as well.
  • Changing the music volume doesn't seem to affect the music that's currently playing. Should it?