80 replies to this topic

[Pinkishu]

Interesting, my animation system uses every character for some effects />
And well without pixel control or anything like that CC will stay very limited in what is possible with it

[immibis]

luanub, on 16 August 2012 - 10:03 PM, said:

There's a big difference between the way people will use characters vs pixels. No one ever really uses all the possible char space and they are not refreshing it on a constant and rather fast rate to make images. If people gain pixel control they will make images and things such as animated games that will need to refresh a lot faster and will cause performance issues on servers with any load on them at all(color or not, color would just be worse).

RP also uses your systems/servers hardware differently />

And then the server will refuse to send screen updates that quickly, and everyone will stop making high-res animated games in SMP because of the lag - it wouldn't be Minecraft that lagged, just that in-game computer.

[Luanub]

immibis, on 17 August 2012 - 08:16 AM, said:

luanub, on 16 August 2012 - 10:03 PM, said:

There's a big difference between the way people will use characters vs pixels. No one ever really uses all the possible char space and they are not refreshing it on a constant and rather fast rate to make images. If people gain pixel control they will make images and things such as animated games that will need to refresh a lot faster and will cause performance issues on servers with any load on them at all(color or not, color would just be worse).

RP also uses your systems/servers hardware differently />

And then the server will refuse to send screen updates that quickly, and everyone will stop making high-res animated games in SMP because of the lag - it wouldn't be Minecraft that lagged, just that in-game computer.

With the way that CC uses the servers hardware it would lag the entire server. Unlike RP, CC's computers has full access to the systems resources. RP is limited to the ram modules you install 8KB isn't much if your running a system with 4GB each CC computer gets access to the full 4GB. On the CPU side RP has access to a 1MHz CPU while each CC computer has you're entire CPU(most these days are well over 2GHz) available to it. Due to that if people were hamming it that hard it would lag the entire server, possibly even crash it.

[Cloudy]

luanub, on 17 August 2012 - 08:34 AM, said:

immibis, on 17 August 2012 - 08:16 AM, said:

luanub, on 16 August 2012 - 10:03 PM, said:

There's a big difference between the way people will use characters vs pixels. No one ever really uses all the possible char space and they are not refreshing it on a constant and rather fast rate to make images. If people gain pixel control they will make images and things such as animated games that will need to refresh a lot faster and will cause performance issues on servers with any load on them at all(color or not, color would just be worse).

RP also uses your systems/servers hardware differently />

And then the server will refuse to send screen updates that quickly, and everyone will stop making high-res animated games in SMP because of the lag - it wouldn't be Minecraft that lagged, just that in-game computer.

With the way that CC uses the servers hardware it would lag the entire server. Unlike RP, CC's computers has full access to the systems resources. RP is limited to the ram modules you install 8KB isn't much if your running a system with 4GB each CC computer gets access to the full 4GB. On the CPU side RP has access to a 1MHz CPU while each CC computer has you're entire CPU(most these days are well over 2GHz) available to it. Due to that if people were hamming it that hard it would lag the entire server, possibly even crash it.

What are you talking about? It would be no different than any other script running on a computer. Providing we have the correct server side control.

[immibis]

Cloudy, on 17 August 2012 - 09:18 AM, said:

luanub, on 17 August 2012 - 08:34 AM, said:

immibis, on 17 August 2012 - 08:16 AM, said:

And then the server will refuse to send screen updates that quickly, and everyone will stop making high-res animated games in SMP because of the lag - it wouldn't be Minecraft that lagged, just that in-game computer.

With the way that CC uses the servers hardware it would lag the entire server. Unlike RP, CC's computers has full access to the systems resources. RP is limited to the ram modules you install 8KB isn't much if your running a system with 4GB each CC computer gets access to the full 4GB. On the CPU side RP has access to a 1MHz CPU while each CC computer has you're entire CPU(most these days are well over 2GHz) available to it. Due to that if people were hamming it that hard it would lag the entire server, possibly even crash it.

What are you talking about? It would be no different than any other script running on a computer. Providing we have the correct server side control.

This. I meant that the rate of updates should be limited, so that using pixels is a trade-off between refresh rate and resolution. If you use pixels, you get more resolution, but can't update the screen as quickly. If you use text, you can update the screen quickly, but only get text.

