Если нравится наш проект, пожалуйста, поддержите любой приемлимой суммой чтобы помочь оплачивать хостинг. Спасибо!
Навигация  🇷🇺RU | 🇬🇧EN

Новые комментарии

Последние файлы

[ Через Yoo.Money ]
(бывшие Яндекс.Деньги) 410011494554572

Contact us if you wish
PayPal or BitCoin donation

Наши друзья

Файловый архив
Carmageddon .PIX to .TGA image converter v1.6
Автор: CTPAX-X Team Размер: 18 КБ Скачали: 325 Дата: 2015-03-24 14:56

Конвертер .PIX / .TAB файлов в .TGA и обратно из игры Carmageddon (Splat Pack и вторая часть также поддерживаются).

С исходными кодами на C.

FAQ: запуск консольных программ >>>
Комментарии [11]

- - - - Комментарии пользователей - - - -

 2016-09-16 17:17 QTZ #1 

For DRACEFLC.PAL it also require to replace duplicated black:

0000152D: 00 08

0000152E: 00 08

0000152F: 00 08

For this palette Stainless using different color for transparency:

00001500: F0 F7

The modified palette is embeded in flics.

Also look: http://qtz.toshiba-3.com/Purple_Palette_Patch_for_All_Carmageddon_Needs.7z

It patching other tools, this one and in game palettes to "purple" version.

(The offsets are for pixtotga.exe)

Thanks for the feedback! One other question before we update the tool - should be the DRRENDER.PAL first palette entry updated too from 0xF0 to 0xF7 (offset 00001200) for consistency?

 2016-09-17 05:50 QTZ #2 

I decided to use different values for each palette since Stainless put such palettes in Splat Pack PIX files (search for *.pix files with ".bmp" inside - it's actually palette). Looking at FLI files - palette DRACEFLC.PAL have sometimes DD (about 50 files) but in most cases it is set to F7 (much more files). DRRENDER.PAL always have F0, so *no*.

Here: http://rr2000.toshiba-3.com/R4/PC/Tosh_C1_helpers.zip are custom palettes fixed to pink using custom FF00FF color (used in most graphic tools as pink by default).

The problem with transparency pink-purple color is that sometimes graphic editor turn red like colors to that pink like color, for example it may turn blood to transparent - as we can see in case of at least one pedestrian in SP (there are holes in bloody area).

Anyway it's way better than duplicated black or white ;)

Other thing - this tool need reverse functionality - to pack bitmaps (tga) into pix pack. I was thinking about such tool which will build pix files from lists of bitmaps.

Here is original pix creator (old, but only version we know that is available): http://rr2000.toshiba-3.com/R4/PC/IWar_Texture_Kit.exe

(it work in DOSBox and allow to pack one picture in one pix).

A lot of information can be found in BRender documentation - look links in MISCELLANEOUS section on this page: http://rr2000.toshiba-3.com/tutorials

Thanks for the links and info, but actually no one in our Team interested in Carmageddon so much. Version and source codes updated to v1.2 - also added packing feature, fixed images width (looks like game uses padding to 32 bits as in BMP) and so on (see the start of the source file for complete changelog).

 2016-09-17 19:02 QTZ #3 

Thank you for the update!

"fix width - remove padding to 32 bit (4 bytes)" can't test this since I don't know how to write proper 8bit tga to import... but image size must be at x multiple of 4, at y any value from 1 (at least for software mode) - I hope this mean exactly this. Some of original textures are sized wrong and visible as color mosaic in game:



http://qtz.toshiba-3.com/screens/crane_fix/moving_crane_after.png .

The corrupted newbiggr.pix came from 3Dfx patch and it cause Win95 version to crash in hires.


There is also similar bad file in High Octane (cut down version of C1).


Only DOS version work with such corrupted pixelmaps.

(In SP there is also one 0 size pix).

There are also files I have mentioned in previous post - used in Splat Pack - which contains sub entries with some of pixelmaps inside pix packs, the sub entries are actually palettes. PixToTga doesn't support that pixelmaps.

AFAIR that palettes are used in PlayThing 2 (the original editor for BRender games, there is also PT1), but game skip it (I have even put there different data for test), so it can be skipped, also removing palettes allow that pixelmaps to open in old tools (and PixToTga currently).

Custom pix files may have additional zeros at the end (from 1 to lot - even more than 100), by default should be 8.

So pix tool should extract that files (but pack to default without errors).

There some 24 or 32 bit pixelmaps. Not handled by game, so in game visible as black. For example gsplatot.pix (24 bit) used in game as robot oil (in robots mode) - as I see already supported by PixToTga, gdrum1.pix is a 32 bit and this isn't supported.

Looking at original tools you can also check how different formats are stored.

I hope you will be interested to at least fix possible problems since Carmageddon is interesting game, especially for modding :) For example we still don't have proper Crush Data generator:


The texture extraction tool will be also nice to extract flics same way as pixelmaps ;)

