TESTY the test car

2 years later, a simple post to share the test car I had made for Errol when he investigated crush datas. It's a simple block on wireframe wheels:

Download it here

As you can see, it's handy to select and modify specific vertices. And for the record, here's what Jeff had to say about crush datas:

Crush Header:

0.450000 // damage multiplier. This is low for strong vehicles and high for small, light vehicles
0.150000,0.400000 // unknown. seems to always be the same
0.050000 // (same)
0.050000 // (same)
0.000000 // (same)
0.000000 // (same)
93 // number of vertices

For each crush vertex:

65 // vertex index
-0.1682, -0.1328, -0.4427 // min position for this vert
-0.0682, -0.0540, -0.3427 // max position for this vert
0.0121, 0.0156, 0.0062 // multiplier for left/top/rear collisions
0.0378, 0.0234, 0.0437 // multiplier for right/bottom/front collisions
74 // number of child vertices (used if the main vertex is hit)

Child vertex #1:

5 // vertex index. This starts at -1 and is added for each vertex. So this vertex is 4 (-1 + 5) in PlayThing
178 // distance of this vert from the parent vertex

Child vertex #2:

1 // vertex index. This is vertex 5 in PlayThing (-1 + 5 + 1)
133 // distance

How to write your own C1 PIX pack

(and thus prepare your custom textures)

With this article, you should be able to /write/ your own pix pack for Carmageddon 1 (C1) from scratch, and then include your bitmaps easily with CarmagEdit. 
Prior to reading and trying to go on with this article. Be sure that you have a hex editor installed (Hex Workshop, FrHed, 010 Editor, etc.).

This stuff is only useful for C1 modders or for people who would like to start modding C1. It is useless for any C2 editing!
I highly recommend you totaly read this article before attempting to create a pix pack for the first time. This way you'll have a global idea of what is awaiting you.

Updated in August 2011!

Continue reading...

Marvelous Carmageddon 1

Here's a short post about some C1 stuff.

Everybody playing C1 knows about the annoying effect in the windows being kinda messed up. I had a look at the reason why it happens like that. First thing is that it isn't linked to the car at all. You can define a material on your car that the game will later replace with a sky material or area material if you are in a SFX volume. Actually these materials that the game is substituing are the "problem". Most of these materials are using the env map (loc) effect, like we use in C2 for chrome etc. and these materials are also rolling by default (controlled by the car's movement). As the env map in C1 is kinda ugly (pixelated) and not working the same way as in C2, Stainless decided to multiply both horizontal and vertical repeatition by 5! This was an unknown feature of the MAT files. And apparently it doesn't go well with the env map effect. Getting rid of the repeatition also get rid of the problem but then the material in the windows are very pixelated, enabling dithering on said material doesn't help. No idea what to do to solve this so far. And fixing this would be a lot of work as C1 uses a lot of these materials all around and they don't all beheave the same way.

At least this made me discover the UV repeatition! Not really sure how useful this could actually be (besides increasing the env map material) but I understood how it works. Hexediting a MAT file you can notice for each material entry a pair of 3F80h. The C1 materials using UV repeatition had 40A0h instead. So to put it simply, 3F80h = 1 and 40A0h = 5. However the scale value isn't a constant. It's decreasing at every power of two. Let me explain: 1 is 3BF0h, to get the texture to repeat to times you must add 80h and thus write 4000h, to go from 2 to 3 however as we passed by 2 power 1 we mustn't add 80h but 40h and write 4040h, it's the same to go to 4 (and write 4080h). Again as we leave 4 which is 2 power 2 the difference must be divided by two again and we must add 20h instead. From 8, the difference will be 10h. And at 16, 8h. To put it simply, here's a table:

1x= 3F80h
2x= 4000h
3x= 4040h
4x= 4080h
5x= 40A0h
6x= 40C0h
7x= 41E0h
8x= 4100h
9x= 4110h
10x= 4120h


