Jump to content




[1.4/1.5] Pixel Manipulation


  • You cannot reply to this topic
80 replies to this topic

#61 Pharap

  • Members
  • 816 posts
  • LocationEngland

Posted 09 September 2012 - 11:36 PM

View PostGopherAtl, on 08 September 2012 - 05: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

I'll be fair, you did actually go and do it, and in that situation vector graphics are better,
but when I tried the following:
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)

The results weren't exactly the 3 lines expected, so needless to say it needs a bit of work.
The whole 'real line' to 'pixel line' thing is the main reason I say vector graphics aren't as simple as you would first expect.
Not saying they aren't useful, but there are reasons that they have yet to replace raster graphics, and I doubt it's merely because raster graphics are more user friendly, because as any programmer knows, with the right user interface, even complex tasks can look simple.

I do however encourage you to keep doing what you are doing and hopefully figure out why some of these little obscurities occur and how to get around them.

#62 GopherAtl

  • Members
  • 888 posts

Posted 09 September 2012 - 11:50 PM

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

#63 Pharap

  • Members
  • 816 posts
  • LocationEngland

Posted 10 September 2012 - 12:34 AM

View PostGopherAtl, on 09 September 2012 - 11:50 PM, 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/>

Well, if you think Vector graphics are the way forward for CC, a good API is always the best way to prove a point (aside from my favourite technique, the cannon, but sadly they've become less effective since the introduction of the internet).

Makes me yearn for floppy disks, even though I've only ever owned about 1.
It makes me beg the question though, surely using less memory was a good thing, but hey-ho, I'm no computer scientist.
I yearn for the days when it wasn't all 'screw gameplay, this game has good graphics'.
I'm going to stop now before I start talking about cathode ray tubes.

#64 GopherAtl

  • Members
  • 888 posts

Posted 10 September 2012 - 12:42 AM

well, less memory was good, but memory became cheap, and raster graphics are more flexible. 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!

:edit: refreshed myself on bresenham's algorithm and wrote a new line function earlier. This version should give you the lines you expected in your example before :D/> Logo api has been updated, link's in my logo thread

Spoiler


#65 dimitriye98

  • Members
  • 77 posts

Posted 15 September 2012 - 11:13 PM

Ok, still, though, raster graphics are easier to use. You argued that with vector graphics the server can have the client do the heavy lifting, you can do that with raster as well. The server tells the client a set of coordinates, probably compressed, and the client draws them. Honestly, as you said:

View PostGopherAtl, on 10 September 2012 - 12: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!
So, honestly, raster graphics seem better. You won't need that much memory if you limit the display clock-speed. What about this:

Quote

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.


#66 GopherAtl

  • Members
  • 888 posts

Posted 16 September 2012 - 12:01 AM

that's the thing. Setpixel is bandwidth-unfriendly. If you were going to a raster display, you'd want to do what early raster displays for real-time graphics did - with tile/sprite sets, rather than pixel-level manipulation.

#67 dimitriye98

  • Members
  • 77 posts

Posted 28 September 2012 - 11:09 PM

No, it isn't. You do this:
local canvas = term.newCanvas()
canvas:setPixels(true, 1, 1, 2, 1, 3, 1, 2, 2, 2, 3) --T stands for test :P/>/>
and the server doesn't send any data to the client until you do this:
term.queueCanvas(canvas)


#68 GopherAtl

  • Members
  • 888 posts

Posted 29 September 2012 - 02:56 AM

yeeah. You're suggesting that if the per-pixel api is implemented in a specific way that would be not at all intuitive to the average computercraft programmer, who has zero prior programming experience, graphics or otherwise, then yes, there's no problem.

Text mode works better with a buffer and a single command to send it to the client, too. It doesn't have one built-in for a reason.

#69 Pharap

  • Members
  • 816 posts
  • LocationEngland

Posted 29 September 2012 - 06:25 AM

There is of course an alternative that I wouldn't recommend be implemented in the the real world.
Since vector graphics tend to be complicated for those less mathematically inclined, and raster graphics tend to waste memory, there is one alternative.
Since images tend to have certain colours grouped together (eg the CC monitor, loads of black pixels grouped in a square), you can save on the information required by treating the image as groups of pixels instead of single points. That way, if you want to shade an entire line of pixels, instead of doing each one individually, have a function that says shade the pixels from x5 to x10 at y6, which is the same as setting 5 points (10 numbers) but instead doing it all at once (using 3 numbers). And when I say line, I don't mean treating it as an actual line, I mean a line of pixels.
Thus, such a method would be a simple half way between raster and vector.

In a way it would be like autoshapes in paint.

Have functions that draw the following shapes:
-Horizontal Line
-Vertical Line
-Filled Square
-Empty Square

And you could save on data without any nasty complicated equations.
Any objections?

#70 GopherAtl

  • Members
  • 888 posts

Posted 29 September 2012 - 05:44 PM

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.

#71 Pharap

  • Members
  • 816 posts
  • LocationEngland

Posted 29 September 2012 - 06:12 PM

View PostGopherAtl, on 29 September 2012 - 05: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.
the nasty bit is figuring out how to express the line in pixels (writing code to decide which pixels the line intersects, not forgetting to account for scaling and angles)

#72 dimitriye98

  • Members
  • 77 posts

Posted 30 September 2012 - 07:55 AM

Ok, then hide my buffering in the java implementation, that can't be too hard?
Honestly, I am absolutely sure that buffered raster graphics are the way to go. Ok, so you implement un-buffered vector graphics. Then some smartass makes raster graphics by making tons of 1 pixel length lines on the screen. Have you achieved anything? If you make buffered raster graphics, that same smartass can try to make vector graphics. And he'll succeed, because while raster graphics cannot be expressed in any reasonable way using vector graphics, vector graphics can EASILY be implemented using raster graphics.

#73 immibis

    Lua God

  • Members
  • 1,033 posts
  • LocationWellington, New Zealand

Posted 30 September 2012 - 09:50 AM

View PostPharap, on 29 September 2012 - 06:25 AM, said:

There is of course an alternative that I wouldn't recommend be implemented in the the real world.
<snip>
You've just described a limited subset of vector graphics.

#74 dimitriye98

  • Members
  • 77 posts

Posted 01 October 2012 - 05:01 AM

You know, all I have to do is bump this thread every so often, the topic so controversial that the thread floats at the top of the forum for weeks at a time.

#75 robhol

  • Members
  • 182 posts

Posted 01 October 2012 - 06:57 AM

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.

#76 Pharap

  • Members
  • 816 posts
  • LocationEngland

Posted 02 October 2012 - 08:26 PM

View Postrobhol, on 01 October 2012 - 06: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.

#77 immibis

    Lua God

  • Members
  • 1,033 posts
  • LocationWellington, New Zealand

Posted 03 October 2012 - 02:22 AM

View PostPharap, on 02 October 2012 - 08:26 PM, said:

View Postrobhol, on 01 October 2012 - 06: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.

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

#78 Xfel

    Peripheral Designer

  • Members
  • 515 posts

Posted 03 October 2012 - 07:34 AM

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.

#79 Cloudy

    Ex-Developer

  • Members
  • 2,543 posts

Posted 03 October 2012 - 10:59 AM

With the upcoming background colour support, you could emulate pixels to some extent.

#80 PixelToast

  • Signature Abuser
  • 2,265 posts
  • Location3232235883

Posted 03 October 2012 - 01:57 PM

View PostXfel, on 03 October 2012 - 07: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.
well actually minecraft stores its own font table of 16x16 making it only one byte per character, although notch could have forgot to convert it to a byte before sending





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users