What causes a console screen to shimmer

[Count23]

What exactly causes a console screen with wirelink to shimmer?

Originally, i had a console screen set up to delete all the data and reload it each time an expression chip runs and i figured there was a lag time between the screen clearing and the new data being written, but after removing the screen[2041] = 1 and using a screen:writestring(" ") as a test, i find that the data is still flickering on any of the data that's supposed to update.

However, i found if i reload the screen with m expression on a fixed timer of about 250ms instead of letting it reload based on updated data from the e2's inputs, then the screen wont flicker.

But on another chip with a similar function, it doesnt flicker. I just dont understand it.

[Divran]

You're not supposed to be writing to a console screen every 0.01 seconds. You should only write to it when needed, such as when a player pushes a button or similar.

[Count23]

So it really should be on a timer and a timer only then? What happened to high speed writing from a wirelink?

[Syranide]

So it really should be on a timer and a timer only then? What happened to high speed writing from a wirelink?

Clients are still limited by physical bandwidth limits, including that of the server. You cannot send infinite amounts of data without it getting queued up, lagging the server and causing various issues.

Meaning, only update the screen when needed, don't do it every tick, and if you do it every tick, make sure they are minimal changes, not clearing and updating the screen.

[Count23]

So in anything relating to a console screen, we should sacrifice e2 efficiency to ensure that the console screen does the minimum amount of work required?

[Nikita]

Hey let's make a dll that accelerates all the screen queues by sending them in their own channel, independant of HL2? We could bite a larger part of total physical bandwidth available.

Did I just say something dumb?

[Syranide]

So in anything relating to a console screen, we should sacrifice e2 efficiency to ensure that the console screen does the minimum amount of work required?

I'm feeling pretty confident that minimizing work for the console screen also means minimizing work for the E2 unless you're doing something very strange. But yes, the console screens does not behave well under stress, so changes to a minimum.

[Divran]

So in anything relating to a console screen, we should sacrifice e2 efficiency to ensure that the console screen does the minimum amount of work required?

What are you talking about. It's a simple matter of using a few if cases to check when and when not to write to the screen.

[Count23]

you mean a few if statements, don't you dirvan. Or has e2 finally got switch/case support?

And yes, i know it's just a few if statments, I'm just saying that in actuality however, that is adding ops to the e2 chip each time you put an if statment in there. So you're losing efficiency on your e2 in terms of op usage for each case statement you add to check the console screen activity.

[shaftm]

It costs less to do an if check than to clear the console screen and write more stuff to it does it not?