You have told me to comment about pixtotga errors and issues.
It also cost my time to prepare the files and test this app.
I have created many tools and fixes for C1 so I understand this is not commercial work and also because of that and because there is such possibility I talk with you to improve pixtotga tool.
So please don't be rude.
ad 1) I think this is OK now.
ad 2) Thank you for the explanation. Too bad it's so difficult. This is not to be idiot proof, we all can makes mistakes, this may just lead to unclear situations, so in my opinion it's important to be clear.
ad 3) I told you twice this is tiny problem. Since actually user don't know that the file is empty until he check it, how can he think that this is empty file... where when looking at log it look like this file is in format which is unsupported by pixtotga. But once again this is not very important, so can be as is.
I have extracted that broken NEWBIGGR.PIX and it look like pixtotga took a "a:" as part of filename, which is not. Result fn: 001-a_newbiggr.bmp.tga
I have tested pixtotga with Mastro's C1 Special Edition and it look like it can't read some pixelmaps which are *working in game*, looking at first one it have bad value set.
Since sometime game crashing on bad files later than it read the files I will fix that files anyway. I have also found similar bad files looking at some custom pixelmaps.
At least one other tool (I have tested with only one) can read that files. If you want to add support for such files I will select them and upload for you. I think the error is similar as in my look2.pix (there are two bytes set to wrong values).
I think if you want to support such bad files this also should have a info in log.
You have told me to comment about pixtotga errors and issues.
Yes, but "errors and issues" not the same as unrelated things.
It also cost my time to prepare the files and test this app.
We're really appriciate it as far as it "errors and issues" only.
So please don't be rude.
Do you really didn't see any differences between errors and other wrong behavior and completely unreleted things? It's very annoying when someone persistent asking for unrelated features. There is one simply and easy question which you should ask to yourself: "Is the thing that I want related to (insert here something) or not?"
Yes? - there are .PIX files with internal palettes and tool didn't work with it - well, that's an error, issue and wrong behavior. Should be fixed.
No? - empty files, corrupted files, etc. - not related to the tool. Never. Imagine someone who drive a car with broken brakes. First of all, you should replace it and not expect that car will be happy to work with it in the first place. Second one - modding a game require some skill. If you don't have it - don't do it. If you really want to you gain some knowledge earlier or later (about empty files too - as example). Learn or die. No one will teach you, nor rewrite the tool for a completely newbie. The same thing goes for the double files - it's utmost unproductive to destroy tool hierarchy only to add unnecessary features for a complete newbies. How many of them will use this tool for 20 year old game anyway? And the third thing - modding a game (as any other complicated work) also requires you to concentrate. If you're unpacking all .PIX files in the same folder - blame yourself and no one else. It's the same thing why no one complaining after unpacking few .ZIP files in the same folder and trying to pack only files from the first archive. You should manually select them or unpack to the empty standalone folder in first place. No one of the software developers responsible for that. It's user-side problems. Completely unrelated.
I have extracted that broken NEWBIGGR.PIX and it look like pixtotga took a "a:" as part of filename, which is not. Result fn: 001-a_newbiggr.bmp.tga
a) File isn't broken. It's 0x3D type (this type has one additional WORD (two bytes) at the header - mip_offset value).
b) You'll be surprised, but "a:" is actually a part of the filename. For example:
A:\AUTOEXEC.BAT
and
A:AUTOEXEC.BAT
both are valid way to specifiy a file in the root folder (and only in the root!) for DOS or Windows.
So maybe NEWBIGGR.PIX originally was at a floppy drive and original .PIX tool just put it inside with the whole path specified from the command line. Anyway it's all speculation. But there is nothng wrong with that file structure. It's completely valid.
...pixelmaps which are *working in game*...
Since sometime game crashing on bad files later than it read...
You just answer to your own question why the game works when it shouldn't.
Carmageddon code very messy. The game skips and didn't check a lot of values in the .PIX header and solely rely on the information from the .TXT files with the pixelmap information.
As for anything else - updated to v1.5 - reworked code for the broken .PIX files.
