View Profile
View Forum Posts
Reply With Quote
Visit Homepage
Excellent work, ZB! The level of detail is spectacular.
Now we just need a new mission that makes use of them...
Well, I'd hoped to have this ready by Christmas (actually I'd hoped to have it ready two months ago, but Real Life chose not to cooperate). This thread is to announce the Alpha release of the System Shock 2 Enhanced Monitor Package. The package contains high-resolution, high-framerate versions of the SS2 monitor (screen) textures. Note that these textures will have no effect on existing missions. They will only show up in missions which have been created or modified to make use of them. This is rather a lot of work for our resident ShockEd'ers, so please make use of this thread to voice your interest in such an undertaking.
Download from FileFront here:
(link removed; see below)
Being an alpha release, it has a few known graphical issues I'll be cleaning up before the final release.
(sorry about the spam at the bottom of the images, it's something ImageShack adds)
EDIT:
Version 1.0 of SHEMP has been released now, so I removed the download link for the alpha version. SHEMP 1.0 can be downloaded here: http://files.filefront.com/13771802
Last edited by ZylonBane; 6th Jun 2009 at 02:16.
"Look at you, hacker, a pathetic creature who smells of elderberries. Now leave, insect, or I shall taunt you a second time."
Excellent work, ZB! The level of detail is spectacular.
Now we just need a new mission that makes use of them...
Brilliant! What a sharp bunch they are! The animated static is particularly arresting for some reason. I keep getting the idea that there's something lurking within it. Perhaps there's some sort of Magic-Eye joke to be made about it.
If the monitor textures in the vanilla campaign were replaced with your new ones, would that mean distributing entire mission files? Or is it simpler than that?
Yes, it requires distributing modified MIS files. This isn't so bad though, there are already a few mods that do exactly that.Originally Posted by Pardoner
...and which you can remove in about 3 seconds.
Great work as usual.
Minor typo: In the camera's datalink box: Abberation -> Aberration
Wow, sharp eye! Fixed.
Oh excellent, nice job!
Really nice, and very useful.
Great work, ZB; they look awesome!
The only problem (correct me if I'm wrong) is that you can't modify the stripped levels because it would require re-portalizing them. So these could be placed into the unstripped levels, but not the originals that we don't have unstripped versions of. A pity, but then again, some are better than none.
Awesome, ZB.
That is, unfortunately, correct. The best we can practically do for the stripped levels is create new high-framerate textures at the original resolutions.
The best we can impractically do is reproduce those levels from scratch. But that would require a huge investment of time and effort.
Didn't Zygoptera make changes to these levels too?
We can change the objects but not the terrain.
Although... a flat plane object that uses the screen textures placed directly in front of the brushes that use them might work.
But you can't set the animation rate on object textures.
True, though you might be able to fake it with clever use of model-cycling.
Isn't model-cycling fairly limited though? A lot of the updated textures use 10 frames of animation (I wanted to use the full 19 frames, but the animated texture size limit squashed that). Perhaps a custom script could be created that implements more flexible model cycling. But that might be too much of a resource drain considering how many screens are in a typical SS2 level.
Yes, model-cycling is limited to 6 'frames'. What I was thinking was to double the texture animation speed by toggling between two objects each with their own set of texture frames, so the first model would use textures 1, 3, 5, 7, 9, and the second model would use textures 2, 4, 6, 8 and 10. I'm not even sure if it would work, or if the current frame would get reset if they don't both use the same texture.
The custom model-cycling script is a good idea, too. I had planned make one of those at some point.
Instead of model cycling, could a script instead hook into the object reskinning system? Would certainly beat having to create hundreds of new model files.
Yes, it could use the replaceable texture functionality, though the problem with that is that it won't load the palette for a texture loaded through texture replacement, which means that the textures are displayed using the default txt palette instead of their own - unless the texture has previously been loaded elsewhere (having the appropriate texture family loaded would count here).
I'm not sure if you can specify an individual frame of an animation as a texture for texture replacement, though.
Ugh, a potential problem just occured to me-- conflict between the custom animation script and the built-in animation system. That would suck to have to include an entire duplicate set of textures without the underscore in the filenames.
That's what I was just thinking.
Well, in any case, it's not much of an issue until someone takes on the much larger task of adding the animated brush screens to the unstripped missions.
Edit: Okay, I looked into using Telliamed's automated texture-swapping tool, but there's a problem with it.
The tool takes a list of textures in the format oldfam/oldtexture newfam/newtexture scaleoffset uoffset,voffset, and the problem is that the uv offset it takes is a fixed value and not a scaler.
For example, if a texture is 64x64 and has a UV offset of 8,8, then replacing that with a 256x256 texture would involve giving it a scale factor of -2 (halve the space taken up twice), and then multiplying all the UV offsets by 4, to be 32,32. The program doesn't do this scaling part.
Telliamed supplied the source code, however, so it should be easy enough to fix.
Since Dark bases the lightmap scale off the underlying texture scale, I'd always assumed that independently twiddling the texture scale would cause Horrible Things to happen.
It would be nice to be proven wrong on this.
Telliamed's tool only adjusts the scale and UV mapping on the brushes themselves, not in the world rep. In other words, you still need to reportalise afterwards, so it won't break the lightmapping but it also won't work on stripped missions.
I modified the program to automatically realign the textures based on the scale factor, and it seems to work flawlessly now. I just need a list of old texture to new texture mappings and scale factors. This is the mapping file that I was experimenting with:
(-1 means the texture is four times the size (2x in both directions), -2 means it's eight times the size, and so on.)Code:tech\b64 techw\b64 -1 tech\p0022 techw\p0022 -2 tech\p0021 techw\p0021x -2 tech\p0015 techw\p0015x -3 tech\p0036 techw\p0036x -2 tech\p0034 techw\p0034x -2 tech\p0011 techw\p0011x -2 tech\p0010 techw\p0010x -3 tech\p0020 techw\p0020x -2 tech\p0024 techw\p0024x -2 tech\p0025 techw\p0025x -2 tech\p0023 techw\p0023x -2
Ah, I was thinking it worked on stripped levels. Still nifty though.
I believe I can generate a mapping file like that. As part of this project I built a spreadsheet with much of the necessary information already compiled. I'm guessing a step that can't be automated is setting the custom animation rates. That shouldn't be too bad though-- if I understand the way DromEd works, the ones with doubled animation rates can be fixed by just changing the tech screen archetype, and there's only a handful with non-doubled rates.
A more time-consuming problem is that, with actual legible text, it's going to be very obvious that a lot of the tech textures were applied rather sloppily. There are tech textures that are backwards, sideways, upside-down, misaligned, you name it. These will require manual adjustment.
Posting Permissions
