Homebrew Pyramids QR Code Hacking

[elisherer]

Still in early development: http://code.google.com/p/pyramidsleveleditor/

you can try it yourself from the "browser source" and download the contents of the bin/debug dir...

---

 

[duke_srg]

00 00 is double space
00 xx is copy 3 blocks from... At least for p7-1c

A bit more accurate - if copy source offset less than current offset - write bytes as is, otherwise perform a copy.
But still can't guess 0C and 0B bytes in p7-1c.

 

[bailli]

DIssection of p2-1:

0x12 (player) 0x0D (fire) 0x00 (blank) 0x9001 (copy/write: offset 0x01 + 1; total count 0x9 + 3 => 12 tiles; since offset < 12 loop through offset till current pos) 0x00; end of first row
0x01 (sand block) 0x44 (some kind of control byte) 0x01 (sand block) 0xB001 (copy/write: offset < count: loop through last to tiles until 0xB+3 tiles are written); end of second row
0x0B (skull) 0x00 0x00 (two blanks) 0x9001 (copy/write offset < count: loop through last two bytes until 0x9+3 tiles are written) 0x0B (skull); end of row
0x1A (sand block covering coins) 0xEB (control byte?!) 0xD020 (copy: offset > count (0xD+3 tiles): copy sandblocks from second row); end of row
first sand block from this row got already copied 0xD02F (copy: offset > count (0xD+3 tiles): copy sandblocks from second row starting at the second tile => the skull from row three gets copied, too); end of row
skull already copied 0xB04F (copy: offset > count (0xB+3 tiles): copy fire/blank from first row (tile 2-15)) 0x0B (skull); end of row
0xE02E (copy 0xE+3 tiles from fourth row second tile); end of row
first sand block already copied 0x00 (blank) 0xA001 (copy/write offset < count: write sandblock/blank until 0xA+3 tiles are written) 0xE05F (copy 0xE+3 tiles from second row starting at tile 16); end of row
this row get already completly copied from row 3
0x48 (another control byte?!) 0x09 (amulet key) 0xB080 (copy 0xB+3 tiles from second row tile 1) 0x13 (door)

okay that's it.

only missing are the three (control?) bytes 0x44 0x48 0xEB

EDIT: hm the text is a bit unstructured but I hope it is understandable...

 

[duke_srg]

Several problems in P7-1c -
at least 0C, 0B, BF is ignored
00 00 0A treated as 3 bytes whereas 00 00 0D - as 00 + repeat 3 bytes from offset 0x0D
FIVE 05 instead of four

 

[elisherer]

DIssection of p2-1:

*snip*

Thanks!!! now my editor opens p2-1 flawlessly...

 

[elisherer]

Looking at "the list" I think every collectable has a covered by sand version...at index+1..

 

[morphius]

still nothing on 0x04 and last 6 bytes?

 

[bailli]

The three flag bytes after 0x10AA0000 are described as unkown, background, always1.
That is not true for p1-3. The always1 byte is 0x00.

Also in p1-3 the unkown byte is 0x04 and in p2-1 it is 0x12. Maybe this (or the always1 byte) is some
kind of mode setting concerning the copy/write mechanics - just a thought because our current
interpretation fits so well to p2-1 but isn't really convincing for p1-3.

 

[elisherer]

sorry i had a mistake on the 1st post...the right order is:

unknown, always1, background

Spoiler

p1-2 02 01 00
p1-3 12 01 00
p1-4 01 01 00
p1-5 16 01 00
p1-6 00 01 00
p1-7 09 01 01
p1-8 0A 01 01
p1-9 09 01 01
p2-1 04 01 01
p2-2 02 01 01
p2-3 09 01 01
p2-4 00 01 02
p2-5 00 01 02
p2-6 00 01 02
p2-7 05 01 02
p2-8 08 01 02
p7-1 00 01 04
p7-2 04 01 04
p7-3 09 01 04

 

[elisherer]

New item: The hourglass

[yt]BDv6JRi_XdA[/yt]

goto minute: 00:53

 

[morphius]

just an observation ...may be nothing but, 0x04 (the unknown) is always within the object range

 

[bailli]

Another dissection (but sadly not as thourogh) p1-3:

If i say "discard" it doesn't mean it is not necessary, but we don't know what to do with it...

1st row:
0x00 (blank) 0x2001 (copy/write: last "two" (only 1 byte available) tiles; count 5)
0x05 0x05 (two blocks) 0x4001 (loop 0x05 0x05; count 7)
0x32 (pillar top)
end of row; unaccounted: 0x00

