798 replies to this topic

[oeed]

FUNCTION MAN!, on 15 January 2016 - 01:11 AM, said:

I'm less concerned with image formats and more concerned with the fact that the GPU can access the file system.

I don't really see what's wrong with that. I mean, sure, from a 'real life' perspective it seems odd; but if it makes things simpler I don't see the issue.

[oeed]

Oh Dan you sneaky bugger



Given that the CC for 1.8 has been released we're one step closer, although Redirection is probably still top of the list.

Edited by oeed, 15 January 2016 - 11:16 PM.

[cyanisaac]

oeed, on 15 January 2016 - 11:11 PM, said:

Oh Dan you sneaky bugger



Given that the CC for 1.8 has been released we're one step closer, although Redirection is probably still top of the list.

I think he's probably counting down the release to Redirection, then CraftOS 2.0 will probably get more attention.

If I had to guess. Maybe he's switched gears and that's a countdown to CraftOS 2.0. Who knows?

[Justy]

cyanisaac, on 17 January 2016 - 02:54 AM, said:

If I had to guess. Maybe he's switched gears and that's a countdown to CraftOS 2.0. Who knows?

What if CraftOS is a part of Redirection this whole time?

[Waitdev_]

justync7, on 17 January 2016 - 04:50 AM, said:

cyanisaac, on 17 January 2016 - 02:54 AM, said:

If I had to guess. Maybe he's switched gears and that's a countdown to CraftOS 2.0. Who knows?

What if CraftOS is a part of Redirection this whole time?

ooo

[oeed]

cyanisaac, on 17 January 2016 - 02:54 AM, said:

I think he's probably counting down the release to Redirection, then CraftOS 2.0 will probably get more attention.

Hmm actually that's probably more correct.

Also, sorry for the massive screenshot, OS X doesn't like scaling retina screenshots

[cyanisaac]

oeed, on 17 January 2016 - 11:56 AM, said:

cyanisaac, on 17 January 2016 - 02:54 AM, said:

I think he's probably counting down the release to Redirection, then CraftOS 2.0 will probably get more attention.

Hmm actually that's probably more correct.

Also, sorry for the massive screenshot, OS X doesn't like scaling retina screenshots

// offtopic I'm jealous I'm on a nonretina macbook the display is so low res help me

[Creator]

Will the coordinate system start at 0 or at 1? 0 is better.

[Wojbie]

Creator, on 20 January 2016 - 02:05 PM, said:

Will the coordinate system start at 0 or at 1? 0 is better.

Well it is Lua based and Lua stuff starts from 1 so if you wanted it to stay logical...

[Creator]

Wojbie, on 20 January 2016 - 02:24 PM, said:

Creator, on 20 January 2016 - 02:05 PM, said:

Will the coordinate system start at 0 or at 1? 0 is better.

Well it is Lua based and Lua stuff starts from 1 so if you wanted it to stay logical...

Love2D starts at 0. And it is easier for the graphics math to have it be 0.

[dan200]

Creator, on 20 January 2016 - 02:05 PM, said:

Will the coordinate system start at 0 or at 1? 0 is better.

Pixel coords start at 0,0. I initially had them start at 1,1 to be more "lua-like", but it resulted in a lot of code ugly like "tilex = ((pixelx - 1)/tilewidth) + 1". One of the benefits of developing this in private is I can go back on bad API decisions

[Creator]

dan200, on 20 January 2016 - 08:24 PM, said:

Creator, on 20 January 2016 - 02:05 PM, said:

Will the coordinate system start at 0 or at 1? 0 is better.

Pixel coords start at 0,0. I initially had them start at 1,1 to be more "lua-like", but it resulted in a lot of code ugly like "tilex = ((pixelx - 1)/tilewidth) + 1". One of the benefits of developing this in private is I can go back on bad API decisions

Thank you!

Edited by Creator, 20 January 2016 - 09:40 PM.

[oeed]

dan200, on 20 January 2016 - 08:24 PM, said:

Pixel coords start at 0,0. I initially had them start at 1,1 to be more "lua-like", but it resulted in a lot of code ugly like "tilex = ((pixelx - 1)/tilewidth) + 1". One of the benefits of developing this in private is I can go back on bad API decisions

Oh dear. Not that that's a bad thing, I think it's good.

...it's just the 19 thousand lines I've gotta update to use a zero based coordinate system

[Waitdev_]

oeed, on 21 January 2016 - 12:02 AM, said:

dan200, on 20 January 2016 - 08:24 PM, said:

Pixel coords start at 0,0. I initially had them start at 1,1 to be more "lua-like", but it resulted in a lot of code ugly like "tilex = ((pixelx - 1)/tilewidth) + 1". One of the benefits of developing this in private is I can go back on bad API decisions

