Jump to content

Home

Obj Images and Layers


DivineDominion
 Share

Recommended Posts

Hi there!

 

I'm from germany, so I've got german versions of my games, including MI2. Now I want to view the images of the characters like Guybrush, the Soldier of Phatt, Largo [...] to get a clue of how they look like (using SCUMMRevisited). Now as i noticed, it doesn't work. Only thing that seems to show anything to me are the paths through the 'maps' and the background images themself. all the other things except the palettes are doing nothing right now. As i also noticed on a Screen at the SCUMMRev-HP there are the Titles of the Rooms written next do the LFLF-Thing. In my files, they aren't. I hope it's not just because I got the german version...

 

Then I want to know how they handled the layers. As I mentioned before, I cannot view the object images or char sets etc, so I have no clue of how the Objects are overdrawing Guybrush, so he walks behind them. If he comes closer to the Player, he can walk before those Objects. How have they handled it?

 

Cheers,

DivineDominion

Link to comment
Share on other sites

The annotations on the scummrev site are for the English language versions and won't (as far as I know) work for the German version. But all the rooms should be in the same order so it shouldn't be to difficult to get them working. Just find the offsets of the rooms in your files and put them in the annotation files.

 

About the layers: In the same block as the background image (in monkey 1 floppy at least) are one or more z-layers. (basically a black and white image of the same dimensions as the room.) When drawing an actor, the engine looks at the actors current walkbox where a mask number is defined and doesn't draw pixels that are behind any of the layers with a lower z-value. The scripts can also set the mask number.

 

Movable objects and actors are probably just sorted by their y-value (the mask value is probably also used here.)

 

For further details you can always spend a couple of hours digging through the scummvm sourcecode --- that's what I did :D

 

MadMoose

Link to comment
Share on other sites

  • 2 weeks later...
Originally posted by checkmate

If you really want to rip the images, you'll have to wait a bit. I'm making plans for an internal GIF compressor, but I don't know much about GIF. You could take screenshots with the Print Screen key, but the colors are all wrong.

 

GIF is a bad idea as parts of it (the compression algorithm) is patented and required licensing (i.e. programs that save GIF have to buy a license from Unisys, decompression apparently is free(?)).

I'd just save it as Bmp, easy to implement and no trouble with licenses. I don't know which compiler you made your tool with, but you can usually save a canvas to BMP using internal Win routines (check Win32 help for more info on this).

Link to comment
Share on other sites

You can get a reference to an internal GDI graphics context (GC) and then treat your DirectDraw surface with GDI functions, so it's not a problem to save a BMP from your program using GDI. If you don't want to use BMP, you can always use any other free, open image format, like PNG (that supports transparency and lossless compression). You could use the GPL'd "libpng" to treat this great file format ;)

Link to comment
Share on other sites

That sounds good. AkosView does the GDI device context thing to display things like "Failed to draw cel". Trouble is, if a part of that text is overlapping the cel, it may end up in your screenshot. Of course, I can just blank out the screen and rerender the image. Is there a way to treat a section of a device context like a bitmap?

Link to comment
Share on other sites

Originally posted by checkmate

I wrote some code to save the image as a BMP file...upside down! I'll upload the new AkosView when I figure out how to flip it right side up.

 

IIRC you just have to set a negative height, i.e. -HEIGHT :)

I think this will work (not sure, though).

Link to comment
Share on other sites

I've flipped the bitmap upside-down (or right-side-up), so that's cool. Sometimes (but very rarely), the saved bitmap is all screwed up. I think AkosView is in for a rewrite, but in the meantime, 0.5 has been released, with the ability to save as a BMP file. Get it here .

 

I took a screenshot of one of the images I found you probably never see in the game.

akos.gif

 

You may think it's the CMI interface, but look closely at that hand icon. Weird.

Link to comment
Share on other sites

You, I, and everyone must always remember some things about the BMP file format!

 

- The palette is stored in BGR, rather than RGB

- The rows are stored upside-down

- While the image width may not be a multiple of 4, the stored rows in the bitmap are, so you write some trash at the end of each stored row

- To compute the amount of trash you need:

trashCount = (((imgWidth + 3) & ~3) - imgWidth)

 

That trash thing I didn't implement in 0.5, so 0.6 will fix the screwed-up bitmap problem.

Link to comment
Share on other sites

 Share

×
×
  • Create New...