80 replies to this topic

[Cranium]

I'm asking if you are wanting to change the pixels for the cahracters at a time, or be able to do the entire screen at a time?

[Pharap]

dimitriye98, on 15 August 2012 - 03:01 AM, said:

Pharap, on 14 August 2012 - 09:29 AM, said:

That's what I thought.

No you don't, you get the character size. A screen can display 900 ascii characters.

Unless the average computer screen has only 5,000 pixels, they weren't (here's a hint, my laptop screen resolution is 1366x768, and has 1049088 pixels).

Yes, they are talking about the only current way to develop non-text guis. Changing the text texture file. (Yes, the text on a computercraft screen is made of rendered textures. LWJGL does not support individual pixel changing as far as I am aware. Like I said the only way to do it this far away from the central draw event is to edit textures on the fly, which will cause a fair bit of lag after about the 7th screen +/- 3)

Like I keep saying look at this image I made earlier:

dimitriye98, on 13 August 2012 - 09:01 AM, said:

Those are the "pixels" I want to change. As in, the little white squares that make up the text on the computer craft screen. These are many times bigger than the pixels you are talking about, the pixels on the actual computer screen.

It's still the same base problem, it means a complete design of how the screen works and if every character on the screen was 8 pixels you'd be rendering 8 times as many textures on top of each console. It's a significant increase.

[immibis]

Pharap, on 15 August 2012 - 04:14 AM, said:

dimitriye98, on 15 August 2012 - 03:01 AM, said:

Pharap, on 14 August 2012 - 09:29 AM, said:

That's what I thought.

No you don't, you get the character size. A screen can display 900 ascii characters.

Unless the average computer screen has only 5,000 pixels, they weren't (here's a hint, my laptop screen resolution is 1366x768, and has 1049088 pixels).

Yes, they are talking about the only current way to develop non-text guis. Changing the text texture file. (Yes, the text on a computercraft screen is made of rendered textures. LWJGL does not support individual pixel changing as far as I am aware. Like I said the only way to do it this far away from the central draw event is to edit textures on the fly, which will cause a fair bit of lag after about the 7th screen +/- 3)

Like I keep saying look at this image I made earlier:

dimitriye98, on 13 August 2012 - 09:01 AM, said:

Those are the "pixels" I want to change. As in, the little white squares that make up the text on the computer craft screen. These are many times bigger than the pixels you are talking about, the pixels on the actual computer screen.

It's still the same base problem, it means a complete design of how the screen works and if every character on the screen was 8 pixels you'd be rendering 8 times as many textures on top of each console. It's a significant increase.

There's no law of nature saying each pixel has to be rendered as a separate texture. It could be one texture for the whole screen updated when the computer changes pixels, for example.

[Luanub]

It don't matter if you're doing the pixel's on the computer screen or the pixels on the CC Terminal screen, its still going to take to much system resources to not cause issues with SMP servers. SSP it would probably work fine, but as long as it will cause issues with SMP it will not happen.

[Pinkishu]

luanub, on 15 August 2012 - 04:49 AM, said:

It don't matter if you're doing the pixel's on the computer screen or the pixels on the CC Terminal screen, its still going to take to much system resources to not cause issues with SMP servers. SSP it would probably work fine, but as long as it will cause issues with SMP it will not happen.

Interesting, how would such a low-resolution thing that only needs to be sent fully on opening and just updates on changes put any stress on smp?

[Luanub]

Due to having more users using it on the same server at the same time maybe? Just like anything else you increase the number of instances being ran and you increase the load on the system. Having multiple people controlling pixels like that will take its toll on the server and cause performance issues(unless you've got a top end machine but I imagine very few of the MC servers run on those types of machines). It people get control of pixels they are going to do more then just print a banner for their program. They are going to go all out and do animations. Thats why it would be okay in SSP, but have issues in SMP.

Do you work with servers? I spent 8+ hours at day working on them...

[Floedekage]

Pharap, on 14 August 2012 - 04:49 PM, said:

Because it would only change the appearance for you, since it would be your font file (like a texture pack only changes the appearance for you) which partly defeats the object. It would be an ok fix for single player, but the people in charge like to have the mod's client and server versions synced, so they will almost certainly say no.

Now, I mean if every computer had a font.png file in their directory it could be transferred to the client when opening the computer, like a texture pack.
Now, I can see the trouble considering the speed and I don't know how long it would take to transfer an image even if it only was in 256 or even 16 colors. (I don't know if you can do that with .png)

But there must be a way to make this happen, even if it should be an add-on.

[Luanub]

There is this http://www.computerc...-computercraft/

I haven't played with it so I'm not sure what all it is capable of.

[Pinkishu]

luanub, on 15 August 2012 - 07:42 PM, said:

