PokeCC & Game-Engine(map/tile-based engine) - What do YOU want to see?

Geforce Fan, on 15 June 2014 - 05:25 AM said:

The idea of onlying having 16 colors in computercraft is not true. Colors powers of 2 and are numbers. There are a lot more colors than you'd think, however some are a bit harder to use.

Geforce Fan, on 15 June 2014 - 05:55 AM said:

Read the entire post.

theoriginalbit, on 15 June 2014 - 06:12 AM said:

Geforce Fan, on 15 June 2014 - 05:55 AM said:

Read the entire post.

which part in particular am I meant to read?

Geforce Fan, on 15 June 2014 - 05:25 AM said:

Edit: Nevermind, I guess colors now rounds to the nearest one. It didn't used to be that way. I really wish they'd give us more colors, this is rediculace. But either way, I'm going to make pokemon in CC, even if it's graphics are horrible.

Bomb Bloke, on 15 June 2014 - 06:23 AM said:

In ComputerCraft, 16 different powers of two are available as "colours". Granted, you could combine these values together, but that doesn't mean it'll render the results. Basically it's a 16 colour palette - the reason for using powers of two to index into it likely has more to do with RedPower's bundled cables (which accept 16 bit signals) than anything else.

If you wanted to be pedantic, I suppose you could say that the foreground version of "black" doesn't match the one used for background rendering. For bonus points you might assert that black and white aren't colours, but shades. The fact remains that when specifying a text or background colour for use in ComputerCraft, you've got 16 options.

Geforce Fan, on 15 June 2014 - 05:55 AM said:

on

Geforce Fan, on 15 June 2014 - 05:55 AM said:

my

Geforce Fan, on 15 June 2014 - 05:55 AM said:

monitor

Geforce Fan, on 15 June 2014 - 05:25 AM said:

It

Geforce Fan, on 15 June 2014 - 03:00 AM said:

is

Geforce Fan, on 15 June 2014 - 03:00 AM said:

the

Geforce Fan, on 15 June 2014 - 03:00 AM said:

same

Geforce Fan, on 15 June 2014 - 06:40 AM said:

Edit: Nevermind, I guess colors now rounds to the nearest one. It didn't used to be that way. I really wish they'd give us more colors, this is rediculace. But either way, I'm going to make pokemon in CC, even if it's graphics are horrible.

local real = 2 ^ math.floor( math.log(providedColour) / math.log(2) )

rs.setBundledOutput("right", colours.combine(colours.white, colours.orange))

Geforce Fan, on 15 June 2014 - 06:57 AM said:

I was talking about the thing where he said text black isn't the same as background black. I have a high-quality 1080 LED IPS and they're the same.

local function log2( n )
  return math.floor( math.log(n) / math.log(2) )
end

local function compressColor( c1, c2 )
  local low = bit.band( log2( c1 ), 0xF )
  local high = bit.band( log2( c2 ), 0xF )
  local color = bit.bor( bit.blshift( high, 4 ), low )
  return color
end

local function uncompressColor( color )
  local low = bit.band( b, 0xF )
  local high = bit.brshift( b, 4 )
  return 2^high, 2^low
end

Geforce Fan, on 16 June 2014 - 08:49 AM said:

pretty sure that'd only save a few kilobytes.

