To list everything we find about C1 and C2.
Little tips, stuff, etc.

First thing that crosses my mind atm:
The TIFFX folder (C2) is only used to store 256 colors TIFF files and will only generate 8bit PIX files (PIX8).

[quotes from my blog]
While porting the C1 Sumo arena I noticed one very interesting thing: at the end of a track textfile the number just before the textfile name is always 1. Well this number is actually a Yon multiplier! Put 2 and you'll increase the drawing distance by two, put 0.5 and it will shorten the drawing distance to its half.

Now that I think of it, Harmalarm noticed another thing. It's possible to set sfx volumes so that they change the sky to a certain color. I knew this and wanted to use that effect in my Mayan Mayhem C2 port but for some reason it didn't work. Harm pointed me later that the depth cue mode must be set on "colour" in order to get this effect to work.

There's a common annoying problem with flapping components (doors, bonnet, etc.) when they get hit: they all of sudden have an offset from their original position. And the only way to put the component back in position is to repair the car completly.
Well you can fix that easily by opening the car back into PT2, selecting the faulty component, pressing SHIFT+T and centering the mesh back on 0,0,0. You can force the identity matrix if you want it never hurts with non-actor-typed components.

It's possible to rotate the ingame track map. However it's not an easy task as handling the transformation matrix is needed. You can for example rotate the map by 90° in comparison to its top down view in PT2. But you can even make a transversal map! It would still be a 90° angle but around the X/Z axis. This could be very useful if you make a very vertical track (like a carpark). And finaly it should be possible to create a 3D view by having a rotation on every axis. It would still be isometric though.

You can also easily translate the actual map, you just have to add/remove the offset in pixels to the first two numbers of the last row in the map transformation matrix (those numbers are often similar to 320*240, I guess they indicate the center of the track map).

One very annoying thing about preprocessing tracks is how it removes materials on long thin triangles/quads. You can prevent that by entering a very high ratio limit (like 100000) in the Tidy Up Kerbs window.

However you can actually use this option to quickly apply a material on every long quad you didn't bother texturing...

Some powerups move on their own and these are the ones ranging from 66 to 88.

Material modifiers uses a number to assign surface characteristics to a material. Well you better pay attention to the texture name as well.
If a material is set to use the fourth material modifier (2ROAD.MAT) make sure the filename of its texture doesn't start with a different number (055_road_diff.tiff for example) because it will read the first char and assign the respective material modifier from that rather than from the material identifier.

