Grim Fandango Deluxe - Original Thread [Locked]
Moderator: ScummVM Team
-
Pirateguybrush
- Posts: 39
- Joined: Mon Apr 06, 2009 9:48 pm
-
JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
Great to hear! There's also the #residualvm channel atPirateguybrush wrote:cplhenshaw and I are now on Steam chat, working out the details of getting the models into Maya correctly, then back out of Maya (possibly making a stop through Blender on the way), then back into the game. I think we're making decent progress.
http://webchat.freenode.net/
You might find some additional help there.
-
Pirateguybrush
- Posts: 39
- Joined: Mon Apr 06, 2009 9:48 pm
Progress! The model has been exported out of Grim, converted to obj, imported into blender, edited, converted to 3do again, and back into Grim. Somewhere along the way some texture information has been lost, and it's placing the same texture on the whole model. But it's a good start. Once we've worked out this bug, we should be able to get going.
-
JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
-
ultraneonoirantihero
- Posts: 106
- Joined: Mon Sep 05, 2011 5:13 pm
Did you repack the whole original .lab file with the new model, or did you tried that lab-stacking trick?
Mogul said by just adding content in new .lab files with higher number in the filename overwrites the content from the .lab files with lesser number. If the game detects new content it overwrites the old one as obsolete.
Theoretically you can add infinite number of new .lab files each containing some sort of an "update": one .lab for textures, one .lab for models...
This is what they've used for official patch, better to add one small file than to repack the original ~200Mb lab files. The same concept as in JediKnight .pk3 files and modifications.
Mogul said by just adding content in new .lab files with higher number in the filename overwrites the content from the .lab files with lesser number. If the game detects new content it overwrites the old one as obsolete.
Theoretically you can add infinite number of new .lab files each containing some sort of an "update": one .lab for textures, one .lab for models...
This is what they've used for official patch, better to add one small file than to repack the original ~200Mb lab files. The same concept as in JediKnight .pk3 files and modifications.
The preferred way is to use "datausr.lab" which is explicitly added for that purpose, mainly since that allows us to identify user-patches more easily in case there are bugs/problems. (And separate them from bugs with the original game).
This also allows us to tell the user that he has such a patch installed. (Although currently it will whine every time, the idea is to allow for a "yes, I know"-solution, but also to effectively allow for starting the game WITHOUT loading the patches (which has many a use in debugging).
In either case, distributing modified originals is tricky, and irreversible, as well as problematic when bugs show up. But, this is all of course known.
Having said all of that, I can say that EMI does use skeletal animation, which means some support for that might eventually get added, but mixing that with the Grim-rendering will be tricky, especially since moving the skeleton according to the movements in the Grim-models will need special-casing. I will not say it is impossible, but it will not happen soon (and would in any case need someone to do the work).
Whether it will get added to the master-trunk if done is also a discussion that will need to be had, as currently the ideas for technical improvement mostly rely on things added and USED in EMI, while such a solution would add entirely new functionality. Personally I'd say no to adding any extra functionality until we have atleast had a stable release that plays the original game WELL without any extra additions.
That being said, keep up the good work
This also allows us to tell the user that he has such a patch installed. (Although currently it will whine every time, the idea is to allow for a "yes, I know"-solution, but also to effectively allow for starting the game WITHOUT loading the patches (which has many a use in debugging).
In either case, distributing modified originals is tricky, and irreversible, as well as problematic when bugs show up. But, this is all of course known.
Having said all of that, I can say that EMI does use skeletal animation, which means some support for that might eventually get added, but mixing that with the Grim-rendering will be tricky, especially since moving the skeleton according to the movements in the Grim-models will need special-casing. I will not say it is impossible, but it will not happen soon (and would in any case need someone to do the work).
Whether it will get added to the master-trunk if done is also a discussion that will need to be had, as currently the ideas for technical improvement mostly rely on things added and USED in EMI, while such a solution would add entirely new functionality. Personally I'd say no to adding any extra functionality until we have atleast had a stable release that plays the original game WELL without any extra additions.
That being said, keep up the good work
-
Pirateguybrush
- Posts: 39
- Joined: Mon Apr 06, 2009 9:48 pm
Hi guys,
Had contact with JohnnyWalker2001 and showed him a document I was making.
Seeing that we are mostly still in the planning-fase I thought a good analysis of the game would be a great idea.
http://www.mediafire.com/?dtldh3prrn273n3
Warning 52 page Word 2010 document and only year 1 and 2 included. Also the savegame.zip is not included
The guide has 5 main parts
Step by step game run:
A small overview of the game, showing when cutscenes happen, characters are introduced, have a costume change or when new items are in the inventory.
This all is linked with savegame names example:(S23Y1). So you can revisit an updated scene with ease when updating things.
Cutscenes analysis:
Full analysis on the locations, characters and items used in every cut scene.
Character overview:
List of all the in game characters divided by years. Information included are for .3do and .cmp .mat files.
(not all information included yet)
Item overview:
List of all the in items divided by years. Information included are for .3do and .cmp .mat files.
(hardly any information included yet)
Location overview:
Overview of all locations used in the game. Included is how many angles and special effect every location uses. Information included are for .bm files.
For the location overview I made a Photoshop file, including all backgrounds that are found ingame as a layer in the image named as the.bm filename. Warning 117MB .PSD file
http://www.mediafire.com/?r56qs85dd5sqf8v
Also for the guide I plan on making simple .bat files that subdivides the Grim Fandango.lab files in the same way as done in the guide. I've already done this for all the location files used.
My aim for this document was mainly as a guide for what there has to be done and for new members so they know what where is and what has to be done. This could be expanded by a work list on what items has been done and workflow information to get new members started.'
I hope you guys like it and let me know how you want to improve it. be critical because I'm starting year 3 and 4 and i wanted to make sure I'm going in the right direction with this document.
Also I will be helping doing 2d art work and if needed 3d.
Had contact with JohnnyWalker2001 and showed him a document I was making.
Seeing that we are mostly still in the planning-fase I thought a good analysis of the game would be a great idea.
http://www.mediafire.com/?dtldh3prrn273n3
Warning 52 page Word 2010 document and only year 1 and 2 included. Also the savegame.zip is not included
The guide has 5 main parts
Step by step game run:
A small overview of the game, showing when cutscenes happen, characters are introduced, have a costume change or when new items are in the inventory.
This all is linked with savegame names example:(S23Y1). So you can revisit an updated scene with ease when updating things.
Cutscenes analysis:
Full analysis on the locations, characters and items used in every cut scene.
Character overview:
List of all the in game characters divided by years. Information included are for .3do and .cmp .mat files.
(not all information included yet)
Item overview:
List of all the in items divided by years. Information included are for .3do and .cmp .mat files.
(hardly any information included yet)
Location overview:
Overview of all locations used in the game. Included is how many angles and special effect every location uses. Information included are for .bm files.
For the location overview I made a Photoshop file, including all backgrounds that are found ingame as a layer in the image named as the.bm filename. Warning 117MB .PSD file
http://www.mediafire.com/?r56qs85dd5sqf8v
Also for the guide I plan on making simple .bat files that subdivides the Grim Fandango.lab files in the same way as done in the guide. I've already done this for all the location files used.
My aim for this document was mainly as a guide for what there has to be done and for new members so they know what where is and what has to be done. This could be expanded by a work list on what items has been done and workflow information to get new members started.'
I hope you guys like it and let me know how you want to improve it. be critical because I'm starting year 3 and 4 and i wanted to make sure I'm going in the right direction with this document.
Also I will be helping doing 2d art work and if needed 3d.
Impressive work!
Indeed, the best way to run through the locations is using the debug codes.
I've two suggestions, having looked briefly at the document:
1) Put the extension to the files in the list you did.
2) Use a non-proprietary format for the document. Libreoffice doesn't seem to parse .docx too well, so please use either .odt or .pdf.
I'm sorry to say this, but the savegame format changed today, so all the savegames you did are not going to work.Lasternom wrote: This all is linked with savegame names example:(S23Y1). So you can revisit an updated scene with ease when updating things.
be helping doing 2d art work and if needed 3d.
Indeed, the best way to run through the locations is using the debug codes.
I've two suggestions, having looked briefly at the document:
1) Put the extension to the files in the list you did.
2) Use a non-proprietary format for the document. Libreoffice doesn't seem to parse .docx too well, so please use either .odt or .pdf.
Just to chip in, there are tons of smaller video-only parts to the game too, for instance, Domino driving off when Manny enters the garage is a video (that doesn't fill the screen). Glottis entering and leaving his hut is a video.
(Which means that changing the models away from that, in any way might make the transition from video to rendered visible unless you guys take care...
(Which means that changing the models away from that, in any way might make the transition from video to rendered visible unless you guys take care...
-
Pirateguybrush
- Posts: 39
- Joined: Mon Apr 06, 2009 9:48 pm
That sounds like awesome work. I'll take a look at it in a while. When you say you want to help with 2d work, do you mean textures?
As for the comprehensive breakdown you mentioned, it sounds like that would be perfect if anyone ever decides to remodel the whole game so it can be re-rendered at a higher resolution.
As for smooth transitions between cutscene models and in-game models, I don't think we can realistically re-animate everything for the cutscenes. I think we'll just have to deal with the old cutscenes and new models - for now, at least.
As for the comprehensive breakdown you mentioned, it sounds like that would be perfect if anyone ever decides to remodel the whole game so it can be re-rendered at a higher resolution.
As for smooth transitions between cutscene models and in-game models, I don't think we can realistically re-animate everything for the cutscenes. I think we'll just have to deal with the old cutscenes and new models - for now, at least.
Ah the savegames were expected not to last long, seeing how the work with Residualvm is still underway. I've also found the debug codes later on and wondered if there was still any use for them. But they mostly came out of necessity while making the document and speedrunning the game to get the savegame files back is only a few wasted hoursgiucam wrote:Impressive work!
I'm sorry to say this, but the savegame format changed today, so all the savegames you did are not going to work.
Indeed, the best way to run through the locations is using the debug codes.
I've two suggestions, having looked briefly at the document:
1) Put the extension to the files in the list you did.
2) Use a non-proprietary format for the document. Libreoffice doesn't seem to parse .docx too well, so please use either .odt or .pdf.
Btw I plan to make the document support .pdf soon when I'm closer to the final design. Also on what files do you need the extensions there are to many lists in the document.
"Comprehensive breakdown" is my aim, at this moment its a short overview of what is ingame. The document at the moment is still lacking on many fronts and like somaen pointed out and has been pointed out on this thread before. That there are alot of small ingame cutscenes I hardly documented at all ATM. The only 2 big ingame cutscenes are noted at locations. Under "Extra" you can find backgrounds that were used for a those two.Pirateguybrush wrote:That sounds like awesome work. I'll take a look at it in a while. When you say you want to help with 2d work, do you mean textures?
As for the comprehensive breakdown you mentioned, it sounds like that would be perfect if anyone ever decides to remodel the whole game so it can be re-rendered at a higher resolution.
As for smooth transitions between cutscene models and in-game models, I don't think we can realistically re-animate everything for the cutscenes. I think we'll just have to deal with the old cutscenes and new models - for now, at least.
Where do i find these files because to me those seem like background effect with a model overlay (the clips ofc)somaen wrote: (that doesn't fill the screen). Glottis entering and leaving his hut is a video.
Look at the http://www.mediafire.com/?1mtcqtnkpwelcqa in scrummv3 you can see the background animation for it.
As for the cutscenes themselves I came to conclusion.
That we might want to aim for a game, where once the cutscene were the best quality part of the game, to a deluxe version where the cutscenes are the worst.
As for 2d I indeed mean 2d artwork like backgrounds or texturing, however seeing that we first need remade models before we can really start texturing, i started doing the game analysis a bit more. also I like ultraneonoirantihero idea of widescreening the game he describes at page 7. That is the reason why the locations part of the document are more expanded then the rest.
BTW I stole the idea of his widescreen youtube title page for my document sorry
Upscaling movies
Hi chaps
I have been playing around with the movies in an attempt to upscale them to 1280x960. I'm using a combination of Avisynth filters to
a) deblock and denoise
b) anti-aliase edges
c) reduce banding
d) upscale
e) sharpen
f) double frame rate to 30FPS using frame interpolation
So far, so good. I've just processed the intro video and it's looking quite nice. Still early days and the scripts need refinement but it seems the videos can be scaled up without looking too bad. Obviously the original videos are over-compressed, causing some ugly blocking artifacts in places, but these can be minimized with some fairly strong deblocking filters. The edge aliasing can also be successfully managed, along with the upscaling and sharpening. The banding caused by the low colour depth is also an issue, but I think it can be managed (it's a balance between too much smoothing versus retaining the original detail).
Anyway, I'll attach a few frame grabs later when I get a chance (and maybe also a video clip).
Should I continue, or is the video side of things already being taken care of? I can also look at upscaling and cleaning up the background images if need be.
Regards
Jumba
I have been playing around with the movies in an attempt to upscale them to 1280x960. I'm using a combination of Avisynth filters to
a) deblock and denoise
b) anti-aliase edges
c) reduce banding
d) upscale
e) sharpen
f) double frame rate to 30FPS using frame interpolation
So far, so good. I've just processed the intro video and it's looking quite nice. Still early days and the scripts need refinement but it seems the videos can be scaled up without looking too bad. Obviously the original videos are over-compressed, causing some ugly blocking artifacts in places, but these can be minimized with some fairly strong deblocking filters. The edge aliasing can also be successfully managed, along with the upscaling and sharpening. The banding caused by the low colour depth is also an issue, but I think it can be managed (it's a balance between too much smoothing versus retaining the original detail).
Anyway, I'll attach a few frame grabs later when I get a chance (and maybe also a video clip).
Should I continue, or is the video side of things already being taken care of? I can also look at upscaling and cleaning up the background images if need be.
Regards
Jumba