RC/repeater ''power rings''

[Nux]

those are not commands.

btw, see Options -> System -> Range Markers

Are you being pedantic about my use of the word 'command'? Those are the list of console variables you can edit on the console command-line. I posted them to be helpful for anyone who wants to create a bind for toggling them.

oh, crap. try setting r_showsky to 1, or going to an area isolated from the sky (ie., the Niveus plant room), and then doing a vid_restart. what happens then? this is just for my curiousity, but otherwise you should try setting r_fastsky to 1, and then doing a vid_restart.

I tried it and it had no effect, sadly.

[/dev/humancontroller]

Are you being pedantic about my use of the word 'command'?

yes.

oh, crap. try setting r_showsky to 1, or going to an area isolated from the sky (ie., the Niveus plant room), and then doing a vid_restart. what happens then? this is just for my curiousity, but otherwise you should try setting r_fastsky to 1, and then doing a vid_restart.

I tried it and it had no effect, sadly.

are you sure? plz test on a map with no sky (for example, thanatos_b3).

[Nux]

No success.

It seems anything to do with these 'binary shaders' doesn't work (with me). The sphere and cones and concave sphere-cones work fine: I can toggle drawing them, change their opacity and select which type of building uses them.

[gimhael]

Maybe your graphics driver choses a visual without alpha channel. The quake engine does not request an alpha channel, so the driver can do whatever is optimal for its hardware. On my nVidia 6600 card OpenGL picks a R8G8B8A0 format (i.e. no A channel) by default.

[/dev/humancontroller]

Maybe your graphics driver choses a visual without alpha channel. The quake engine does not request an alpha channel, so the driver can do whatever is optimal for its hardware. On my nVidia 6600 card OpenGL picks a R8G8B8A0 format (i.e. no A channel) by default.

how would we go about requesting A8 in the engine, or how do we find the number of alpha bits currently in use?

[gimhael]

Taken from sdl_glimp.c:

Code Select Expand


SDL_GL_SetAttribute( SDL_GL_RED_SIZE, sdlcolorbits );
SDL_GL_SetAttribute( SDL_GL_GREEN_SIZE, sdlcolorbits );
SDL_GL_SetAttribute( SDL_GL_BLUE_SIZE, sdlcolorbits );
SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, tdepthbits );
SDL_GL_SetAttribute( SDL_GL_STENCIL_SIZE, tstencilbits );


It doesn't set SDL_GL_ALPHA_SIZE. Unfortunately this is in the client executable - you cannot override it in the qvms

[Nux]

If this is the reason- bear in mind I've only half understood what you've said -is there something else this would cause that I can check, to see if that's affected too? If it's something as simple as alpha not occurring I can say right here and now that I definitely get alpha (for example on these spheres).

Also helpful would be some feedback from anyone else but me.

[/dev/humancontroller]

Nux: could you test this Tremulous executable which requests 1 alpha bit (or patch&compile an executable yourself and test that)?

[/dev/humancontroller]

It doesn't set SDL_GL_ALPHA_SIZE. Unfortunately this is in the client executable - you cannot override it in the qvms

prepare for ioq3 engine changes! nwhahahahaha!

[Nux]

Yes, that works. With that executable I see the binary shaders. Woo!

Sadly, while the pk3 is installed I can't play demos and get an 'ERROR: Bad corpseNum on entity: -1' when I try. This happened with both this .exe and my old one and the problem goes away when the pk3 goes away.

[/dev/humancontroller]

ok, thx for the tips, gimhael.

Sadly, while the pk3 is installed I can't play demos and get an 'ERROR: Bad corpseNum on entity: -1' when I try. This happened with both this .exe and my old one and the problem goes away when the pk3 goes away.

this is expected. you will not be able to play older demos with these modules, and will not be able to play, with older modules, demos created with these modules.

[Plague Bringer]

Brindus was vanilla the other day. Any servers running this?

[F50]

Brindus is not running this, actually, not quite yet. Its currently running gimhael's power rings. Brindus has been GPP a lot recently due to scrims, sometimes I forget to change it back.

[/dev/humancontroller]

ZOMFG, WE R BEING TROLLED, BIG TIME:

I'm sorry but this binary shaders thing is far too messy for trunk.

[Nux]

What does he mean? Is the code messy?

[/dev/humancontroller]

Is the code messy?

no, the code is very clean and modular.

What does he mean?

he doesn't like the approach used to draw lines.

[Plague Bringer]

Is the code messy?

no, the code is very clean and modular.

What does he mean?

he doesn't like the approach used to draw lines.

Your powers of arbitrary deduction are fantastic.

[jm82792]

It would be really nice if we could get this integrated on an official basis.

[/dev/humancontroller]

Is the code messy?

no, the code is very clean and modular.

What does he mean?

he doesn't like the approach used to draw lines.

Your powers of arbitrary deduction are fantastic.

yours likewise.

PS: see the full statement.

[Nux]

Any idea why it is better to not have the feature at all than have a hacked up version of it? Is it somehow offensive even when it's not active? Does it somehow open doors to trouble?

