search

NearInfinityBrowser / NearInfinity

An Infinity Engine Browser and Editor
https://github.com/NearInfinityBrowser/NearInfinity/wiki
GNU Lesser General Public License v2.1
87 stars 37 forks source link

New file type variant: TIS #18

Closed Argent77 closed 11 years ago

Argent77 commented 11 years ago

Garbled TIS files (almost every file) Cause: new PVRZ format

Argent77 commented 11 years ago

More information about the TIS format:

The header structure is the same as in the original format. The field 'Length of tile section' (at offset 0x0c) can be used to determine whether a tile is compressed in-place (size=5120) or outsourced into external PVRZs (size=12).

The filenames of the linked PVRZ files are made up from the first character of the TIS filename prefix (e.g. A from AR, O from OH), the four digits of the area code, the 'N' from 'night' tilesets and a two-digit index number, starting at 00. For example: AR0300.TIS refers to the files A030000.PVRZ, A030001.PVRZ, A030002.PVRZ, ... AR0300N.TIS refers to the files A0300N00.PVRZ, A0300N01.PVRZ, A0300N02.PVRZ, ...

A single tile within the TIS consists of 3 dwords (indicated by the tile size=12 in the header):

Argent77 commented 11 years ago

I have added preliminary TIS->BMP support to my PVRTools.

Link: PVRTool v4

Argent77 commented 11 years ago

Looking at the existing TisResource class, I'd probably have to rewrite major portions of the code, since most of it deals with decoding the old TIS format. That's why I've been thinking about writing a new TisResource class, transferring only a bare minimum of code from the old class.

This also means an opportunity to make changes to the old TIS viewer. I'd like to know your thoughts about it. Do you like the current design (a 7x5 grid of tiles, scrollable via prev/next buttons) or do you have different/better ideas how to present the tiles?

FredrikLindgren commented 11 years ago

This also means an opportunity to make changes to the old TIS viewer. I'd like to know your thoughts about it. Do you like the current design (a 7x5 grid of tiles, scrollable via prev/next buttons) or do you have different/better ideas how to present the tiles?

Speaking as someone who doesn't do area graphics, I would imagine that seeing the composited image is more useful than seeing the individual tiles. There might be something in resource.are.ViewerGraphics that can be used or should be refactored (accessed from fileViewArea in BrowserMenuBar).

Edit: at this rate, maybe there's little point to shipping v1.35.0 with partial support for BGEE and v1.36.0 with full support. One or more perhaps feature-incomplete beta versions might be a better route (beta versions are probably a good idea regardless). Thoughts?

Argent77 commented 11 years ago

The area viewer already works very well, but it shows only the tiles referenced in the WEDs, and it doesn't show 'night' tilesets. We could remove the 'experimental' flag, however. I've never experienced bugs or other issues. I would also propose to move the area viewer from the menu directly into the ARE viewer, so more people may use this feature. (Even I have found this menu item only by chance not too long ago.) Any thoughts?

The TIS viewer doesn't make use of WEDs and should have the capability to display all tiles within a TIS file. DLTCEP, for example, show a single column of tiles by default (which isn't much better than NI's current TIS viewer), but you can manually define how many tiles per row will be displayed. I like this idea in principle, but I'd prefer to use an easier method to modify the number of tiles per row (e.g. a slider or a set of buttons).

Edit: at this rate, maybe there's little point to shipping v1.35.0 with partial support for BGEE and v1.36.0 with full support. One or more perhaps feature-incomplete beta versions might be a better route (beta versions are probably a good idea regardless). Thoughts?

Yes, I'm in favor of beta (or WIP) releases too. Since each new resource type has its own challenges (I still don't know anything about the FNT or MOS V2 type), we can take our time to properly implement each new feature. However, we have to solve this issue first before releasing anything at all. It's preventing older NI versions from starting under certain conditions and, from the user's perspective, solving the problem isn't trivial at all.

Argent77 commented 11 years ago

This is a mock up screenshot about how I envision the next TIS viewer: Screenshot

Please tell me your thoughts.

FredrikLindgren commented 11 years ago

Looks good. I'm not sure if the slider's necessary, but maybe I'm overlooking some situation when it'd be useful to have a variable number of tiles per row.

Argent77 commented 11 years ago

The slider would give the user control over how to arrange the grid of tiles, since TIS resources don't provide any information about their dimensions.

Argent77 commented 11 years ago

The TIS viewer is ready. It contains a new component, written from scratch, to show the tileset in a grid layout. The main problem is probably the huge amount of memory consumption which I have tried to solve in a somewhat hackish way, since Java doesn't know about explicit memory deallocation. The main component of the "View Area" feature had to be be written from scratch too, to support the new PVRZ format. It uses multithreading to speed up the decoding process.

Commit: https://github.com/Argent77/NearInfinity/commit/1382df2c1b7a3561671aa70811f29b407f8b4b71

Could you test it thoroughly and report back your experiences?

FredrikLindgren commented 11 years ago

I've tentatively penned this in for tomorrow.

FredrikLindgren commented 11 years ago

Whatever method you are using to guess the initial value of tiles per row could possibly be improved upon. It's frequently off by 1 (e.g., guessing 81 for ar1400.tis when the correct value is 80).

Other than that, the new TIS viewer seems to work fine.

Edit: with regards to memory management, I think setting the variables to null and suggesting a GC run (as you already do) might be the most we can do. Have you tried without System.gc()? From what I understand, it's something of an iffy practice and if it's possible to do without it, maybe we had better.

Argent77 commented 11 years ago

Whatever method you are using to guess the initial value of tiles per row could possibly be improved upon. It's frequently off by 1 (e.g., guessing 81 for ar1400.tis when the correct value is 80).

The only reliable way to calculate the "correct" aspect ratio of a TIS file is by looking into the associated WED file if one is available. I'll test it and see if it works.

FredrikLindgren commented 11 years ago

Hmm, testing this on another machine, performance on the BG2 TIS files seems subjectively worse with the new code, perhaps by as much as second or so.

Argent77 commented 11 years ago

You are right. I've just tested it in a single-core VM and the time to display TIS files or area maps is significantly higher than the with the old code. I'll see what I can do to improve performance.

Edit: The calculation of the correct TIS aspect ratio with the help of WED files works better than I had expected. In my tests it displayed all TIS files correctly. However, this comes at the cost of a slightly worse loading time.

Edit2: The multithreading code causes very high loading times on certain systems. Looking into it.

Argent77 commented 11 years ago

Updated TIS and MOS viewer routines. They should be faster now.

Commit: https://github.com/Argent77/NearInfinity/commit/8c788eccdbdd74daf746756c108f58c12fa51133