Netlogo export-world format - netlogo

Question

I have been experimenting trying to work out how does the export-world work, in particular how does the DRAWING section work.
I created the following code to experiment using the default environment size of max-pxcor and max-pycor of 16. If you run this code shown at the end of this post, each file produced will be 5 megabytes, so it is easy to use up over a gigabyte of data after a minute of running.
Anyway, my question is this: How does the DRAWING section work? I have seen that the first entry is at -16.4, 16.4. I have summarised some of my observations in the simple table below. The first column is how much the turtle has moved, while the second column shows partial output in the CSV file.
0.001 FF1D9F78
0.016 FF1D9F78FF1D9F78
0.093 FF1D9F78FF1D9F78FF1D9F78
I have also seen that the first entry is created when the turtle moves by 0.001.The second entry seems to happen when the turtle has moved by 0.016 and the third entry is 0.093.
I am trying to work out what the pattern could be, but there doesn't seem to be one. How much turtle movement does one of the entries represent in the CSV file?
Thanks.
---- The code is below.
globals
[
totalAmount
]
to setup
ca
crt 1
[
setxy -16.4 16.4
pd
set heading 90
set color turquoise
]
set totalAmount 0
end
to go
ask turtles
[
fd moveAmount
]
set totalAmount moveAmount + totalAmount
export
end
to export
let filetemp word "turtletest" totalAmount
let filename word filetemp ".csv"
;print filename
export-world filename
end

Answer 1

The drawing layer is just a bitmap – a grid of pixels. It doesn't know what turtles moved and how far, it only knows what pixels the turtles colored in while moving. Internally, it's a java.awt.image.BufferedImage with TYPE_INT_ARGB encoding.
It's written to an exported world file by this code:
https://github.com/NetLogo/NetLogo/blob/533131ddb63da21ac35639e61d67601a3dae7aa2/src/main/org/nlogo/render/TrailDrawer.java#L217-L228
where colors is the array of ints backing the BufferedImage, and toHexString just writes bytes as hexadecimal digits (code).
If your image is mostly black, you'll mostly see a bunch of 00 bytes in the file.
As for your non-zero bytes, it appears to me that FF1D9F78 is a pixel with alpha = FF (opaque), red = 29, green = 159, blue = 120. At least, I think that's the right interpretation? Is that plausible for what you're seeing on screen? Maybe the A-R-G-B bytes are in the reverse order? To double check it, I'd need to do export-view and then look at the resulting PNG file in a program that could tell me the RGB values of individual pixels -- I don't have such a program handy right now. But hopefully this'll put you on the right track.