Weapons In Hand

[Ares Ex Machina]

DOWNLOAD

I've created a plugin that does two things to the original weapons-in-hand graphics for Marathon 2 and Marathon Infinity:

1. A different looking muzzle flash, featuring blended edges.
2. Motion blur on certain frames.

Only a select few frames have been altered at all, so right now what the plugin does is mix and match my new frames with the default ones in the original shapes file. Sounds funky, but it seems to be working fine. I'm considering copying over the rest of the default frames into the plugin, but at this stage doing so just seems redundant.

Since Aleph One has to switch back and forth between reading from a plugin and reading from a shapes file, all while in the middle of a sequence (such as firing or reloading), is there any potential for slowdown or any other kind of drawback?

Also, I decided not to generate mipmaps with the dds files due to the tiny nature of the default graphics. Any drawback to that?

I've uploaded a preview featuring just the magnum.
[attachment=4704:Weapons_...ion_Blur.zip]
Maybe you guys could tell me if anything looks off with the dds files and/or mml, since I'm no expert with either.

Edit: Project complete. Link added.

[treellama]

Since Aleph One has to switch back and forth between reading from a plugin and reading from a shapes file, all while in the middle of a sequence (such as firing or reloading), is there any potential for slowdown or any other kind of drawback?

No, they should be interchangeable once loaded. In fact, loading a moderate sized DDS file is probably faster than translating from the Marathon shapes format to an OpenGL texture.

[Ares Ex Machina]

No, they should be interchangeable once loaded. In fact, loading a moderate sized DDS file is probably faster than translating from the Marathon shapes format to an OpenGL texture.

Interesting. So in that case it sounds like there is an advantage to putting all the frames in the plugin.

[treellama]

Interesting. So in that case it sounds like there is an advantage to putting all the frames in the plugin.

No, I don't think there is. Just replace what you need to.

[Ares Ex Machina]

No, I don't think there is. Just replace what you need to.

Ok. Thanks!

[Ares Ex Machina]

Is bloom possible with the weapons in hand? I've been doing some failed experiments and would like to know if it's an error on my part or simply impossible.

[treellama]

Not right now, but you could use additive blending.

[Ares Ex Machina]

Not right now, but you could use additive blending.

If by that you mean fading out the edges to create a translucent effect, I've done about as much as I can. Any more and I run into the borders of the bitmap dimensions, which (as far as I know) cannot be enlarged without altering the shapes file.

[Ares Ex Machina]

One thing I can't figure out is how to create a frame that doesn't put a colored outline around the hand when there's a muzzle flash in front of it.

Compare the edges of the right hand in each image here:

[attachment=4739:comparison.jpg]

You could call this a happy accident, since the orange outline creates the illusion of the hand being back-lit by the muzzle flash. But is it possible to make it so the outline doesn't show up?

[treellama]

The hands in those images look the same to me

[ukimalefu]

The hands in those images look the same to me

Me too. And I also see the backlit effect is cool.

[Ares Ex Machina]

The hands in those images look the same to me

Did you click on the image and zoom in to 100%? It's around the silhouette.

Here's a zoom in that shows it more clearly:

[attachment=4741:comparison_2.jpg]

[treellama]

Are you asking how to get rid of that in the image itself? Does GIMP have a feather selection command?

[Ares Ex Machina]

Are you asking how to get rid of that in the image itself? Does GIMP have a feather selection command?

Sorry, I realized after posting when I was afk that I didn't do a good job at phrasing that. I have no problems creating an image without an orange outline. It does not appear in the image itself. It only appears when seen in game.

So better phrased, is there something I can do so that the orange outline doesn't appear around parts of the image when it's seen in game?

[treellama]

Sorry, I realized after posting when I was afk that I didn't do a good job at phrasing that. I have no problems creating an image without an orange outline. It does not appear in the image itself. It only appears when seen in game.

