Hey guys. I've noticed that recently a lot of work has been put into making Marathon 2 and Infinity look better than ever, and this is fantastic. Why, though, has there been relatively so little work put into the original Marathon in terms of graphical updates? For one thing, it's fair to assume that polishing Marathon would bring in new players, which is something we'd all like. It is a jarring experience to hop from the now pristine sharpness of 2/Infinity into the muddy depths of Marathon with it's 90s throwbacks.

Something to do with M1's different file formats, maybe? (AFAIK most of the A1 tools are designed to handle M2/MI formats and don't like M1's) Or plain old lack of focus compared to the more polished (base-game-wise) M2 and MI.

Because a now defunct company by the name of Freeverse redid the graphics for the XBLA re-release of marathon 2. All was needed to make it work for infinity was to fill in several holes which was not an insignificant amount of work. (And it's been several years for that to happen). To redo all the sprites for marathon 1, which has it's own art style, would be an enormous undertaking. There is only one person here who has the skills to possibly do it, but it would take an ungodly amount of time. And I'm sure he has other things to do. As such, I wouldn't hold your breath.

Would it even be possible to make an HD monsters pack for M1? There doesn't seem to be a recorded index of all the bitmaps, it seems like you would have to sit there and try and map out every index number yourself, unless they are the same as M1A1...

I can't open that file, since it zipped and all it's data in the resource fork. I don't know of any M68k compatible unzip programs that handle OS X style zipped resource forks. However, given that this file is storing data in the resource fork, I'm guessing it's just an M1 shapes file that someone just tacked the .shpA extension to. That's not translation.

M1A1's shapes file is M1 shapes translated into M2 format. It certainly was done in a very unusual way, for example, why are the media splash sprites, which did not exist in M1, shoehorned into the items slot and not scenery, thus requiring scripting in order to function?

I'm working on something better, but I've wanted to keep this all under my hat until I have a complete two-level demo finished. I'm at university so progress is slow, but, I have the hardest stuff done and I have next spring off, so it's possible I might have something playable by Feburary.

General Tacticus wrote:I can't remember who made it, but I use the following file as a guide for replacing bitmaps and to make shape patches. It is basically the m1 shapes directly translated into an m2 file.

The directory of this file is very interesting, the monster types don't match up with the defaults in ShapeFusion.

Weird. When I extract it with ZipIt inside the VM I get a zero kb file... but natively, Ark spits it out just fine. Basillisk II being buggy I suppose.

Flippant Sol wrote:The directory of this file is very interesting, the monster types don't match up with the defaults in ShapeFusion.

The collections are ordered sequentially within the file structure, they aren't actually named in the file itself. ShapeFusion probably assumes you are opening an M2/M∞ shapes file and names the collections according to where it expects the shapes to be. Marathon 1 just ordered the collections differently.

If you are inserting png files into the .shpA file via shapefusion, then you will just need to use a blue background. If you are just modifying the shape file, then no patching should be needed.

If you are using mml to replace shapes, you need to use a transparent background.Shape patches are necessary if you want your new mml defined shapes to have different x/y offsets or aspect ratios from the ones defined in the current shpA file.

General Tacticus wrote:If you are inserting png files into the .shpA file via shapefusion, then you will just need to use a blue background. If you are just modifying the shape file, then no patching should be needed.

If you are using mml to replace shapes, you need to use a transparent background.Shape patches are necessary if you want your new mml defined shapes to have different x/y offsets or aspect ratios from the ones defined in the current shpA file.

Well, I figured that out the hard way, but here is my first attempt:http://simplici7y.com/items/xbr-monsters-for-m1A problem I'm having is that I can see blue outlines on all of the sprites, and yet in the images themselves there are none. I wouldn't know how to fix this. Would a shapes patch fix it? I know nothing about shapes patches.

The blue outlines are due to the blue background not being fully removed from the upscaled sprites, I can see soome blue faintly.Did you remove the blue background before or after scaling them up? If I understand this correctly, you would need to do it before so the blue doesn't bleed in.

Shape patches are unrelated to this sort of thing, this seems to be an issue with how the sprites are being upscaled.

*edit*by the wat, the fighters are missing 1 frame from their run sequence at 0ºOther then that, this looks pretty nice.

Aorta has some code to deal with this when generating mipmaps, which you could add to your XBR scaler.

I actually added a hq3x scaler to Aleph One at one point, but didn't care at all for the results so I never committed it. I don't really think the XBR ones are better than the originals either ::shrug::

Aorta has some code to deal with this when generating mipmaps, which you could add to your XBR scaler.

I actually added a hq3x scaler to Aleph One at one point, but didn't care at all for the results so I never committed it. I don't really think the XBR ones are better than the originals either ::shrug::

That's okay. It's all personal taste, and personally, I find Aleph One's built-in scaler a little lacking, especially in high definition. Thanks for the advice!

EDIT: This is what Aorta spat out: When I put it through the algorithm, it came out like this:How is this possible? Can PNG store hidden color data?

So then I thought that maybe something was wrong with the algorithm, and I found a variant called <No Blend>, which looks like this:Well, that took care of the blue, but the image loses some smoothness. I guess it'll work though.

Aorta will only use the edge regeneration when it creates mipmaps. You'll have to get the code if you want to do it on an image before enlarging it. No-Blend seems to work OK though; if you're going for the XBR comic-book look, that will work well with opac_type=0 in Aleph One's MML.

treellama wrote:Screenshot of blue in game? Does it only happen with mipmapped sprites? How did you configure Aortas mipmap export settings?

I exported the bitmaps and the mask out of an original shapes file, then using Aorta's batch convert, I checked the box for look for masks, and I assumed that would take care of the transparency problems when I exported them to png and then ran them through ImageResizer.I'm not sure what you're referring to about code and Aorta. It's just an executable sitting in My Documents.As you can see here,There is no visible blue halo. The masks absorbed the transparency pretty much perfectly.And yet,In fact, here is that exact texture, but flipped horizontally:

My hypothesis is eitherA)There is a halo that blends with the texture and the foreground, and Aleph One is converting Alpha into blue, orI have no clue. Occam's Razor.

Export from Aorta using DDS and turn on mipmaps (you want those for monster sprites anyway). You probably want texture compression. The "Fast Halo Removal" checkbox should be enough to get rid of the blue halos, considering the source material. If not, you can try "Reconstruct Edge Colors" and pick that bright blue as the background color, but I don't think you'll need to.

Okay, so here is my conclusion:If I take the raw bitmaps from the shapes file and run them through Aorta and export them as .dds with the following settings:Use DXTCGenerate MipmapsImage RepeatsFilter BoxFast Halo RemovalReconstruct Edge Colors,and Blue as background color,

Then, in order to use them with the algorithm, I need to convert them back to .png with at least 98% quality retention using some batch program, Then I can run them through the algorithm, which since the blue will be gone, I can go back to using the Blending algorithm, which will then produce the desired result. (?)

I will test this when I have time. Expect 1.2 to have no blue outlines.

Hey, this is awesome! I've tried fiddling with some algorithmic way to up the res, but with unsatisfying results. Between this, the TTEP, the new HD weapons, and my 8192x3072 starscape, Marathon 1 is finally capable of causing framerate problems on my 10-year-old mobile workstation.