Grim Fandango Deluxe - Original Thread [Locked]

Longcat · Post by **Longcat** » Fri Aug 05, 2011 6:11 am

It's everything I ever dreamed of;)

bgbennyboy · Post by **bgbennyboy** » Fri Aug 05, 2011 11:10 am

The .mat format also has a variant that supports 16 bit colour rather than Grim's 8 bit.

People used it for modding in the Jedi Knight games

somaen · Post by **somaen** » Fri Aug 05, 2011 11:35 am

Yes, but is that version supported by ResidualVM?

bgbennyboy · Post by **bgbennyboy** » Fri Aug 05, 2011 11:54 am

I dont know, I dont think so.
Easiest way to tell though is for Thunder to try it with the modified build of ResidualVM. Mat16 lets you create them.

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Fri Aug 05, 2011 4:12 pm

Manny's 16-bit suit (also 512x512). Sadly it doesn't like 16-bit textures

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Fri Aug 05, 2011 8:54 pm

Now using 512x512 textures:

Colour is becoming a problem, though. It'd be great to fix that and have a 16-bit palette.

cplhenshaw · Post by **cplhenshaw** » Wed Aug 10, 2011 10:43 pm

This all looks really great!

I think the biggest improvement to the look of the game would be if the resolution could be increased. As you pointed out, you won't really see the benefit of new textures unless they are large or close to the screen, and rendering at a higher resolution would allow the difference to be more pronounced for all the smaller things in the game as well. Whether it's actually feasible to change the resolution in ResidualVM or not I don't know.

MeddlingMonk · Post by **MeddlingMonk** » Thu Aug 11, 2011 12:28 am

The environment is made up of pre-rendered 800x600 images. So, that's a problem. You couldn't just re-size them and have it look good.

somaen · Post by **somaen** » Thu Aug 11, 2011 3:44 am

Actually, they are 640x480, and eh, the original renders them at 640x448 iirc (blacking out the upper and lower few lines).

Simply rendering them at 1280x960 should leave extra resolution to actually show the additional detail on the textures, without needing to add additional details to the backgrounds (in fullscreen on LCDs you will get stretching in fullscreen anyway, as the panels have fixed-pixels, actually rendering at higher resolution might even benefit those slightly, as I think we could do better or atleast equivalent scaling than what the panels themselves do).

CRTs are another story entirely, as they can perform proper 640x480.

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Thu Aug 11, 2011 2:02 pm

Yes, a higher resolution could be good, too. I don't know exactly how difficult that might be, though.

Anti-aliasing adds a lot to the quality, too (making up for the lower resolution). Here's a comparison with Manny's latest texture (4x the size) with AA turned on.

Longcat · Post by **Longcat** » Thu Aug 11, 2011 4:05 pm

This is my nerdy wet dream come true!

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

So it seems we have three possible way to improve the graphics:

1. Textures (plus adding 16-bit colour)
2. Upping the model quality
3. Upping the game resolution to 1280x960

cplhenshaw · Post by **cplhenshaw** » Sat Aug 13, 2011 5:41 pm

I've had a go at writing some code aimed at converting between .3do and .obj but its still a long way off from being an easy process to update the models, and I can think of plenty of issues that will crop up later.

What I've got so far is code to read .3do files into some intermediary data structures and then write from those back to .3do files. There is also code that can do a basic write to .obj files BUT
- no .mtl files yet
- texture vertices appear to be very wrong
- no rotations of the various model pieces is done

Alot of the models from the first two years of the game don't have any default rotations in them, but the rest will come out crooked / folded in on themselves.

Also there is not any code for the reverse journey from .obj files.

You can try it out with these
For windows
For linux
Example of output

It can be run from a command prompt and takes two arguments, the filename to read and the name you want the output to be called. i.e Run it like this:
'3do manny.3do manny.obj'

Try it out (I hope it works

). I'm putting it out there now because I didn't want to work on it for a bit and then sit on it for a couple of months. Also if anyone wants to take a look at the source code I can put that up too.

somaen · Post by **somaen** » Sat Aug 13, 2011 6:28 pm

I did a binary-3do to text-3do-converter a few weeks back, although the filename says 3do2obj, I never got around to adding the obj-stuff to it.

https://github.com/somaen/residual-tool ... do2obj.cpp

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Sat Aug 13, 2011 9:11 pm

Great job, cplhenshaw! I wonder if you could take a look at somaen's code. I know he had some success converting the files to text 3do and obj. There doesn't appear to be any reason to convert the text 3do files to binary, as the game can apparently read text 3do files without issue (as evidenced by signpost.3do).

Great to have someone else trying to help. Any information from your explorations you can share is much appreciated.

You can grab the latest version of somaen's app here (Windows build):

http://www.thunderpeel2001.com/grim/3do2obj.exe

If you want to mess around with it, usage goes like this:

3do2obj binary.3do filename.3do.txt

or putting any extra character (e.g. "a") on the command line outputs a .obj version of the .3do:

3do2obj binary.3do filename.3do.obj a

So a real world example for extracting Year 1 Manny to mannysuit.3do.txt:

3do2obj mannysuit.3do mannysuit.3do.txt

Or to an .obj file:

3do2obj mannysuit.3do mannysuit.3do.obj a