I'm tired, so I'll get MCP tomorrow and have a look at the source, but I could get something even weirder. Which version of MC do you have?

I just tried the same thing as above in 1.6.2, the screenshot was made using 1.5.2, and it seems to work, although still "buggy".
I'd expect that:
1. Redstone gets powered
2. Repeaters realize they get powered -> Repeaters turn on
3. Repeaters realize they're powered by another repeater -> Lock on state
4. This state is stable

But it's more like:
1. Redstone gets powered
2. One repeater realizes it's getting power -> Turns on
3. Repeater next to 2. realizes it's being powered by another repeater -> Lock current (still off) state
4. Repeat for next two -> Pattern
5. Also stable state
Bug? Or two, actually (2. + 3.)
There may also be a relationship with repeater orientation, the locked repeaters face the same/opposite direction.
If the ticks were in a specific order, the pattern wouldn't be diagonal, would it?

Screenshot:

Quote from: harold on August 23, 2014, 05:14:54 pm

Quote from: Vogtinator on August 23, 2014, 05:09:40 pm

Oh, I thought it was your implementation... The reason could be that minecraft does it the way I mentioned: Random ticks per chunk, but it has to tick every block in a chunk first before it ticks a block the second time (I'm not sure how to explain it better). What happens if you connect two not gates to the repeater inputs (input & lock) instead of a repeater? Does the behaviour change if you change orientation, location etc.?

Could you draw the circuit?

I found out that sometimes it's visible that the right torch turns on slightly faster than the left one, sometimes the opposite.

Quote

With statefulness my old Minecraft clone (years ago, lwjgl) achieved a 2-calls-per-chunk renderer (IIRC. It was an experiment how to get most performance out of LWJGL with a lot of cubes and big worlds)

Well how? glBindVertexArray, glDrawElements .. nothing left to change state. I'd have 2 calls if it wasn't for the uniform buffer.

It was GL 2.0 back then, fixed function pipeline etc. I'd get the source but it's on my old hard drive I put somewhere in my room
[/quote]

It's the north/south and east/west bias. As the program reads the chunks in a certain way, there is a slight difference between positions and orientations.

I had a quick look at the redstone code in minecraft, most of it is handles by BlockRedstoneLogic.java and it doesn't seem that there is any double-buffering happening at all. That doesn't explain the patterns, though.