KarlosTKG now on GitHub

[Karlos]

Fixed up the highspec version of level A (with the PVS edit and control point routing improvements) to the misc/redesign branch.

[HornBeamSoft]

This map eX_TKG-A_beta1_q1 is really good.
Looks almost like original. And works with OpenGL quake.
It is really nice.

[abu_the_monkey]

Originally Posted by Karlos

Fixed up the highspec version of level A (with the PVS edit and control point routing improvements) to the misc/redesign branch.

did you push this to git?

[Karlos]

Originally Posted by abu_the_monkey

did you push this to git?

Yes, to the misc/redesign branch. The Lowspec version is probably buggered as all the control point stuff needs an update.

Looks like I committed but didn't push. Done.

[abu_the_monkey]

cool, off to check it out

[abu_the_monkey]

Originally Posted by Karlos

It might be a challenge to add this fix to the high spec version because I think level A is out of zones.

what is it that actually imposes this 256 zones per level limit in the game engine?

what I am asking I guess is if I double the zone limit in the editor what would happen? we already extended the point limit from 600 to 800 with no side effects.
was it just so it fit in 2 meg? or is there a real brick wall reason?

[Karlos]

Originally Posted by abu_the_monkey

what is it that actually imposes this 256 zones per level limit in the game engine?

what I am asking I guess is if I double the zone limit in the editor what would happen? we already extended the point limit from 600 to 800 with no side effects.
was it just so it fit in 2 meg? or is there a real brick wall reason?

The ZoneID field in the structure is a word and it's almost always a word wherever it is ref'd. However, there are other data structures which likely don't grow linearly with node count. There is a much smaller limit on Control Points, for instance, probably because the potential connection graph between them grows as the square. There may also be other contexts in which the zone is indexed by a byte.

I would suggest making a branch of the game and editor to explore this limit.

[abu_the_monkey]

I might have a bit of time to try this over the weekend.

[Karlos]

Originally Posted by abu_the_monkey

I might have a bit of time to try this over the weekend.

A little something for the weekend, is it sir? Ooh. Suits you, sir.

[Karlos]

Hmm, still got a couple of wallhumpers on the command deck. I mean I know they're a funny bunch up there but that probably needs fixing...

[abu_the_monkey]

Ooh!

so a very quick and dirty test and nothing broke too bad. levels loaded and played ok ish. some graphical glitches (hall of mirrors, etc) maybe there is some mileage in this after all?

[Karlos]

Originally Posted by abu_the_monkey

Ooh!

so a very quick and dirty test and nothing broke too bad. levels loaded and played ok ish. some graphical glitches (hall of mirrors, etc) maybe there is some mileage in this after all?

Definitely. Be warned though that there could be some very unforeseen consequences.

Ah dark brown cobblestone. I will never understand it. Almost as if secretly an entirely different game was planned.

[abu_the_monkey]

for sure there will be pitfalls ahead

this was, like I said, just a quick and dirty test just doubling the max zone limit and the work memory and buffer space in LevelED.

[grond]

Originally Posted by Karlos

There may also be other contexts in which the zone is indexed by a byte.

The 68k processors don't have a byte-index address mode, the smallest index is 16 bits. Of course, if the index gets loaded as a byte and then used as a 16bit index silently or explicitly typecasting it, there might be a hard limit in the code but that should be easy enough to fix. Furthermore, using a 16bits index wouldn't make the code any slower since that is what the processor does anyway.

[Karlos]

Originally Posted by grond

The 68k processors don't have a byte-index address mode, the smallest index is 16 bits. Of course, if the index gets loaded as a byte and then used as a 16bit index silently or explicitly typecasting it, there might be a hard limit in the code but that should be easy enough to fix. Furthermore, using a 16bits index wouldn't make the code any slower since that is what the processor does anyway.

That's true for (scaled) indirect index addressing modes but there could be contexts in which the byte value is just added directly to something which only expecting a 0-255 value. I haven't checked too deeply yet mind.

[Karlos]

Changes pushed to the misc/redesign branch.

@abu_the_monkey - you know what they are. Try to find it.

[grond]

Originally Posted by Karlos

That's true for (scaled) indirect index addressing modes but there could be contexts in which the byte value is just added directly to something which only expecting a 0-255 value. I haven't checked too deeply yet mind.

That would be very strange because in my opinion this would require an overflow into the upper 24 or 8 bits which would make an add.b unusable for the operation. For address registers (ADDA instruction) there is no byte operand at all.

The only (quite bizarre but hey...) case I could come up with that would result in a byte-size limitation on the 68k would be to have an array aligned to a 256-byte boundary and then somehow access that through a move.b into an index register. But then there wouldn't be any scaling at all and you'd end up with only 64 elements in the array.

[Karlos]

Originally Posted by grond

That would be very strange because in my opinion this would require an overflow into the upper 24 or 8 bits which would make an add.b unusable for the operation. For address registers (ADDA instruction) there is no byte operand at all.

Addresses aren't always calculated in address registers. I've seen code that does several integer operations in a data register, then adds that data register to an address register for use.

In any case, experimentation is the key. It sounds like it might be safe anyway.

[grond]

Originally Posted by Karlos

In any case, experimentation is the key. It sounds like it might be safe anyway.

I wasn't posting for the sake of argument but trying to be encouraging. What could possibly go wrong?

[abu_the_monkey]

so, exceeding the 256 zone limit kind of works.

there are issues with the auto map plotting some odd stuff which when toggled on screen caused the lighting in the 'extra' zones to be trashed
also around the 280 zone mark all the lighting goes to full bright when it is seen for the first time (at least on the quick map I experimented with)
some kind of overflow I guess?

otherwise the level geometry rendered ok