Grim Fandango Deluxe - Original Thread [Locked]
Moderator: ScummVM Team
-
YakBizzarro
- Posts: 37
- Joined: Wed May 18, 2011 8:10 am
Just registered to post in this thread. I am a huge Grim Fandango fan, and to see an HD project with legs is something I never thought would happen. The work done so far looks amazing! No modeling skills myself, else I'd offer to help, just wanted to express appreciation for the work you guys have started.
I can also relate to having no time because of Diablo 3.
I can also relate to having no time because of Diablo 3.
I'd say finish the entire models for Manny and Glottis before continuing. That way, you can release full two updated models that can be played in the whole game. That way, just in case for whatever reason Grim Fandango Deluxe doesn't end up being finished, the two models will still be available to play in ResidualVM.Blacksad wrote:To be honest, not at the moment. I'm totally busy playing diablo3 right now
Further there are some decisions to be made before we continue. Should we finish the manny and glottis models for the whole game, or should we finish the other models for the first year?
-
JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
-
Harrypoppins
- Posts: 124
- Joined: Sat Apr 25, 2009 1:23 pm
Hi, I'd like to help with this project.
I'm a programmer (although I don't know if I could help much with those skills, since I haven't done much byte I/O work), and I'm a 3D modeler and I've worked graphics too, so I'd like to do as much as I can.
The only trouble I've ran into is gathering all those tools you've written
I've been hunting this thread for a while now, so do you think any of you could make a summary post with all the tools needed?
Thanks in advance, and I hope I could be of some use to you.
EDIT: BTW, facial expressions are all separate images put in one MAT file. How many of them are in a file, is stored at byte offsets 0x0C and 0x10 (Why there are two values, I don't know, maybe it'a rows/columns thing.). And I think that some of them use a bit of compression (not compression per-se, but something like "division by n^2")...
For example, Manny's facial expressions are in m_jaw.mat (I think there are 10, I forgot...), so if that wasn't accounted for, I think a new extraction tool will be needed. Did somebody already come to this conclusion?
EDIT 2: The dimensions of the images are held in the MAT file too, at offsets 0x74 and 0x78 (4 bytes going backwards, although only the last two are relevant, not counting the ones about the compression), and depending of the file (if it's a multi-part MAT, at the end offset of the end of the image + 0x74 or 0x78).
EDIT 3:
There you go, an example:
http://www.youtube.com/watch?v=f2FCrwvklkw
Sorry about choppy FPS, and no Audio, didn't set it in my recorder settings...
I'm a programmer (although I don't know if I could help much with those skills, since I haven't done much byte I/O work), and I'm a 3D modeler and I've worked graphics too, so I'd like to do as much as I can.
The only trouble I've ran into is gathering all those tools you've written
I've been hunting this thread for a while now, so do you think any of you could make a summary post with all the tools needed?
Thanks in advance, and I hope I could be of some use to you.
EDIT: BTW, facial expressions are all separate images put in one MAT file. How many of them are in a file, is stored at byte offsets 0x0C and 0x10 (Why there are two values, I don't know, maybe it'a rows/columns thing.). And I think that some of them use a bit of compression (not compression per-se, but something like "division by n^2")...
For example, Manny's facial expressions are in m_jaw.mat (I think there are 10, I forgot...), so if that wasn't accounted for, I think a new extraction tool will be needed. Did somebody already come to this conclusion?
EDIT 2: The dimensions of the images are held in the MAT file too, at offsets 0x74 and 0x78 (4 bytes going backwards, although only the last two are relevant, not counting the ones about the compression), and depending of the file (if it's a multi-part MAT, at the end offset of the end of the image + 0x74 or 0x78).
EDIT 3:
There you go, an example:
http://www.youtube.com/watch?v=f2FCrwvklkw
Sorry about choppy FPS, and no Audio, didn't set it in my recorder settings...
OK, I brushed up on my byte work, and now I'm creating something similar to MatMaster, but specifically for Grim Fandango.
Currently it's functionality is very limited because I don't know the correct process that you guys use.
The prog exports MAT files to TGA (8-bit, Indexed), in their correct colors (if the correct CMP pallete is chosen), so they can be edited directly. It shouldn't be difficult to make the reverse process too, but I don't know what you guys succeeded in doing manually, for example: 16 bits. I'll continue when somebody checks in.
EDIT:
Here's a bit of it in action. It looks bad, and hasn't got many features, but you should get the picture. I'll wait for further input, as not to work in vain.
http://www.youtube.com/watch?v=lZh4dPOwl_0&hd=1
Currently it's functionality is very limited because I don't know the correct process that you guys use.
The prog exports MAT files to TGA (8-bit, Indexed), in their correct colors (if the correct CMP pallete is chosen), so they can be edited directly. It shouldn't be difficult to make the reverse process too, but I don't know what you guys succeeded in doing manually, for example: 16 bits. I'll continue when somebody checks in.
EDIT:
Here's a bit of it in action. It looks bad, and hasn't got many features, but you should get the picture. I'll wait for further input, as not to work in vain.
http://www.youtube.com/watch?v=lZh4dPOwl_0&hd=1
-
JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
No problem, I'll make it save a multiple MAT file, although it might take a while.
What I'm interested in is:
-Did you find a way to make a 16bit image and use it in-game?
-I noticed that some of the MAT's have a transparency bit (for use in images like Glotis' mouth. I'm not sure how TGA handles that, but I'm guessing that's a palette thing)
-I read in some previous posts that you managed to use a palette with more than 256 colors? Could you explain that to me, so I could implement it code-wise?
Thanks.
Oh and by the way, (I mentioned I'm a 3D modeler), in the case of rebuilding the models, normally you'd have to adapt their UV's to match the original textures, or modify all of the textures to match the model's UV's. How do you go about this process?
What I'm interested in is:
-Did you find a way to make a 16bit image and use it in-game?
-I noticed that some of the MAT's have a transparency bit (for use in images like Glotis' mouth. I'm not sure how TGA handles that, but I'm guessing that's a palette thing)
-I read in some previous posts that you managed to use a palette with more than 256 colors? Could you explain that to me, so I could implement it code-wise?
Thanks.
Oh and by the way, (I mentioned I'm a 3D modeler), in the case of rebuilding the models, normally you'd have to adapt their UV's to match the original textures, or modify all of the textures to match the model's UV's. How do you go about this process?
-
JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
A lot of questions, and sadly quite a few I can't answer. The summation of our collected knowledge is in this thread, I believe.
There has been no success in adding 16-bit colour to the textures, but somaen was talking about adding support for 16-bit TGA files to Grim through ResidualVM (as this is the system that Monkey 4 uses, also supported by ResidualVM).
As for the transparencies, as you'll have noticed, Grim uses BMP files, not TGAs. As for exactly how they're done, I'm fairly certain it's a colour from the 8-bit palette of the image, but there will be some more technical posts about this going back (sorry!).
Does that help? (Sorry if my answers are a bit wooly, it's been a while since I've been in this headspace.)
There has been no success in adding 16-bit colour to the textures, but somaen was talking about adding support for 16-bit TGA files to Grim through ResidualVM (as this is the system that Monkey 4 uses, also supported by ResidualVM).
As for the transparencies, as you'll have noticed, Grim uses BMP files, not TGAs. As for exactly how they're done, I'm fairly certain it's a colour from the 8-bit palette of the image, but there will be some more technical posts about this going back (sorry!).
Does that help? (Sorry if my answers are a bit wooly, it's been a while since I've been in this headspace.)
Yes, this helps. Thank you for the prompt answers.
I'm not worried about BMP for now, I'm only worried about the transparency bit when it comes to TGA, since they both hold the pixel data and the palette in the same way, difference is the header itself, it's size and content (I prefer TGA because it only needs 18 bytes for the header, while BMP needs 54, and since I'm parsing and writing them manually, it's extra work). As far as I know, BMP doesn't hold transparency info either, so we'll see how that turns out.
A more worrying issue is compression. The only possible compression in this case I think would be RLE, which shouldn't be too hard to implement (except if it's a custom written algo, like in Simon the Sorcerer 1, man was THAT playing with my nerves). I don't think I've seen any compressed images up until now, so I'll leave it out at present.
UPDATE: The prog now exports images as *.BMP or *.TGA. You can select any image from a multi-part *.MAT and export it. I need more info before I start writing the IMPORT procedure, namely the stuff below Ôåô
Last thing I want to ask:
When you remastered Manny, what colorspace did you use? That doesn't look like INDEX, more like RGB. If that's the case, what did you do about the palette? For example, if you changed the palette for the suit, the colors in suit.cmp would be modified, and the colors for the face would be different right?
Could you explain that process for me please? I'm asking because obviously we'd want to make the images bigger, which is not a problem, but what do you do after you EDIT/PAINT on an image? What EXACTLY do you do to get it back into the *.MAT? I need to know this, because this dictates if changes to the pallette (CMP) files are needed too.
Specifically, I'm interested about what you meant in this post:
http://forums.residualvm.org/viewtopic.php?p=1241#1241
My manual process consisted of copying the MAT's raw image bytes in a new file, appending the suitable pallete's raw data, editing it in Photoshop (using the colors from the existing palette ONLY), and then rewriting the raw image bytes into the *.MAT file.
UPDATE: Batch export to folder added.
I'm not worried about BMP for now, I'm only worried about the transparency bit when it comes to TGA, since they both hold the pixel data and the palette in the same way, difference is the header itself, it's size and content (I prefer TGA because it only needs 18 bytes for the header, while BMP needs 54, and since I'm parsing and writing them manually, it's extra work). As far as I know, BMP doesn't hold transparency info either, so we'll see how that turns out.
A more worrying issue is compression. The only possible compression in this case I think would be RLE, which shouldn't be too hard to implement (except if it's a custom written algo, like in Simon the Sorcerer 1, man was THAT playing with my nerves). I don't think I've seen any compressed images up until now, so I'll leave it out at present.
UPDATE: The prog now exports images as *.BMP or *.TGA. You can select any image from a multi-part *.MAT and export it. I need more info before I start writing the IMPORT procedure, namely the stuff below Ôåô
Last thing I want to ask:
When you remastered Manny, what colorspace did you use? That doesn't look like INDEX, more like RGB. If that's the case, what did you do about the palette? For example, if you changed the palette for the suit, the colors in suit.cmp would be modified, and the colors for the face would be different right?
Could you explain that process for me please? I'm asking because obviously we'd want to make the images bigger, which is not a problem, but what do you do after you EDIT/PAINT on an image? What EXACTLY do you do to get it back into the *.MAT? I need to know this, because this dictates if changes to the pallette (CMP) files are needed too.
Specifically, I'm interested about what you meant in this post:
http://forums.residualvm.org/viewtopic.php?p=1241#1241
My manual process consisted of copying the MAT's raw image bytes in a new file, appending the suitable pallete's raw data, editing it in Photoshop (using the colors from the existing palette ONLY), and then rewriting the raw image bytes into the *.MAT file.
UPDATE: Batch export to folder added.
OK, I grew impatient so I tried to guess your process:
You import the image into Photoshop, use a full palette, edit it, then you export the existing palette as *.ACT, and apply it to your image in Photoshop. Then you import your image in the *.MAT file via MatMaster or something similar.
If that's the case, I'm done. I added a feature to export the palettes as *.ACT files too, and the multi-frame *.MAT export is complete. I'll add some graphics and icons to make it look better, and I'll upload it some time tomorrow. Let's get to work people!
UPDATE: I'm currently not considering implementing modifications to the palette files. The reason for this is that multiple files use the same palette, so if you change the palette while working on Manny's SUIT, Manny's FACE (and his other features) will be distorted.
UPDATE: It will crash if you try to save over the same *.MAT that you're reading from, so save to another location, or under a different name for now, and then overwrite it in Windows. Also, when saving *.ACT files, don't save over existing ones, because instead of replacing the file, it will append the data to it. When we discover some more of these (I like to let these things accumulate) I'll fix them.
You import the image into Photoshop, use a full palette, edit it, then you export the existing palette as *.ACT, and apply it to your image in Photoshop. Then you import your image in the *.MAT file via MatMaster or something similar.
If that's the case, I'm done. I added a feature to export the palettes as *.ACT files too, and the multi-frame *.MAT export is complete. I'll add some graphics and icons to make it look better, and I'll upload it some time tomorrow. Let's get to work people!
UPDATE: I'm currently not considering implementing modifications to the palette files. The reason for this is that multiple files use the same palette, so if you change the palette while working on Manny's SUIT, Manny's FACE (and his other features) will be distorted.
UPDATE: It will crash if you try to save over the same *.MAT that you're reading from, so save to another location, or under a different name for now, and then overwrite it in Windows. Also, when saving *.ACT files, don't save over existing ones, because instead of replacing the file, it will append the data to it. When we discover some more of these (I like to let these things accumulate) I'll fix them.
Last edited by Guest on Tue Jun 26, 2012 2:41 pm, edited 2 times in total.
Here it is, the grand unveiling of "THE GRIM REAPER" (I called it the Grim Ripper at first, but I like the sound of "THE GRIM REAPER" better, with the mariachis playing inside my head )
It exports Single-Frame *.MAT files, as well as Multi-Frame ones, and takes in *.BMP's and *.TGA's at Import. You can import your images one by one (but not a whole folder), I deliberately made it that way to avoid human errors. 8bit's the limit.
https://dl.dropbox.com/u/39978570/GrimReaper.rar
I think this should accelerate the process quite a bit.
Feel free to tell me about any bugs or any ideas for additional features.
Oh, and it's probably gonna need .NET 4.0, since I didn't want to go legacy.
So, now I think we should set some new goals, coordinate, and try to achieve as much as we can.
)It exports Single-Frame *.MAT files, as well as Multi-Frame ones, and takes in *.BMP's and *.TGA's at Import. You can import your images one by one (but not a whole folder), I deliberately made it that way to avoid human errors. 8bit's the limit.
https://dl.dropbox.com/u/39978570/GrimReaper.rar
I think this should accelerate the process quite a bit.
Feel free to tell me about any bugs or any ideas for additional features.
Oh, and it's probably gonna need .NET 4.0, since I didn't want to go legacy.
So, now I think we should set some new goals, coordinate, and try to achieve as much as we can.