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.

Originally Posted by Neobeo

Well ok, this is a prototype ... differences are.

Well that chatlog test is a fancy program

Originally Posted by Neobeo

http://www.files.bz/files/5589/vcrtest1.png
http://www.files.bz/files/5589/vcrtest2.png
http://www.files.bz/files/5589/vcrtest3.png
http://www.files.bz/files/5589/vcrtest4.png
http://www.files.bz/files/5589/vcrchat1.png
http://www.files.bz/files/5589/vcrchat2.png
http://www.files.bz/files/5589/vcrchat3.png
http://www.files.bz/files/5589/vcrchat4.png

=O

Wow. Release plz D=

Looks like cheating. Or at least an undetectable unfair advantage.

Originally Posted by Radium

=O

Wow. Release plz D=

No, because

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

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

This could be too much of a hassle, but how about VCR diplays layer 4 data only if the gametype is treasure?

//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 :'(

Is that CLI you're using?

No, C#.
My problem is because I love te managed framework, I'd never had a reason to use the unsafe keyword.. :'(

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

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

Wow dude. This stuff is great (for the community)!

EDIT: Woah, old thread :s

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:

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

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

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

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 ;\.

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.

J2LC code o.o

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.

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?

Wait, it can handle .lev files, OL?

Nope, it doesn't. In fact, I'm interested in .lev files. Where can I find these?

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.

LEV is the file extension for the Level file associated with NetHack 3.x.

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.

Originally Posted by Drmoo

LEV is the file extension for the Level file associated with NetHack 3.x.

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.

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.

Yay, this gives me a lot more incentive at trying to fix up some minor errors and missing information. Keep it up.

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];

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)

I'm quite sure such a program would be greatly appreciated

As promised, here is the (de)compiler source code. Have fun.

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

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

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.

Originally Posted by Neobeo

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.

On a related note, I've uploaded an implementation in C of a layer extractor.

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

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.

Originally Posted by Neobeo

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.

It's a running CRC of all four compressed streams.

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?