With our beloved PT2 it is possible to generate lines (real lines I mean, no triangle, just vertices linked to eachother).
You just have to create a plane in MAX with as much length subdivions as you want, but the width mustn't be subdivided just, two vertices wide if you see what I mean. Then you move the vertices from one side onto their respective vertice on the other side (using vertice magnet). Ofcourse here it's a fake line as it is composed of 0 width polygons. But when you'll import it into PT2 and use the "optimize" function on it, PT2 will create a real line out of it, removing the unnecessary vertices.
I think the game will render it like that (PT2 won't unless in wireframe mode), but you can always use the wireframe actor rendering mode to be sure.

When making custom C1 cockpit images, remember that somehow the game doesn't like you fiddling with the transparency too much. Don't even think about making a cool shading effect on the borders or something similar by diffusing black pixels over the transparency: it will mess up the rendering of said cockpit image.
Just stick to clean well defined transparent areas.

Noticed this with Alex's Battlax:
To make a car shake without having to use a groove on the whole car, simply apply smaller angular momentum proportions.

From Errol Errolson:

• You can use "lastlap" and "otherlaps" instead of "constant" and "distance" in funks, these work on cars too!
• !materialname makes a flat surface become water, !!materialname makes the game instantly auto-recover you.
• Set the SPARKY noncar keyword on heavy noncars to make them spark when they move. Nice on 36rollinrock1.txt and 06rollinrock2.txt
• Game freezing when opponents fall off your map? Lower your YON!

Don't put your C1 install too deep in your folders hierarchy as it might prevent the game from starting.

Example, with this path, my game crashes:
C:\Documents and Settings\All Users\Documents\Carmageddon\VanillaC1

But if I put the game one level higher, it will run:
C:\Documents and Settings\All Users\Documents\VanillaC1

When loading local resources, the game probably has a char limit for the paths, it mustn't be too long.

I always thought C1 Glide mode couldn't handle textures larger than 256x256 or non-power-of-two sizes. Actually Glide is fine with both as long as these sizes aren't precisely 512 or 1024 (maybe 2048 and so on).

So 256x512 won't load, but 256x514 will work. You get the idea.

Go figure... Carmageddon, ladies and gentlemen...


[EDIT] OK, I missed a huge thing: Glide mode actually resizes bigger textures down to 256*256.

The software mode barely cares about the texture sizes (which is awesome). The Glide mode however can load these textures apparently but downsizes them to 256*256

Did some tests in C2 yesterday and the day before.

- Actors with transformation (mirror, rotation, scale) are only reset if you set an animation in their GROOVE, paths are ok.
- Actors being named FLWHEEL.ACT, FRWHEEL.ACT, RLWHEEL.ACT, RRWHEEL.ACT can reset their position. So if you instance/transform wheel actors it might be wise to avoid naming them directly like that and rather prefer naming so a parent dummy that'll get groovy. It is also necessary to have that naming in order to enable the wobbly wheels when they are damaged.
- It is possible to do instances of a single model in C2 as well: just name the actors THING.1, THING.2, THING.3, etc. and have the model named THING. Or even WHEEL.FR, WHEEL.FL, WHEEL.RL, WHEEL.RR and the model named WHEEL. However keep in mind that in the case of wheels for example, if you do instances it means you'll also transform their actor. So you can't groove them directly with animations such as spin or rock and have to rely on a parent dummy as explained above. But if you don't groove them, they'll be crushed by collisions (also has they share the same model, the crushing is instanced too!). Best thing to do then is simply to add a useless groove on them (not a lolli, constant, no path, no animation) to disable crushing without resetting the transformation matrix.
- Anyway, by experience I find that in general it is better to apply the transformation matrix on yet another parent dummy than directly on the model. You can have several parent/child levels.
- Instancing detachables is not a good idea. The accessory isn't restored to its prope position once the car is repaired. Instances sharing the same model, means they all get the same crushing even if they weren't part of the collision. Trying to trick the game by using a parent dummy might lead to the game crashing.
- Instancing boring parts all share the same collision and doesn't look realistic because of that.
- If you want to work on individual model you can split the DAT file and have as many DAT files as you have models loaded by your ACT file. DAT filenames don't matter so you can sort them like that if you want:
eagle3_main.dat
eagle3_wheel.dat
eagle3_driver.dat
The game will parse the car folder and load all DAT files in there anyway. This also means you can put the simple and shell models in the main DAT file if you want.
- The very same applies to the MAT file (can be split, named differently, simple/shell materials embedded).

- The exact vertex limit is 1024 (one more vertex and the game crashes). I couldn't reach a face limit (2052 doesn't crash so it's not 2048). I suppose there's no face limit. It's difficult to achieve more faces with a 1024 vertices limit anyway.

And here's the ultimate testing machine:

Splitting DAT files: as I said, I find it easier to work on some singled out components. Especially as Harm's script can export DAT files only. When you prepare instances you have to edit the ACT file manually and clean the DAT file. If you have to edit an instanced mesh afterward it's just easier to work on it individually and export it separately without having to edit the ACT and main DAT again. Catch my drift?
Oh yeah, forgot an important thing: there's a content limit to DAT files! For cars at least, never ran into that problem with tracks. I don't know if it's the amount of component, the vertex quantity or the filesize though. Anyway, splitting the file in two makes it work.


Precisely the case I'm working on The whole car is highly detailed and I instance all groovy stuff. Also if you're ok with some symmetrical geometrically dense parts not deforming, it halves that load within the DAT file.

A couple more tricks:

When you apply a groove to the parent of a deformable component, the child won't appear with the shell model (or if you force it, it won't animate). Easy solution: apply a null groove on the child (this won't reset its transformation matrix) to make it appear with the shell model. Then add a default entry for that same child in the wam file to restore its crushability.

Via hex editing, it is possible to mirror a material or multiply it along the X/Y axis. PlayThing1 can also help you change the material's transformation matrix. To mirror a material on the Y axis for example you just have to find the second 3F80 word in that material chunk (in the .mat file) and change it to BF80.
It is useful with env mapping when you want to easily make an inverted clone of such a material without duplicating the texture file.

Some stuff

Actually the 'rock' funk wasn't documented, here it is:


Actually not used by the game, but just for the record here's how the funk lighting stuff was supposed to be written:


Apparently there's a # material identifier flag (I mean, like the ! to make a pass-through water surface-type-material). And it's like a water-filled tunnel side/top material. Yeah I really wonder too. Will have to test that.

If you wondered how to reproduce the scrolling reflective texture (as seen in the Castle corridors for exemple) outside of special volumes, well you can't. That effect is added to any textured material told to replace the windshield material (as set in a car text file) via a special volume and only like that. Too bad!

C1 completely disregard the ride height value. Generates it on its own from the min-y bounding box coordinate.

There was a C2 thing as well but I forgot! Thanks to Errol for his usual help!
[edit] I remember the C2 bit, some of you guys probably noticed a long time ago, but I recently did: textures with an alpha channel are converted into pixelmaps with less colours. Explains why the car menu pics look so bad.

Copying this here as it doesn't seem to be anywhere in the board (from C2S' track making tutorial):

In Carmageddon1 (maybe C2 software too), applying a blend table on a material (either via the \50 switch in the identifier or by loading the table directly within the material file) will disable the depthcue/fog shading on it.

This basicaly renders these materials full bright and can be used for neons etc.

In Carmageddon 1 (software mode), there's an inconsistency between the sky rendered by the external camera and the one rendered by the internal cam (cockpit). If I'm not mistaken, it's the same difference as between the skies of the C1 software external cam and the external cam while in Glide mode.

This is explained like so: the external cam in software mode doesn't rely on the sky setup code from the txt file. The game adjusts it automatically. Maybe it is because of that, but it seems like many skies weren't then setup properly for the internal cam/glide external cam.

The fix seems easy: just have to setup that bit of code in the txt file to make the internal/glide skies match the software external sky. However the way software mode adjusts the sky for the external cam makes it not look the same once in lowres mode! yay! Might have to use a different sky texture for the lowres mode.