Daggerfall Mod talk:Image formats

I'm trying to work out a way to put higher resolution textures into Daggerfall. Won't help the screen resolution, and I don't know what it'll do to the aliasing, but it will at least keep things that are in your face from being really blocky.

I've looked at these texture file formats, and things are going fairly well for decoding, but I've run across an oddity: the daedra seducer (TEXTURE.284). In three of her animations, her textures are wider than they legally can be. She isn't RLE encoded, which means she's encased in a 256 pixel wide image, but her stated width is 270-280 when her wings are extended. When using other people's image extraction tools, I see a wraparound that is exactly what I would expect in that case, but I'm curious if it actually happens in-game. If it doesn't, then something inside the file format that nobody understands yet must provide for the extra pixels, and I'll probably have to figure out how to encode it for putting images back into the files.

I'm not good enough at playing Daggerfall myself to get to a Daedra Seducer, so I went searching for videos on youtube, and found some. Unfortunately, the full wingspan was never captured on screen, and even if it had been the video compression generated so many artifacts that the small wraparounds I'm looking for wouldn't be visible. On a side note, I also saw a few frames during her transformation that confused me -- her wings appeared to actually fade in. That should be extremely difficult for Daggerfall to do with a fixed color palette. From what's in the file formats, it should be impossible, because there's only one transparent color, and it is fully transparent. I was wondering if the video capture was doing something odd, or if there actually is some form of alpha blending that can be encoded. I wonder about this as well because the extracted images of Lysandus's ghost are just magenta silhouettes. If alpha blending is possible, then I need to try to figure out how it is encoded so that I can handle it properly when I put the new images in.

The point (finally!): I've never gotten very far in Daggerfall myself, and I was wondering if any of you happened to have any Daggerfall save games that you could reach a seducer and then save again, and send it to me. Then I could take care of trying to get the screenshots I need. I could also use DosBox's internal lossless compression to make sure I'm seeing what the game is generating. (a savegame with Lysandus might be handy, although I think I can get that outside at night in Daggerfall itself...)

Thanks for your consideration, Mac (my email name is mac, and the server is macreitercreations, which is a com. Hopefully that makes sense to the humans and not to the robots) 205.162.232.254 18:30, 28 July 2008 (EDT)

---

It's Mac again. I got to wondering what the pal.pal palette file actually looked like, so I generated a simple 16x16 image that had all 256 colors in it. It looked fairly reasonable, with several hues each having 16 intensities. One thing that surprised me was that palette indices 1-31 were all magenta. That didn't make any sense to me, but it did suggest how they were encoding alpha blending. If indices 0-31 were alpha levels, instead of just index 0 being fully transparent (as suggested), then the Seducer's wings could actually fade in, and Lysandus could be transparent and still have details.

So I copied my pal.pal and then rewrote the bottom 32 entries to range from black to white. Then I fired up the excellent Daggerfall Explorer by Interkarma and had it show me TEXTURE.473 (Lysandus's ghost). Whoohoo! Instead of being a magenta silhouette, it's a grayscale floating ghost! They actually have alpha blending in Daggerfall!

I'm going to do my texture replacement via .PNG files, something like this:

1. Export the existing images out, scaled up to 256 pixels wide each (maintain ratio for height), saved as PNG files with alpha.
2. Someone more artistic than I can then play with those PNG files to make them eye-wateringly beautiful (I should be so lucky). They can even play games with the alpha channel!
3. I will take PNG files and there corresponding texture files, choose nearest color matches, and wedge it back into the texture file.
4. I'll cross my fingers and hope Daggerfall doesn't explode when using the result...

Mac 205.162.237.46 03:06, 29 July 2008 (EDT)

---

Mac again. Decided to actually register a user account, and I've always liked DigitalMonk (although I can't get it on several sites).

It occurred to me that Lysandus may be a special texture, since I haven't seen anything else use the magenta. I can imagine that the video programmers might have been willing to support one truly transparent sprite, especially for an important character like Lysandus, but didn't want to have to support multiple transparent sprites at once. The computational cost increases somewhat, but the bigger problem is trying to handle a stack of partially transparent sprites. The computational cost of multiple overlays might have been too high.