1) Again: no one in our Team interested in Carmageddon to spent so much time on it. Sorry.

2) The same goes for FLIC format - it's well widespread, so no one will write another converter for it. Use Google to find tools which supports it.

3) If you want to submit a bug or add support for corrupted files - provide at least download link for .ZIP/.RAR archive with example files. Because, for example, "gdrum1.pix" (6598 bytes) from C1 supported and converted without any problem (note that mip_offset not supported - see the help info when running this tool without any parameters). This tool supports 8, 16 (partial), 24 and 32 bits per pixel .PIX formats.

 2016-09-18 19:39 QTZ #4 

You are right the gdrum1.pix is converted to tga, but then it's displayed as black box... so if nothing is wrong with the header the problem is in Irfanview which I'm using to browse graphic files. This tga can be opened in PhotoFiltre and it look correct (file saved from PF is not 8bit, so can't be imported back).

It's always good to try a different graphic viewers to check and compare. Also try XnView (http://www.XnView.com/) or nConvert (can be downloaded at the same site) if you need to convert something. nConvert is freeware for private or educational use (including non-profit organizations). And just in case - pixtotga _can_ import back any image of 8, 16 (partial), 24 or 32 bits per pixel. The other question - will or will not the game support and work with the imported image BPP.

 2016-09-18 20:06 QTZ #5 

Thanks for the info I will check that tools.

There is no public available converter for Carmageddon flics, old CarmagEdit can import graphics over existing files but it's limited - result file must have same resolution and must have exact frame count, it's also uncomfortable to import series of 100 images one by one. Also some files are not handled properly and can't be opened at all, some are became broken after save. AFAIK only modern tool which support C1/SP flics is Media Player Classic HC, but it's only player, which sources are available.

If you are still not interested, skip this, but I think this may be interesting programming experience and the whole community will be grateful for such converter.

The pixelmaps with palettes are present in Splat Pack, all palettes have ".bmp" extension inside pix packs.

Here is an example of error:

pixtotga.exe PORKBON.PIX


005-PKSAIL.PIX.tgaError: identifier block not found.

Here: http://qtz.toshiba-3.com/pix_info/pix_with_pal.zip is a file which batch, log, and unsupported file list (except for broken font from C1, which is already supported)

Would you mind to tell what word in the "If you want to submit a bug or add support for corrupted files - provide at least download link for .ZIP/.RAR archive with example files." you don't understand? Example files - .PIX files. No one have Splat Pack nor want to find and download it.

 2016-09-20 18:45 QTZ #6 


There are original SP files and (fixed) without sub-data.


Here the custom files I have created long time ago to demonstrate how it's possible to hide the picture behind another picture using the palette swap trick.

When palette support will be implemented it should extract also that files.

High Octane loadscrn.pix:


This is problematic pixelmap from C1 High Octane. It work only with DOS exec (the only included in this version).

This one have palette (wrong for this image, with default colors), but there is also problem with header. I have included also two edited versions - with edited header, but still with palette and another without palette.

Updated to v1.3 - now using internal palettes (if any) when unpacking. By the way, "LOOK2.pix" so broken. About FLIC:


And the last one - please don't use comments on site for talking or requesting help for modding. Comments here only for reporting errors or other issues with our tools. Thank you.

 2016-09-22 06:27 QTZ #7 

I'm not requesting help for modding...

OK, but there is missing option to override the internal palette to race or menu (it look like even "m" switch doesn't work in that case), it will be useful since some pixelmaps have wrong palettes - as this one from HO (or as in my example - custom data is set as palette). I think log need information when internal palette is set.

Another thing which is not critical, but not comfortable - when we work with few pixelmaps we need to extract each to separate dir (sub-dir) - if we have more tga's with same numbers it took "random" files (first found) to pack. Maybe adding result pix filename to tga will fix the problem? Or... personally I don't like sub-dir's...

1) Internal palette has top-priority of any menu/race palettes because it's internal. For images with the internal palettes any combination of the command line switches will be ignored. If you want to change palette - just repack the .PIX file:

a) unpack it

b) pack it back (image palette will be dropped)

c) unpack again with or without "m" switch

2) You can do it with a batch file like this "unpixall.bat" (place it with the same folder as pixtotga and .PIX files you want to unpack):

@echo off

for %%a in (*.pix) do (

md "%%~na"

cd "%%~na"

..\pixtotga.exe "..\%%~a"

cd ..


This will unpack each .PIX file to its own separate folder. You can modify this .BAT file to pack them back. Adding archive filename to output filenames will just make them even more long and ugly than it was now.

3) If you don't like the music start your own radio station. It's easy! (c) VRock, GTA: Vice City Source codes provided, so you can modify this tool as much as you want to match your own needs - no one will stop you. We promise. Really. Seriously. Just do it.

 2016-09-22 17:09 QTZ #8 

I have already tested that method (ad.1) but since this is required in most cases it's not good to use internal palettes by default.

