Difference between revisions of "TsAGE/TODO"

From ScummVM :: Wiki
Jump to navigation Jump to search
(CD version is completable)
m (Minor cleanup of TsAGE TODOs)
 
(26 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This is a list of things that still need to be handled properly for the Ringworld game:
{{Infobox_TODO|
*Add sound support
taskname=TsAGE Engine TODO|
**Adlib
techcontact=[[TsAGE]] Engine Team|
**Sound Blaster
subsystem=Engine|
**Midi (MT-32)
}}


Known engine bugs:
== Game status ==
* There's a Valgrind warning in SceneObject::removeObject() about _visage being undefined when it tests for it. ("Conditional jump or move depends on uninitialised value(s)".
* Ringworld Floppy version: Completable.
* The start play / introduction dialog looks a bit different int the CD version compared to the floppy versions currently implemented. It's positioned slightly differently, the "Introduction" button has a different border (default button, perhaps?), and when clicked the button goes black, not red.
* Ringworld First wave version: Completable.
* In DOSBox, the button remains selected unless I move the mouse entirely off the button. (Should be fixed now, but the fix is a bit hackish.)
* Ringworld CD version: Completable.
* Quitting the game while the inventory dialog is open generates a failed assertion.


Known hardcoded logic bugs in floppy version:
* Blue Force Floppy version: Completable.
* In scene #6100, the Rocks occasionally get drawn on-screen over-sized at the very bottom of the screen. This is most easily noticable by navigating into a sunflower.
* Blue Force First wave version: Completable.
* Blue Force CD version: Completable.
* Blue Force CD Spanish: Not supported.


Known hardcoded logic bugs in First Wave version:
* Return to Ringworld Demo: Completable.
*Scene 2320: When Quinn picks the arms, there a priority glitch (to be verified)
* Return to Ringworld CD: Completable.
*Scene 6100: At the end, texts are not skippable, it looks wrong (to be verified)


Known hardcoded logic bugs in CD version:
== Known Bugs ==
*Scene 2150: Saving in this scene triggers the assertion, "engines/tsage/saveload.cpp:74: void tSage::Serializer::syncPointer(tSage::SavedObject**, Common::Serializer::Version, Common::Serializer::Version): Assertion `idx > 0' failed." Once this is fixed, please check if the elevator works after loading the savegame. There used to be a problem with this in scenes 2320 and 2100.
Ringworld:
*Scene 5100: If I remove the rock that covers the food pit, then enters the throne room but leaves without the stasis box, Quinn and Seeker talks briefly and Quinn goes back for the box. This triggers an assertion, "engines/tsage/converse.cpp:249: virtual void tSage::SequenceManager::signal(): Assertion `_sceneObject' failed."
* None.
*Scene 6100: If I allow the probe to get too damaged, it leads into a conversation between Quinn and Seeker. The mouse cursor is shown here - I don't know if that's a bug or not - and the cursor movement is much jerkier than usual. (This jerkiness is also present when successfully reaching the destination with the probe.)
*Scene 7000: I'm a bit uncertain about this, but it appears that if you talk to Skeenar ("I can't swim with you ...", "Lord Poria will not come ...") and then walk back to the lander, Quinn enters through the elevator door and the scene with the pod returning is replayed. This talk action causes Scene7000::Object1::doAction(CURSOR_TALK) to be called. None of the flags it tests for is true, so it falls into the final else. Is there something about this that triggers the bug, I wonder... (If I force flag 13 to be set, returning to the lander puts me in the room with the pressure suits, and the code in that case is similar, so I guess it has something to do with how you return to the lander.)
*Scene 2100: After being told to look for the Explorer, I went to talk to Seeker. But when I do, Quinn uses the computer console (scene 2120) instead.
*Scene 2320: This may be by design, but after being told to look for the Explorer I was able to construct the arms for the dolphin. I didn't even know I would need that!


Present in the original game:
Blue Force:
*Scene 4000 (or maybe 4045): If you tell the chief to show you the Tech, Miranda will say "Quinn, it's a simple force field regulator", even if she's not in the room with you because she's stuck with Rock. (Update: This is apparently a bug in the original interpreter as well, but could perhaps be fixed in ScummVM?)
* Game speed is much slower (~50%) compared to original interpreter running under DOSBox.
*Scene 5300: This may not be a bug, but if I escape this room and are recaptured (by falling into the pit again), Quinn says "Was it something I said?", etc. Is he supposed to say that every time, or just the first time I get here?
* Map Cursor slow to appear and is not USE hand...
*Scene 5100: After stunning one of the flesheaters, the other one runs away. If you stun the one on the right, the other one hides on the far left of the scene. Even though you can't see it, you can examine it and touch it. The descriptions you get are the same as for the stunned flesheater. Apparently, the game doesn't make any difference between them.


Game status:
=== Present in the original game (Script Bugs) ===
*Floppy version: Completable.
Ringworld:
*First wave version: Completable.
* Scene 2320: After being told to look for the Explorer I was able to construct the arms for the dolphin. I didn't even know I would need that!
*CD version: Completable.
* Scene 4000 (or maybe 4045): If you tell the chief to show you the Tech, Miranda will say "Quinn, it's a simple force field regulator", even if she's not in the room with you because she's stuck with Rock.
* Scene 5100: After stunning one of the flesheaters, the other one runs away. If you stun the one on the right, the other one hides on the far left of the scene. Even though you can't see it, you can examine it and touch it. The descriptions you get are the same as for the stunned flesheater. Apparently, the game doesn't make any difference between them.
* Scene 5300: If I escape this room and are recaptured (by falling into the pit again), Quinn says "Was it something I said?", etc. This happen until Quinn drinks the potion, so it looks a bit weird when it's not the first time.
* Scene 6100: If I allow the probe to get too damaged, it leads into a conversation between Quinn and Seeker. The mouse cursor is shown here (present in the original) and the cursor movement is much jerkier than usual. (This jerkiness is also present when successfully reaching the destination with the probe.)
* Scene 6100: At the end, texts are not skippable, it looks wrong
 
Blue Force:
* None
 
=== Possible Enhancements ===
 
* Currently only Adlib/Soundblaster is supported. It would be nice to support others, such as Roland or General Midi
 
* Rewrite the savegame mechanism
 
Currently the savegame code works similiar to the original, in that every object derives from a 'SavedObject' base, which is registered in a master list when objects that derive from it are instantiated. So the saving code essentially loops through the objects one by one to have each save their data in turn. The trouble with this it when loading a savegame, it relies on all the objects registered in the list to have been instantiated in the exact same order; which may not be the case if the savegame is loaded in another system, or even which an executable compiled using another compiler, since the fields of a given class are guaranteed to be created in the same order.
 
A lot of this could be resolved by replacing this with a manual hierarchnical saving of data, where the overall Globals object would explicitly call the synchronize method of all the objects within it, and they each explicitly call the method for the objects they contain, and so on. Whilst this would handle the majority of the save process, there is one remaining issue, that of pointer handling.
 
In many places in the engine there are pointers to other objects. The Sequence (Cutscene) manager can, for example, take in pointers for the characters the cutscene applies to. Currently these are handled by storing the index in the list of instantiated objects of the object the pointer points to, and then doing a lookup doing savegame restore. Because of this, it will be very difficult to get rid of the existing savegame mechanism without coming up with a good way to represent the same information. Perhaps giving any object that can be pointed to a unique Id, and having a lookup list of only those Ids. This might ensure savegame restore would work, and allow them to be portable.

Latest revision as of 12:51, 16 March 2016

TODO List
Name TsAGE Engine TODO
Technical Contact(s) TsAGE Engine Team
Subsystem Engine

Game status

  • Ringworld Floppy version: Completable.
  • Ringworld First wave version: Completable.
  • Ringworld CD version: Completable.
  • Blue Force Floppy version: Completable.
  • Blue Force First wave version: Completable.
  • Blue Force CD version: Completable.
  • Blue Force CD Spanish: Not supported.
  • Return to Ringworld Demo: Completable.
  • Return to Ringworld CD: Completable.

Known Bugs

Ringworld:

  • None.

Blue Force:

  • Game speed is much slower (~50%) compared to original interpreter running under DOSBox.
  • Map Cursor slow to appear and is not USE hand...

Present in the original game (Script Bugs)

Ringworld:

  • Scene 2320: After being told to look for the Explorer I was able to construct the arms for the dolphin. I didn't even know I would need that!
  • Scene 4000 (or maybe 4045): If you tell the chief to show you the Tech, Miranda will say "Quinn, it's a simple force field regulator", even if she's not in the room with you because she's stuck with Rock.
  • Scene 5100: After stunning one of the flesheaters, the other one runs away. If you stun the one on the right, the other one hides on the far left of the scene. Even though you can't see it, you can examine it and touch it. The descriptions you get are the same as for the stunned flesheater. Apparently, the game doesn't make any difference between them.
  • Scene 5300: If I escape this room and are recaptured (by falling into the pit again), Quinn says "Was it something I said?", etc. This happen until Quinn drinks the potion, so it looks a bit weird when it's not the first time.
  • Scene 6100: If I allow the probe to get too damaged, it leads into a conversation between Quinn and Seeker. The mouse cursor is shown here (present in the original) and the cursor movement is much jerkier than usual. (This jerkiness is also present when successfully reaching the destination with the probe.)
  • Scene 6100: At the end, texts are not skippable, it looks wrong

Blue Force:

  • None

Possible Enhancements

  • Currently only Adlib/Soundblaster is supported. It would be nice to support others, such as Roland or General Midi
  • Rewrite the savegame mechanism

Currently the savegame code works similiar to the original, in that every object derives from a 'SavedObject' base, which is registered in a master list when objects that derive from it are instantiated. So the saving code essentially loops through the objects one by one to have each save their data in turn. The trouble with this it when loading a savegame, it relies on all the objects registered in the list to have been instantiated in the exact same order; which may not be the case if the savegame is loaded in another system, or even which an executable compiled using another compiler, since the fields of a given class are guaranteed to be created in the same order.

A lot of this could be resolved by replacing this with a manual hierarchnical saving of data, where the overall Globals object would explicitly call the synchronize method of all the objects within it, and they each explicitly call the method for the objects they contain, and so on. Whilst this would handle the majority of the save process, there is one remaining issue, that of pointer handling.

In many places in the engine there are pointers to other objects. The Sequence (Cutscene) manager can, for example, take in pointers for the characters the cutscene applies to. Currently these are handled by storing the index in the list of instantiated objects of the object the pointer points to, and then doing a lookup doing savegame restore. Because of this, it will be very difficult to get rid of the existing savegame mechanism without coming up with a good way to represent the same information. Perhaps giving any object that can be pointed to a unique Id, and having a lookup list of only those Ids. This might ensure savegame restore would work, and allow them to be portable.