Sam.

Where does the key "Information" point to for a mod that has a readme, a forum, and a website all hosted online, and not necessarily at the same base URL?

Also, if you mandate everyone conform exactly to "an industry standard", you must point to strict documentation of that standard. Preferably, the standard and documentation would be rigorously maintained by a recognized authority. Ideally, the format chosen would be established and widespread enough to be *natively* supported by many programming languages, and IMO be human-readable.

Isn't it more elegant to format your INI file as valid WeiDU variable assignments and INCLUDE it?

Thanks for looking.

The EEs have 32-bit bitmaps that have a Windows BMP Version 5 header, which is not documented in the IESDP. A decent explanation of the BMP file format (I generally find it more useful than what is already in the IESDP) can be found here, and a breakdown of the Bitmap V5 Header can be found here.

For reference, I'll provide an overview of the structure along with values from a file (1CHELMX6.bmp) that is typical of those found in the EEs:

;;;;;	32-bit Windows 5.x BMP	;;;;;
http://www.fileformat.info/format/bmp/egff.htm
https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/ns-wingdi-bitmapv5header
BMP Version 5 (Microsoft Windows 5.x)

Offset	Type	Size	Data	Description	Typical Example From EE
0	WORD	2	FileType	File type, always 4D42h ("BM")	BM
2	DWORD	4	FileSize	Size of the file in bytes	120458
6	WORD	2	Reserved1	Always 0	0
8	WORD	2	Reserved2	Always 0	0
10	DWORD	4	BitmapOffset	Starting position of image data in bytes	138
14	DWORD	4	Size	Size of this header in bytes	124
18	LONG	4	Width	Image width in pixels	160
22	LONG	4	Height	Image height in pixels	188
26	WORD	2	Planes	Number of color planes	1
28	WORD	2	BitsPerPixel	Number of bits per pixel	32
30	DWORD	4	Compression	Compression methods used	3
34	DWORD	4	SizeOfBitmap	Size of bitmap in bytes	120320
38	LONG	4	HorzResolution	Horizontal resolution in pixels per meter	2834
42	LONG	4	VertResolution	Vertical resolution in pixels per meter	2834
46	DWORD	4	ColorsUsed	Number of colors in the image	0
50	DWORD	4	ColorsImportant	Minimum number of important colors	0
54	DWORD	4	RedMask	Mask identifying bits of red component	0x00FF0000
58	DWORD	4	GreenMask	Mask identifying bits of green component	0x0000FF00
62	DWORD	4	BlueMask	Mask identifying bits of blue component	0x000000FF
66	DWORD	4	AlphaMask	Mask identifying bits of alpha component	0xFF000000
70	DWORD	4	CSType	Color space type	1934772034 (sRGB)
74	LONG	4	RedX	X coordinate of red endpoint	0
78	LONG	4	RedY	Y coordinate of red endpoint	0
82	LONG	4	RedZ	Z coordinate of red endpoint	0
86	LONG	4	GreenX	X coordinate of green endpoint	0
90	LONG	4	GreenY	Y coordinate of green endpoint	0
94	LONG	4	GreenZ	Z coordinate of green endpoint	0
98	LONG	4	BlueX	X coordinate of blue endpoint	0
102	LONG	4	BlueY	Y coordinate of blue endpoint	0
106	LONG	4	BlueZ	Z coordinate of blue endpoint	0
110	DWORD	4	GammaRed	Gamma red coordinate scale value	0
114	DWORD	4	GammaGreen	Gamma green coordinate scale value	0
118	DWORD	4	GammaBlue	Gamma blue coordinate scale value	0
122	DWORD	4	Intent	Rendering intent for bitmap	0
126	DWORD	4	ProfileData	Offset to profile data	0
130	DWORD	4	ProfileSize	Size of embedded profile data	0
134	DWORD	4	Reserved3	Always 0	0

BAMWorkshopII supports an unpaletted BAM format (BAMU) and has the following to say about it:

---------------------------
0.3 Alpha Changelog
---------------------------
IMPORTANT NOTE
There is a new file format availble now: the Unpaletted BAM (or BAMU). BAMUs do NOT work with any infinity engine game, however they serve two purposes:

Firstly, they allow the user to create images without first having to decide on the palette colours and serve as a good way to save "work in progress"; the user can convert them to a paletted BAM later and get (hopefully) an optimised palette.

Secondly BAMUs will hopefully be included in the "Beyond Infinity" project, a TeamBG project to create a new engine capable of powering games designed for the Infinity Engine but with greater flexibility.

CHANGE LOG:
o REDID Copy/paste: unpaletted data may now be pasted in (i.e. from external applications)
o ADDED Mouse Wheel scroll: used to zoom image
o ADDED Unpaletted BAM format
o ADDED Paletted<-->Unpaletted conversions
o ADDED Transparent View

New TODO Items:
o Frame Optimisation (i.e. RLE on/off)
o Multi select in frames mngr
o Free Rotations