So better phrased, is there something I can do so that the orange outline doesn't appear around parts of the image when it's seen in game?

If it appears in the game, it's in the image. Aleph One doesn't add an outline.

What does your image look like? In particular, the colors in the transparent parts of the image.

[Ares Ex Machina]

If it appears in the game, it's in the image. Aleph One doesn't add an outline.

What does your image look like? In particular, the colors in the transparent parts of the image.

The colors in the transparent parts of the image are orange, which I suspect is the same orange seen in the outline. However, the transparent parts of the image do not extend to the bottom of the hand, where the outline appears in game.

This is the image I'm using which, as you can (hopefully) see, does not have an orange outline around the hand when viewed outside the game.

[attachment=4742:12_shotgun.png]

[treellama]

This is the image I'm using which, as you can (hopefully) see, does not have an orange outline around the hand when viewed outside the game.

Sure it does!
[attachment=4745:nomask.png]
Aorta can fix this. Save as DDS, check generate mipmaps, uncheck image repeats, check Fast Halo Removal, uncheck "Reconstruct Edge Colors" (or check it and pick that orange as the background color). Reopen the fixed DDS and save that as PNG.

Your colors will then look like this:
[attachment=4746:fixed.png]

Explanation why this happens/why this fixes it: http://www.vterrain.org/Plants/Alpha/

That's for mipmaps, but I find the same thing happens with the magnification filter.

[Ares Ex Machina]

Sure it does!
[attachment=4745:nomask.png]
Aorta can fix this. Save as DDS, check generate mipmaps, uncheck image repeats, check Fast Halo Removal, uncheck "Reconstruct Edge Colors" (or check it and pick that orange as the background color). Reopen the fixed DDS and save that as PNG.

Your colors will then look like this:
[attachment=4746:fixed.png]

Explanation why this happens/why this fixes it: http://www.vterrain.org/Plants/Alpha/

That's for mipmaps, but I find the same thing happens with the magnification filter.

How did you bring back that orange I got rid of?! Apparently there's something about pngs I'm missing.

Well, thanks for the help. I followed your instructions and it mostly worked, but there is still some outline happening where the hand gets close to the muzzle flash. I'm guessing this is inevitable as long as I have the orange glow from the muzzle flash fading out that far?

[treellama]

How did you bring back that orange I got rid of?! Apparently there's something about pngs I'm missing.

Aorta will split the three color channels from the alpha channel if you load an image. That's how I saw all that orange. Most tools don't bother to show you those colors, but OpenGL samples them when minifying/magnifying.

Well, thanks for the help. I followed your instructions and it mostly worked, but there is still some outline happening where the hand gets close to the muzzle flash. I'm guessing this is inevitable as long as I have the orange glow from the muzzle flash fading out that far?

Aorta will only fix pixels that are completely transparent. You may have some that are only semi-transparent, but still contaminated with all that extra orange. You may be able to fix things by hand, if Reconstruct Edge Colors doesn't work for you.

[Ares Ex Machina]

Aorta will split the three color channels from the alpha channel if you load an image. That's how I saw all that orange. Most tools don't bother to show you those colors, but OpenGL samples them when minifying/magnifying.
...
Aorta will only fix pixels that are completely transparent. You may have some that are only semi-transparent, but still contaminated with all that extra orange. You may be able to fix things by hand, if Reconstruct Edge Colors doesn't work for you.

Thanks again. I've been fixing things by hand and the end results indicate I understand the basics of principal. This has mainly come in handy (no pun) with the other weapons, but the shotgun is an exception where I might just leave it because if I really want to get rid of the last of the outline, I'll have to cut back the glow of the muzzle flash. I'll do some experiments to figure out which route I'll take with it.

[Ares Ex Machina]

If by that you mean fading out the edges to create a translucent effect, I've done about as much as I can. Any more and I run into the borders of the bitmap dimensions, which (as far as I know) cannot be enlarged without altering the shapes file.