2nd row:
0x12 (player) 0x00 (blank) 0x27 0x28 (top of 4cat) 0x02 (ammo)
0x00 (blank) 0x05 (block) 0x19 (coins)
now it gets messy: 0x00 0x00 0x15 0x15 0x01 0x01 (somehow
correspond to blank-4*sand as duke_srg pointed out)
0x00 (blank) 0x0F (dog left) 0x33 (pillar)
end of row; unaccounted: 0x08

3rd row:
0x2B 0x2C (top of 4twofig) 0x29 0x2A (bottom of 4cat)
0x000F (copy 3 tiles (ammo-blank-block) from above - why not blank-dog?)
0x05 (block) 0x00 (blank) 0x14 (fly)
0x80 (unkown) 0x0001 (copy 3 tiles (from offset -2 => blank-fly-blank)
0x05 0x05 0x33 (two blocks-pillar)
end of row;

4th row:
0x2D 0x2E (bottom of 4twofig) 0x00 (blank) 0x02 (ammo)
0x30 (unkown - discard) 0x02 (ammo) 0x0D (fire)
0x001F (copy 3 tiles from two rows above - (block-coins-blank)
0x2020 (copy 5 tiles row 2/starting tile 9: blank-4*sand)
0F (dog left) 0x33 (pillar)
end of row;

5th row:
0x23 024 (top 4block) 0x60 (discard) 0x00 (blank)
0x000E (copy 3 tiles from above+1tile: ammo-fire-block))
0x401F (copy 7 tiles from two rows above: (2*block-blank-fly-
blank-fly-blank)
0x14 (fly) 0x13 (door) 0x33 (pillar)
end of row;

6th row:
0x25 0x26 (bottom 4block) 0x3F (discard) 0x00 (blank) 0x02 (ammo)
0x004D (copy 3 tiles from 5 rows above(1st row)+2tiles: 3*block)
0x001F (copy 3 tiles from 2 rows above: coins-2*blank)
0x2056 (copy 3 tiles from first row/tile4: 3*blank)

now we have a problem again:
0x201F should result in: (copy 5 tiles from 2 rows above: sand-dog-pillar)
but that is obviously wrong. Additionally the next byte already
describes the 7th tile of the next row:

7th row (starting 7th tile):
0x105F (copy 4 tiles from 2 rows above: (2*block-blank)
0x301F (copy 5 tiles from 2 rows above: fly-blank-fly-blank-fly)
0x4E (discard) 0x00 (blank)
0x001F (copy 3 tiles from 2 rows above: pillar-bottom 4block)
end of row;


8th row:
bottom 4block from last copy; 0x0D (fire) 0x0D (fire)
0x005F (copy 3 blocks from 6 rows above: ammo-blank-block)
0x78 (discard)

here we are again 0x003F should be copy 3 tiles form 4 rows above
but the next byte is already next row tile 3....

9th row (starting tile 3):
0x23 (0x70 discard) 0x24 (top 4block)
0x0010 (copy 3 tiles from above+1tile: fire-ammo-blank)
0x5081 (copy 8 tiles from 1st row tile6: blank-7*block)
0x003F (copy 3 tiles from 4 rows above: (pillar-bottom 4block)

10th row:
first bottom 4block from last copy
0x25 0x26 (bottom 4block)
0x05 (block) 0x02 (ammo) 0x09 (amulet key)
0x501F (copy 8 blocks from 2 rows above: 7*blank-pillar)
end of row;

 

[elisherer]

just an observation ...may be nothing but, 0x04 (the unknown) is always within the object range

It's definantly not an object but it might be a BitString filled with flags and you can see that the first 4 bits is either 1 or 0...

 

[elisherer]

1 more icon: bug_chain (collectable)




Uploaded with ImageShack.us

Source: The manual

 

[duke_srg]

Started an analysys with p1-2
It's almost ok except of one copy command mismatch and several ignored bytes.

 

[elisherer]

Another "QR Making" game is going to be released by the same developer

http://3dsware.nintendolife.com/games/3dsware/block_factory

 

[duke_srg]

Tss.. don't make them know we know their secret

 

[elisherer]

I'm working on the editor as we speak...we'll keep it quiet for a while...you can delete the google document...

 

[elisherer]

Almost done...check the 1st post!

 

[bailli]

I got the part about the compression - but what about the checksum?

EDIT: or is it a checksum from the compression algorithm?