I talked about dithering in C1 materials. I don't think it was ever used in both C1 and C2 (must not have much incidence in C2 but for its software mode) but it actually works (I know that for a long time, just forgot to talk about it). Dithering might seldom be suitable for C1 texturing as it diffuses pixels to loosen the texels and (imo) it doesn't fit in C1 which is more about pixelart. Also dithering soften details in textures. However there are some cases where it is useful. Textures where random noises is welcome or which are supposed to offer a lot of matter detail at different distances. For example I used it on the log of recently released Mighty Fist. You can see in the shot here how it diffuses pixels from a texel to another:

Dithering example


Speaking of diffusing pixels I'm now sure you can't do that with transparent pixels for the cockpit images. It either makes the game crash or then messes up the cockpit image itself. You might want to diffuse transparent pixels if for example you wanted blurry edges or subtle shading on the borders of the transparent areas. Well forget it, the game doesn't like that. I guess it keeps track of the amount of transparent areas in the cockpit image and if it encounters too much of them or a 1x1pixel one it goes pop-fizzle.

Another thing that apparently might crash C1 when working on an addon car is the amount of shrapnel colors. Keep it low. 3 maximum. The car here above with log had 4 shrapnel colors and it made the game crash every time shrapnels had to be generated. It's either 3 maximum or they are SimpMat colors that make the game crash.

And finaly a word about the C1 palette. All of sudden it came to my mind that if the C1 palette was that customized in comparison to the standard 256 palette then it should be possible to modify it given the fact it wasn't integrated into the executable itself,(and thus relying on both palettes located in REG\PALETTES. Well it does use these palettes and you can modify these easily. The PAL file format is the same as the Microsoft PAL but for the header. Also it isn't needed to modify DRRENDER.PAL directly as the game will load anything in the PALETTES folder and give priority to the last one loaded. So just create a new palette keeping the same name as DRRENDER.PAL in the header but write the filename so that it is loaded after DRRENDER.PAL it will then overwrite it.
I proceeded to mod said palette and created a SinCity look alike one.

SinCity Carmageddon 1

Click the thumbnail to enlarge it.

This wasn't short at all.

Oh and about BBQ: ToDo list

Things are getting slower lately as I'm working on normal C1 and C2 stuff but BBQ is still progressing towards its first proper release. Here's what I'm planning to work on until then. You'll notice stable Internet gaming isn't on the list yet (getting rid of the lag) this is because I want to have ressources done before. LAN gaming is working a treat anyway, and if the host has a very good Internet connection (univertities, etc.) the Internet lag is greatly decreased.

  New content:

- Port of the Stunt Park from Carmagedddon TDR2000. Errol released last year a near fully featured port of the TDR2000 Hollowood track. The TDR multiplayer level "Stunt Park" is actually an excerpt of Hollowood so I'm working on it from there. My port however will be much more complete gfx-wise as it will include the hard shadows the original has, ambiant lighting, the multiplayers powerups and spawning points gfx and all sort of goodies.
Early Silo Area 3 screenshot

- Silo Area 4. The two first Silo areas are part of the singleplayer Silo race. The third was an unused part of the latter which rather made it as a multiplayer arena. Well I've been designing a fourth area on my own some months ago. A WipeOut inspired gameplay with an overal setting placing the area on the edge of the base with lava breaking the tunnel on the deepest part and an apocalyptic open sky at the top. The level will be available as a checkpoint race as well as an arena.
Early Silo Area 3 screenshot

Ressource editing:

- Setting the Silo Area 3 original lighting ambiant back. The beta visuals of Carmageddon 2 depicted the third Silo area as a prerendered scene, backing shadows and lights into textures (a la C1), however the way it was in C2 added shading over the prerendered textures, which ofcourse kills the whole atmosphere. This will be fixed in BBQ, colors and contrast will be back as they were meant to be.

- In the BBQ alpha version, the Opponent Repulsificator powerup was replaced by the Slaughter Mortar one. This is because the Carmageddon TDR2000 multiplayer events made it clear that this powerup was totally unfair. Yet I finally thought that completly removing the powerup isn't a bright idea either. So I'll just replace the powerup references in the tracks themselves and leave the option to level designers to add a real Opponent Repulsificator in their addon level if the gameplay really needs it.


