Page 1 of 2

Quick C1/C2 finds & facts

Posted: Wed Jun 23, 2010 4:54 pm
by Toshiba-3
To list everything we find about C1 and C2.
Little tips, stuff, etc.

Quick C1/C2 finds & facts

Posted: Wed Jun 23, 2010 4:56 pm
by Toshiba-3
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).

Quick C1/C2 finds & facts

Posted: Wed Jun 23, 2010 4:59 pm
by Toshiba-3
[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.

Quick C1/C2 finds & facts

Posted: Wed Jun 23, 2010 5:04 pm
by Toshiba-3
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.

Quick C1/C2 finds & facts

Posted: Wed Jun 23, 2010 5:32 pm
by Toshiba-3
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).

Quick C1/C2 finds & facts

Posted: Wed Jun 23, 2010 5:39 pm
by Toshiba-3
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...

Quick C1/C2 finds & facts

Posted: Wed Jun 23, 2010 5:41 pm
by Toshiba-3
Some powerups move on their own and these are the ones ranging from 66 to 88.

Quick C1/C2 finds & facts

Posted: Fri Jun 25, 2010 11:37 am
by Toshiba-3
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.

Quick C1/C2 finds & facts

Posted: Sat Jul 24, 2010 9:11 pm
by Toshiba-3
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.

Quick C1/C2 finds & facts

Posted: Sat Jul 24, 2010 9:16 pm
by Toshiba-3
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.

Quick C1/C2 finds & facts

Posted: Fri Jan 14, 2011 4:16 pm
by Harmalarm
Be careful with using Photoshop when modding carmageddon 1. For some unknown reason, PS deletes or either adds meta-data into the BMP files. As soon as you import in carmageddit, you will get an error message and the texture will shift a couple of pixels.
To avoid this, simply re-save your BMP with an alternative program. I used XNview to fix the files. Simply open up your file and hit the save button.

Quick C1/C2 finds & facts

Posted: Wed Jun 29, 2011 9:55 pm
by Toshiba-3
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.

Re: Quick C1/C2 finds & facts

Posted: Fri Jun 01, 2012 12:46 pm
by Toshiba-3
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!

Re: Quick C1/C2 finds & facts

Posted: Fri Jun 01, 2012 1:06 pm
by Harmalarm
Game freezing when opponents fall off your map? Lower your YON!
OR

add an extra opponent path node, high above the map (500 units). Then add an extra opponent path segment, and link the new node to the first node.

(The game freezes because opponents are spawned inside the players view. This trick will prevent this.)

Re: Quick C1/C2 finds & facts

Posted: Tue Jun 19, 2012 9:43 pm
by Toshiba-3
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.

Re: Quick C1/C2 finds & facts

Posted: Thu Dec 08, 2016 3:57 pm
by Toshiba-3
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...


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

Re: Quick C1/C2 finds & facts

Posted: Thu Dec 08, 2016 9:13 pm
by Razor
I was under the impression that the game only handles resolutions in powers of two? Does it not go all haywire with those extra two pixels?

Re: Quick C1/C2 finds & facts

Posted: Wed Dec 14, 2016 8:49 pm
by Toshiba-3
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 :mad:

Re: Quick C1/C2 finds & facts

Posted: Fri Dec 16, 2016 8:44 am
by Harmalarm
damn, that's a pity :sad:

Re: Quick C1/C2 finds & facts

Posted: Sat Dec 17, 2016 12:35 pm
by Toshiba-3
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:

Re: Quick C1/C2 finds & facts

Posted: Tue Dec 20, 2016 5:20 pm
by Harmalarm
Wow, where did you find all that motivation? :thumbsup:

Never expected the crushing to be instanced too. And when instancing on detachables is also not really working it makes it a bit useless on cars if you ask me. Unless you have super highly detailed wheels and start using the parenting system if I understand correctly.

It's good to know about the actor names for the wheels such as FLWHEEL.ACT etc. I think it gave me a lot of confusion when making the car export script, and now I know why.

Splitting dat files... never thought of that. Is there anything beneficial about this?

Nice testing machine :supercrazy:

Re: Quick C1/C2 finds & facts

Posted: Wed Dec 21, 2016 7:52 am
by Razor
Harmalarm wrote:Splitting dat files... never thought of that. Is there anything beneficial about this?
Also wondering this, other than for organisation, what benefits would this have, if any?

Re: Quick C1/C2 finds & facts

Posted: Wed Dec 21, 2016 6:03 pm
by Toshiba-3
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.
Unless you have super highly detailed wheels and start using the parenting system if I understand correctly.
Precisely the case I'm working on :grin: 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.

Re: Quick C1/C2 finds & facts

Posted: Fri Dec 30, 2016 2:54 pm
by Toshiba-3
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.

Re: Quick C1/C2 finds & facts

Posted: Fri Nov 24, 2017 1:17 am
by Toshiba-3
Some stuff :sneutr:

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

Code: Select all

WIPERS.MAT
	constant
	rock
		harmonic		// mode
		2			// period
		25			// angle
		20,20		// x,y center - might actually be 0.2,0.2 - or both work
	no lighting thank you
	no animation either i'm fine really
