Opened 11 years ago
Closed 11 years ago
#6263 closed defect (wontfix)
LURE: Text speed too fast.
| Reported by: | SF/gk967 | Owned by: | dreammaster |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Lure |
| Version: | Keywords: | ||
| Cc: | Game: | Lure of the Temptress |
Description
Hi! :-)
Dialogue texts are way too fast, (so it's really hard, to read them).
I tried the "slow text" option (from inside the game) and also I minimized the subtitles speed (from options). Still no luck. Some texts are at normal speed, while some others are very fast. I tried with the latest stable version from SF.NET at Win7 x64 and Kubuntu 12.10 x64 (ScummVM, build from sources).
An option needed, to slow down the texts (not the game altogether). Bye! :-)
PS. I attached the savestate at smith's shop. You can talk to his mother or to the smith. Some texts are normal, while some other are way too fast to read.
Ticket imported from: #3608774. Ticket imported from: bugs/6263.
Attachments (1)
Change History (18)
by , 11 years ago
comment:1 by , 11 years ago
| Summary: | Text speed problem. → LURE: Text speed problem. |
|---|
comment:2 by , 11 years ago
| Owner: | set to |
|---|
comment:3 by , 11 years ago
gk967: Have tested with the attached savegame on my Linux x86_64 box with latest git master.
I admit that the texts are fairly quick, but not to the point of unreadability and I don't think this is a regression.
I have tested with both Lure VGA English and Lure EGA English, with no observed difference.
Two questions: 1. Exactly which version of Lure are you using i.e. VGA/EGA and Language, and was this from the downloads on our site? 2. Has this text speed changed since any previous version you have been using? 3. Can you record a small screenshot video demostrating this scene's text speed, post on Youtube and attach the link to this artifact for reference so we can see if we are both observing the same speed. If not, then please time each "line" and attach as a list i.e.
Ego: "Have you found Goewen?" - 4 seconds Smith: "Not yet" - Less than 1 second etc.
comment:4 by , 11 years ago
| Summary: | LURE: Text speed problem. → LURE: Text speed too fast. |
|---|
comment:5 by , 11 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → pending |
comment:6 by , 11 years ago
Hi and sorry for the delayed answer! :-)
Somehow I couldn't found my previous savestates, so I restarted it. This time, texts aren't so fast (although they're still above normal speed). I played LOTT when it was released as freeware (I was using WinXP at the time) and text speed was slower.
I uploaded a half-minute cast here: http://youtu.be/Gw1kDsUmG6c (Sorry for the absence of sound. I just installed GTK-Recordmypc, but it needs some tweaking in kde in order to record the sound as well).
I have downloaded LOTT from the ScummVM download page.
comment:7 by , 11 years ago
| Status: | pending → new |
|---|
comment:8 by , 11 years ago
| Owner: | changed from to |
|---|
comment:9 by , 11 years ago
And sorry for delay in reply as I was away on business! :)
I checked out your video and the text speed is no faster than I am seeing and within reading limit, though I admit I remember it being slower on my old machine (painfully so i.e. the text used to be painfully slow).
I have looked at the code and I suspect that dreammaster's fixes to various parts of the engine and increases in machine speed have exposed a latent issue here in the LURE engine code where the delay for text output is partly implicit i.e. it relied on other parts of code (now removed or faster than on older DOS machine) to be the delay for the text output. I will release this bug and reassign to dreammaster as he should take a look...
comment:11 by , 11 years ago
| Resolution: | worksforme |
|---|
comment:12 by , 11 years ago
| Priority: | normal → high |
|---|
comment:13 by , 11 years ago
This bug is nice to get fixed before the release. Raising priority for keeping the track.
comment:14 by , 11 years ago
I've reviewed the existing code, and the engine uses a hardcoded delay for how long dialogs will remain open. As for subtitle speed, as noticed, there is only the option for 'fast' versus 'slow' text speed.
I did some experiments with hooking in a configurable speed; unfortunately, the engine is fairly complicated in that it not only has semi-independant delays for the dialog overall versus text display, the overall dialog display speed is also used in the background for conversation delays where no dialog is explicitly shown.
Since the speed as it is seems to pretty much match the original, having a more flexible display speed is something that I would consider a feature request, rather than a bug. As such, I'm suggesting we consider it as a lower priority for the upcoming release.
comment:15 by , 11 years ago
| Priority: | high → normal |
|---|
comment:16 by , 11 years ago
Upon further reflection, I'm more convinced that we can't really mess around with the timing of the talk dialogs. Whilst there is basic logic in place to prevent successive dialogs in a talk chain from appearing until a previous one closes, the interactive nature of the game means that NPC characters just walking around can also talk to each other, and slowing down the dialogs would have side effects, such as dialogs remaining active after characters changed screen. Unless I slowed the game down in it's entirety to compensate, I don't really see this as feasible. Closing the ticket with Won't Fix, sorry.
comment:17 by , 11 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Save state.