Ok, this is what you have to do in the hex editor: Open the PNG Select the first 4 bytes (89 50 4E 47) CTRL + C Place the cursor before the first byte (left from 89) CTRL + V Save file as *.OZP If you don't want to edit the files manually, you can let AceWell's bms scripts do the work for you. First...

Deneky wrote:Now I plan to edit that png img and if I want to add back in that file how I can add ?

Dude, you only have to reverse the steps. I give you a hint: instead of deleting 4 bytes you'll have to add 4 bytes.
You can do it, I believe in you!

But isn't you already declare yoffset before horOffset? I'm not sure exactly what horOffset means but it doesn't quiet matter if one can make a new font. xOffset, yOffset and horOffset were my first guess for the last 3 values but I guess I was wrong :) If you figure out the true meaning, I can cor...

I pretty sure I mixed up the offsets (x/y/hor).
The value that is currently named horOffset is high for characters like "." and "," so I think that's the actual y-offset, is that possible?

@adol365: Just a quick question. At the current state the program outputs this data:
https://www.mediafire.com/?7acvohe2y3tcb79
Is this sufficient for you to edit the font? If yes, I could start to write the repacker.

adol365 wrote:Oh, did you open it as a raw file from Photoshop? Is there a specific height?

Actually I wrote a simple java program that converts the font file into a raw image.

The font characters are simple 8-bit grayscale bitmaps with a fixed size of 19x36 pixels per character.
Here's a screenshot of the characters in main_font.unpack, mapped onto a 1024 pixels wide texture atlas:

Here's what I found out about the file format: // main_font_sdw_vita.unpack byte header[12]; // it's the same in both .unpack files int characterCount; struct charInfo { short keycode; byte zero; // always zero byte xOffset; // not sure about the offsets byte yOffset; byte horOffset; byte charWidth;...

Thanks for the background info. That sucks, hopefully they release those tools soon. And here's a little update about the Flummery tool: Although I somehow managed to import the model, most of the textures just don't show up. I had to ignore some data that wasn't present in previous versions of the ...

I (or rather we) should have googled the file format first :) As it turns out there's a program called Flummery that can import Carmageddon files but unfortunately Max Damage isn't supported (yet). However, I checked the source code of the MDL and CNT formats and they are exactly the same except for...

I believe that the hierarchy of the models (and the relative position of the submodels) can be found in car.CNT. c_body.MDL is only the chassis @0xB2: face count = 23256 struct face { int unknown; // always 0 int index1; int index2; int index3; } @0x5AE36: vertex count = 23441 struct vertex { float ...

The .zad file is a simple zip.
Inside there are a couple of files, MDL = 3D model, TDX = texture, and some other file types.

I only had a quick look at c_body.MDL, haven't converted the faces yet, vertices only:

I used TextureFinder to figure out the format of the *.g1t PS3 files, the PSV files however have a different texture format. Don't know how what *.phyre files are but I found this document which looks like an unpacked phyre file:
http://pastebin.com/x11i11p6

But how i can use it? The viewer is just to see and The decompliler starts, then ends, but nothing happens. Decompiler.exe is a console program that means you would have to run it from the command shell (cmd.exe) and pass the input file and output directory as arguments. But you don't have to care ...