I found out a few days ago there is a way. Using the a frame I created (with larger dimensions than what's in the shapes file), I combined image_scale with x_offset and y_offset in the mml to create a faint glow that extends outside of the default bitmap's dimensions. I got it to work great with one frame (getting the x, y, and scaling just perfect), but some of the others are proving to be a headache. All of them are way off center (obviously the incorrect x and y) and some are stretched horizontally (why?).

Is there a method for determining how much image scaling to use in the mml and how much offsetting to do with x and y based on the difference in frame dimensions (compared to the original)?

[treellama]

All of them are way off center (obviously the incorrect x and y) and some are stretched horizontally (why?).

Image scale appears to affect both U and V. So, if you don't use the same aspect ratio as the original sprite, you'll get a squished image.

Is there a method for determining how much image scaling to use in the mml and how much offsetting to do with x and y based on the difference in frame dimensions (compared to the original)?

If I'm reading right, it looks like the scaling and offsetting are done in pixel coordinates in the original non-replacement texture space. So, hopefully that calculation would be pretty straightforward.

[Ares Ex Machina]

Image scale appears to affect both U and V. So, if you don't use the same aspect ratio as the original sprite, you'll get a squished image.

Do I need to know what U and V are? The original magnum firing sprite is 89x121. Mine is 356x484. That is the same aspect ratio, yet the image is squished.

If I'm reading right, it looks like the scaling and offsetting are done in pixel coordinates in the original non-replacement texture space. So, hopefully that calculation would be pretty straightforward.

I tried a few things out and I still don't get it. Would you mind maybe explaining what scaling and offsetting to use for the image I described above? If I understand that, then hopefully I can apply the same principle with the rest of my images.

[treellama]

I don't know if this stuff works with weapons-in-hand. With an inhabitant, if you wanted a 356x484 image to line up with the 89x121 sprite, you wouldn't need any offset_x or offset_y, and you'd leave the image scale to the default of 1.0.

[Ares Ex Machina]

Ok, so I've eyeballed everything to the point where my graphics appear to be about the right size and shape, with about the right placement (with 400% the canvas size for each image -- plenty of room for the muzzle flash glow effect I want). But what I really want are precise calculations, not the approximations I have. If anyone would like to help me figure out a way of finding those exact numbers, I would be grateful.

Below are two attachments designed to aid anyone interested in helping me. Note that when I say canvas, I mean it in the context of Photoshop terminology.

[attachment=4834:Weapons_...vas_Size.zip]This is a plugin with the default weapons graphics, only the canvas dimensions of each image is 400% larger than normal. To compensate for the stretching Aleph One does, the images in this plugin have been counter-stretched and there is MML used to adjust the offsetting and scaling. All of the data from this plugin is organized in the spreadsheet attachment below.

[attachment=4835:Weapon_Chart.zip]This is a spreadsheet with all my numbers organized.

• Each row represents one frame/image/weapon.
• Click on the top of each column to display additional information about it.
• The first section of white columns contains data from the shapes file for the original unaltered images (scale factor, origin, and keypoint). I'm not entirely sure if this is relevant/useful. Also included are the dimensions for the original unaltered images.
• The next section of gray columns shows how I edited each frame in Photoshop. You can see what percentage I used to stretch each image in order to counter the stretching happening in Aleph One (note that I never stretch the canvas dimensions -- only the dimensions of the image sitting in the middle of the 400% size canvas). These percentages are probably off by a little, so I need help finding the exact percentage required to counter-stretch each image.
• The last section of white columns shows MML data (scaling and offsetting). This is used to get the weapon in the right place on the screen in game, and to get it the right size. These numbers are most likely off by a little, so I need help finding the exact numbers required for each frame.
• The red text means the numbers are approximations of what they really aught to be. These are the ones I need help with!

I've taken this as far as I can go, so hopefully someone out there can help. In the meantime, I'll be fine-tuning the muzzle flash and motion blur effects.