Actually not used by the game, but just for the record here's how the funk lighting stuff was supposed to be written:

Code: Select all

NEON.MAT
	constant
	no effect this time
	linear, harmonic, flash, controlled, absolute or continuous		// modes
		2			// period
		0.0,0.1,0.1		// ambient min, direct min, specular min
		0.8,0.1,0.1		// ambient max, direct max, specular max
	no animation
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.

Re: Quick C1/C2 finds & facts

Posted: Wed May 30, 2018 11:15 pm
by Toshiba-3
Copying this here as it doesn't seem to be anywhere in the board (from C2S' track making tutorial):
Unit conversions (CU = Carmageddon unit, could be also BRU = BRender unit)

1 CU = 6 meters
1 meter = 0.17 CU

Re: Quick C1/C2 finds & facts

Posted: Mon Nov 12, 2018 2:16 pm
by Toshiba-3
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.

Re: Quick C1/C2 finds & facts

Posted: Mon Nov 12, 2018 2:38 pm
by Toshiba-3
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.

Re: Quick C1/C2 finds & facts

Posted: Wed Nov 21, 2018 12:21 am
by Toshiba-3
400 is the limit of pixelmaps or materials loaded via a race's TXT file (toward the start of the file where PIX TAB MAT DAT and ACT files are loaded, the map and splashes don't count for example).

And just to be clear: I don't mean 400 .MAT or .PIX files (unless they each have only one entry? haven't tested that). I mean 400 total materials or pixelmaps packed into a handful of MAT of PIX files as usual.

Re: Quick C1/C2 finds & facts

Posted: Wed Jul 31, 2019 12:12 pm
by Toshiba-3
the -spamfritter argument for DOS Carmageddon simply allows 2 more megabytes of memory.

Re: Quick C1/C2 finds & facts

Posted: Wed Jul 31, 2019 4:05 pm
by Toshiba-3
Some limits:

Max pixelmaps in 1 file : 200
Max shade tables in 1 file : 50
Max materials in 1 file : 200
Max models in 1 file : 2000

Max pixelmaps for the player's car : 40
Max shade tables for the player's car : 2
Max materials for the player's car : 40
Max models for the player's car : 30

Max pixelmaps for the opponents : 300
Max shade tables for the opponents : 50
Max materials for the opponents : 500
Max models for the opponents : 200

Max pixelmaps per level : 400
Max shade table per level : 50
Max materials per level : 400
Max models per level : 1000

AFAIK the limits above don't take resources loaded in REGistry (I mean it's possible to use more than 400 pixelmaps in a track if the excess is placed in REG/PIXELMAPS).
Haven't stumbled upon limits for resources in Registry (besides the allocated memory I guess).

Max pixelmaps for pedestrians (for the whole of 'em during a race) : 500
Max shade tables for peds : 10

Max lollipops (that includes peds..!) to be processed within drawing distance from the camera : 100

Re: Quick C1/C2 finds & facts

Posted: Thu May 21, 2020 3:26 pm
by Toshiba-3
New little bit uncovered by Harm and Errol:
If a pickup (powerup) model is used by several pickup actors, including the rotating ones (powerup number #66-85), they will ALL rotate.

So I tested a bit more, and if that same model is also used for a noncar or non-preprocessed actor, it will also rotate..! And the collision will be in sync. Finally as this effect is applied on the model rather than on the actors the latter can be transformed without the animation resetting it.

The downside ofcourse is that the effect is limited to that hardcoded rotation speed, though I imagine it could be possible to cumulate the trick onto itself.

Re: Quick C1/C2 finds & facts

Posted: Wed Jan 03, 2024 11:45 pm
by Toshiba-3
From Mastro:

C1 and C2 software mode can only correct perspective on materials using textures with the following sizes:
64x64, 128x128, 256x256, and 1024x1024.

This also applies to dithering (still while in software rendering mode).

Re: Quick C1/C2 finds & facts

Posted: Thu Jan 04, 2024 1:51 am
by Mastro 666
Toshiba-3 wrote: Wed Jan 03, 2024 11:45 pm From Mastro:

C1 and C2 software mode can only correct perspective on materials using textures with the following sizes:
64x64, 128x128, 256x256, and 1024x1024.

This also applies to dithering (still while in software rendering mode).
This is only applicable to C1 maps.

I converted a bunch of c1 cars with weird sizes without the shaky and wobbly effect. Look at this crap:

https://youtu.be/62kYPvWJ9zs

Image

Re: Quick C1/C2 finds & facts

Posted: Thu Jan 04, 2024 10:53 pm
by Toshiba-3
Mastro 666 wrote: Thu Jan 04, 2024 1:51 amThis is only applicable to C1 maps.
When I ran my test, it was on a car..! What's the polycount on that car in your video? Maybe the topology is so well distributed the wobble effect isn't noticeable? Is that mod available or is it WIP?

Because if really these odd sizes don't break the perspective correction, we really have to understand what's going on !