Omnimaga
General Discussion => Technology and Development => Computer Projects and Ideas => Topic started by: harold on August 22, 2014, 08:29:54 am
-
You may have seen a couple of screenshots of this appear on IRC, at the time of writing it looks like this:
(http://i.imgur.com/b0uUiuV.png) (http://imgur.com/b0uUiuV)
They're pulse circuits, so it looks like a bunch of things are incorrect but that's just because of their delay.
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..
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.
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)
- 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).
- 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.
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)
- 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. 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, 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. 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.
Tech used/platform
C# and OpenGL 4. The biggest compatibility obstacle is probably the extensions I used and buggy/old GPU drivers.
-
Seems pretty interesting. I wonder if there will be 2D view so people who see the 3D as an annoyance when editing redstone circuits? Also if the speed is the same as real Minecraft then it might be handy to test advanced stuff since we wouldn't be misled into thinking our redstone TI-Nspire emulator or whatever we try to work on is fast enough for a real MC map. :P
-
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 :D
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 >:(
-
Redstone (and repeaters) on walls, ceilings, torches on ceilings as well? That'd be very useful :D
All of that could be done. Isn't it a bit of a cheat though? Ah well I'll see.
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.
Good idea
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?
Uhm, I guess it isn't. I'm not sure how that's supposed to work tbh. Aren't torches supposed to ignore 1-tick pulses? Why else are "1 tick torch transmission" things so "special"? Then again, that circuit was always a 1 tick clock IIRC.
"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.
Yea normally it's simple, but for example if you power a repeater at the same time you power the lock, it gets locked in OFF state, even though at that point it is not powered from the side yet. It gets worse if you add an other repeater that simultaneously tries to lock the lock. Please tell me you know how that works..
How did you implement this [redstone dust]? 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)
Basically I floodfill through it starting from active power supplies.
If you have chunks (exactly like minecraft) anyway, why not make the map infinite?
Well right now, I'd run out of coordinate space. I could use a wider type there I guess. Also because of the way I did it, I'd run out of floating point resolution relatively quickly if you go much further from the origin than you can now, I'd have to throw in some more trickery to avoid that. Might happen.
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?
Oh it was fine .. on a small enough or sparse enough map. If 1 million cubes is small to you, this will never be good enough. 1 million cubes is right up there with the PCIe 2.0 x16 throughput limit of 0.8GB per update (assuming 10Hz), actually slightly beyond the limit. Of course that case would only be hit if all chunks changed and they were all in the frustum, but that's not something that's completely impossible. Now this will not be a problem again (unless I put in pistons).
-
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?
Uhm, I guess it isn't. I'm not sure how that's supposed to work tbh. Aren't torches supposed to ignore 1-tick pulses? Why else are "1 tick torch transmission" things so "special"? Then again, that circuit was always a 1 tick clock IIRC.
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.
"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.
Yea normally it's simple, but for example if you power a repeater at the same time you power the lock, it gets locked in OFF state, even though at that point it is not powered from the side yet.It gets worse if you add an other repeater that simultaneously tries to lock the lock. Please tell me you know how that works..
That could be the same situation as above.
How did you implement this [redstone dust]? 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)
Basically I floodfill through it starting from active power supplies.
Yeah, the easiest implementation. A small hint, which would have prevented some wasting of time while implementing it in crafti: You have to recalculate each part of a circuit upon removing a part of wire.
If you have chunks (exactly like minecraft) anyway, why not make the map infinite?
Well right now, I'd run out of coordinate space. I could use a wider type there I guess. Also because of the way I did it, I'd run out of floating point resolution relatively quickly if you go much further from the origin than you can now, I'd have to throw in some more trickery to avoid that. Might happen.
Minecraft does it like (wow, I didn't know I read so much about MC internals..) this: It assignes chunks virtual coordinates. The chunk you're standing on has ALWAYS (0/0/0) as virtual coordinate and the geometry is calculated based on this.
Oh it was fine .. on a small enough or sparse enough map. If 1 million cubes is small to you, this will never be good enough. 1 million cubes is right up there with the PCIe 2.0 x16 throughput limit of 0.8GB per update (assuming 10Hz), actually slightly beyond the limit. Of course that case would only be hit if all chunks changed and they were all in the frustum, but that's not something that's completely impossible. Now this will not be a problem again (unless I put in pistons).
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.
-
This looks interesting. Do you also plan on creating a .scematic exporter so that you can paste anything you make in a real minecraft world?
-
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:
(http://i.imgur.com/zC7hACQ.png)
Especially not since that appears to happen consistently.
But then you add an other repeater, and suddenly:
(http://i.imgur.com/0MwFvDM.png)
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.
This looks interesting. Do you also plan on creating a .scematic exporter so that you can paste anything you make in a real minecraft world?
Maybe. They're not entirely compatible though, only roughly in the same ballpark. There are, and probably always will be, slight differences that would break some circuits if you took them from this to MC or back.
-
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?)
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.
-
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?)
How do I debug minecraft? To clarify, those pictures are of how it should be, not of how it currently is in my clone.
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.
I'd have to add a geometry shader stage for the normals. And do some pretty wonky stuff in it. It's possible, but not worth it especially since the reason would be to make things worse. After all, this isn't about turning 1GB into 500MB, it's about turning 8MB or so into 500MB, that doesn't make any sense. The biggest problem would remain anyway: it just plain takes too much to generate all that geometry data. It would still do so without normals and crap.
And statefulness would break my nice 3-calls-per-chunk renderer.
-
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?)
How do I debug minecraft? To clarify, those pictures are of how it should be, not of how it currently is in my clone.
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.?
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.
I'd have to add a geometry shader stage for the normals. And do some pretty wonky stuff in it. It's possible, but not worth it especially since the reason would be to make things worse. After all, this isn't about turning 1GB into 500MB, it's about turning 8MB or so into 500MB, that doesn't make any sense. The biggest problem would remain anyway: it just plain takes too much to generate all that geometry data. It would still do so without normals and crap.
And statefulness would break my nice 3-calls-per-chunk renderer.
With statefulness my old Minecraft clone (years ago, lwjgl) achieved a 2-calls-per-chunk renderer :P (IIRC. It was an experiment how to get most performance out of LWJGL with a lot of cubes and big worlds)
-
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?
With statefulness my old Minecraft clone (years ago, lwjgl) achieved a 2-calls-per-chunk renderer :P (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.
-
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?
(http://img.ourl.ca/2014-08-23_23.21.55.png)
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 :P (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 :/
-
You need a repeater from the side there of course, and if you add that .. it still locks in OFF state.
-
Oh, the repeater is necessary? I didn't know that, I haven't played minecraft in years (only before beta 1.7).
A repeater is itself a block, so it adds a delay of 1 tick minimum.
-
A repeater is itself a block, so it adds a delay of 1 tick minimum.
That can't be the whole story though. Both repeaters have a delay of 1 tick, so both would turn on at the same moment (1 tick after the signal turns on). However, in the case with just the 2 repeaters, the one that locks the other (let's call it A, and the one that is locked B) consistently turns on first.
Then if you add a third repeater C that can be locked by repeater B, and then power is supplied to all three simultaneously, obviously A always turns on since nothing prevents it from doing that, so it locks B, but then B either locks C or doesn't lock C, depending on whether or not B was locked in its ON state (which one wins depends on where power flows from). So now the entire situation is changed, even though all that happened is that we gave repeater B the chance to lock something.
-
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?
(http://img.ourl.ca/2014-08-24_00.59.11.png)
-
Ah yes, that shows the problem pretty well.
I do most of my experiments in 1.6.2, I haven't found any differences between that and 1.7.10 though. Doesn't mean there aren't any, but from what I've heard, this area of redstone hasn't seen much change after 1.5
-
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:
(http://img.ourl.ca/2014-08-24_03.05.52.png)
-
Is it the orientation though? In my test, also moving the level made a difference. Perhaps it's the relative position of the level with repeaters?
-
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?
(http://img.ourl.ca/2014-08-23_23.21.55.png)
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 :P (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.
-
Eiyeron, it does this thing in all directions. In the "2 repeaters, one locks the other, both receive power at the same time" case, the locker always win.
-
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.
-
After some discussion on an other forum, I've decided that this issue will actually not be resolved.
Only the "normal" behaviour (the usual descriptions of how redstone elements work) will be replicated, not this sort of thing that doesn't follow any clear set of rules.
edit: I've worked on it again, so despite appearances it may not be entirely dead. Simulation still has severe bugs though, so it may not go anywhere.