Cheers for the encouraging words and pictures (even the gross ones
), I appreciate every one.
TX, on 15 May 2011 - 03:45 PM, said:
Btw, is there any way to make this work in Polymost, perhaps by the same multi-pass methods you're using for classic?
Wasn't Polymost being, if not completely, then at least gradually deprecated in favor of Polymer? That said, I did give it a try... it turned up with HOM effects, unsurprisingly. The high-level code of a first forward pass to collect all sectors to-be-drawn and the subsequent real drawing (now back to front) could stay the same, but it's what happens in between that's crucial to the correct functioning.
DanM, on 15 May 2011 - 05:38 PM, said:
wow this is so easy to use, is there any limit to the amount of stacks you can have iam upto 6 now
The maximum number of levels that are drawn to each side (above and below) is a compile-time constant, currently at 8. This means that you can have up to 9 stacked sectors and see any one of them at any level. The maximum number of bunches in the map at large is 256. If you need more than 8 levels of drawing, call me and I'll raise it to 16. I'd be seriously surprised if you managed to make a real level that needs more, though.
NY00123, on 16 May 2011 - 01:07 AM, said:
Just a little warning for the ones who want to add ROR... Transparency doesn't seem to work with sloped ROR floors/ceilings; Even for "sloped" ones with a slope value of 0!
This is probably a limitation of the software renderer.
Heh, I missed that even though that was the reason to have sloped ROR'ed sectors -- window panes and such. There's simply no translucent texure-mapping function for them, I guess.
Micky C, on 16 May 2011 - 01:21 AM, said:
Hold on I just read that the TROR maps are using a new map format (v9), does this mean we can expect so see all sorts of new features that break the old map limits in the future? Like larger sector/wall/sprite counts or sprites and textures that can be sloped?
No, V9 is essentially still V8 but the number had to be incremented because the new data wouldn't be of much use to older EDuke32 versions. The only real max-count that needs to be doubled IMO is that of the walls (because most maps have a wall/sector ratio of about 8), but there are technical issues with that. Having stuff like spriteext in the map is certainly desirable, but that's for another time.
Fox, on 16 May 2011 - 01:39 AM, said:
I am impressed on how stable this is, considering how untrustable Build engine can be
I wouldn't say the engine itself is unstable -- in fact, I've come to like BUILD internals pretty much. It's just that the early BUILD editor was pretty sloppy in its error-checking that gave the impression.
CraigFatman, on 16 May 2011 - 02:41 AM, said:
I see that you've reserved sector's
xpanning properties to remember bunch number it belongs to, what isn't good for masked sectors (they can be panned only y-wise). There's an unused "filler" parameter which you might want to use as well (it is shared between the floor and ceiling though). Also TROR has some problems with viewing through sloped surfaces (you've already placed a "bug" label where it appears in the sample map).
Well, let's document those new sector
cstat flags... If I understand correctly, they're dedicated for:
- 512 Block movement when used as a portal
- 1024 ROR portal flag (xrepeat is the bunch number)
- 2048 Block hitscan when used as a portal
So the feature as a whole is very promising; still I'll have to use
showview to render individual passes in my mod, but having the ability to control rendering passes via CON scripts would be great.
Xpanning seemed to me the least of all evils, the reason being that masking sectors would in 99% be with 'seamless' textures like water, slime, or glass. Where alignment is necessary, you can somewhat weasel around that limitation by assigning a different firstwall.
The meaning of the floorstat/ceilingstat bits is correct. Additionally, wall[].cstat now uses bits 1024 and 2048, meaning "constrained wall, look up upper neighbor wallnum in lotag (1024) or lower neighbor wallnum in extra (2048)". As I said earlier, they're only used inside the editor and when loading the map into the game, after which they're transferred out of sight (for now). Eh, I guess I'm just being overcautious here... but after all, imagine what would happen if a CON script happily used wall lotag/extra for its own purposes...