This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Waitdev_'s profile picture

Optimization of printing pictures

Started by Waitdev_, 28 October 2015 - 09:40 AM
Waitdev_ #1
Posted 28 October 2015 - 10:40 AM
The better way to print pictures
As it says™. This tutorial is simply making it faster to print pictures, as it makes a significant difference. This can be used for animations, huge rendering and more.

Normally printing pictures
Now, as a lot of people normally print pictures they might do something like this:

pic = paintutils.loadImage("somerandompicture")
paintutils.drawImage(pic,1,1)

after testing this for speeds, it got 0.1 seconds. i know its not really much, but it can do better if you're printing multiple pictures, or printing to a monitor. if its 2 pictures, that would get 0.2 seconds. 10 would be 1 second. with the next yet quite bigger code, its easier to get better speeds.

loadedfile = "Your Picture Here™"
function load(file) --thanks valithor and bomb bloke for teaching me this ;)/>/>
  local out = {}
  for line in io.lines(file) do
	out[#out + 1] = line
  end
  return out
end
file = fs.open(loadedfile,"r")
lines = load(loadedfile)
space = ""
for i = 1,#lines do
  for i = 1,#lines[i] do
	space = space.." "
  end
  term.blit(space,space,lines[i])
  write("\n")
  space = ""
end
i know that's 10 times bigger, but it will do. it's only over ~390 bytes compared to ~140 bytes.
all math aside, it does do the trick. with some tests, this got 0.05 seconds each time.
remember i said 10 pics would be a second? now it's a half second. this will again help you people print crazy huge pictures on crazy huge monitors.
what its doing in order:
  • loading and splitting a file into its lines
  • calculating the length of each line, to fit the spaces making colour
  • blitting each line, makes it faster to print a line
  • nothing else, it didn't really do much in the first place
any feedback will be appreciated, though this is just a small thing i found out using term.blit
Edited on 28 October 2015 - 09:42 AM
MKlegoman357 #2
Posted 28 October 2015 - 12:21 PM
I don't really see how this is a tutorial. A code snippet (which has some mistakes and enforces bad coding habits) should not be considered a tutorial.
Bomb Bloke #3
Posted 28 October 2015 - 12:58 PM
It does technically work (somewhat to my surprise - I wasn't aware that term.blit() accepts spaces within its second and third parameters), though it could be optimised. Removing the redundant fs.open() call, for example, and rigging it to "draw" at a specified screen co-ord.

This bit here:

  for i = 1,#lines[i] do
        space = space.." "
  end

… could just be written as:

  local space = string.rep(" ", #lines[i])

But really it'd be faster to just do:

  local line = lines[i]  -- Cache a table lookup.
  term.blit(line, line, line)  -- Use the result for all three of blit's parameters.

For one-shot images, you could even stick the blit calls within the io.lines()-based "for" loop, skipping the table access entirely.

But yeah, a tutorial generally explains how to do something, step by step, while explaining the mechanics of those steps. "Here's a block of code" doesn't fit the bill.
Lyqyd #4
Posted 28 October 2015 - 03:44 PM
Moved to APIs and Utilities.
Creator #5
Posted 28 October 2015 - 04:26 PM
That part where you open the file outside of the function and don't close it afterwards makes me shiver. Just open the file in the function and fix the variable names. Don't get me wrong, I respect you as a person and the idea there is nice, but the implementation is horrible. With friendly feelings, Creator.
Edited on 28 October 2015 - 03:26 PM
Waitdev_ #6
Posted 31 October 2015 - 12:49 AM
thanks for the feedback everyone. i guess i really could of done better -_-/>
also, thanks for all the tips i didn't know about a lot of things, it will help me be able to optimize my OS when i work on it more.