KNOWN ISSUES:
o BAMU --> BAM palette optimisation is flawed. I'm working on it.
---------------------------
OK
---------------------------

 

"Beyond Infinity" sounds suspiciously like GemRB. Was this format ever implemented anywhere, or does any further documentation about it exist? Looking at a BAMU, the Header looks like:

Offset     Size (data type)     Description
0x0000     4 (char array)     Signature ('BAMU')
0x0004     4 (char array)     Version ('V1  ')
0x0008     2 (word)     Count of frame entries
0x000a     1 (unsigned byte)     Count of cycles
0x000b     1 (unsigned byte)     The compressed colour index for RLE encoded bams (ie. this is the colour that is compressed)
0x000c     4 (dword?)    Unknown field.  One observed value is 0xFF0000FF
0x0010     4 (dword)     Offset (from start of file) to palette
0x0014     4 (dword)     Offset (from start of file) to frame entries (which are immediately followed by cycle entries)
0x0018    4 (dword)     Offset (from start of file) to frame lookup table

Note I’m unsure what the 4 bytes at 0x000c are for. Any ideas?

OffsetToPalette is usually/always 0, and no palette appears to be stored in the file.

Otherwise, Frame Entries, Cycle Entries, and Frame Lookup Table sections are the same as in BAM V1, except that frames do not have RLE. Frame data is stored as 24bpp in the RGB order, and has no scanline padding.

Some legacy mods set the storage capacity to 0 which makes them "truly unlimited", but that has been shown to cause problems like you describe in the past. The better practice for "truly unlimited" storage is to set the capacity to one less than the maximum possible value of the field (a signed integer?), but 999 should be perfectly fine.