Due to having more users using it on the same server at the same time maybe? Just like anything else you increase the number of instances being ran and you increase the load on the system. Having multiple people controlling pixels like that will take its toll on the server and cause performance issues(unless you've got a top end machine but I imagine very few of the MC servers run on those types of machines). It people get control of pixels they are going to do more then just print a banner for their program. They are going to go all out and do animations. Thats why it would be okay in SSP, but have issues in SMP.

Do you work with servers? I spent 8+ hours at day working on them...

Which isn't too much updating, if setting a few pixels on/off lags a server they shouldn't be hosting /> Any sophisticated RP2 systems would probably cause more toll (Note: RP2 allows "drawing" by having a bigger display and being able to draw box-characters)

[inventor2514]

Personally, I would like to have pixel manipulation. I can't see it being a huge issue, but I haven't worked much with servers. Maybe the API could be optional, like the http API.

[Pharap]

immibis, on 15 August 2012 - 04:23 AM, said:

Pharap, on 15 August 2012 - 04:14 AM, said:

dimitriye98, on 15 August 2012 - 03:01 AM, said:

Pharap, on 14 August 2012 - 09:29 AM, said:

That's what I thought.

No you don't, you get the character size. A screen can display 900 ascii characters.

Unless the average computer screen has only 5,000 pixels, they weren't (here's a hint, my laptop screen resolution is 1366x768, and has 1049088 pixels).

Yes, they are talking about the only current way to develop non-text guis. Changing the text texture file. (Yes, the text on a computercraft screen is made of rendered textures. LWJGL does not support individual pixel changing as far as I am aware. Like I said the only way to do it this far away from the central draw event is to edit textures on the fly, which will cause a fair bit of lag after about the 7th screen +/- 3)

Like I keep saying look at this image I made earlier:

dimitriye98, on 13 August 2012 - 09:01 AM, said:

Those are the "pixels" I want to change. As in, the little white squares that make up the text on the computer craft screen. These are many times bigger than the pixels you are talking about, the pixels on the actual computer screen.

It's still the same base problem, it means a complete design of how the screen works and if every character on the screen was 8 pixels you'd be rendering 8 times as many textures on top of each console. It's a significant increase.

There's no law of nature saying each pixel has to be rendered as a separate texture. It could be one texture for the whole screen updated when the computer changes pixels, for example.

Even doing it that way could have major negative effects. It means that the texture has to be opened for editing, then each pixel has to be read and updated according to the new arrangement. This arguable takes longer than the method I stated earlier since you are editing a texture mid game, also meaning you have to store each computer's texture separately on top of that, and the edit would have to occur each update without a complicated way of testing if it needs updating (you can't test if images are equal in programming since they are essentially large arrays of data, you can only assign images).

[dimitriye98]

Ok, we've been arguing quite a bit wether this is possible or not, so Cloudy or Dan200, please answer:

Is this feasible?

If so, can/will it be implemented?

[Pharap]

dimitriye98, on 16 August 2012 - 07:34 AM, said:

Ok, we've been arguing quite a bit wether this is possible or not, so Cloudy or Dan200, please answer:

Is this feasible?

If so, can/will it be implemented?

Was luanub's link to mast3rplan's project not enough?

[Pinkishu]

Fun fact: the server doesn't have to do any drawing. It just saves and array of boolean values thats is sent to the client which then handles the drawing and that only if the PC screen is opened

[Pharap]

Pinkishu, on 16 August 2012 - 11:14 AM, said:

Fun fact: the server doesn't have to do any drawing. It just saves and array of boolean values thats is sent to the client which then handles the drawing and that only if the PC screen is opened

If there were colours, it would have to be an array of 3 byte values, which could make the array anywhere from 2 to 1 times more bigger (boolean values take up different amounts of bytes per pc, or so I'm told)
For those who no thing of arrays, they are one of the optional equivalents of lua's tables. Lua works weirdly with it's tables compared to the c and basic based languages.

[Pinkishu]

As far as i've seen the first post doesn't mention colors though~

[dimitriye98]

Pharap, on 16 August 2012 - 11:49 AM, said:

Pinkishu, on 16 August 2012 - 11:14 AM, said:

Fun fact: the server doesn't have to do any drawing. It just saves and array of boolean values thats is sent to the client which then handles the drawing and that only if the PC screen is opened

If there were colours, it would have to be an array of 3 byte values, which could make the array anywhere from 2 to 1 times more bigger (boolean values take up different amounts of bytes per pc, or so I'm told)
For those who no thing of arrays, they are one of the optional equivalents of lua's tables. Lua works weirdly with it's tables compared to the c and basic based languages.

I don't want colors, I simply want to turn on and off those white squares, also:

Funfact: If I was implementing this, I wouldn't use an array of boolean values, I'd use a function which maps the boolean values to a binary number.

[Luanub]

Here's a reply from an admin about having control over the 5000 pixels on the default CC Screen and why it won't happen... http://www.computerc...-color-control/

As people have said, this has been brought up and has been rejected due to the impact on servers in SMP...

[Pinkishu]

well 900 characters at 1 byte = 900 byte
5000 pixels at 1 bit = 625 byte

Also noting: that topic had colors suggested too

RP monitors have 4000 characters

[Luanub]

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 />