[1.4/1.5] Pixel Manipulation

term.getPixelSize()

term.togglePixel(x, y)

term.setPixel(x, y, set)

term.getPixel(x, y)

term.setPixels(...)

term.clear()

term.clearLine()

dimitriye98, on 12 August 2012 - 07:58 AM said:

the reason I want it is custom graphics and better guis…

dimitriye98, on 13 August 2012 - 02:54 AM said:

Why would it make your computer lag horribly? Practically any application for your computer does a lot more graphically intensive work than determining whether a certain grid square (since I'm not referring to true pixels, but the low-res squares that the text on the computer is made up of at the moment) should be colored black or white. They need to manage 3 values between 0 and 255, and they do this on a much higher resolution. So no, it would not make your computer lag like hell thank you very much.

Pharap, on 13 August 2012 - 03:15 AM said:

Mostly it would kill servers, as for single player minecraft, there's a chance that the individual drawing logic would cause a load of slow down.

What games do, they load up all their sounds and textures at one point early on in the execution of the program/level. The textures are optimised at that point so it's easy to draw objects coated in those textures, since it is essentially just copying and pasting data.
When you start to invoke complicated calculations to determine an image from individual rectangles or pixels, the computer then has to calculate those every time the screen draws, so a simple copy and paste is now a drawn out calculation. If you have enough monitors running this in normal mode alone it would add to the already noticeably existent minecraft lag.
Put it on a server and you'd be lucky to not cause exceptions or stack overflows.

Pharap said:

Despite all that, if you really want to try something like this, I believe this add-on may be up your street/alley:
http://www.computerc...__fromsearch__1

Yes, I am slightly contradicting myself, but the point of these forums are to resolve people's issues, so here you go, one resolution for you.

If you want more information into the background behind the no pixels argument, try threads like this: http://www.computerc...-color-control/

craniumkid22, on 13 August 2012 - 06:18 PM said:

So are you saying to manually draw the pixels for each character using a function? Or are you saying to get the pixel x,y for the entire screen?

dimitriye98, on 13 August 2012 - 10:01 PM said:

craniumkid22, on 13 August 2012 - 06:18 PM said:

So are you saying to manually draw the pixels for each character using a function? Or are you saying to get the pixel x,y for the entire screen?

I want to manually draw the pixels. This allows for much better GUI's and greatly expands the function of ComputerCraft graphics-wise. That doesn't mean I want the text functions removed, far from it, I simply want the addition of pixel manipulation.

Pharap, on 13 August 2012 - 10:52 PM said:

So are saying you want it only for the gui that opens when you right click, or do you want it to draw on the huge monitors as well?

craniumkid22, on 13 August 2012 - 10:53 PM said:

^^that would cause massive lag just to get the pixel size^^

Human0303, on 14 August 2012 - 07:31 AM said:

I have read in other threads that admins were saying the reason why it will NOT be added is due to lag.
However if the code for CC was open source people would probably do that but it is NOT.
I would love to see this feature added but it sadly will not.

ardera, on 14 August 2012 - 08:07 AM said:

I am working on something like this… Its not an extra mod, but its an modified "default.png" Image.

dimitriye98, on 14 August 2012 - 09:34 AM said:

Pharap, on 13 August 2012 - 10:52 PM said:

So are saying you want it only for the gui that opens when you right click, or do you want it to draw on the huge monitors as well?

Both.

craniumkid22, on 13 August 2012 - 10:53 PM said:

^^that would cause massive lag just to get the pixel size^^

No it wouldn't, you already have to get pixel size for displaying text on monitors.

Human0303, on 14 August 2012 - 07:31 AM said:

I have read in other threads that admins were saying the reason why it will NOT be added is due to lag.
However if the code for CC was open source people would probably do that but it is NOT.
I would love to see this feature added but it sadly will not.

These were likely talking about different "pixel manipulation" then I am. Earlier I made an image to explain what I meant. They were likely talking about screen pixels.

ardera, on 14 August 2012 - 08:07 AM said:

I am working on something like this… Its not an extra mod, but its an modified "default.png" Image.

How exactly would this work? The application of what I suggested is impossible without changes to the code.

Floedekage, on 14 August 2012 - 02:41 PM said:

I like this idea, this is exactly what I need.
However, why not make a font.png image in every computers directory containing 256 characters, then this could be edited in-game and if one character was "font.png / 16" in width and the same in height you could make 256 color graphics. You could even make Arabic and Chinese characters easily or change the font color.

I hope this is understandable.

Pharap, on 14 August 2012 - 10: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)

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

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

Pharap, on 14 August 2012 - 10: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 - 10: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.

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

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

Pharap, on 14 August 2012 - 10: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 - 10: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.

luanub, on 15 August 2012 - 05: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.

Pharap, on 14 August 2012 - 05: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.

luanub, on 15 August 2012 - 08: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…

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

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

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

Pharap, on 14 August 2012 - 10: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 - 10: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.

dimitriye98, on 16 August 2012 - 08: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?

Pinkishu, on 16 August 2012 - 12:14 PM 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

Pharap, on 16 August 2012 - 12:49 PM said:

Pinkishu, on 16 August 2012 - 12:14 PM 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.

luanub, on 16 August 2012 - 11: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 :(/>/>

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

luanub, on 16 August 2012 - 11: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, on 17 August 2012 - 09:34 AM said:

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

luanub, on 16 August 2012 - 11: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, on 17 August 2012 - 10:18 AM said:

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

immibis, on 17 August 2012 - 09: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.

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

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

Sebra, on 17 August 2012 - 03: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.

ds84182, on 28 August 2012 - 01: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)

