Grim Fandango Deluxe - Original Thread [Locked]
Moderator: ScummVM Team
-
- Posts: 54
- Joined: Wed Aug 10, 2011 9:17 pm
I had a look through the ResidualVM code and while I don't really know C++ it suggested that the correct colourmap was indicated in the .cos costume files. In each .cos there is a listing of components, and the .cmp files indicate their "parent" .3do
I wrote all the pairings to a text file and then sorted it:
http://www.mediafire.com/?jdcn3fnro3b2tyg
The results is 435 lines, pairing .3do files to the .cmps that it uses. Note that some use more than one in different circumstances so they will have 2 or 3 lines. 435 is reasonably close the number of .3do files in the game so there's a good chance it has most of what we might need.
I wrote all the pairings to a text file and then sorted it:
http://www.mediafire.com/?jdcn3fnro3b2tyg
The results is 435 lines, pairing .3do files to the .cmps that it uses. Note that some use more than one in different circumstances so they will have 2 or 3 lines. 435 is reasonably close the number of .3do files in the game so there's a good chance it has most of what we might need.
- JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
You just made my day! Thanks for this!cplhenshaw wrote:I had a look through the ResidualVM code and while I don't really know C++ it suggested that the correct colourmap was indicated in the .cos costume files. In each .cos there is a listing of components, and the .cmp files indicate their "parent" .3do
I wrote all the pairings to a text file and then sorted it:
http://www.mediafire.com/?jdcn3fnro3b2tyg
The results is 435 lines, pairing .3do files to the .cmps that it uses. Note that some use more than one in different circumstances so they will have 2 or 3 lines. 435 is reasonably close the number of .3do files in the game so there's a good chance it has most of what we might need.
- 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
Have you considered remastering Grim Fandango to support widescreen? I've made a quick example:
Hope you like it. Maybe once you crack the locked resolution problem someone could add the additional art on the sides. This example was done in Photoshop and I guess it could be done this way... although someone with good 3D skills could make this faster and better.
Cheers
Hope you like it. Maybe once you crack the locked resolution problem someone could add the additional art on the sides. This example was done in Photoshop and I guess it could be done this way... although someone with good 3D skills could make this faster and better.
Cheers
- 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
Thanks.
I have the game installed on hdd but instead I went to Google Images and found: the first office screenshot, the one with the overhead view of Many's computer and shot of Copal's answering machine. It was faster than going through all those locations in the game itself.
I forgot (dumbass) that we can see the computer in the Intro cutscene, so I took the hard way and corrected the perspective on the overhead view of the Many's computer (when he's looking at Celso's file). It turned out quite nicely (except for the flat keyboard) but if I had remembered the intro shot of the computer I would have done it a lot faster... and it would've looked a lot better. I used Copal's computer screen since it had better resolution. The right side of the desk was drawn from scratch and that's why it looks awful. File cabinets were just cloned, that was the easiest part.
I totally forgot about the movies, and let's face it: there is no quick way of adding additional material on them without looking like crap. It would take months if someone did it right.
Some scenes have alternative angles, which is good from the resource point of view... but most of them don't.
What would happen to the characters (and other on-screen) object positions if the backgrounds were replaced with the widescreen versions and display area stretched? Are the coordinates absolute (fixed on 640x480) and calculated from the top left corner? Then all of the 3D objects would be misplaced and shifted on the left. Is there a way ResidualVM can display the game screen centered, then detect current room and just add two images on the side (independently from the game engine)?
If not, it would be impossible to re-calculate all the object coordinates, right? Unless ResidualVM can change all the position variables depending on the resolution, something like:
many_x = original_many_x * screen_factor.
One other question: how many people is working on this project, just one?
P.S. Do you know about this:
http://www.youtube.com/watch?v=iByj4NIj ... r_embedded
I have the game installed on hdd but instead I went to Google Images and found: the first office screenshot, the one with the overhead view of Many's computer and shot of Copal's answering machine. It was faster than going through all those locations in the game itself.
I forgot (dumbass) that we can see the computer in the Intro cutscene, so I took the hard way and corrected the perspective on the overhead view of the Many's computer (when he's looking at Celso's file). It turned out quite nicely (except for the flat keyboard) but if I had remembered the intro shot of the computer I would have done it a lot faster... and it would've looked a lot better. I used Copal's computer screen since it had better resolution. The right side of the desk was drawn from scratch and that's why it looks awful. File cabinets were just cloned, that was the easiest part.
I totally forgot about the movies, and let's face it: there is no quick way of adding additional material on them without looking like crap. It would take months if someone did it right.
Some scenes have alternative angles, which is good from the resource point of view... but most of them don't.
What would happen to the characters (and other on-screen) object positions if the backgrounds were replaced with the widescreen versions and display area stretched? Are the coordinates absolute (fixed on 640x480) and calculated from the top left corner? Then all of the 3D objects would be misplaced and shifted on the left. Is there a way ResidualVM can display the game screen centered, then detect current room and just add two images on the side (independently from the game engine)?
If not, it would be impossible to re-calculate all the object coordinates, right? Unless ResidualVM can change all the position variables depending on the resolution, something like:
many_x = original_many_x * screen_factor.
One other question: how many people is working on this project, just one?
P.S. Do you know about this:
http://www.youtube.com/watch?v=iByj4NIj ... r_embedded
- JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
There's about four of us currently involved at the moment, with some people (like the lead GF programmer) chipping in with advice occasionally. The project is still very young, too.
I'm not sure I see the benefit of letting Manny walk somewhere he can't at the moment. Wouldn't adding detail to the left and right side of the screen be good enough?
You've done a really good job, especially for a first pass, btw. Really nice.
I'm not sure I see the benefit of letting Manny walk somewhere he can't at the moment. Wouldn't adding detail to the left and right side of the screen be good enough?
You've done a really good job, especially for a first pass, btw. Really nice.
Last edited by nuphonic on Mon Sep 05, 2011 9:37 pm, edited 1 time in total.
- JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
What did you write this in, cpl? Can you share your sources?cplhenshaw wrote:I've had a go at writing some code to convert from .obj back to .3do and managed to get it working at a very basic level. It's not reading in material names or anything (it just chooses the first material for now) and also doesn't handle any of the rotations of the meshes (which are present in later files). Plus I think the normals may be wrong too.
Basically I just got it to the point where it will somewhat work and figured I'd put it up if you guys want to try out.
The program: http://www.mediafire.com/?kxw4n3bqc9hw8d8
I'm not sure which 3d modelling programs people want to use but there are a few considerations for the .obj file.
It should be split into "object groups" i.e in the .obj there are lines of the form "o groupname" for each piece of the model
The group name should either equal or contain the original mesh name.
Anyway I'm pretty tired now so I'm going to sleep and dream of a two headed Manny encased in some kind of weird bodysuit.
- ultraneonoirantihero
- Posts: 106
- Joined: Mon Sep 05, 2011 5:13 pm
Nice, the lead Grim Fandango programmer? How did you get to him?
And what you just said - is what I've meant: just adding detail on the sides, not walking space. But the problem I was talking about is this:
This is GF on widescreen monitor with high resolution. If you change the backgrounds and make them wider, then all the coordinates are gonna change and the objects will have different positions.
And what you just said - is what I've meant: just adding detail on the sides, not walking space. But the problem I was talking about is this:
This is GF on widescreen monitor with high resolution. If you change the backgrounds and make them wider, then all the coordinates are gonna change and the objects will have different positions.
- JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
Ah, I see what you mean! My bad. Hopefully someone with more knowledge of Grim and ResidualVM can answer your question.ultraneonoirantihero wrote:Nice, the lead Grim Fandango programmer? How did you get to him?
And what you just said - is what I've meant: just adding detail on the sides, not walking space. But the problem I was talking about is this:
This is GF on widescreen monitor with high resolution. If you change the backgrounds and make them wider, then all the coordinates are gonna change and the objects will have different positions.
-
- Posts: 54
- Joined: Wed Aug 10, 2011 9:17 pm
I've been writing in C, and unfortunately I haven't gotten around to making any changes since I made that post. I followed the github tutorial and put the source files up there. If you have any questions about it feel free to ask.JohnnyWalker2001 wrote: What did you write this in, cpl? Can you share your sources?
https://github.com/cplhenshaw/boop
The coordinates of 3d objects wouldn't need to be changed with widescreen background, since the 3d space wouldn't change. The 2d objects instead, (e.g. the tube in manny's office) would need adjusting.
@ultraneonoirantihero
what did you do in that last screenshot? did you just increase the resolution without increasing the background size? if yes, that's to be expected, but making the background's size right would fix that problem. The 3d objects and the 3d space (so walking space too) aren't tied to the resolution in any way.
(as long as the form factor is kept, otherwise a little fix is needed)
@ultraneonoirantihero
what did you do in that last screenshot? did you just increase the resolution without increasing the background size? if yes, that's to be expected, but making the background's size right would fix that problem. The 3d objects and the 3d space (so walking space too) aren't tied to the resolution in any way.
(as long as the form factor is kept, otherwise a little fix is needed)
- ultraneonoirantihero
- Posts: 106
- Joined: Mon Sep 05, 2011 5:13 pm
No, although that's what this guy did:giucam wrote:what did you do in that last screenshot? did you just increase the resolution without increasing the background size?
http://widescreengamingforum.com/node/13818
I just found the example of what I thought would've happened if the backgrounds, screen display size and ratio were to be altered.
So in theory, it's very easy to make Grim Fandango widescreen? Because:
- 1. The guy in that link managed to get it running on higher resolution
2. You say that by increasing the background size, the backgrounds can fill up the screen and correspond the 3D objects
3. And applying that "little form factor fix" would solve other 3D problems
So GrimE can't scale backgrounds, that's the main problem? The engine can be hacked to work on higher resolutions but there is no scaling, cropping or interpolation algorithm that can adjust the game to different resolutions? The game is made just and just for 640x480?