This question has come up before, and I think I've even asked it myself although I can't find that specific post right now. What exactly are the negative effects of having more than 1023 tiles in a level, counting animated tiles, and if there are some, how are they triggered? JCS warns against it, but JCS also says that the level will be unplayable in JJ2, which is manifestly untrue. Stijn and n0 both report success in ignoring that warning, and I've had similar experiences, but I think things have gone wrong at least once. So I'd like to figure out exactly what goes wrong.

Here's some additional information. Level files in JJ2 are divided into four data streams. The first data stream contains a list of every animated tile, 128 animated tiles long in 1.23 or earlier and 256 animated tiles long (I think) in TSF. The contents of the first data stream have no way of interacting with the number of the tiles in the tileset, so one needn't worry about them.

What's at issue is how tiles are referenced in the third data stream, the "dictionary," which specifies which tiles or animated tiles are used in each four-tile-wide "word" that can be placed in various layers. The details of the word/dictionary system don't matter here; all that's important is that tiles and animated tiles are referred to using shorts, which are two bytes (=sixteen bits) long.

00000000 00000000

There can be up to 1020 regular tiles in a 1.23 level, or 4090 in a TSF level. In 1.23, the red bits, which can represent any number from 0-1023, specify the tile, whereas TSF must use the green and blue blue bits as well. A flipped tile has the green (1.23) or orange bit (TSF) set to 1. Thus a flipped tile 0 will have value 1024 in 1.23, or 4096 in TSF.

Regular animated tiles, that is, animated tiles that don't break the supposed tile limit, also use the red bits (or red+green+blue in TSF). However, instead of starting from 0 like regular tiles, they end at 1023 (or 4095 in TSF) and work their way back down. In a level with three animated tiles, the first (uppermost in JCS) will be referred to by value 1021, the second by 1022, and the third by 1023. Or, in TSF, 4093 and 4094 and 4095. This fact is, moreover, utterly independent of the number of tiles in the tileset. In a 1.23 level with n tiles and m animated tiles, short values will look like this:

0 to (n-1): regular tiles
(1024-m) to 1023: animated tiles
1024 to (1024+n-1): flipped regular tiles
(2048-m) to 2047: flipped animated tiles

It's easy enough to see why it should be impossible to have excess animated tiles, since regular and animated tiles both compete for values within the red (or red+green+blue) bits. Up the number of animated tiles to five, and the first one (in 1.23) should use value 1019, which is the final regular tile value. However, there is a second strategy.

Excess animated tiles, ones above the animation limit, work entirely differently. The purple bit is set to 1, and the numbering starts over from 0, so, for instance, the ninth animated tile in a 1.23 level with 1020 regular tiles will have both the purple bit and the fourth red bit set to 1. Flipping works just the same as ever, set by the green bit in 1.23 or presumably the orange bit in TSF. Since the use of the purple bit (and note that the black bits are never used at all) puts these excess animated tiles on an entirely different numerical track, there is no way the number of a single short in the dictionary can ever be ambiguous. Within the context of the .j2l file, there appears to be absolutely no issue with having more than 1023 tiles, and JJ2 reads these purple-bit animated tiles without direct complaint.

So what's the problem? I'd love to see some levels with clearly reproducible errors. Such tilesets as Blasteria, Spacey Universe, or Mega Megatropolis, which have the maximum numbers of tiles allowed for their respective versions, are good sets to use for this kind of research.

1.23:

Simply copying the same animated tile to go up to JCS' strict limit of 128 animated tiles let me make some ugly lines on the 16-bit textured background (and only the 16-bit, textured background):

These lines appear only over certain colors. Each animated tile added over the limit seems to add one more color that the lines will appear over, and it's clearly in an order according to the palette. This seems to mean that at the aforementioned JCS cap, these lines appear over half the colors.

The only other effect I found offhand was that killing Jazz instantly skipped the death animation sequence. I have a gut feeling that trigger/destruct events will have something to do with all this, I'll continue experimenting.