GopherAtl, on 06 September 2012 - 12:34 AM said:

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

GopherAtl, on 06 September 2012 - 04: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.

GopherAtl, on 08 September 2012 - 06:28 AM said:

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

function line(x1,y1,x2,y2)
  local distX=x2-x1
  local distY=y2-y1
  if math.abs(distX)>math.abs(distY) then
    --step over x
    local stepx=1
    if x2<x1 then
      stepx=-1
    end
    local stepy=stepx*distY/distX
    local y=y1    
    for x=x1,x2,stepx do
      term.setCursorPos(x,y)
      term.write("x")
      y=y+stepy
    end
  else
    --step over y
    local stepy=1
    if y2<y1 then
      stepy=-1
    end
    local stepx=stepy*distX/distY
    local x=x1    
    for y=y1,y2,stepy do
      term.setCursorPos(x,y)
      term.write("x")
      x=x+stepx
    end

  end
end

term.clear()
line(3,9,2,2)
line(3,9,7,4)
line(7,4,2,2)
term.setCursorPos(12,12)

GopherAtl, on 10 September 2012 - 12:50 AM said:

heh. yeah, my line algo is not very polished, but it was a rush job, and I hadn't implemented a line drawing algorithm in probably a decade or more. I plan on continuing with my logo project at least a bit longer, and eventually I'll get around to disecting and improving the line drawing algorithm; it was basically "good enough" for me to continue pushing forward with the proof of concept.

And actually, raster graphics replaced vector graphics 30 years ago. The earliest monitors were all vector-based, as early computers didn't have the memory for pixel graphics, at least not at any reasonable resolutions. Vector graphics are decidedly low tech, which is what I like about them :D/>/>

GopherAtl, on 10 September 2012 - 01:42 AM said:

Vector graphics can be implemented on a raster display easily, as I just proved, but a raster display can't be emulated with vectors, at least not in a sane way - vectors cease to use less memory if you fill the whole screen with 1-pixel-long lines of different colors!

term.newCanvas() - Returns a new canvas.
term.queueCanvas(canvas) - Queues the canvas to be displayed at the next display update.
canvas:setPixel(x, y, on) - Where canvas is the return value of term.newCanvas() if on is true sets pixel (x, y) on the canvas, otherwise clears it.
canvas:getPixel(x, y) - returns wether or not pixel (x, y) on that canvas is on.
canvas:setPixels(on, x1, y1, x2, y2, …, xn, yn) - sets the pixels indicated on the canvas if on is true otherwise clears them.

local canvas = term.newCanvas()
canvas:setPixels(true, 1, 1, 2, 1, 3, 1, 2, 2, 2, 3) --T stands for test :P/>/>

term.queueCanvas(canvas)

GopherAtl, on 29 September 2012 - 06:44 PM said:

I really don't know what's so nasty or complicated about line( x1, y1, x2, y2 ), which is the basic method for vector graphics… the logo language adds the idea of angles to that, but even that doesn't involve complex math. Logo is an example of something you can do with vector graphic though, not a proposed interface for them.

Pharap, on 29 September 2012 - 07:25 AM said:

There is of course an alternative that I wouldn't recommend be implemented in the the real world.
<snip>

robhol, on 01 October 2012 - 07:57 AM said:

I actually think this would be very nice. If we get this, then boom! suddenly, graphical OSes/shells :(/>/>

Personally, I'd want something basic that allows you to draw shapes possibly text. Sending the instructions instead of an entire bitmap would be likely to save some space if it's not insanely complicated. Either way, there are compression algorithms that could help diminish the traffic.

Pharap, on 02 October 2012 - 09:26 PM said:

robhol, on 01 October 2012 - 07:57 AM said:

I actually think this would be very nice. If we get this, then boom! suddenly, graphical OSes/shells :(/>/>

Personally, I'd want something basic that allows you to draw shapes possibly text. Sending the instructions instead of an entire bitmap would be likely to save some space if it's not insanely complicated. Either way, there are compression algorithms that could help diminish the traffic.

The best way would be to divide the CCcomputer screen up into a number divisible by 8 so that each 'pixel' can be represented by a single bit, eg if the screen was an 8x8 grid of pixels, it would take just 2 java integers to track the data (assuming my sources are corrent and Java integers take 2bytes, I could be wrong, Java's memory usage isn't as clearly laid out as C#). Logically, 2 integers per computer object shouldn't be a massive increase in network traffic. Especially when you consider that a string holding just one word would use more than that. Of course 8x8 isn't much, but it's better than nothing, and even if it was a 16x16 grid, that would be about 8 integers, which still isn't a hugely massive amount. I don't know how much memory strings take up in Java, but I'm pretty sure that the string "Java uses 2 bytes per integer" already exceeds the memory use of 8 integers. I could be wrong, but that's what I'd guess the situation is.

Xfel, on 03 October 2012 - 08:34 AM said:

And you are wrong, java integers take 4 byte. And a string takes for byte for the length integer and two byte for each character.

Xfel, on 03 October 2012 - 08:34 AM said:

And you are wrong, java integers take 4 byte. And a string takes for byte for the length integer and two byte for each character.

immibis, on 03 October 2012 - 03:22 AM said:

You can't do very much in 8x8 pixels.