qbismSuper8 builds

[qbism]

Sorry about the vis, but nonetheless thrilled by this map I noclipped to get a similar viewpoint to the pre-release promo shot just to see if it could happen.

[Baker]

[Baker]

Not on topic exactly:

No edit button? No reply button?

It's like the Dark Ages!

I'd complain except it's nice that Inside3D isn't dead. And except the fact that, well, I am complaining! Not to anyone in particular.

I guess PHPBB is now like Linux. It's mostly good and then suddenly buttons or things everyone uses on daily basis suddenly vanish.

[Spike]

there is supposedly an edit button... somewhere... you might need to use tab to find it, but its there!
yay for minimalist user interfaces!

I'd completely forgotten about that markv patch. I was about to deny working on it too.
I believe it still has a couple of limits, specifically the max_leafs limit, which is imposed by lots of static buffers all over the place. probably also others due to me being lazy.
I kinda wish bsp2 had a concept of clusters, and stored the various brushes too, and lightmap scaling, and embedded rgb lighting. that's not entirely just wishful thinking - all but the first of those are already actually implemented to some degree via extra bspx lumps, but meh, needs tools, and people willing to utilise it, and that requires standards, and that requires harassing people, and I'm lazy, and its easier to just directly load .map files... wait, this isn't the what are you up to thread.</tangent>

bsp2 really is just a case of making dupe versions of the various bsp dfoo_t structures so that all the shorts are either ints or floats. then using one set or the other. the existing byteswapping code means that its all copied over anyway.
and to then make sure all your mfoo_t structures also use ints instead of shorts... hint: msvc has a setting to enable warnings about data type truncations, which can be quite handy in situations like this, yay for easy debugging.

regarding 666, what irks me is that it still has no way to report to the server that a client supports it, so public servers either can't use 666, or many clients crash-to-console. imho, this makes it pointless as far as multiplayer is concerned.
the server is free to implement as little of the protocol as it wishes (see msvc remark above), considering that much of the protocol doesn't contribute to anything to do with map sizes (just precache limits iirc), so long as other clients don't get confused (I think you'd need the nextthink values networked, I don't remember anything else). the client only really needs to implement as much of it as the server does, yay for subsets (stub the rest if you cba to implement it properly yet, ideally with helpful messages about it being you that is lazy rather than the server being buggy). yay for implementing things in phases - the only way to get something working without getting bored before its complete!
its probably worth mentioning rmqe's 999 protocol, which is mostly just 666 but with some extra options for different primative sizes (which allows smoother rotations or larger boundaries to maps). I think it also adds .scale, but meh to that.

EDIT: mwahaha! yay tab!

[qbism]

Do the huge signon packet sizes of bsp2 maps prohibit multiplayer? It takes an efficient protocol just to keep the signon below 64Kbytes (unsigned int).

[Spike]

technically, you don't need to write baselines and spawnstatics inside a singular signon buffer, one way is to use multiple signon buffers (with a lower size that keeps other quake clients happy, like quakeworld), or to generate that data on a per-client basis (fte does this in order to cope with different types of client).

this can be done without using a new protocol of course, but still takes some notable server changes.

what's more of an issue is the 1024-byte unreliable datagram limit. you can boost that limit but doing so results in vanilla clients erroring out, or you can leave it as it is and end up with various entities going invisible.
clients that support fitz666 can be expected to also support significantly higher sizes (the exact new limit is a little harder to predict), however, sending packets larger than 1450 or so (1512 - udp+ip+quake overhead+vlan+pppoe+etc) will result in fragmentation - and not all routers/hosts support fragmentation.
fitz666 doesn't provide anything to work around this.

bsp2 itself doesn't result in larger packet sizes, rather it just provides more playing area for entities and submodels to be within.
you can have the same issues with bsp29 (especially the unreliable datagram limit).

[Baker]

qbism there is a guy named Legend that has posted in the Arcane Dimensions forum about troubles running Arcane Dimensions in QBism super8. He has also posted in at func.

Just wanted to point this out so you know.

(He's knows his way around Quake and QuakeC and stuff so he's probably very helpful in bug reporting).

[qbism]

Thanks. There's an overflow affecting the vid buffer. No crash when the mod's progs.dat is removed, and maps load fine. So guessing progs.dat or a limit-breaking custom asset is the issue.

[qbism]

The Medusa bug! manifestation: overflow into video memory and eventual crash when rotating view toward a specific direction... weird.

[mankrip]

Try "r_drawentities 0;r_drawviewmodel 0". If the bug vanishes, disable each entity type individually until you find the cause.

Reducing the viewsize also helps to investigate such things while avoiding crashes.

[ericw]

I see the shotgun model at the bottom of the screen, but I know progs/v_shadaxe0.mdl (the axe viewmodel) causes problems for software renderers, I've seen screen corruption like that screenshot, and it crashes Baker's MarkV-Winquake when you switch to the axe.

So with any luck the underlying cause is the same..

[ericw]

Oh, the rockets pickup is another example, this is dm4:

[Baker]

Interesting.

I have some buffer guard code that isn't enabled in a release build obviously that should let me quickly find when and where that happens.

But I'm not really in engine coding mode and won't be for months.

I don't like anything in an engine misbehaving, but never encountered a model doing that.

[qbism]

Mankrip, it did not crash after that. And ericw, you nailed it. There must be something funky with the mdls. They look OK in Noesis but saved as a smaller file. After batch re-saving the whole set the crash and vid overflow is gone.

Also the files are smaller after this.

Updated progs mdls zip:

[Baker]

qbism, after you did that does Arcane Dimensions run?

You might let Sock know about that in the func_msgboard Arcane Dimensions board. I'm pretty sure he would want to know and fix.

Also at the end of this thread:

http://celephais.net/board/view_thread. ... &start=392

legend and mk are discussing something about beam models in super8 (and by extension mk's engine I guess).