Questions about Crafti code

[ThatHackerDudeFromCyberspace]

We can see doorrenderer using the block side data:

void DoorRenderer::toggleState(const BLOCK_WDATA block, int local_x, int local_y, int local_z, Chunk &c, const uint8_t open_state)
{
    BLOCK_SIDE side = static_cast<BLOCK_SIDE>(getBLOCKDATA(block) & BLOCK_SIDE_BITS);

    uint8_t new_data = door_side_map[side] | open_state | (getBLOCKDATA(block) & DOOR_TOP);

    c.setLocalBlock(local_x, local_y, local_z, getBLOCKWDATA(getBLOCK(block), new_data));

    //Change the other door part as well
    if(getBLOCKDATA(block) & DOOR_TOP) //If top
            c.setGlobalBlockRelative(local_x, local_y - 1, local_z, getBLOCKWDATA(getBLOCK(block), new_data ^ DOOR_TOP));
    else
            c.setGlobalBlockRelative(local_x, local_y + 1, local_z, getBLOCKWDATA(getBLOCK(block), new_data ^ DOOR_TOP));
}

This seems to indicate that it is first three bits?
(as in the bits with values1,2 and 4)

BLOCK_SIDE side = static_cast<BLOCK_SIDE>(getBLOCKDATA(block) & BLOCK_SIDE_BITS);

Since BLOCK_SIDE_BITS is 0b111 it seems to be this way

[ThatHackerDudeFromCyberspace]

It makes you wonder what this is for:

typedef uint8_t BLOCK_SIDE_BITFIELD;
constexpr BLOCK_SIDE_BITFIELD BLOCK_FRONT_BIT = 1;
constexpr BLOCK_SIDE_BITFIELD BLOCK_BACK_BIT = 2;
constexpr BLOCK_SIDE_BITFIELD BLOCK_LEFT_BIT = 4;
constexpr BLOCK_SIDE_BITFIELD BLOCK_RIGHT_BIT = 8;
constexpr BLOCK_SIDE_BITFIELD BLOCK_TOP_BIT = 16;
constexpr BLOCK_SIDE_BITFIELD BLOCK_BOTTOM_BIT = 32;

constexpr BLOCK_SIDE_BITFIELD blockSideToBit(const BLOCK_SIDE side)
{
    return 1 << side;
}

[ThatHackerDudeFromCyberspace]

That code seems to convert BLOCK_SIDE to "bits"

So block_side:

enum BLOCK_SIDE{
    BLOCK_FRONT=0,
    BLOCK_BACK=1,
    BLOCK_LEFT=2,
    BLOCK_RIGHT=3,
    BLOCK_TOP=4,
    BLOCK_BOTTOM=5
};

And seems to shift 1 by the value of that so...

constexpr BLOCK_SIDE_BITFIELD BLOCK_FRONT_BIT = 1;
constexpr BLOCK_SIDE_BITFIELD BLOCK_BACK_BIT = 2;
constexpr BLOCK_SIDE_BITFIELD BLOCK_LEFT_BIT = 4;
constexpr BLOCK_SIDE_BITFIELD BLOCK_RIGHT_BIT = 8;
constexpr BLOCK_SIDE_BITFIELD BLOCK_TOP_BIT = 16;
constexpr BLOCK_SIDE_BITFIELD BLOCK_BOTTOM_BIT = 32;

[ThatHackerDudeFromCyberspace]

But this doesn't seem to match up with what you said earlier @m-doescode as the bit values take more than 3 bits...

[ThatHackerDudeFromCyberspace]

It seems that they are represented sequentially by 3 bits

[m-doescode]