[/dev/humancontroller]

Any idea why it is better to not have the feature at all than have a hacked up version of it?

the feature is done in a creative way, not a hacked-up way.

Is it somehow offensive even when it's not active? Does it somehow open doors to trouble?

no, no.

[A Spork]

Any idea why it is better to not have the feature at all than have a hacked up version of it?

the feature is done in a creative way, not a hacked-up way.

Translation: Hacked up.

[/dev/humancontroller]

Any idea why it is better to not have the feature at all than have a hacked up version of it?

the feature is done in a creative way, not a hacked-up way.

Translation: Hacked up.

DOES U SPEAKS ENGRISH?

[Nux]

It would be nice to actually hear from Lakitu7. I've shouted to him over on irc with no response. If anybody's online when he is, could you ask him to post here or something as it would be nice to hear what his take on this is.

EDIT: I've had a brief inexpert look at the binary.shader file and I can't say I understand it very well yet but I can say it looks like you've bruteforced something that could have been coded much more nicely at a lower level. Yet again, I'll admit I'm no leet coder but when I see 256 chunks of text each differing by either increments or by seemingly arbitrary steps, my nearest guess is that you've hard coded something because you don't want to have to access a less limiting level of code.

[/dev/humancontroller]

EDIT: I've had a brief inexpert look at the binary.shader file and I can't say I understand it very well yet but I can say it looks like you've bruteforced something that could have been coded much more nicely at a lower level. Yet again, I'll admit I'm no leet coder but when I see 256 chunks of text each differing by either increments or by seemingly arbitrary steps, my nearest guess is that you've hard coded something because you don't want to have to access a less limiting level of code.

one chunk contains 6 shaders, which do the following steps:

• mark parts of the screen (applied to the exterior parts of shapes)
• unmark parts of the screen (applied to the exterior parts of shapes)
• draw some color on marked points (and unmark all points)
• mark parts of the screen (applied to the interior parts of shapes)
• unmark parts of the screen (applied to the interior parts of shapes)
• draw some color on marked points (and unmark all points)

these shaders have different, monotonic sort values, which means that they are drawn in respective order (also, one chunk at a time). this is important for correctness. marking is done by altering the alpha value of pixels on the screen.

256 chunks means that you can see lines drawn for at most 256 buildables at a time. 256 is an overkill, because you in practice never see 256 buildables (but note that the engine allows up to 16384 shaders to be defined, out of which only ~2000 are used on some complex maps).

atm there doesn't seem to be a way to procedurally define these shaders. however, the binary.shader file doesn't really need to be looked at, and it doubtfully gets in the way of developers.

[Lakitu7]

It would be nice to actually hear from Lakitu7. I've shouted to him over on irc with no response. If anybody's online when he is, could you ask him to post here or something as it would be nice to hear what his take on this is.

EDIT: I've had a brief inexpert look at the binary.shader file and I can't say I understand it very well yet but I can say it looks like you've bruteforced something that could have been coded much more nicely at a lower level. Yet again, I'll admit I'm no leet coder but when I see 256 chunks of text each differing by either increments or by seemingly arbitrary steps, my nearest guess is that you've hard coded something because you don't want to have to access a less limiting level of code.

Your inexpert nailed it perfectly. This needs to be done at the lower level of code.

It was also not a unilateral decision, but a consensus of developers who had a discussion about it. I just delivered the message.

[Nux]

Just to be clear, I didn't get someone else to look at it. I looked at it inexpertly. It's just that I can't help but feel a little proud for understanding it at least that much.

Anyhow, it's fair enough if you've considered it well. I'm just interested to know what the overriding disadvantage was to including it as the flawed but sole implementation of the feature. Or is it because if you accept this, then it will be settled for and never improved upon?

[Lakitu7]

When we add code to Tremulous we're essentially making a commitment to debug and maintain it indefinitely. This quickly becomes impossible if we include a bunch of ugly hacks. People submit patches that on the surface work at the moment and then they ride off into the sunset, but if those patches are messy, we, not them, would be the ones to deal with that mess indefinitely.

Obviously I used to be on the other end of this, making poorly coded features with hacky workarounds, and including them in unofficial releases that people used and liked, but it did become a buggy impossible to maintain mess, and it was only possible in the first place because trunk is kept to a higher, cleaner standard.

[Nux]

Sounds fair.

In any case, /dev/humancontroller, you've made a very cool and appreciated unofficial addition. Also, if ever you have the time, you're in a great position to implement a tighter version of it now you have this proof of concept.

[/dev/humancontroller]

/dev/humancontroller, you've made a very cool and appreciated unofficial addition.

i have a feeling you're missing someone to mention.

Also, if ever you have the time, you're in a great position to implement a tighter version of it now you have this proof of concept.

this isn't just a proof of concept, this is a full, well-tailored implementation for the current engine. also, the range marker feature without the binary shader subfunctionality is also usable. a completely different, lower-level approach would require additional engine features, which will be included S00N(TM) after DNF2 is released.