- Compress executables back.
- Add version layer for Glide rendering. (There's already one but it only appears in D3D mode which is unsupported in BBQ)
- Adding the Multiplayer Car Changer.
- Handling the Internet lag directly from within the Winsock hook?!

Voilà, let's just hope for the best and this stuff should arrive soon. And yes once again I copy pasted, this time from my ModDB news item.

ENB Series for Carmageddon II

Hello, let me get this straight, this is actually the ENB mod for GTA Vice City! Only two functions work correctly with C2: bloom and occlusion. Bloom is very easy to get going without losing much fps at all. While occlusion is a ressource hog, only use it if you have a powerful computer.

This archive should include everything you need:
- ENB Series (d3d9.dll)
- Needed DirectX dependencies (d3dx9_26.dll, d3dx9_40.dll)
- Config files (enbseries.ini)
- The DX9 glide wrapper, dgVoodoo (glide2x.dll)
- dgVoodoo setup (dgVoodooSetup.exe)

There are three config files:
- enbseries.ini (this is mine, Toshiba, only subtle bloom and color correction)
- enbseries_hazardic.ini (this is Hazardic's, heavy dark bloom, very dark and oppressive)
- enbseries_chevy2.ini (ChevyII's, with occlusion)

Put all these files in your C2 folder.

If you want to use Hazardic's or ChevyII's, simply delete or rename mine, then rename the wanted one to enbseries.ini. Pay attention that ChevyII's config activate occlusion, you'll quickly notice whether your comp can run it or not.

You can ofcourse modify the config file yourself. Just head to enbdev.com and read up documentation etc. The thing isn't that easy to handle.

Once you've extracted the files into your C2 folder, configure dgVoodoo by executing dgVoodooSetup.exe and setting it up to your likings. The important part is to use the DirectX9 API instead of DirectX7.

There are a few DX9 glide wrappers but only one is known to work with ENB and it is dgVoodoo. If you already have dgVoodoo installed on your comp, having another instance of it within another folder will not change a thing. If you have another glide wrapper installed (Zeckensack's for example), extracting dgVoodoo with ENB in a C2 folder will make this very C2 use dg rather than Zeckensack's but all other glide games will use Zecken'.

Not much to do if it's the case with yours :(

ENB Series is made by Boris Vorontsov: http://www.enbdev.com
dgVoodoo is made by dege: http://dege.freeweb.hu

Oh, by the way you can download this little pack at Road Reaction in the PC tools part. And yes you guessed it, I just posted the readme I just wrote...

Error messages

Things sure are slowing down a lot lately, that's because of my business taking more time by the day.

Anyway I'm still modding C2 almost everyday, yet I never experienced so much bugs and errors than this week. I ported the C1 Sumo arena to BBQ and wanted to keep the textures unfiltered so put the MAT and PIX files within the REG folder. I spent two days to discover that for absolutely no apparent reason three textures were the cause of an error message I never saw before and then didn't stop occuring: "DataFileStack type mismatch, wanted 3, got 3". I swear I checked and tested everything. Finaly I simply kept these three textures within the track folder, they'll be filtered.

Then I did a lot of betatesting to try to see why the three Cameron cars included in BBQ were crashing the game. First thing was the bbox. The three of them were too complicated and most probably a bit concave here and there. But then the game kept on shouting two kind of messages: "Physics error type #" (type 9 and 16 were the most recurring ones) and "Net contents too big" or similar. I tried cleaning the wam but that wasn't enough. So I replaced the three cars with three other ones...

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 the 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.

Right now I'm still working on BBQ, and will maybe quickly port some models to C1. I still have a lot of stuff to do for both C1 and C2 and they'll be done one at a time. etc.

Full lit materials for C2 cars, peds via REG folder


I'll make this one kinda short. There's a way to have full lit colors and textures on your peds, cars, noncars, etc. even though you can't use the track full-lit trick. The idea is to use a material/texture from the REG folder! In order to achieve that, you have to create a reference to this external MAT file within the model DAT file only (and thus no entry in the normal car MAT file).

Usually working in PT2, when you save your car/ped, PT2 creates/updates the MAT file to make it include all the materials in use on said model. If you happen to want a full bright yellow color on some part, here's what you'll do:
C2 includes SimpMats (if you're an advanced modder you should know that) and one of them is a full bright yellow, M38.MAT. So in PT2, create a new empty material named M38.MAT (flags and the likes doesn't matter at all, we just need the exact material name) and then assign it to the triangles you want. Save your model, PT2 creates/updates the MAT file. This car MAT file includes M38.MAT and this is bad as we want the game to use the external one (from the REG folder uh (it's inside simpmat.mat which is loaded automaticaly)). So open up your car MAT file with a hex editor, find the M38.MAT entry and delete it (correctly). And voila, your car will now use the generic M38 material which will render full lit ingame.

Ofcourse so far this shows limited uses, only full lit colors. You can still achieve very interesting design touches though. As example look there Coffeycup's Zenabot is using this trick to have green glowing eyes. They come out very well out of the metalic chrome effect.

But yeah... it's possible to go further. You can put your textures in the REG/PIXELMAP folder (usualy twatted though) and create a specific MAT file for them all. The main difference with the SimpMat.mat is that you can have other lighting settings than full lit (setup via PT2), not sure about diffuse colors. Once again referencing the external material in the DAT file only (and not in the car/ped mat file) will load the new MAT file from the REG folder. The textures will render ingame as full lit (or as set up) but also unfiltered (might still be dithered though (if flagged)).

You guessed it, it's not very comfortable to use as usualy the REG datas are twatted. Still it's an interesting feature for modders working on total convertions. Also I'm positive it should be possible to hack the main C2 executable to make it load other TWT files (and thus addon ressources).

Well anyway... seriously I could use these SimpMats for a million things. And so do you.

Mayan Mayhem notes


Mayan Mayhem is about to be released actually. I couldn't achieve all the design ideas I had in mind. It was not really worth the effort anyway. I just wanted it finished correctly for the next BBQ build.

Designed a new level mixing C2's nuclear silo with wipeout-styled levels today. Must complete the TDR Stuntpark multiplayer level (for C2 uh) first though.

Kinda understood how to get rid of these crashes occuring when opponents fall out of the track in fanmade tracks btw: opponent path node types.


Hello, here's some news about my doings.

I'm currently working on an update for BBQ, a lot of things are already changed/added and right now the StuntPark from TDR is in the works (based on Errol's Hollowood port) and I'm also completing the Mayan Mayhem level by adding powerups! I automated the importation of the original C1 powerups, I just have to create custom powerup models (3d versions of the C1 sprites uh) and they'll be there! Good thing it's all automated and we now have Dan's noncar tool to plot these instantly, else I wouldn't have placed 421 powerups by hand in PT2... Once both of these are done I'll release them as standalone for singleplayer mode.

I'll probably write another couple of tutorials or more (in the near future), about special materials for cars/peds/drones, the api wrappers, and maybe one about the noncar tool, but it will be for advanced users, it takes a bit too much time to explain everything from scratch.

I also want to test that unused Force Front flag in PT2 material options. Got an idea by looking at one of Agent Orange's drawings.

After finding out how to give and offset to the track in the minimap texture (usualy centered) I can now rotate it. Gonna be handy with that StuntPark track as I'm rotating it so that it faces the C2 light vector the way I want. And then I rotate the minimap back so that I can use the original horizontal minimap from TDR.

Did you know it's possible to load the materials through the actor instead of directly with the model? I wonder if it's possible to cumulate materials or create interesting effects with this.

And finally I REALLY want to find how to get rid of those hardcoded blue boxes around the timer in the ingame HUD. Using a process memory dumper to watch what's going on, might help me as I'm clueless as to where it could be in the exe binary.


After months of silence etc.

It's been a long long time I was waiting for that.
CFe is open again under a new form.
That is all.

And I know Google currently blocks this page, but it's a false alarm...

  • By Toshiba-3 | Saturday, February 6 2010 | 12:29