I'll have to look at TEXTURE.473 and see if any of the UnknownX fields contain special values for Lysandus that aren't used anywhere else, and if so see if they seem to indicate that the texture should be "fully" alpha blended. Otherwise, I'll put in partial transparency pixels in textures that won't know how to use them, and we'll have magenta auras around everything. --DigitalMonk 16:35, 29 July 2008 (EDT)

---

Argh...

Well, let me start with the good news: I've managed to take textures out of the Daggerfall texture files, scale them up, and reinject them back into the texture files.

The "argh" moment was when I fired up Daggerfall and saw that the size of the texture affects the size of the object in the game. This is very bizarre to me, coming from OpenGL, Direct3D, 3D modelling programs, etc. In those environments, the size of the texture has nothing to do with the size of objects inside the game. Textures are mapped onto objects using UV coordinates, where the range 0-1 is mapped to the width or height of the texture. That means that once the object has a texture mapped onto it, you can change the size (resolution) of the texture without affecting basic appearance of that texture in the game world (it will get blurrier or sharper, but it won't be smaller or larger).

For architectural textures (panel with a window in it), this meant that the number of times the texture was tiled onto the wall or floor changed based on the size of the texture. For sprites (people, statues, signs), it meant that the physical size of the object changed with the size of the texture. I made the texture for a statue inside a temple be four times larger than it had been, and now the statue is HUGE inside the temple. Cool, but not even remotely close to what I wanted...

So I've been trying to decode some of the Unknown_ and Type_ fields to see if they encode scaling factors. As near as I can tell, they don't (at least not in any direct way). The fields change even when the size of the texture doesn't, and then they don't change when the size of the texture does. At first, looking at TEXTURE.381, I thought I might have found it. Images 0 through 4 are one size and image 5 is quite a bit larger. Looking at the headers (see my comments out on the actual page about splitting Unknown3 into two shorts), Unknown3/4/5 are the same for images 0-4, but different for image 5. Seemed an obvious case of them encoding something useful. Unfortunately, modifying the values of those fields (in other textures -- I don't have a ready save game with a nearby Redguard male) has no effect. And when you watch them in other textures, like TEXTURE.255 (the rat), those fields MOSTLY change when the size of the image changes, but not always. Images 5, 11, and 15 all have the "wrong" values -- they have the values that are assigned to the other size of image.

In other news, I found some other ghosts and wraiths that also used multiple transparency levels. I'm not sure how Bethesda marked those (still a lot of Unknown fields that need decoding), but for my own use when pulling PNGs back in, I just said that if more than 1/4 of the pixels in the image had an alpha that wasn't 0 or 255, then the whole image would use just alpha values. Other images split alpha at 128: smaller maps to 0 (to the fully transparent color) and larger maps to 255 (fully visible). This is because the palettized system they use can't do a transparent AND a color, it can just be transparent.

I'd post my program, but since it can't usefully increase the texture resolution, you'd probably be better off with AndyPic or one of the other tools.

I'm disappointed, and out of ideas. There has to be some way of modifying the texture->worldsize ratio, because if you look at TEXTURE.381-398 (or just pay attention when you stop someone on the street to talk to them), there are different size textures for the same person, and those people don't suddenly become 50% taller when they stop to talk to you. But there isn't anywhere left to look. I'm pretty much convinced that the ratio and "types" of imagery must be hardcoded into the EXE somewhere... --DigitalMonk 00:27, 1 August 2008 (EDT)

Decoding RleCompressed Image Data

Decoding RleCompressed image data is one of those rare routines which is easier done in ASM or Forth, than most other languages. Uniblab 05:50, 3 February 2009 (EST)

Split?

Should the article be split into seperate articles? It's getting rather large, but it is foundational; one can't make use of the Texture section w/o first reading the Img section (for example), and the data structures are shared/common. I'm leaning towards leaving it as it is, but if i/we add more content we might want to split it up along the lines of BLOCKS.BSA. The main article would describe the process, with subarticles for the actual structures and formats. --Uniblab 10:40, 9 August 2009 (UTC)