Jump to content

Home

jott

Members
  • Posts

    58
  • Joined

  • Last visited

Personal Information

  • Resolution
    1920x1200
  • Height in cm
    0

jott's Achievements

Newbie

Newbie (1/14)

10

Reputation

  1. If it is helps, all my relevant code parts are hereby dual-licensed under the MIT and GPLv2 (or later) license. That is extractpak.c, mkspeech.c (which was only GPLv3) and speech.c. My modifications to unxwb are of course GPLv2 (or later). I assume for my part this should be sufficient as a statement.
  2. As far as I understand, the mapping from the original SCUMM files to the new textures is done via a serialized binary representation of xml files. The central part is the monkey1_retail.scumm.xml which refers to (almost) all used costumes and backgrounds. So here the original rooms and costumes are most likely mapped to the new ones. The rooms and costumes again are in some binary format (which by it's extension can be assumed to be some sort serialization of an xml file). For costumes I started to reverse engineer the fields and definitions. It is pretty complete: http://www.lucasforums.com/showpost.php?p=2651346&postcount=84 For the rooms and the main "xml" file the structure looks very similar but it seems nobody has done any work on it yet (at least there is nothing published). So, if you like, look into the other "xml" files and try to define some structures. This way a further step in understanding the whole system could be done (in the end it would be great to have ScummVM support MISE). Other than that, there seem to be some hardcoded references in the new SCUMM engine that is used. So some parts may only be revealed by code analysis (or LucasArts opening up.. *g*).
  3. You are probably right, the context needed should be small or just an offset, if the delta algorithm is smart enough. I was thinking too much about normal text diff there.
  4. Exactly. And I agree that it's not as burning as the other problems but would be nice to have. Well if it is (legally) possible to redistribute a full patch that includes all current changes there will indeed not be much left to do. The mapping for the mkspeech can be dumped from the current automatic association based on the scummtr output. As we touch every line of speech I am not quite sure how the legal point in redistributing a patch is (as it will include nearly all of the text lines) so using scummtr is less problematic for that matter. On the other hand the installer could easily be bundled with all the necessary tools and just call them properly. I sent Espiox a rough script as a starting point for just that about a week ago.
  5. First of all the modified SCUMM scripts have to be finished. There are still some minor things to do IMHO (removing some of the "Throopweed" variations, maybe add logic to the sword fighting scenes that the proper response sample is chosen, ...) If that is done, there is still some more work to be done, as the sword fighting scenes (and some other places) need a proper speech file assignment. Finally the installer has to be finished to reduce the need of technical skills. I'm not sure how Espiox is coming forward with that. For my very rough estimate, I guess it's about 5-8 man hours of work with some polish, maybe more. Translate that to the spare time everyone involved has for the project.... Of course anyone who wants to help out is welcome to do so. Alpha & beta testing is essential too....
  6. Maybe the secret project is MI2SE ....... Would be great to have actual Monkey Island fans work on the graphics.
  7. I wonder if it would be easier to patch ScummVM instead of messing with nearly all scripts.....
  8. Ok, I updated the tool again. Now it should fall back to the next best line when the room does not match... I'm not sure how much more time I will/can put into this...... well.... the source code is as always included. And I cleaned the code up at least a little bit. Also a value of -2 in the mapping.txt should ignore the sample for the line... i.e. "66,1=-2". But this is untested.
  9. Well now it only matches if the room number is correct. I think there are really few rooms that do not match, so it's probably not worth the effort to add extra logic there. The remaining lines are mostly the sword fight scenes.
  10. Well still I assume fixing FOA sync is not trivial (otherwise it would probably be done already). I also think that the current approach is better, as the lines are always in sync this way. And I bet it won't be that hard to fix the problem when subtitles are disabled. Yeah, I'll probably add something later. "x,y=-1" should do the job I guess.. I really like the Guybrush_UnknownFilename_07 sample *g* Is it actually included at the moment? Only samples that have a matching text line are copied to the monster.soX anyway... Feel free to do so! I never played around with descumm so I can't help you there.
  11. Ok, with the hint of LogicDeLuxe it works MUCH better now. EDIT: It also matches the interaction/script number now. So even less collisions. The input file needs to be generated with: scummtr -cw -g monkeycdalt -of mi1.txt -h -H For the output it remains the same (the meta-info is not copied): scummtr -cw -g monkeycdalt -if mi1new.txt -H As usual the updated version at the same place: http://helicoid.de/scumm/mkspeech.zip P.S.: Stupid question: How to disable the subtitles for MI1 in ScummVM? I have set it to "Speak only" but the subtitles still pop up... P.P.S.: Well the room number for Spiffy is wrong ..... hardcoded the change. I also filter all "OBNA" lines now....
  12. Well we could, but it will not improve FOA with the current approach as FOA only uses one sample per line. (Well a mod could probably be made .. but I wonder if there would be any people willing to do so....). Fell free to make a patch though :-) Oh! I must have overlooked the -h option. Well yes, this could indeed improve it a lot.
  13. Ah! That's exactly what I was missing. Thanks. Ok, this will not help with multiple lines. I wonder if it helps with cut off samples when having the last tag >= length of the sample... While that is true, I think we can expect people to use ScummVM when they want a proper Talkie version. And I was somehow hoping we could find a trick this way... As said, multiple lines are in fact working fine with ScummVM only that they are messed up when the subtitles are turned off. Well that said, the tags are definitely no solution for this problem, as they are just for lip-animation timing nothing more. So this finally leaves us this four options: 1) Try to patch ScummVM and bring the patch upstream. 2) Modify the scripts so no more multi-lines are used. 3) Merge audio files and have out of sync subtitles. 4) Force the user to always have subtitles enabled. Or am I missing something? IMHO 1) or 2) are the better solutions as they should not have any negative side-effects. Hey, the party just started
  14. Hmm strange, this particular scene seems to work fine here. I'm using the latest SVN build of ScummVM btw.... Anyway, if somebody has some inside knowledge of the exact tag definition that (s)he is willing to share, we could probably fix some of the problems....
  15. Oh I did not say that. I just wondered if there is an "official" place for them as it seems to be a bit... hidden... please if there are no objections, we should put all relevant links in the first posting. Hmm that's bad... I am not sure if there is a way to fix it. I guess we could either go back to merging the samples (which would bring the text and speech out of sync....), look if ScummVM would accept a patch that fixes this behavior or modify the game code so that only single lines are used.... (or find out if the tag field might be useful here too) Yes, I noticed that too. Not sure what to do here either. Maybe the "tags" field can be used to prevent this?! Right. Those can be ignored. First: The second number ".,X=..." is used to determine the section when there are multiple lines in one row. Like "Hi!" "My name is Guybrush Threepwood!" And yes, the main task is to find out where a line is said and which is the correct one. For some the context might give a hint, for other there is probably no other way but playing the game to the point where it is said. In theory, yes. There might be fields with a missing sample where the proper sample exists and has to be determined.... but I think it should not happen that often. I would say the priority should be to find the right matches for the ambiguous lines, as those are also the ones which will sound *wrong*. When there is no sample played it's not as strange as when the wrong one is played ....
×
×
  • Create New...