Just un point: why does the "fast mode" seem to be slower on my calc?

Weird. For me it's almost a 100% improvement.. It can't be slower, though. Maybe you accidentially changed the max. distance?

By the way, would it be possible to make the "loading" vanish while playing even though it reduces the speed? The loads would be progressive instead of all in the same time.

Not really. I could generate 10MB of Chunks and use that, but it'd take 10 minutes to generate and also 10 minutes to load each time you want to play.
And I'm not sure what you mean by "even though it reduces the speed".

Anyway, I forgot to mention that crafti also became my official project at school, so crafti is now part of my abitur 

Quote from: Vogtinator on June 02, 2014, 04:05:41 pm

Weird. For me it's almost a 100% improvement.. It can't be slower, though. Maybe you accidentially changed the max. distance?

Actually, the "fast mode" is faster but involves much more "loading"...

That's just because of the higher FPS you also walk faster to the next unloaded chunks. You could turn the speed to "slow", I guess.

Quote from: Vogtinator on June 02, 2014, 04:05:41 pm

Not really. I could generate 10MB of Chunks and use that, but it'd take 10 minutes to generate and also 10 minutes to load each time you want to play.
And I'm not sure what you mean by "even though it reduces the speed".

I was asking if instead of loading a block of map each time you need it, you could begin to load it progressively when we come close to it. This progressive load would reduce a bit the speed but would make the "loading" disappear.

That's basically how it works now...

Basically yes. It could also happen if the generation of the Chunk geometry takes too long.
While you walk, it determines the Chunks that would have to be loaded and loads it.
If they're not loaded when you reach it (the sum of chunks currently loading) exceeds a specified value, it shows the loading message instead of hanging.
To get something like this done smoothly is very hard (near to impossible) without proper multitasking.

Quote from: mdr1 on June 02, 2014, 04:13:01 pm

Quote from: Vogtinator on June 02, 2014, 04:05:41 pm

Not really. I could generate 10MB of Chunks and use that, but it'd take 10 minutes to generate and also 10 minutes to load each time you want to play.
And I'm not sure what you mean by "even though it reduces the speed".

I was asking if instead of loading a block of map each time you need it, you could begin to load it progressively when we come close to it. This progressive load would reduce a bit the speed but would make the "loading" disappear.

That's basically how it works now...

Why, then, does it have to load all the generated chunks at start? Can't you just load selective parts of the file into memory, accessing like an array? (Guessing you don't have arbitrarily large block data yet, but you could still stick that at the end (found by a position dictated in the header of the save).)

Ninja edit: It looks awesome. Nice work.

大声笑！它支持TI-NSPIRE CAS号！
它的工作太棒了！虽然我喜欢原来的材料  .

Pretty sure of it.

Speaking of multitasking. You know what I think would be fun, and awesome but probably isn't likely or possible(or already has been done in which case I'm an idiot and stop reading this)? Threads for calcs.

Yes, it has already been done, but it has much overhead.

But the real question is do they have GPU's?

That depends on your definition of GPU.. The LCD controller (PL110) can do some basic things itself, but nothing useful.

I'm way to lazy to check or ask if this is at all possible or whether or not it has or has not been done. This post is actually more of me showing my appreciation of the challenges of multi-threaded process/rendering.

Yep, that's really the case. Multithreading can be a PITA..

Anyway, AWESOME game/engine/thingi Vog, I haven't been checking up on it for a while but it looks GREAT!

Thanks!

Quote from: Vogtinator on June 02, 2014, 04:16:43 pm

Quote from: mdr1 on June 02, 2014, 04:13:01 pm

Quote from: Vogtinator on June 02, 2014, 04:05:41 pm

Not really. I could generate 10MB of Chunks and use that, but it'd take 10 minutes to generate and also 10 minutes to load each time you want to play.
And I'm not sure what you mean by "even though it reduces the speed".

I was asking if instead of loading a block of map each time you need it, you could begin to load it progressively when we come close to it. This progressive load would reduce a bit the speed but would make the "loading" disappear.

That's basically how it works now...

Why, then, does it have to load all the generated chunks at start? Can't you just load selective parts of the file into memory, accessing like an array? (Guessing you don't have arbitrarily large block data yet, but you could still stick that at the end (found by a position dictated in the header of the save).)

File access is SLOW. Slower than generating chunks on-the-fly. That's why I just load every Chunk in the savefile directly at the splash screen..

Ninja edit: It looks awesome. Nice work.

Tee-eitch-ex!

大声笑！它支持TI-NSPIRE CAS号！
它的工作太棒了！虽然我喜欢原来的材料  .

Great to hear that it works on HW as well as on nspire_emu

Also, most of us don't speak chineese

At my school the teachers can now take chinese lessons for free. God knows why, but my history teacher really annoys me.
Sometimes, when he walks into class he greets us with "Nǐ hǎo" 

But BTT: I'm currently in the process of thinking about redstone, and I haven't found the best solution yet.
I thought about giving each block a bit, which indicates whether it's powered or not, and a tick() function for redstone-active stuff.
The problem is, that if a wire is between two blocks and you power one of them, the wire also powers the other block.
Now, if you turn the block off, the other block is still active and the wire lets it propagate to the other block. Now both blocks will stay powered forever
Does anybody have an idea, which is simple, elegant and also fast?

Hmm, I guess that could work. Just another bit for indicating whether it's a power source. I wonder why I haven't thought of this earlier, thanks 
A simple enum {
NOT_POWERED,
PASSIVELY_POWERED,
ACTIVELY_POWERED } should do it.
Sadly I just found out that the door block occupies the highest bit (1<<7, for top/bottom door part) which I wanted to use..
Is it ok if I break all doors (suddenly consisting out of two bottoms)?