JazzJackrabbit Community Forums
Page 2 of 6 1 2 3456
Show 40 post(s) from this thread on one page

JazzJackrabbit Community Forums (http://www.jazz2online.com/jcf/index.php)
-   General Jazz Jackrabbit Talk (http://www.jazz2online.com/jcf/forumdisplay.php?f=4)
-   -   JJ2 File Format Specifications (http://www.jazz2online.com/jcf/showthread.php?t=15059)

Cpp Apr 7, 2006 11:42 PM
Well I can send you some levels saved in 1.23 and 1.24 so that you can see the difference.
Also you could include a layer 3 on the VCR thing as well as make it display events as original sprites. I myself had some problems dealing with 32 players for theres not enough different colors that I could use for the dots.

Marijn Apr 9, 2006 02:51 AM
Quote:
Originally Posted by Neobeo
Well ok, this is a prototype ... differences are.
Well that chatlog test is a fancy program :D

Radium Apr 9, 2006 03:55 PM
=O

Wow. Release plz D=

Monolith Apr 9, 2006 05:32 PM
Looks like cheating. Or at least an undetectable unfair advantage.

Neobeo Apr 9, 2006 05:43 PM
Quote:
Originally Posted by Radium
=O

Wow. Release plz D=
No, because

Quote:
Originally Posted by Monolith
Looks like cheating. Or at least an undetectable unfair advantage.
The VCR was actually designed to test the capabilities of parsing J2L and J2T (back to topic!), and it has no plans of being released, unless as some sort of server tool. If you meant release the chatlog, which is completely harmless, that will probably come out eventually (except I no longer have the time and/or motivation to work on it).

Pako Apr 11, 2006 01:11 PM
Quote:
Originally Posted by Monolith
Looks like cheating. Or at least an undetectable unfair advantage.
Well, make this only usable for the server. This would be perfect to know where is everyone when:
1.) You are on an hotel, and someone entered on the "INCREDIBLE SEKRET SUPAH ELITE ROM!!!11" thing (Haphazy ;P). How to know that? With this program. Also useful on Ground Forces (especially on the Tower of Doom).

cooba Apr 11, 2006 01:13 PM
This could be too much of a hassle, but how about VCR diplays layer 4 data only if the gametype is treasure?

Marijn Apr 30, 2006 08:14 AM
Code:
//decodejj2t.cs

using System;
using System.Runtime.InteropServices;


unsafe class app
{
        char[] input;
        char *output;
        int CompressedSize;
        int UncompressedSize;


        static void Main()
        {       
        app a = new app();
        a.Decode();
        Console.ReadLine();
        }

        public unsafe void Decode()
        {
        string (-) = "Let us attempt to compress this string";
        input = (-).ToCharArray();
       
        UncompressedSize = input.Length;
        CompressedSize = (int)((float)(UncompressedSize * 1.01 ) + 12);

        compress2(output, &CompressedSize, input, UncompressedSize, 9);

 
        Console.WriteLine("Done..");       
        }

[DllImport("zlib.dll")]
static extern long compress(ref object dest, ref object destLen, ref object src, long srcLen);
[DllImport("zlib.dll")]
static extern long compress2( char* dest, int* destLen, char[] src, long srcLen, int Level);
[DllImport("zlib.dll")]
static extern long uncompress(ref object  dest, ref object  destLen, ref object src, long srcLen);
[DllImport("zlib.dll")]
static extern long crc32(long crc, ref object  buffer, long bufferLen);

}
AAh.. Supid formats.. The C# compiler complaints about this error:

decodejj2t.cs(30,20): error CS0212: You can only take the address of an unfixed expression inside of a fixed statement initializer

decodejj2t.cs(30,20): error CS0212: Alleen het adres van een niet-vaste
expressie kan binnen de initialisatiefunctie van een vaste instructie
worden gebruikt

I need to use the keyword "fixed" but.... Where :'(

Cpp Apr 30, 2006 02:47 PM
Is that CLI you're using?

Marijn May 1, 2006 01:42 AM
No, C#.
My problem is because I love te managed framework, I'd never had a reason to use the unsafe keyword.. :'(


Quote:
Originally Posted by Neobeo
If you meant release the chatlog, which is completely harmless, that will probably come out eventually (except I no longer have the time and/or motivation to work on it).
Just release :D

Onag Aug 15, 2006 07:21 PM
You can ban me for resurrecting this, but...

Has anyone actually tried decompressing any of the files using these file formats? Every time I try to do it with a .j2t, I run into a problem with the Data1 block. Specifically, When I inflate/decompress the block of 4153 bytes, I fill up the 27652 bytes it's supposed to be with 4 bytes still remaining in the compressed block.

For example:

CData1 = 4153
UData1 = 27652

So, I allocate an array of 4153 bytes and copy the CData1 block into it. I then use a zlib library (a managed/.NET one called ICSharpCode.SharpZipLib) to inflate/decompress that data into another array of 27652 bytes.

The 27652 byte array is filled up with uncompressed data, but there are still 4 bytes remaining in CData1 that have not yet been touched.

The header seems to be right, and all of the other blocks work fine, but I can't figure out what is going on with those 4 bytes.

Anyway, I'm wondering if anyone else has been able to get this working. If so, I'll know the problem is either in my code, or in the way the zlib library is working.

-Nag

PhAyzoN Aug 15, 2006 09:28 PM
Wow dude. This stuff is great (for the community)!

EDIT: Woah, old thread :s

Cpp Aug 15, 2006 10:00 PM
Onag: I've done it with J2L format in C++ with zlib1.dll and it works like a charm. Decompiles the level into 4 streams allowing me to manually edit them and then recompile them into a modified J2L which runs fine. Don't know about the 4 bytes you're mentioning there as I only care for a working decompress/recompress. Might be CRC32?

EDIT: Here's the code I use to decompress:
Code:
// Uncompress the data pDataComp => pDataUncomp
bool CJ2FD::UncompressData() {
       
        int i;

        // Check if all compressed data pointers exist
        for (i = 0; i < 4; i++)
                if (pDataComp[i] == 0)
                        return false;
       
        // Check the compressed data file sizes
        for (i = 0; i < 4; i++)
                if (!(Header.CData[i] > 0))
                        return false;

        //Allocate memory for the uncompressed data
        for (i = 0; i < 4; i++) {
                if (pDataUncomp[i] != 0) delete[] pDataUncomp[i];
                pDataUncomp[i] = new unsigned char[Header.UData[i]];
        }

        // Finally uncompress the data
        for (i = 0; i < 4; i++)
                if (uncompress(pDataUncomp[i], &Header.UData[i], pDataComp[i], Header.CData[i]) != Z_OK)
                        return false;

        return true;
}
The pDataComp[4] are pointers to 4 char arrays where each holds the compressed data of a single stream (CData). The function above will decompress the data into pDataUncomp[4], pointers to 4 arrays of uncompressed data.

Code:
unsigned char*        pDataComp[4];                        // Pointer array for compressed data
unsigned char*        pDataUncomp[4];                        // Pointer array for uncompressed data

Onag Aug 16, 2006 08:24 AM
Thanks Overlord.

I think the problem lies in way the zlib library I'm using is working. Sometimes, it leaves 4 bytes, sometimes it doesn't. The uncompressed data *appears* to be intact, though I haven't tried using all of it yet.

I'm going to continue looking for a C# zlib that actually works. In the mean time, I just close my eyes and ignore the extra bytes. Hopefully things will work out.

-Nag

Neobeo Jan 21, 2007 03:52 PM
Four-month revival, but I was just wondering whether anyone has been using this information. Looking back, there are some incomplete stuff, inconsistencies and mistakes in my original specs. I was thinking of updating them, but it is probably pointless if no one takes a second look.

Alternatively, I have been working on a set of C++ libraries that allows one to edit JJ2 files. (J2L class based on Overlord's code) These are used in the new JSD and J2L editor, and some other secret programs. If there's enough interest I'm willing to release these libraries, which can be useful for the casual programmer. Or if there are more VB programmers or so, I could release them in the form of a VB DLL ;\.

Cpp Jan 21, 2007 04:27 PM
Always keep your posts up to date. ;)
I did use this thread as a reference quite a lot while working on the J2LC code and there will likely be such time again.

FQuist Jan 21, 2007 04:48 PM
J2LC code o.o

Cpp Jan 22, 2007 01:32 AM
That's short for Jazz 2 (1.24 to 1.23) Level Converter (has nothing to do with the level group). It was supposed to open J2L files only, but ended up being able to open all related formats. And so I named it C_J2FF as Class Jazz 2 File Format.

Marijn Jan 23, 2007 10:30 AM
I can't seems to start with C#,
how to get the byte* array, to an byte[] array, and so on.

Can someone give me some pointers?

n0 Jan 24, 2007 01:06 PM
Wait, it can handle .lev files, OL?

Neobeo Jan 24, 2007 03:02 PM
Nope, it doesn't. In fact, I'm interested in .lev files. Where can I find these?

Violet CLM Jan 24, 2007 06:43 PM
They are included in 1.00g (and presumably h).

EDIT: .lev is a common extension for lazy people. The actual format is usually different from game to game, though. The only relevant .lev is the JJ2 .lev.

EDIT #2: Umm, yes. Thank you for quoting the response I made to Drmoo in response to Drmoo.

Dermo Jan 25, 2007 12:05 PM
LEV is the file extension for the Level file associated with NetHack 3.x.

Cpp Jan 25, 2007 05:25 PM
Those "lev" files take a noticeable amount of extra space compared to regular "j2l". Besides its an outdated format, doesn't seem to be compressed afaik.

ThunderPX Jan 26, 2007 06:54 AM
Quote:
Originally Posted by Drmoo
LEV is the file extension for the Level file associated with NetHack 3.x.
Quote:
EDIT: .lev is a common extension for lazy people. The actual format is usually different from game to game, though. The only relevant .lev is the JJ2 .lev.

Torkell Feb 14, 2007 04:04 AM
I'm going to have a try at sticking this lot into the ERE. The description looks pretty good, so I'm going to put it in mostly as-is, just tidying up bits where it makes sense for the wiki.

Edit: done the three file specifications (see J2A File Format, J2L File Format and J2T File Format). I'm just about to add the zlib info.

Edit: zlib done. These pages need to be linked into the main wiki, but should do for now.

Neobeo Feb 14, 2007 06:29 AM
Yay, this gives me a lot more incentive at trying to fix up some minor errors and missing information. Keep it up.

Cpp Feb 15, 2007 06:18 AM
I'm going to post my j2l/j2t (de)compiler source code (CJ2FF Class) here in the near future so feel free to integrate that as well.

~Ol

EDIT: Oh and you might want to update the the J2L Data1 with this info:

short JCSCameraX;
short PasswordRelated1;
short JCSCameraY;
short PasswordRelated2;
char PasswordLayerFlags;
char AmbientLightningMin;
char AmbientLightningStart;
short NumberOfAnimatedTiles;
char HoriOrVertSplitScreen;
char IsThisMultiplayerLevel;
long BufferSize;
char LevelName[32];
char Tileset[32];
char BonusLevel[32];
char NextLevel[32];
char SecretLevel[32];
char MusicFile[32];
char HelpString[16][512];

Neobeo Feb 15, 2007 09:42 PM
Oh don't worry, I have far more complete specifications that that. It's just a matter of whether I will end up updating or not.

Also, what do you think of a TSF - 1.23 Level converter? (I have such a program, but never quite released it because it was a half-assed job)

Grytolle Feb 15, 2007 10:57 PM
I'm quite sure such a program would be greatly appreciated

Cpp Feb 16, 2007 01:35 AM
As promised, here is the (de)compiler source code. Have fun.

http://downlink.lordprime.com/jazzja.../code/j2ff.zip

Cataphract Feb 16, 2007 11:19 AM
What about the really cool stuff, something like the layer 4+tileset parser I've seen?
I shouldn't mind getting hold of that code :)

n0 Feb 16, 2007 08:24 PM
Hot stuff Neobeo and Overlord... and thanks to Torkell for the wiki upload.

Between the three of you, I have regained interest in cracking this game of ours.

Cataphract Feb 17, 2007 09:15 PM
Quote:
Originally Posted by Neobeo (Post 396745)
Oh don't worry, I have far more complete specifications that that. It's just a matter of whether I will end up updating or not.
If you do have more complete specifications, it would certainly be very helpful if you shared them.

With the ones currently on this thread, I'm quite sure that the moment I tried to do something a bit more complicated I should end up in a dead end and have to start poking around with a binary comparison program, a task for which I have neither the time -- the second semester is near --, nor the inclination -- debugging code is already boring enough.
Therefore, anyone would be reluctant in investing his time with such uncertain results.

The (marked) incompleteness of j2t specification is compensated by the open-source implementation of the tileset extractor, but the j2l specification or the relation between the two have no reference implementations.

Obviously, incomplete documentation is quite preferable to nothing, however, I should point more emphasis is unfortunately given to side issues such as the interface with zlib (IMO a brief reference to the relevant functions should suffice), rather than the specification per se.

Cataphract Feb 21, 2007 11:33 AM
On a related note, I've uploaded an implementation in C of a layer extractor.

Neobeo May 1, 2007 06:26 AM
Recently noticed a surge in people interested in 1.10o (version 0x0200) J2L format. Unfortunately I have not yet researched this file format, so it would be great if someone could provide this information (and/or update it to the ERE).

Violet CLM May 1, 2007 07:10 AM
It's sufficiently similar that if you add the JJ2 header at the start of the file and modify the checksum to reflect the new filesize, 1.23 will be able to run it.

Violet CLM Dec 20, 2008 04:13 PM
Quote:
Originally Posted by Neobeo (Post 354460)
CRC Checking

Finally we get to the crc32 stage. All (or most) of the JJ2 files contain an internal (and some even external) CRC check to verify that the file is not corrupted in any way. Seeing how most programmers are lazy, they will probably skip the CRC mechanism and just assume that file is valid, but it will be included here just for completeness anyway.

Declare Function crc32 Lib "zlib.dll" (ByVal crc As Long, ByRef buffer As Any, ByVal bufferLen As Long) As Long

or, in C++ format,

uLong crc32 (uLong crc, const Bytef *buf, uInt len);

As you can see, the crc32 function takes 3 arguments. The first one is a previous crc value, in case we do the CRC check in chunks. For simplicity, we will always use CRC on the whole buffer at once, which means we leave CRC as 0. buf/buffer is the buffer, and len/bufferLen is the length of the buffer. If you’ve fully understood the uncompress and compress2 functions then there is no need for an example here, since the buffer and length arguments are used here in exactly the same way as before.
How is this applied for actually working with, say, .j2l files? JJ2 won't run with an improper CRC long, but I'm not sure what buffer I'm supposed to be using, if .j2l files have four separate zlib streams and all sorts of other data.

Ricerind Dec 20, 2008 04:25 PM
It's a running CRC of all four compressed streams.

Violet CLM Dec 21, 2008 12:10 PM
Sorry, but could you be more specific? I'm new to the concept, and Google offers very few hits for "running CRC." What is the implementation? CRC the first block, then append the second and CRC again, then...? or what?


All times are GMT -8. The time now is 05:21 PM.
Page 2 of 6 1 2 3456
Show 40 post(s) from this thread on one page

Powered by vBulletin® Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
JCF © 2001-Infinity Jazz2Online