Dear returning Carmageddon fans ![Image]()
These last years, the CWA Board assimilated what was archived from many old Carmageddon forums, including the whole of the Official Carmageddon.com Forums.
If you wish to merge any previous account you might have had with your new or existing CWA account, don't hesitate to reach out to us !
![Image](https://www.cwaboard.co.uk/images/smilies/beer.gif)
These last years, the CWA Board assimilated what was archived from many old Carmageddon forums, including the whole of the Official Carmageddon.com Forums.
If you wish to merge any previous account you might have had with your new or existing CWA account, don't hesitate to reach out to us !
Quick C1/C2 finds & facts
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
To list everything we find about C1 and C2.
Little tips, stuff, etc.
Little tips, stuff, etc.
Tags:
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
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).
The TIFFX folder (C2) is only used to store 256 colors TIFF files and will only generate 8bit PIX files (PIX8).
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
[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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
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).
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).
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
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...
However you can actually use this option to quickly apply a material on every long quad you didn't bother texturing...
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
Some powerups move on their own and these are the ones ranging from 66 to 88.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
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.
Just stick to clean well defined transparent areas.
- Harmalarm
- road raged psycho
- Posts: 1302
- Joined: Tue May 13, 2008 3:56 am
- Location: Den Haag, Holland
- Contact:
Quick C1/C2 finds & facts
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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Quick C1/C2 finds & facts
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.
To make a car shake without having to use a groove on the whole car, simply apply smaller angular momentum proportions.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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!
- Harmalarm
- road raged psycho
- Posts: 1302
- Joined: Tue May 13, 2008 3:56 am
- Location: Den Haag, Holland
- Contact:
Re: Quick C1/C2 finds & facts
ORGame freezing when opponents fall off your map? Lower your YON!
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.)
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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.
So 256x512 won't load, but 256x514 will work. You get the idea.
Go figure... Carmageddon, ladies and gentlemen...
![Very Mad :supermad:](./images/smilies/icon_evil.gif)
- Razor
- Stomping-on-Kittens
- Posts: 3431
- Joined: Sat Dec 01, 2007 6:38 pm
- Location: Beaver City
- Contact:
Re: Quick C1/C2 finds & facts
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?
[ Razor @ Carmageddon Webmasters Alliance Network ] [ My Downloads ] [ My Carma Items ] [ Conversion lists ]
To download the BETA Mod and more information on my other work, visit me @ https://razor.cwaboard.co.uk
To download the BETA Mod and more information on my other work, visit me @ https://razor.cwaboard.co.uk
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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 :mad:](./images/smilies/icon_mad.gif)
![Mad :mad:](./images/smilies/icon_mad.gif)
- Harmalarm
- road raged psycho
- Posts: 1302
- Joined: Tue May 13, 2008 3:56 am
- Location: Den Haag, Holland
- Contact:
Re: Quick C1/C2 finds & facts
damn, that's a pity ![Sad :sad:](./images/smilies/icon_e_sad.gif)
![Sad :sad:](./images/smilies/icon_e_sad.gif)
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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:
- 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:
- Attachments
-
- Carma2_HW 2016-12-17 12-32-38-67.jpg (94.09 KiB) Viewed 21444 times
- Harmalarm
- road raged psycho
- Posts: 1302
- Joined: Tue May 13, 2008 3:56 am
- Location: Den Haag, Holland
- Contact:
Re: Quick C1/C2 finds & facts
Wow, where did you find all that motivation?
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![Crazy eyes! :supercrazy:](./images/smilies/new_Eyecrazy.gif)
![Thumbs up :thumbsup:](./images/smilies/up.gif)
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
![Crazy eyes! :supercrazy:](./images/smilies/new_Eyecrazy.gif)
- Razor
- Stomping-on-Kittens
- Posts: 3431
- Joined: Sat Dec 01, 2007 6:38 pm
- Location: Beaver City
- Contact:
Re: Quick C1/C2 finds & facts
Also wondering this, other than for organisation, what benefits would this have, if any?Harmalarm wrote:Splitting dat files... never thought of that. Is there anything beneficial about this?
[ Razor @ Carmageddon Webmasters Alliance Network ] [ My Downloads ] [ My Carma Items ] [ Conversion lists ]
To download the BETA Mod and more information on my other work, visit me @ https://razor.cwaboard.co.uk
To download the BETA Mod and more information on my other work, visit me @ https://razor.cwaboard.co.uk
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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.
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.
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 onUnless you have super highly detailed wheels and start using the parenting system if I understand correctly.
![Very Happy :grin:](./images/smilies/icon_e_biggrin.gif)
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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.
![Neutral :sneutr:](./images/smilies/shotgun/neutral.gif)
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
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
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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.
This basicaly renders these materials full bright and can be used for neons etc.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
the -spamfritter argument for DOS Carmageddon simply allows 2 more megabytes of memory.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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
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
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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.
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.
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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).
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).
- Mastro 666
- motorised death
- Posts: 968
- Joined: Thu Jan 26, 2006 6:24 pm
- Contact:
Re: Quick C1/C2 finds & facts
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](https://i.postimg.cc/xCJzj6mg/untitled.png)
- Toshiba-3
- BRender Actor
- Posts: 5515
- Joined: Sun Jun 08, 2003 12:14 am
- Location: MagnaChem Data Unit
- Contact:
Re: Quick C1/C2 finds & facts
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 !
Check who’s online
Users browsing this forum: No registered users and 229 guests