Semi-related, there should be block and line drawing characters in CC, something like [url=http://en.wikipedia.org/wiki/Code_page_437]code page 437[/code]

[Sebra]

Limit it by one draw operation on console/monitor per tick.
So you can write 20 lines of text per second or spend two seconds to draw one 5x8 symbol.

[Cloudy]

Yeah, agreed. We do want to support other languages' char sets, so we will probably look into support for that at the same time (they are already in the default font image).

[Sebra]

Then make other code pages possible, please.
As a config choice or a picture swap. or ...

[Cloudy]

Sebra, on 17 August 2012 - 02:26 PM, said:

Then make other code pages possible, please.
As a config choice or a picture swap. or ...

We won't support it as a code page if we do - we will just try and get the characters supported.

[dimitriye98]

Ok, I apologize for my absence in arguing my suggestion, I'd forgotten that I'd even suggested something /> Anyhow, so, Cloudy, would it be possible for this suggestion to be added?

Sebra, on 17 August 2012 - 02:20 PM, said:

Limit it by one draw operation on console/monitor per tick.
So you can write 20 lines of text per second or spend two seconds to draw one 5x8 symbol.

Also, I would agree with this if provided with the ability to combine multiple coordinates into a single update, so, while I could spend two seconds to draw one 5x8 symbol, I could also put all the points into a table or something similar and call a special set function which would draw the whole 5x8 character in one go. So basically what I would request if such a limitation were added would be a method of combining points similar to how, in the redstone api, I can combine bundled cable colors to change them all with one function.

[Sammich Lord]

What if to display pixels you had to define the pixel locations at the top of the code then it loads the custom pixel gen into memory then just copies and pastes them when called for. So kinda like how games load the graphics first then basically just copies and pastes them.

[ds84182]

First, the server would be informed by draw commands. So if I wanted to set all of the pixel to white then fill true in some kind of number system gets sent. The server then tells the client what to draw. It creates a drawlist. The drawlist isn't syncronized, so you don't have to tell the server over and over again. Plus, like how the yielding timer works, it could stop all draw commands for a few seconds if too many are sent. Basically, it is sent like a cpu opcode, the first 4 bits are the command, and the other 28 are options (32 bit values are used)
[] = unused
, = option seperator
clear -> 0x0[0000000]
fill true -> 0x1[000000],1
fill false -> 0x1[000000],0
plot 400, 144, true -> 0x2,190,90,1[0]
plot 400, 144, false -> 0x2,190,90,0[0]
You probably get the rest... And It DOESN'T HAVE TO BE LIMITED TO 32BIT(4bytes)

[immibis]

ds84182, on 28 August 2012 - 12:40 AM, said:

First, the server would be informed by draw commands. So if I wanted to set all of the pixel to white then fill true in some kind of number system gets sent. The server then tells the client what to draw. It creates a drawlist. The drawlist isn't syncronized, so you don't have to tell the server over and over again. Plus, like how the yielding timer works, it could stop all draw commands for a few seconds if too many are sent. Basically, it is sent like a cpu opcode, the first 4 bits are the command, and the other 28 are options (32 bit values are used)

,
Like display lists in OpenGL? I like it.

[GopherAtl]

Maybe its just me, but vector graphics seem more appropriate. Logo-style, penUp, penDown, move, and turn.

[Pharap]

GopherAtl, on 05 September 2012 - 11:34 PM, said:

Maybe its just me, but vector graphics seem more appropriate. Logo-style, penUp, penDown, move, and turn.

Vector graphics are more complicated and involve loads of calculations, hence why raster graphics are still standard

[GopherAtl]

Loads of calculations? Not really. Line drawing algorithms are trivial, and a 360-degree slope lookup table is trivial as well; using reflection you only need a table for 45 degrees. Other than that you just need basic vector addition. More Important, I think, is that vector graphics take a lot less memory than pixel graphics, making them more server and bandwidth friendly.

[Pharap]

GopherAtl, on 06 September 2012 - 03:41 PM, said:

Loads of calculations? Not really. Line drawing algorithms are trivial, and a 360-degree slope lookup table is trivial as well; using reflection you only need a table for 45 degrees. Other than that you just need basic vector addition. More Important, I think, is that vector graphics take a lot less memory than pixel graphics, making them more server and bandwidth friendly.

If they are so trivial, I'd love to see some examples of such calculations. I assume you have some you'd be willing to share with the community?

[GopherAtl]

challenge: accepted.

Just threw together a basic line drawing function in terminal, and a program to use it to do a basic dancing line. Time so far: ~45 minutes. Later will make a logo API with penUp/Down, penChar, turn, turnTo, forward, and moveTo functions.

http://pastebin.com/iJYzitra

works with any size monitors if you run it as "monitor <side> dancingLine" (or whatever you named it in the pastebin get)

stop with ctrl-T

:edit:

after a break went back and spent another 45 mins or so of effort. Now have logo API...

http://pastebin.com/vn5B8ZUg (save as "logo" for the sample program to load and use it properly)

and the sample program...

http://pastebin.com/QyCQAhqP

[dimitriye98]

Wow, I forgot about this thread and it's stayed alive for a very long time. Anyhow, GopherAlt, thats very neat but raster graphics would honestly be easier to use. Simply tell the computer to turn a certain set of coordinates on or off.

[GopherAtl]

well, easier to use? certainly. But vector graphics would offload most of the heavy lifting to the clients instead of the server, who simply maintains lists of lines, and maybe I'm crazy (ok, certainly I'm crazy - I've started implementing a full logo language interpreter now, complete with variables and functions based on this initial code), but I like the symetry of turtle graphics in the computercraft universe.

My only point was that the arguments against vector graphics shouldn't include complexity or computational cost, and in fact from a technical standpoint they have advantages in reduced memory, and thus bandwidth, load for the server.