Well, how do you load the module? Did you compile it?

IIRC somebody did that already.

I saw the textures in crafti were a little wonky (maybe for speed reasons), are there any texture routine more accurate?

Depends on what you mean by "wonky". Some inaccuracies are due to the fixed point math.
For obvious reasons it's doing Affine texture mapping, but you don't notice that much while playing.
The problem is, that for every scanline, the X distance is the total length of the line. If you want to do it the "correct" way, the length is sqrt(dx*dx+dz*dz), but doing it every line (or like quake, every 5th or so) is still a whole lot too slow. And I can't use the invsqrt trick, as that only works for floats.

The source code can be found on GitHub and the latest commit says "TouchPad & CX Supported.".

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?

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.

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.
[/quote]
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 from: Vogtinator on August 23, 2014, 03:06:21 pm

The weird thing with those is, that if you "tick" every block in a chunk in the same order (0/0/0),(0/0/1),...,(0/1/0),...(15/15/15). you can see "invalid" states.
As calculation doesn't happen parallel to rendering (that'd be horrible, both usability- and code-wise), (15/15/15) can react to a change of (15/15/14) in the same tick. Minecraft does it a bit differently: Only a few blocks of each chunk are "tick"ed each frame. They're chosen randomly, so you get such states very seldom. It can cause horrible bugs, though.. I also thought about a game-of-life like implementation, like double-buffering. Copy the redstone state of the chunk before doing ticks and only after every block recalculated itself, make the new state the current one.

I'm using the "fill a new buffer, then make it the current one" approach now. I'm not sure how the repeater locking enigma interacts with this. I still don't see how this makes sense though:
Especially not since that appears to happen consistently.
But then you add an other repeater, and suddenly:

Debugging this should be easy. Do a breakpoint at the repeater's tick function, in the block to lock it and look at the redstone state of the inputs.
I don't see any differences of the two pictures though. (Uh, this sentence sounds and looks weird. Where's my mistake?)

Quote

I get 1000000 (cubes) * 6 (faces) * 4 (vertices) * 5 (x/y/z/u/v) * 4 (bytes in a float) ~= 500 MiB and that's EVERYTHING. In the ultimate WORST case.

I put a bit more in there (normal, texture array index, stuff to paint redstone dust directly onto it, which might be a bit wasteful perhaps), comes out at 48 bytes per vertex, just over 1GB for a million cubes. But that's all just a factor of 2 anyway, make it 2 million cubes and you have the same problem again.

A BIT wasteful? That's a massive understatement.. The normal is unnecessary (the GPU calculates it faster in a shader every frame), as is the redstone dust stuff. I would also replace the texture array index by something stateful. I don't know whether glBindTexture(id, GL_TEXTURE_2D) still exists.

You may have seen a couple of screenshots of this appear on IRC, at the time of writing it looks like this:
They're pulse circuits, so it looks like a bunch of things are incorrect but that's just because of their delay.

It looks good, and that's exactly the problem I got with crafti's redstone implementation as well.. If you find a solution, let me know!

Anyway, the goal as I set it for this project is to be able to build/test/run redstone circuits without various minecraft annoyances, most of which can be fixed with mods I suppose..

Redstone (and repeaters) on walls, ceilings, torches on ceilings as well? That'd be very useful

Basically it's creative mode on steroids. Nothing that distracts from just building circuits. World-edit-like godmode editing. And I have some plans for putting in things like displaying delays and critical paths and some automated circuit testing stuff (such as cycling through a bunch of different inputs without having to build a circuit to do it). None of that exists just yet, I'm just doing the basics now. Also, the ability to pauze, step, fast-forward redstone simulation.

A nice feature would be to save "patterns" like gatters or special configurations and the ability to place them down wherever you like and in every orientation.

Some redstone logic already works to some degree, for example:
 - torches, both floor-mounted and wall-mounted. Don't burn out though, and I'm not sure whether to make them burn out. They also react to 1 tick pulses, which is wrong. (that's how the above screenshot has 1 tick pulses)

Why is this wrong?

- repeaters. You may have hear me complain about them. A normal 1-tick repeater that isn't locked works fine. Other delays may or may not do what they're supposed to do, the screenshot above is testing how they respond to 1 tick pulses and they respond correctly. I'm not sure about other inputs though. Also, locks make no sense and are currently incorrect (correct behaviour requires time travel).

"time travel"? Weird data dependancies? Or have I forgotten how they work? AFAIK it's only that the repeater doesn't change state if it's powered from the side.

- redstone dust, I think, works correctly in terms of which blocks it powers, what it looks like (apart from the particle effect), how far signals travel, and signals don't go down transparent diodes.

How did you implement this? Minecraft does it exactly how I do it in crafti: Connected redstone dust is treated like a single thing and updated at once (for timing and loop-avoiding purposes)

Some things are not there but will be there soon:
 - comparators
 - editing (it just loads and simulates now)
Some things may or may not ever be included:
 - pistons (I know you like them, but they suck to simulate, and I'm sure you remember how long they caused trouble in MC)

What kind of trouble? Should be fairly easy if you restrict it to pushing only a single block.

- shadows / lightlevels would be pretty, but not useful and would slow down rendering, particularly of complex+big maps.
Trickery used
The world can get pretty big (256x256x256 at least, it should work with 1024x1024x512 as well but not tested), which is smaller than "real minecraft", but still brings some challenges.
For example, it's impossible in general to reupload all geometry every frame, or you'd have maybe 1 frame per second. In order to avoid having to reupload too much stuff that wasn't changed, the world is divided in 16x16x16 chunk. Chunks with no changes are left alone.

If you have chunks (exactly like minecraft) anyway, why not make the map infinite?

However, naively, if a redstone signal changes, that means a change in a chunk because you'd have to update some texture coordinates and that means reuploading the geometry, this time with different texture coordinates. That would make far too many chunks be reuploaded, so to counter that, I've decoupled powerlevels from geometry

Powerlevels don't have to be sent to the GPU. If you mean the color of the redstone wire/dust, that's IMHO unnecessary complexity. GPUs and DMA are fast enough, so if you use VBOs, everything should be fine without these optimizations. Did you do any performance tests?

, so I can update them separately with only a tiny upload of only 2kb (16x16x16/2 because power levels can be packed in nibbles) versus about 1kb per solid block (minus faces that touch other solid blocks) in the chunk. It's a bad deal only if there are 1 or 2 blocks in a chunk, which is not the common case.
The powerlevel data is also used by "objects" (torches, repeaters, etc) to determine their state, even for the lock-bar of repeaters, so as long as only redstone signals change, no geometry is reuploaded.

To avoid having to deal with "ordering" with transparent parts (torches draw some transparent parts), transparent pixels are discarded. AA tends not to like that, but it works in combination with sample shading.
Possible future trickery: if I can figure out how to do it well, maybe fuse some faces and use texture wrapping. That would significantly reduce the polycount in some cases, but I'd have to careful not to mess anything up.

It's really easy to implement and there's not much to mess up, if it works for the simplest case, it works everytime.

Polycount hasn't really been a problem so far though, a million randomly placed (but not multiple at the same location) solid blocks still render at 30FPS (on a HD6950, +vsync), I doubt any real build would even come close to that.

Oh, look at youtube: "Redstone computer"

Tech used/platform
C# and OpenGL 4. The biggest compatibility obstacle is probably the extensions I used and buggy/old GPU drivers.

No, that you're using OpenGL 4, not supported by any open source graphics drivers