Difference between revisions of "Tony/TODO"

Jump to navigation Jump to search
245 bytes removed ,  22:33, 11 November 2012
Remove bug fixed by rasky in Pull Request 290 (fix sound effect volumes)
(Add Tony sound dialog issue)
(Remove bug fixed by rasky in Pull Request 290 (fix sound effect volumes))
Line 8: Line 8:
* 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.
* 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?
* It seems that FPStream::setVolume() is sometimes 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 "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.
** 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.
TrustedUser
574

edits

Navigation menu