Oh dear. Not that that's a bad thing, I think it's good.

...it's just the 19 thousand lines I've gotta update to use a zero based coordinate system

well, you could use yer' favourite text editor and sniff out that little "find" tool

Edited by Waitdev_, 21 January 2016 - 02:02 AM.

[apemanzilla]

Waitdev_, on 21 January 2016 - 02:01 AM, said:

oeed, on 21 January 2016 - 12:02 AM, said:

dan200, on 20 January 2016 - 08:24 PM, said:

Pixel coords start at 0,0. I initially had them start at 1,1 to be more "lua-like", but it resulted in a lot of code ugly like "tilex = ((pixelx - 1)/tilewidth) + 1". One of the benefits of developing this in private is I can go back on bad API decisions

Oh dear. Not that that's a bad thing, I think it's good.

...it's just the 19 thousand lines I've gotta update to use a zero based coordinate system

well, you could use yer' favourite text editor and sniff out that little "find" tool

That won't work too well. A lot of basic UI calculations, like text centering, are different depending on whether the pixels start at 0 or 1, for example.

[oeed]

dan200, on 15 January 2016 - 01:37 AM, said:

I may go back on this later, but right now, the filesystem is a shared resource which all devices can access (as is the main memory). A benefit of this is it allows the Lua CPU to be "just another device" without any special privileges.

Another thing on the file system, what is the speed like? I noticed a few things slowing down and realised that it was the file system reading files.

Essentially, when you have binary images files that are 24+ kilobytes the fastest I could possibly get it reading was about 0.05 seconds (average of 100 trials) in Minecraft (i.e. not an emulator). It mightn't sound terrible, but that simply isn't viable. If you're trying to display just a handful of those the system will freeze for a noticeable amount of time, especially when the user is used to 60ish FPS.

Here's the code I was using to test it. Note, I'm not actually doing anything with the data. I'm literally just reading the bytes.

local s = os.clock()
local n = 100
for i = 1, n do
  local handle = fs.open( "Arc de Triomphe.ucg", "rb" )
  if handle then
	local read = handle.read
	local lastByte
	repeat
	 lastByte = read()
	until not lastByte
	handle.close()
  end
end
print( "Total time: "..( os.clock() - s ) / n )

Given the likely increase in fairly large binary files, I'd be good if this could be improved upon.

We don't really know much about how the file system works, but if it's fairly similar to the CC method I'd suggest creating a .readAll function for binary files that returns a table of all the bytes (as numbers).

Edited by oeed, 22 January 2016 - 03:22 AM.

[dan200]

In CraftOS 2 the API matches the Lua standard: you don't have to read binary files one byte at a time anymore.

[Konlab]

oeed, on 21 January 2016 - 12:02 AM, said:

dan200, on 20 January 2016 - 08:24 PM, said:

Pixel coords start at 0,0. I initially had them start at 1,1 to be more "lua-like", but it resulted in a lot of code ugly like "tilex = ((pixelx - 1)/tilewidth) + 1". One of the benefits of developing this in private is I can go back on bad API decisions />

Oh dear. Not that that's a bad thing, I think it's good.

...it's just the 19 thousand lines I've gotta update to use a zero based coordinate system />

Or just write a term redirect that changes every position to position - 1

[Creator]

Konlab, on 22 January 2016 - 06:07 PM, said:

oeed, on 21 January 2016 - 12:02 AM, said:

dan200, on 20 January 2016 - 08:24 PM, said:

Pixel coords start at 0,0. I initially had them start at 1,1 to be more "lua-like", but it resulted in a lot of code ugly like "tilex = ((pixelx - 1)/tilewidth) + 1". One of the benefits of developing this in private is I can go back on bad API decisions />

Oh dear. Not that that's a bad thing, I think it's good.

...it's just the 19 thousand lines I've gotta update to use a zero based coordinate system />

Or just write a term redirect that changes every position to position - 1

It adds an extra layer of operations significantly slowing everything down.

[Konlab]

Creator, on 22 January 2016 - 06:12 PM, said:

Konlab, on 22 January 2016 - 06:07 PM, said:

oeed, on 21 January 2016 - 12:02 AM, said:

dan200, on 20 January 2016 - 08:24 PM, said:

Pixel coords start at 0,0. I initially had them start at 1,1 to be more "lua-like", but it resulted in a lot of code ugly like "tilex = ((pixelx - 1)/tilewidth) + 1". One of the benefits of developing this in private is I can go back on bad API decisions />/>

Oh dear. Not that that's a bad thing, I think it's good.

...it's just the 19 thousand lines I've gotta update to use a zero based coordinate system />/>

Or just write a term redirect that changes every position to position - 1

It adds an extra layer of operations significantly slowing everything down.

I don't think there is a better solution other than changing those 19k lines.