Grim Fandango Deluxe - Original Thread [Locked]

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Thu Jul 28, 2011 4:35 pm

giucam wrote:
JohnnyWalker2001 wrote:Thanks, I'm getting to understanding what's going on now, although I'm still not sure which *file* the offset is being read from. (Edit: I see you're saying it's in the .mat files?)
Yes, in the .mat files.

Huh. Well it's seriously confusing because the size (128) doesn't seem to be stored anywhere in the .mat files, at any offset. *scratches head*

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Thu Jul 28, 2011 4:45 pm

somaen wrote:Sure, or OBJ for that matter, as long as it's a documented format, it shouldn't be that hard to add, the main issue would be detecting that the files are non-standard I guess.

This is very exciting news!

giucam · Post by **giucam** » Thu Jul 28, 2011 5:05 pm

JohnnyWalker2001 wrote: Huh. Well it's seriously confusing because the size (128) doesn't seem to be stored anywhere in the .mat files, at any offset. *scratches head*

How are you looking in the file? Are you sure you are looking a it encoded in decimal?

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Mon Aug 01, 2011 10:56 pm

giucam wrote:
JohnnyWalker2001 wrote: Huh. Well it's seriously confusing because the size (128) doesn't seem to be stored anywhere in the .mat files, at any offset. *scratches head*
How are you looking in the file? Are you sure you are looking a it encoded in decimal?

No, I was looking for 80 in hex... but thinking about it I think I may have been looking in my new .mat 256 file. I guess was hoping that it was causing the problem, but Aquadran has made me question if it's actually a fundamental limitation in Grim.

My computer is out of action until tomorrow, so I'll try again then.

I guess it's going to be new models and textures!

bgbennyboy · Post by **bgbennyboy** » Wed Aug 03, 2011 1:37 pm

Conversion to a more generic format is certainly doable. As proof of concept here's a quick converted model to .obj.

Its the coral item, although it looks like I messed up somewhere because the textures arent applied correctly (the base is wrong).

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Wed Aug 03, 2011 1:52 pm

Excellent! How did you convert it?

In other news: It seems that the .mat files aren't to blame after all, and in fact are storing the correct texture size. Grim/ResidualVM is just ignoring it, though. (Or so it seems.)

In the original files it says 128 (80 00 00 00), but in my modified file it says 256 (00 01 00 00). So there's definitely a limitation in Grim/ResidualVM that doesn't take into account texture sizes bigger than 128 x 128.

So remodelling is looking like the way to go!

bgbennyboy · Post by **bgbennyboy** » Wed Aug 03, 2011 1:58 pm

I did it by hand just because it was a quick test. For speed I used the text 3do from the demo rather than the binary one from the full game.

For a project like this to work, you'd need:

A decision on the best/most suitable format to convert the 3do models to.
Someone to add code to make residual support the loading of external/alternate models
Someone to make a convertor for the models to the new format
And finally people to create enhanced models and textures.

Its a big job.

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Wed Aug 03, 2011 2:03 pm

Yep, it's a big job

I'm happy to try and take care of Step 4, but the first three steps are beyond me.

Step1: People seem to think that Cal3D or OBJ are the most likely formats.

Step2: I think Aquadran will be needed for this.

Step3: Not sure who has the skills to convert the old formats to a new one. Could you write an app that could do this if you were given all the specifications, BG?

somaen · Post by **somaen** » Wed Aug 03, 2011 5:37 pm

Are there any limitations in the model-format that is used in Grim originally that are problematic, or couldn't that simply be used, instead of adding additional complexity to ResidualVM?

If the existing format is workable (or workable with minor adjustments), then all that is needed would be converting to obj/cal3d and back. (i.e. no actual changes necessary in the ResidualVM-codebase).

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Thu Aug 04, 2011 1:32 am

somaen wrote:Are there any limitations in the model-format that is used in Grim originally that are problematic, or couldn't that simply be used, instead of adding additional complexity to ResidualVM?

If the existing format is workable (or workable with minor adjustments), then all that is needed would be converting to obj/cal3d and back. (i.e. no actual changes necessary in the ResidualVM-codebase).

A good question. Someone more technically involved with ResidualVM will have to explain further, but other than the texture dimension problems, I'm not sure what other problems there might be with the existing format.

Based on what people (like Ender) have said, though, adding a new format would be just as easy?

More information is needed, obviously

giucam · Post by **giucam** » Thu Aug 04, 2011 8:40 am

Adding a new format may be easy, but it would however mean adding new code and complexity, which it's better not to do.
I don't know any other model format aside .3do, but i don't see any limitation with it.
As regards the materials, ResidualVM does use the texture size. If your bigger texture is not working right, that's likely to be a simple bug in the code.

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Thu Aug 04, 2011 7:51 pm

Result! We have a hires Manny! (Thanks to Somaen and Guicam for the help!) It's just the beginning, but yes, it's possible...

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Thu Aug 04, 2011 9:19 pm

So after some messing I around, I can already start to see some limitations.

For a start, the increase texture resolution is only really visible when Manny is REALLY close to the camera (see below). Secondly, being only able to use the 256 colour palette of the game is very restrictive (see Manny's tie, below). Thirdly, GF is very stylized, so it's not entirely clear how and where the extra detail should be placed (although this could be figured out).

It seems to me that, at the very least, we need a way of adding more colours to the palette. Without it means it's only worth adding bigger textures to a very small collection of items in the game (those that are seen close-up).

This might be worth doing in the meantime (it IS nice that Manny's face doesn't pixelate so), I don't know of a way on doing it on a per-model basis... it's every texture in the game or no textures at the moment.

Any ideas?

The way I see it, we have three options:

1. Add high-quality textures to a small amount of items in the game (i.e. the things that are seen close-up).

Problem: Need to be able to remap the textures on a per model basis.
Pros: Very quick and easy way to make Grim Fandango look nicer to modern eyes.

2. Make more colours available to textures in an attempt to be able to add more detail that way (think shading).

Problem: Adding more colours to textures is quite a big job (from what I gather).
Pros: It might allow use to add a little more detail to textures -- although I expect not much.

3. Remodel the characters and use an increase polygon count to improve the visuals of the game.

Problem: We need a way of converting .3do files to .obj and back again. Also, very time consuming.
Pros: We could end up with a very beautiful version of Grim Fandango.

Longcat · Post by **Longcat** » Thu Aug 04, 2011 10:22 pm

Nice!

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Thu Aug 04, 2011 11:56 pm

Cool, isn't it?

Grim Fandango Deluxe - Original Thread [Locked]

Re: Grim Fandango: Remastered

Re: Grim Fandango: Remastered

Re: Grim Fandango: Remastered