Jump to content

Mod Added Area Compatability for BG2 and BG2EE in 2019?


cmorgan

Recommended Posts

6 minutes ago, paladin84 said:

Is this area TIS or TIS+PVRZ? It looks like the location taken from IWD1/IWD2.

TIS V1, but after convert with tile2ee to TIS V2 (PVRZ) - still the same. Yes from IWD1EE (Eastheaven). Edited with DLTCEP 7.7,

Edited by szef
Link to comment

Based on my experience, tile2ee works well only if you need to convert TIS+PVRZ back into TIS. To convert TIS to TIS+PVRZ it is better to use NI. See this message:

After the conversion via NI, these multiple black lines should disappear and then you will notice lines at the doors...

Edited by paladin84
Link to comment

This can also occur with the normal tiles on the background map. If the width of the pvrz image file is larger than the tiles section, then it is 1 pixel larger in the x direction on both sides. The same applies to the y direction.
Only if image width = tile width or image height = tile height, then there is no pixel.

Example
t = tile  Image section is 5 x 3 tiles

t t t t t        5*64 Pixel = 320 Pixel = width
t t t t t        3*64 Pixel = 192 Pixel = hidth
t t t t t

1st case Pvrz file is 320 x 192 pixels => no additional border pixels
2nd case Pvrz file is e.g. 384 x 192 pixels => one additional pixel in each x direction => image section 322 x 192
The same applies in the y-direction or in both directions simultaneously if the sides are correspondingly larger.

 

For example B010013.PVRZ All the image sections have border pixels.

This is a bit complicated and I have problems putting it into words, especially in english :)

Edited by Weigo
Link to comment
13 minutes ago, Weigo said:

his can also occur with the normal tiles on the background map. If the width of the pvrz image file is larger than the tiles section, then it is 1 pixel larger in the x direction on both sides. The same applies to the y direction.
Only if image width = tile width or image height = tile height, then there is no pixel.

Can this happen if an image with width and height divisible by 64 is converted into TIS+PVRZ using NI?

The workflow with the proposed script is:

1. Convert TIS v1 into PNG (assuming its width and height are divisible by 64)

2. Use the proposed script to create new PNG and WED file.

3. convert new png into TIS+PVRZ using NI

Link to comment
1 hour ago, paladin84 said:

(assuming its width and height are divisible by 64)

I don't think it needs to be. As the tiles can always get more empty black, and the BG2EE game does it in either way if you go to look at the map border. Or your map is smaller than the whole screen. It might have been the case in the old BG1 games... but the widescreen mod went around the issue by added empty tiles, when needed.

Edited by Jarno Mikkola
Link to comment
11 hours ago, paladin84 said:

Can this happen if an image with width and height divisible by 64 is converted into TIS+PVRZ using NI?

I don't know.
This is exactly what makes the whole issue so difficult. The error is somewhere in the baldur.exe file, probably where the tis files are put together to form an image. Beamdog then stupidly did not correct the error in the exe, but with the additional border pixels.
That's why I took the pvrz files from the originals and transferred the graphical changes by hand.

11 hours ago, paladin84 said:

3. convert new png into TIS+PVRZ using NI

NI converts them much better and more robustly than tile2ee. Both use modified routines.

Unfortunately I don't know how it assembles the edge parts of the map. At the beginning you have the 1024x1024 tiles. These always work without problems. Then come the tiles on the right and bottom edges. These are also put together in certain related areas (see example B010013.PVRZ). When they are set in a png by the routine, the border pixels are set. But this makes the routine incredibly complex. Or you can generally make a border pixel row around each tile for every the border areas tile.

Link to comment

Honestly, I still don't fully understand how the described glitches looks like (and even where to get B010013). Do you have the screenshot with the glitch?

Anyway, I feel myself much more comfortable, manipulation with images than editing binary files, so if something can be done this way (adding extra empty tiles, reorganizing them, etc) I would rather do this (with a script) than try manually adjusting many TIS+PVRZ files...

Edited by paladin84
Link to comment

I was just trying to search my thoughts from a year ago when I started BGGO to find the error. The script from you is a great thing, I'm not very good at programming. If you can solve the problem technically, that's always better.
The B010013.PVRZ is a part of the BG0100 are (NW Baldurs Gate City)

Link to comment

I checked how NI converts into tis+pvrz. It seems that if the source was PNG, it just cut the whole image by 1024x1024 pieces (so the tiles are located as they were in PNG and how they are going to be located in the game). If it converts from TISv1, it probably tries to do a better job by placing tiles using the information from WED file, but for my experience it does more harm than good: glitches at doors never gone, but sometimes tiles are misplaced. Thus, I ended up to converting everything through PNG (and it was easy enough for me to change WED and PNG files in the middle of the process).

I tried to open the file you mentioned (B010013.PVRZ) in NI and saw that tiles in it are definitely not located as they should be on the image. I still don't know how the glitch looks like in the game (I guess, I should install the mod for that and teleport to the area), but what I would try is to convert the tis+pvrz files for the whole area into PNG (with NI if it is possible at all) and then convert it back into tis+pvrz to see if the glitch still there.

Link to comment
10 hours ago, paladin84 said:

I still don't know how the glitch looks like in the game

That's probably an example of how we've passed each other by :)  It's because of my mediocre knowledge of English

This was just an example of how the PVRZ image files were cut up by Beamdog and that the individual cut-outs are all 1 pixel larger at the edges.
BG0100 has no lines and glitches in the original, but the old BGGO version does when converting from v1 to v2. But now in the new version it has none. :)

But thanks anyway for your efforts.

Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...