5 replies to this topic

[Tjakka5]

From the comments I have seen on these forums I saw that the biggest problems with big programs were that the screen was flickering.

I am guessing this was because the way you would print the GUI is that you calculate a piece, render it, calculate, render, etc for 1 frame.
I instantly thought this could be fixed by making a buffer (What is probably the thing that everyone does), meaning that you calculate something, store it somehow, calculate the next thing, store it, and print every frame in one go without calculating.

Is this right? And if so, how would you do that?

Edited by Tjakka5, 16 November 2013 - 06:00 AM.

[jay5476]

Well you would only get flickering if redrawing the screen to often so i dont see how a buffer would help

[Bomb Bloke]

As far as I know, the only way to go about it would be to create a table which keeps track of the character + foreground colour + background colour for each and every x/y offset on your screen. You dump everything you want to write into that table instead, then when your buffer has been completely "painted", iterate through the whole table and get it onto the actual screen. This is how GopherAtl's buffering system works (as used with his Wolf3D-type engine).

However, when considering the use of a buffer, I feel the first thing you should ask yourself is whether you need one. In most cases, you can reduce or eliminate flickering simply by not redrawing the whole screen - unless your program needs (as in, needs) to change the majority of the display with each update (eg like the example linked above), or frequently redraw arbitrary and complex patterns on the screen (eg windows that were covered by other windows), then there's really no need to do so. For example, my Tetris clone seldom changes large areas of the screen and so uses no buffering at all.

With all that said, if a buffer is needed for whatever task you have in mind then I don't think I can find fault with GopherAtl's implementation.

[Lyqyd]

I'm of the belief that a table of strings, one per line, is better. This setup enables you to scan the line for chunks of contiguous colors and write out more of the line at once under normal circumstances, which reduces network usage and therefore screen latency. You can also easily skip writing entire lines of the screen if there are no changes from the last time it was drawn via a second buffer kept for reference or a "dirty" flag for each line.

[theoriginalbit]

Lyqyd, on 16 November 2013 - 02:59 PM, said:

I'm of the belief that a table of strings, one per line, is better. This setup enables you to scan the line for chunks of contiguous colors and write out more of the line at once under normal circumstances, which reduces network usage and therefore screen latency. You can also easily skip writing entire lines of the screen if there are no changes from the last time it was drawn via a second buffer kept for reference or a "dirty" flag for each line.

String operations such as construction and concatenation aren't exactly the cheapest tasks to be performing. I'd still prefer to use tables. one for the current screen, one for the desired screen, one for the differences in both. The differences buffer could easily be sorted by colours to easily reduce network traffic with colour changes (I've done it before with printers to reduce ink usage) and in terms of traffic from changing the characters on the screen, it could be reduced by grouping characters that are adjacent, however any solution that attempts to reduce traffic of sending the characters is going to do one of two things; one, its not going to reduce traffic much; two, its going to be sending data that hasn't changed just so that it can reduce in traffic.

[Lyqyd]

Uh, no, the point of working to reduce network traffic is to not send the data that hasn't changed. Since ComputerCraft transmits the whole line anyway each time anything on the line changes, I simply ignore any unchanged lines. Manipulating the table of strings is no slower than either writing out the entire line via network for each character on the line, or having to concatenate the line each time there are changes. The real savings, I suppose, are in not having to split up the strings in order to stuff individual characters into the table. For either system, the other big gain is in keeping track of the previous screen state.