(Actually, I just realized you already mentioned this in your first comment

[ThatHackerDudeFromCyberspace]

Those 3 bits are extracted by this code:

    BLOCK_SIDE side = static_cast<BLOCK_SIDE>((getBLOCKDATA(block) & BLOCK_SIDE_BITS));

And then traated as a number from the enum

[m-doescode]

Exactly

[ThatHackerDudeFromCyberspace]

WHY does block_front_bit even exist??????

(probs some random renderer thing or maybe for texture mapping)

[m-doescode]

I might actually be wrong in that the first 8 bits are used for the type. Because according to this code the first 8 leftmost bits are used for the data, then I assume the latter 8 bits are used for type.

constexpr uint8_t getBLOCKDATA(BLOCK_WDATA bd) { return (bd >> 8) & 0x7F; }

[ThatHackerDudeFromCyberspace]

We need a system for this

Are "first bits" left to rigt?
First bit: 10000000

Or are "first bits" right to left?
First bit: 00000001

[m-doescode]

Im pretty sure they are right to left, at least according to the bit shift operators

[ThatHackerDudeFromCyberspace]

I get that, I mean when you refer to them, you refer to first bit as the bit with a value of 1 right?
(right to left)

[m-doescode]

Sorry, in my comments about data and types I meant first 8 bits from the left. I have edites it now.

[ThatHackerDudeFromCyberspace]

What I have so far is that the regular blocks are basically just standard 8-bit integers
Whilst special blocks are 16 bits:

where the leftmost 8 bits seem to be for data
and the rightmost 8 bits seem to be for block type

getBlockData seems to give the last 8 bits
but then it does & 0x7F which I don't understand bc I like to stay 2-safe-meters away from bitshifts and binary in C++

[ThatHackerDudeFromCyberspace]

possiblly, it's interesting that there is also the same gap for the (now legacy bc of my improvements) break particles

// As special block breaking particles haven't been fully implemented yet
static const struct { int x, y; } special_block_texture_idx[BLOCK_SPECIAL_LAST - BLOCK_SPECIAL_START + 1] =
{
    {4, 0}, // Torch -> Planks
    {4, 3}, // Flower -> Leaves
    {11, 0}, // Spiderweb -> Spiderweb
    {9, 7}, // Cake -> Cake
    {14, 8}, // Mushroom -> Mushroom block
    {1, 6}, // Door -> Door bottom
    {13, 12}, // Water -> Water
    {13, 14}, // Lava -> Lava
    {15, 5}, // Wheat -> Wheat
    {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, // Gap (135-146)
    {3, 13}, // Redstone Lamp -> Lamp (off)
    {1, 0}, // Redstone Switch -> Stone
    {4, 10}, // Redstone Wire -> Redstone Wire
    {4, 0}, // Redstone Torch -> Planks
    {1, 0}, // Pressure Plate -> Stone
    {0, 4}, // Wool -> White Wool
};

(the comment is old, special block breaking particles have now been implemented with a totally-not-hacky sollution)

[ThatHackerDudeFromCyberspace]

Since something like that would be manual, and commits don't seem to indicate any cut blocks

[ThatHackerDudeFromCyberspace]

Also, out of curiousity, what software did you use to make these images?

Is it OneNote or something?

[m-doescode]

Erm, I'm not on my PC so I used the photos app on my phone.

But usually I would've used ShareX

[ThatHackerDudeFromCyberspace]

huh

[ThatHackerDudeFromCyberspace]

Do you know what the purpose of & 0x7F; is:

constexpr uint8_t getBLOCKDATA(BLOCK_WDATA bd) { return (bd >> 8) & 0x7F; }

?

[m-doescode]

My guess is that it was done for organizational purposes. We have already determined that there is no reason for special blocks to start 127, so I think redstone is the same story.

I think Vogtinator didn't want to have to move up every special block's number whenever he wanted to add a normal block. I think the same goes for redstone

[ThatHackerDudeFromCyberspace]

yeah

[ThatHackerDudeFromCyberspace]

Interesting that the special block gap is exactly 10...

[ThatHackerDudeFromCyberspace]

I'm about to compile something potentially dumb

// As special block breaking particles haven't been fully implemented yet
static const struct { int x, y; } special_block_texture_idx[BLOCK_SPECIAL_LAST - BLOCK_SPECIAL_START + 1] =
{
    {4, 0}, // Torch -> Planks
    {4, 3}, // Flower -> Leaves
    {11, 0}, // Spiderweb -> Spiderweb
    {9, 7}, // Cake -> Cake
    {14, 8}, // Mushroom -> Mushroom block
    {1, 6}, // Door -> Door bottom
    {13, 12}, // Water -> Water
    {13, 14}, // Lava -> Lava
    {15, 5}, // Wheat -> Wheat
    // GAP REMOVED YOLO
    {3, 13}, // Redstone Lamp -> Lamp (off)
    {1, 0}, // Redstone Switch -> Stone
    {4, 10}, // Redstone Wire -> Redstone Wire
    {4, 0}, // Redstone Torch -> Planks
    {1, 0}, // Pressure Plate -> Stone
    {0, 4}, // Wool -> White Wool
};

[ThatHackerDudeFromCyberspace]

Slight problem [nvm, solved, see last reply]

While the 16 bit bitmap seems to work fine with special blocks, how exactly do normal blocks handle data? (blocks of BLOCK type (uint8_t))

as they are only 8 bit, and do not appear to carry data, however, when selecting arenderer in blockrenderer.cpp:

map[BLOCK_AIR] = null_renderer;
    map[BLOCK_BOOKSHELF] = oriented_renderer;
    map[BLOCK_CAKE] = std::make_shared<CakeRenderer>();
    map[BLOCK_CRAFTING_TABLE] = oriented_renderer;
    map[BLOCK_DIRT] = color_renderer;
    map[BLOCK_DOOR] = std::make_shared<DoorRenderer>();
    map[BLOCK_FURNACE] = oriented_renderer;
    map[BLOCK_GLASS] = std::make_shared<GlassRenderer>();
    map[BLOCK_GRASS] = color_renderer;
    map[BLOCK_LEAVES] = std::make_shared<LeavesRenderer>();
    map[BLOCK_TNT] = std::make_shared<TNTRenderer>();
    map[BLOCK_PLANKS_NORMAL] = color_renderer;
    map[BLOCK_PUMPKIN] = oriented_renderer;
    map[BLOCK_REDSTONE_LAMP] = std::make_shared<LampRenderer>();
    map[BLOCK_REDSTONE_SWITCH] = std::make_shared<SwitchRenderer>();
    map[BLOCK_REDSTONE_WIRE] = std::make_shared<WireRenderer>();
    map[BLOCK_REDSTONE_TORCH] = std::make_shared<RedstoneTorchRenderer>();
    map[BLOCK_PRESSURE_PLATE] = std::make_shared<PressurePlateRenderer>();
    map[BLOCK_SAND] = color_renderer;
    map[BLOCK_STONE] = color_renderer;
    map[BLOCK_TORCH] = std::make_shared<TorchRenderer>();
    map[BLOCK_WATER] = std::make_shared<FluidRenderer>(13, 12, "Water");
    map[BLOCK_LAVA] = std::make_shared<FluidRenderer>(13, 14, "Lava");
    map[BLOCK_WHEAT] = std::make_shared<WheatRenderer>();
    map[BLOCK_WOOD] = color_renderer;
    map[BLOCK_WOOL] = std::make_shared<WoolRenderer>();

You can see that oriented blocks exist, and in the function that renders them:

void OrientedBlockRenderer::geometryNormalBlock(const BLOCK_WDATA block, const int local_x, const int local_y, const int local_z, const BLOCK_SIDE side, Chunk &c)
{
    BLOCK_SIDE map[BLOCK_SIDE_LAST + 1];

    BLOCK type = getBLOCK(block);
    switch(static_cast<BLOCK_SIDE>(getBLOCKDATA(block)))
    {
    default:
    case BLOCK_FRONT:
        map[BLOCK_TOP] = BLOCK_TOP;
        map[BLOCK_BOTTOM] = BLOCK_BOTTOM;
        map[BLOCK_LEFT] = BLOCK_LEFT;
        map[BLOCK_RIGHT] = BLOCK_RIGHT;
        map[BLOCK_BACK] = BLOCK_BACK;
        map[BLOCK_FRONT] = BLOCK_FRONT;
        break;
    case BLOCK_BACK:
        map[BLOCK_TOP] = BLOCK_TOP;
        map[BLOCK_BOTTOM] = BLOCK_BOTTOM;
        map[BLOCK_LEFT] = BLOCK_RIGHT;
        map[BLOCK_RIGHT] = BLOCK_LEFT;
        map[BLOCK_BACK] = BLOCK_FRONT;
        map[BLOCK_FRONT] = BLOCK_BACK;
        break;
    case BLOCK_LEFT:
        map[BLOCK_TOP] = BLOCK_TOP;
        map[BLOCK_BOTTOM] = BLOCK_BOTTOM;
        map[BLOCK_LEFT] = BLOCK_FRONT;
        map[BLOCK_RIGHT] = BLOCK_BACK;
        map[BLOCK_BACK] = BLOCK_LEFT;
        map[BLOCK_FRONT] = BLOCK_RIGHT;
        break;
    case BLOCK_RIGHT:
        map[BLOCK_TOP] = BLOCK_TOP;
        map[BLOCK_BOTTOM] = BLOCK_BOTTOM;
        map[BLOCK_LEFT] = BLOCK_BACK;
        map[BLOCK_RIGHT] = BLOCK_FRONT;
        map[BLOCK_BACK] = BLOCK_RIGHT;
        map[BLOCK_FRONT] = BLOCK_LEFT;
        break;
    }

    BlockRenderer::renderNormalBlockSide(local_x, local_y, local_z, side, block_textures[type][map[side]].current, c);
}

The oriented block renderer uses block data directly (no 3 bit bitmap stuff) to determine orientation of a regular block

[ThatHackerDudeFromCyberspace]

Does this mean that regular blocks have their own block data being only orientation???

[ThatHackerDudeFromCyberspace]

So I've tracked it down to the inventory, where blocks are converted to special blocks regardles within the inventory:

BlockListTask block_list_task;

static const BLOCK_WDATA user_selectable[] = {
    BLOCK_STONE,
    BLOCK_COBBLESTONE,
    BLOCK_DIRT,
    BLOCK_GRASS,
    BLOCK_SAND,
    BLOCK_WOOD,
    BLOCK_LEAVES,
    BLOCK_PLANKS_NORMAL,
    BLOCK_PLANKS_DARK,
    BLOCK_PLANKS_BRIGHT,
    BLOCK_WALL,
    BLOCK_GLASS,
    BLOCK_DOOR,
    BLOCK_COAL_ORE,
    BLOCK_GOLD_ORE,
    BLOCK_IRON_ORE,
    BLOCK_DIAMOND_ORE,
    // ...

and

BLOCK_WDATA current_block = world.getBlock(selection_pos.x, selection_pos.y, selection_pos.z),
                    block_to_place = current_inventory.currentSlot();

in worldtask.cpp

[ThatHackerDudeFromCyberspace]

Ok I don't need your help with this one, but if you want to know what it was:

In worldtask.cpp

//Only set the block if there's air
        if(current_block == BLOCK_AIR || (in_water && getBLOCK(current_block) == BLOCK_WATER))
        {
            if(!global_block_renderer.isOriented(block_to_place))
                world.changeBlock(pos.x, pos.y, pos.z, block_to_place);
            else
            {
                AABB::SIDE side = selection_side;
                //If the block is not fully oriented and has been placed on top or bottom of another block, determine the orientation by yr
                if(!global_block_renderer.isFullyOriented(block_to_place) && (side == AABB::TOP || side == AABB::BOTTOM))
                    side = yr < GLFix(45) ? AABB::FRONT : yr < GLFix(135) ? AABB::LEFT : yr < GLFix(225) ? AABB::BACK : yr < GLFix(315) ? AABB::RIGHT : AABB::FRONT;

                world.changeBlock(pos.x, pos.y, pos.z, getBLOCKWDATA(block_to_place, side)); //AABB::SIDE is compatible to BLOCK_SIDE
            }

            //If the player is stuck now, it's because of the block change, so remove it again
            if(world.intersect(aabb))
                world.changeBlock(pos.x, pos.y, pos.z, current_block);
        }

If the block is oriented, then the block is placed with orientation added to its data, this also further confirms that orientation is the first 3 bits of the data (like you said)