local tLines = {}
local size = 0
for iX,vX in pairs(tMap) do
  tLines[iX] = ""
  size = math.max(size,iX)
  for iZ,vZ in pairs(vX) do
	local line = tLines[iX]
	tLines[iX] = (
	  iZ > #line 
          and line..string.rep(" ",math.max(0,iZ-#line-1))..vZ
	  or line:sub(1,iZ-1)..vZ..line:sub(iZ+1)
	)
  end
end
local file = fs.open("mapFile","w")
for line=1,size do
  file.writeLine(tLines[line] or "")
end
file.close()

Geforce Fan, on 16 June 2014 - 08:56 PM said:

here's the actual largest version. 16KB for filling the screen with solid red.
http://www.pastebin.com/iWx7z2g2

white       0000
orange      0001
magenta     0010
lightBlue   0011
yellow      0100
lime        0101
pink        0110
gray        0111
lightGray   1000
cyan        1001
purple      1010
blue        1011
brown       1100
green       1101
red         1110
black       1111

Geforce Fan, on 17 June 2014 - 09:08 AM said:

Oh. Thanks. So a real example for that would be:
00110000

local function log2( n )
  return math.floor(math.log(n) / math.log(2))
end

local function packBoolean( nibble, bool )
  return bit.bor(bit.blshift(nibble, 1), bool and 1 or 0)
end

local function unpackBoolean( byte, mask )
  return bit.band(byte, mask) == mask
end

local function packByte( color, solid, cliff, water, battle )
  return bit.bor(bit.blshift(packBoolean(packBoolean(packBoolean(packBoolean(0, solid), cliff), water), battle), 4), log2(color))
end

--# returns in the order color, solid, cliff, water, battle
local function unpackByte( byte )
  return 2^bit.band(byte, 0xF), unpackBoolean(byte, 128), unpackBoolean(byte, 64), unpackBoolean(byte, 32), unpackBoolean(byte, 16)
end

local t1 = {colors.orange, true, true, false, false}
local t2 = {colors.red, true, false, true, false}

local t3 = {unpackByte(packByte(unpack(t1)))}
local t4 = {unpackByte(packByte(unpack(t2)))}

for i,v in ipairs(t1) do
  if t3[i] ~= v then
    error("t1: something went wrong", 0)
  end
end
for i,v in ipairs(t2) do
  if t4[i] ~= v then
    error("t2: something went wrong", 0)
  end
end

Bomb Bloke, on 17 June 2014 - 09:59 AM said:

I've been keeping sorta half an eye on this thread, and I suppose I would like to suggest "half decent graphics". At the moment I get the impression you're gunning for something that Dwarf Fortress would put to shame.

The way I see it, you could probably get away with square 9x6 character "sprites".

You dump these sprites into a table (along with the properties of the tiles that go with them), then your map consists of indexes pointing into that tile table. You could even attach sets of sprites to a given tile (which the game would run through in sequence, eg in order to animate a wave on the beach).

There are two obvious issues here:

One is that this just isn't workable unless you're playing on a monitor - something like 5x5 with the smallest text scale, at the least. Obviously, I'm proposing that a monitor be put to good use: it'd be simple to control your character by clicking a tile, and having him/her pathfind there.

The other is that, even with a monitor, this adds up to an awful lot of data being rendered to the screen. I would say that it's worth it, though, and could be mitigated by a complete lack of map scrolling - similar to ye olde games of yore, the full display need only be updated when you hit a map edge.

theoriginalbit, on 17 June 2014 - 10:23 AM said:

in addition to what Bomb Bloke is saying, you could define more detail in sprites through use of coloured texts as well as coloured backgrounds (yes the save file I have could be modified for that too, each tile would take up more than 1 byte though).

Geforce Fan, on 17 June 2014 - 09:08 AM said:

Oh. Thanks. So a real example for that would be:
00110000

well again, no.

having `s` as true in the table, and having `c` as colours.white, would yield 00010000

EDIT: I got bored, and the boredom yielded this.

Improved State Packer

local function log2( n )
  return math.floor(math.log(n) / math.log(2))
end

local function packBoolean( nibble, bool )
  return bit.bor(bit.blshift(nibble, 1), bool and 1 or 0)
end

local function unpackBoolean( byte, mask )
  return bit.band(byte, mask) == mask
end

local function packByte( color, solid, cliff, water, battle )
  return bit.bor(bit.blshift(packBoolean(packBoolean(packBoolean(packBoolean(0, solid), cliff), water), battle), 4), log2(color))
end

--# returns in the order color, solid, cliff, water, battle
local function unpackByte( byte )
  return 2^bit.band(byte, 0xF), unpackBoolean(byte, 128), unpackBoolean(byte, 64), unpackBoolean(byte, 32), unpackBoolean(byte, 16)
end

Test code to make sure it reads bytes back correctly

local t1 = {colors.orange, true, true, false, false}
local t2 = {colors.red, true, false, true, false}

local t3 = {unpackByte(packByte(unpack(t1)))}
local t4 = {unpackByte(packByte(unpack(t2)))}

for i,v in ipairs(t1) do
  if t3[i] ~= v then
	error("t1: something went wrong", 0)
  end
end
for i,v in ipairs(t2) do
  if t4[i] ~= v then
	error("t2: something went wrong", 0)
  end
end

I would like to point out again that all this extra info has been added at no extra expense to file size ;)/>/>

Geforce Fan, on 29 June 2014 - 08:50 PM said:

Here's the new format's first test: http://pastebin.com/WqjTy18Y
Can't be sure it worked; I havn't wrote a load function yet. It looks messed up but it might be fine.

Geforce Fan, on 29 June 2014 - 08:50 PM said:

edit: tried a single gray dot at the top and got 135. something is wrong. probably something simple, too.
edit: it's something with the pack function. Do note I'm passing nil for boolean values.

theoriginalbit, on 30 June 2014 - 01:47 AM said:

Geforce Fan, on 29 June 2014 - 08:50 PM said:

Here's the new format's first test: http://pastebin.com/WqjTy18Y
Can't be sure it worked; I havn't wrote a load function yet. It looks messed up but it might be fine.

well the first thing to note is you can't use the HTTP API with that file format, unless you make use of base64 encoding, a LuaJ bug stops you sadly from having bytes >127

Geforce Fan, on 29 June 2014 - 08:50 PM said:

edit: tried a single gray dot at the top and got 135. something is wrong. probably something simple, too.
edit: it's something with the pack function. Do note I'm passing nil for boolean values.

colors.gray should give a result of 7, what's the code you're using? also it should be noted that passing nil will inevitably converted to false, with the logic I've used. there's no way to store nil, it's either true or false.

Geforce Fan, on 30 June 2014 - 03:00 AM said:

Why wouldn't I be able to use http?

theoriginalbit, on 30 June 2014 - 01:47 AM said:

unless you make use of base64 encoding, a LuaJ bug stops you sadly from having bytes >127

Geforce Fan, on 30 June 2014 - 03:06 AM said:

http://pastebin.com/W7wH8T3B - code being used to make the save

I don't understand. I thought the data was going to be packed into a single byte; it's in 3 bytes from what I can see.

CometWolf, on 16 June 2014 - 09:22 PM said:

That's an awful waste of space. Each color should be represented by a character, which is converted to a color when loaded or drawn. Ideally, it should look something like the lower layers of this
http://pastebin.com/t6erfyeu
This is huge, but it's a 90 block tall tower, so it's to be expected :P/>
Infact, you could handle this much the same way i do. In Turtle Architect, a built block is represented by an uppercase letter, while an unbuilt block is a lowercase. Using this same technique, you could represent solids with uppercase and non-solids with lowercase. Even while keeping your format as a serialized table(bad idea) it would save lots of space.

theoriginalbit, on 30 June 2014 - 03:21 AM said:

Geforce Fan, on 30 June 2014 - 03:00 AM said:

Why wouldn't I be able to use http?

theoriginalbit, on 30 June 2014 - 01:47 AM said:

unless you make use of base64 encoding, a LuaJ bug stops you sadly from having bytes >127

with the LuaJ bug anything >127 comes up as 127. it only occurs in events though, meaning the HTTP API cannot support binary strings.

Geforce Fan, on 30 June 2014 - 03:06 AM said:

http://pastebin.com/W7wH8T3B - code being used to make the save

I don't understand. I thought the data was going to be packed into a single byte; it's in 3 bytes from what I can see.

it shouldn't be… how are you 'seeing' how many bytes it is stored in?

Geforce Fan, on 30 June 2014 - 03:29 AM said:

1 character, regardless of what it is is 1 byte. Like, that last sentance is ~48 bytes(probably off, but it proves the point regardless.)

theoriginalbit, on 30 June 2014 - 04:29 AM said:

EDIT: also your code is, well, horrendous to read, and I'm still trying to completely understand what you're doing, but I'm noticing a huge lack of variable localisation and a massive lack of optimisation.
[namedspoiler=for example here's just two optimisations you can make]
[b]Your code[/b]
[code]
paintutils.drawPixel(51,1,colors.white)
paintutils.drawPixel(51,2,colors.orange)
paintutils.drawPixel(51,3,colors.magenta)
paintutils.drawPixel(51,4,colors.lightBlue)
paintutils.drawPixel(51,5,colors.yellow)
paintutils.drawPixel(51,6,colors.lime)
paintutils.drawPixel(51,7,colors.pink)
paintutils.drawPixel(51,8,colors.gray)
paintutils.drawPixel(51,9,colors.lightGray)
paintutils.drawPixel(51,10,colors.cyan)
paintutils.drawPixel(51,11,colors.purple)
paintutils.drawPixel(51,12,colors.blue)
paintutils.drawPixel(51,13,colors.brown)
paintutils.drawPixel(51,14,colors.green)
paintutils.drawPixel(51,15,colors.red)
paintutils.drawPixel(51,16,colors.black)
[/code]

[b]Improved code[/b]
[code]
for i = 1, 16 do
paintutils.drawPixel(51, i, 2^(i-1))
end
[/code]

[b]Your code[/b]
[code]
if events[4] == 1 then
currentColor=colors.white
elseif events[4] == 2 then
currentColor=colors.orange
elseif events[4] == 3 then
currentColor=colors.magenta
elseif events[4]==4 then
currentColor=colors.lightBlue
elseif events[4]==5 then
currentColor=colors.yellow
elseif events[4] == 6 then
currentColor=colors.lime
elseif events[4]==7 then
currentColor=colors.pink
elseif events[4]==8 then
currentColor=colors.gray
elseif events[4] == 9 then
currentColor=colors.lightGray
elseif events[4] == 10 then
currentColor=colors.cyan
elseif events[4] ==11 then
currentColor=colors.purple
elseif events[4] ==12 then
currentColor=colors.blue
elseif events[4]==13 then
currentColor=colors.brown
elseif events[4]==14 then
currentColor=colors.green
elseif events[4] ==15 then
currentColor=colors.red
elseif events[4] ==16 then
currentColor=colors.black
elseif events[4] ==17 then–erasing
currentColor=nil
end
[/code]

[b]Improved code[/b]
[code]
if events[4] == 17 then
currentColor = nil
elseif events[4] > 0 and events[4] < 17 then
currentColor = 2^(events[4] - 1)
end
[/code]
[/namedspoiler]
[/quote]

Geforce Fan, on 30 June 2014 - 06:22 AM said:

-snip-

Bomb Bloke, on 02 July 2014 - 01:54 AM said:

Paint saves data by creating an ASCII representation of a hex representation of the powers applied to two to get the correct colour values to represent each position in the image. This makes it easy for the human eye to read, and isn't terribly inefficient; the files are only about twice the size they could be.

You could do something similar, but you'd be limited to something like less than a hundred different sorts of tiles to play with. Though I'm getting a sinking feeling that you'll probably end up devoting just one character on the screen to each tile anyway…

Writing actual zeros and ones to your file in ASCII (as opposed to packing eight of those bits into each byte) would bloat your files by 8x, however. So, um, don't do that.

Geforce Fan, on 02 July 2014 - 09:06 PM said:

It would not have ACSCII. Plus, it couldn't with an actual 51x19. I want to use all mechanics from the normal game.

Geforce Fan, on 02 July 2014 - 09:06 PM said:

It's been like a month since I started this project. I don't mean to offend, but I really need a simple answer, not a 1/2 answered question. This project has been preventing me from moving on, I really want to get on to other projects. I can't figure out this binary stuff, and I need help. How do I make a full save file with binary?

Bomb Bloke, on 03 July 2014 - 03:53 AM said:

Well, more what I was getting at was the "singular" use of characters per tile - bearing in mind that everything CC lets you render counts as a "character", spaces included, drawings with paintutils definitely included.

As mentioned, I realise this would necessitate the use of a monitor to increase the display resolution, but I won't repeat myself too much.