AFAIR game ignore internal palettes and only PlayThing 2 using embedded palettes. Since race palette is most used and pixtotga has proper "pink" version, I think race palette should be default and internal palette should be skipped, but show in log that is present and skipped - to inform user that it can be used with additional switch (when there is no internal palette, that switch should only show log information that there is no embedded palette and do nothing - use default race palette).

ad.2 I was trying a batch, but this one is much clever, thanks :).

However if you extract few pixelmaps to one dir, pixtotga will pack one of 000, one of 001, etc. even without warnings, maybe it should stop if there is more than one file with same number... or something, since we are loosing control if there are duplicate numbers.

You want suggestions - so I trying to help. However It's very nice you have publishing source code :D and thanks for permission ;D

Unfortunately I don't remember much from the time I was using C... (most of my programs are in VB6/Tibbo Basic, also few years break...). Maybe I try at least understand how pixtotga currently work - so question which compiler to use?

1) In that case can probably add the "r" option which will force race palette, "m" will force menu palette and nothing will extract with internal palette + race palette as default. Is it ok?

2) Do not unpack pixelmaps to one folder. Just don't do it - it's really simply.

3) Our source codes ANSI C'89 compatible, so any C compiler should work. We're using GCC 3.2 from DEV-CPP (2002) with some of our internal hacks which allows to build tiny executables without any external dependences (like MSVCRT.DLL) and compatible with Windows 98 till Windows 10 inclusive.

 2016-09-22 19:26 QTZ #9 

ad.1) IMO: race palette as default; m-menu pal; i-internal pal, when no internal palette use race pal; im-internal, but when missing use menu pal.

ad.2) Maybe just add warning that duplicated file(s) ### are skipped? - In case of accidentally have duplicated numbered files.

ad.3) Sounds cool, you rock! The Win 98 compatibility and even XP compatibility is a problem of many new programs of today.

(BTW: [Sorry for OT] We have hifi's wrappers for C1 [and other games] which are compatible with selected Windows only, GOG has compiled latest version with different compiler and it's not compatible with WinXP anymore... [hifi's version source code are available]).

Another tiny thing: In Splat Pack there is one 0 size RIGMAP.PIX (which is wrong), pixtotga return error on it, which is OK, but there is no information that this file is empty.

Error: invalid input file format: RIGMAP.PIX

1) Ugh... one-letter switch, so no "im". One. Letter.

To sum things up:

a) no switches - force race palette on all images (even on images with internal palette)

b) "m" - force menu palette on all images

c) "i" - use internal palette (where available) and race palette elsewhere

d) "n" use internal palette (where available) and menu palette elsewhere

2) Not gonna happen. Do. Not. Unpack. Pixelmap. To. One. Folder.

3) "0 size" - i.e. 0 bytes? So... well... why message "invalid input file format" didn't satisfy you? What kind of message you want? This message appears when one or more of the 4 big endian values from the header (0x12, 0x08, 0x02, 0x02) didn't match these constants.

 2016-09-22 20:43 QTZ #10 

ad 1.) IMO like that will be correct.

ad 2.) I think it took the file list then go through and skip duplicated numbers or wrong formatted file names, so why not display skipped file names with duplicated numbers... It may help very much when we incidentally put duplicate files. Currently to prevent such errors we need to extract created file and check what is inside... or we see wrong textures later in game...

ad 3.) It's tiny problem of only one file, but since this file is by default in game, I think user should know that this is not pixtotga unsupported file, but the file is empty.

1) Updated to v1.4.

2) There is no such thing as "file list". Read MSDN about FindFirstFile(), pixtotga uses static buffer for one single file for each iteration (while there files matching with the find mask). First file matchig the mask "###-*.tga" will be taken (where ### - sequence of numbers 001, 002, ...) and there was cut off first 4 and last 4 chars from the name. That's all, nothing more checked in filename. If you want to build complete file list you must take into account a lot of things to build "protection from the idiot". It's a lot of work, so not gonna happen. Well, you always can quickly write a bad junk code - that's why there are source codes. Because _you_ may write it if you wish. And _we_ don't.

3) So, we're talking here about complete idiot who didn't understand that file with zero bytes in size can't be valid in _any_ format at all?

To make things clear: it's a handmade fan converter, non official. And we even didn't sell it. So why the heck we should bother for minor things like empty files or files with the double numbers? It's not commercial software with paid technical support in first place. Use it as it was, modify for your own needs or didn't use at all.

 2016-09-23 02:20 QTZ #11 

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:




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.

Ваше имя:
Текст комментария:

    © CTPAX-X 2006-2024 | engine version 2.5
Based on original site design by Blade



При копировании материалов ссылка на сайт WWW.CTPAX-X.ORG обязательна!
Использование материалов влечёт безоговорочное принятие правил сайта.
Количество запросов к БД: 8 | Страница сгенерирована за 0.00883 сек.