If you are on a classic game, there might have been a TobEX component that had something to do with containers (I can't remember for sure). If you're on the latest version of an EE game, try to reproduce the behavior without mods installed, and if you can report it to BeamDog. Other than that, I'm not sure what to suggest.

Have you installed some version of bottomless bags of holding?

Post it or PM me and I'll take a look at which internal formats the BMP is using.

Use Infinity Animations instead?

BAM Batcher comes with a few resources and templates that might or might not be helpful. There is an overview in the Tools section of the readme.

 

I broke down and wrote it anyway, which concludes my initial vision for the project. The first beta release containing the full feature set can be found on GitHub.

Wow thanks! Could you write a tutorial on how to use your tool?

 

Setup-PS_Tileset.tp2 is a working example that displays almost all of the functionality offered by the tool, plus it intentionally uses some bad inputs (where noted in the comments) to show that it handles them properly. That main TP2 file has inline comments explaining what each call to the function library is doing, plus I tried to make sure the library itself (ps_tileset_lib.tpa) was well commented. If you have specific questions, I'd be happy to answer them the best I can.

Thank you for the examples. It seems I am still doing something wrong, tho:

Edit: Code redacted

gives:

 

Game = BGEE

UPDATE_PVRZ_INDICES in "BGEECLASSICMOVIES/CHAPDRM/BGEE/MOSV2/ARRIVE.MOS"
Copying and patching 1 file ...

INSTALL_PVRZ for "BGEEClassicMovies/chapdrm/BGEE/MOSV2/MOS0000.PVRZ"

Source filename does not match MOSxxxx.PVRZ. Skipping file.

[...]

Edit: I figured it out.

So I have a folder of MOS V2 + PVRZ files I want to install to the override folder of an EE game. It looks like I need to use the WeiDU functions INSTALL_PVRZ, UPDATE_PVRZ_INDICES, and FIND_FREE_PVRZ_INDEX to make sure I don't overwrite anything already in the game, but I don't quite understand how they are supposed to be used. Could anyone please either post an example or point me to one?

TIA,

Sam.

If you need any help figuring out BAM Resizer, just let me know.

@Sam.: PS_Tileset looks promising. Btw, one of the TIS files in question is about 25 MB big. Does the mod handle TIS files of 16 MB or bigger?

Sadly, no... I guess I should have thrown in that disclaimer with my initial statement, sorry. I'm still hoping this gets implemented sooner rather than later.

 

Sorry, I did not see your post before.

Yes, the renaming PVRZ and and updating references in the TIS files is what I am doing right now.. I tested it for some example areas, works fine. I now do the remainders.

Except for two files BH1000 and bH2201. There is something odd with those. It looks fine in the original version but gets the *EE horizontals* when converted to PVRZ?

[...] If you have a decent hex editor you could manually add some dummy tiles to the TIS files to make them work. BH1000.TIS requires one addition tile and BH2201.TIS requires four additional tiles.

 

This is exactly the type of thing PS_Tileset is designed to do. Adding the missing tiles to both tilesets is a total of 3 function calls away. If you upload both of the original tilesets for me, I can show you how.

I mirror a copy (that has had HTML syntax errors corrected) here:

http://readme.classicadventuresmod.com/TobExReference.html

 

0x000b 1 (unsigned byte) The compressed colour index for RLE encoded bams (ie. this is the colour that is compressed)

 

The transparency index is set to the first occurence of RGB(0,255,0). If RGB(0,255,0) does not exist in the palette then transparency index is set to 0

I haven't done exhaustive testing, but it seems the EE engine (and probably also ToB) do not like it when the RLEColorIndex is not zero (0). The EE engine transforms the color of the RLEColorIndex into transparent (Green) while ToB renders it even more poorly. There goes some potential compression...

There was some discussion here:

http://forums.pocketplane.net/index.php/topic,29685.0.html

Your best bet may be to avoid any commands specifically designed to work with 2DAs and parse the files manually e.g. with RegEx yourself.

It hasn't been extensively tested yet, but here is a function library to do stuff with tilesets:

PS_Tileset

Note that if you want to add bitmap tiles to a PVRz-based tileset, you will need to run Tile2EE to convert it to a palette-based tileset first, then convert it back.

 

ps_tileset_lib ps_tileset_repair_header

Repairs a couple of errors in tileset headers:  missing header and wrong version number

ps_tileset_remove_tiles

Removes tiles from a tileset

ps_tileset_add_tiles

Adds or replaces tiles in a tileset

ps_tileset_create_tileset

Creates a tileset from a number of tiles

ps_tileset_export_tiles

Exports tiles from a tileset

ps_tileset_info

Gathers and reports basic or verbose information from a tileset

ps_tileset_replace_palette_entry

Replaces palette entries in a tile with a new color

ps_tileset_recolor_pixel

Recolors a pixel in a tile without changing the color of every pixel using the same palette entry

ps_zlib_compress

Z-lib compresses a file

ps_zlib_decompress

Z-lib decompresses a file

I broke down and wrote it anyway, which concludes my initial vision for the project. The first beta release containing the full feature set can be found on GitHub.

I have updated the library with a new function, ps_tileset_replace_palette_entry, that replaces palette entries with a new color. So say there was a tileset with a tile that contained a pure green pixel, which would look odd. You can use this function to replace every pure green pixel with some other color. I feel like there was a fixpack somewhere that did something like this. A problem arises if you need to replace the color of a single pixel without entirely removing that color from the tile (like if that bad green pixel was in a door or water overlay tile that intentionally uses green for the transparent sections). To replace the color of this pixel, you would first look to see if the color you want to replace it with was already in the palette. If it is, great you're done. If it isn't, you would next have to look for an unused palette entry. If every palette entry is used, you would look for duplicate palette entries, combine them, and then use the free entry. If there are no duplicates, you're left with calculating the nearest-neighbor color within the existing color pool. I have basically already done this for BAMs in a different language (AHK) so I know how to do this, but rewriting it in WeiDU would constitute significant time and effort. While this last function would complete my initial vision for this tileset function library, I'm a bit hesitant to put forth the effort if there is no need for it. Other than this, my library (along with Tile2EE) includes the capability to do anything with a tileset I could envision anyone wanting to do that couldn't be done better with just a well placed WRITE_BYTE.

Thoughts? Anyone know which fixpack I vaguely remember or how it went about replacing green pixels?

After entirely too many months of delays, here is an initial beta that anyone is welcome to play around with. The function library comes with a test suite to demonstrate a variety of its capabilities and to purposefully trigger various warnings and errors. IMO it can do quite a lot with tilesets that AFAIK has never been done with WeiDU before, but keep in mind that until WeiDU's filesize limitation has been resolved (hopefully a solution is in the works), it won't work on large tilesets. Also note that if you need to add tiles from bitmaps to a PVRz-based tileset, you will first have to use Tile2EE to convert it to a palette-based tileset, add/replace the tiles, then use Tile2EE again to convert it back to a PVRz-based tileset.

Feedback, bug reports, suggestion, criticisms, etc. are all welcome.

Idea : make the card game against Aesgareth fair (I mean something close to randomness).

In 3rd round, he always draws the card "Wheel" and win...

IIRC the deck itself (if you acquire the item) is 'stacked against you' . You can't draw the best cards unless you have previously made a "bad" draw. I've always thought this was a stupid nerf (presumably added for "balance") that went against the randomness and luck-of-the-draw nature that is the deck's essence. I'm not sure either (or even both) of these warrant a new tweak component, tho. A global un-nerfing tweak would be awesome, but it would be quite a bit of work and there would never be a consensus on what should be included.

The .bah format is removed from the EE. But from what i see, it was bam without bitmaps (bam header).

In the same vein (although presumably with a bit different implementation) as tilesets and their headers being stored separately? I find it hard to imagine why this type of thing would have been done in the first place. My only guess is that it resulted in fewer computational steps for the images to be send to the graphics card, or otherwise facilitated marginally faster rendering of the graphics?