that is another solution, for level design ease in itself, it'd be good to have some bigger pieces anyways

why? level design gets done with the pixels of an image.

i think grouping entities just would unnecessarily complicate things in this case.

oh, didnt know, i was just going by some pics from his other projects and i thought they were placing cubic segments in the level editor. my bad.

the problem.. how to do a modelblock, wich contains 150x150 segments.. and how to dig parts out of it...
( i asked that some time ago , but no solution )...
I think that´s the major problem... all that blocks...

you didnt read vents post at all?

I have the same fps drop here and was curious about it.

It is not the count of entities nor the shaders. It is YOUR fault.

In the file "blocking.c" you define the object actions like object_erde, object_fels or object_boden. The first two actions start with set(my,SHADOW);. Seriously, in the start map there is nothing digged into the ground, so why should they casts shadows?

Tip #1: if you wanna use stencil shadows, execute a function on each digging step which calculates which blocks are able to throw shadows and then turn their shadows on.

Second, in all three actions you have wait(1)-while's. Even worser, in object_erde and object_fels you always do

my.z = nullpunktvariable;

I removed the while's and ... TADA! My framerate is as hot as my coffee.. the reason is, that this simple .z alignment instructions forces the engine to update e.g. the ABT tree and all sorts of stuff. I guess, that your blocks won't move anytime in your level.

Tip #2: don't move entities when they should'nt!!!

Also:

Tip #3: when entities dont move, rotate or scale or do animation and stuff, enable their static flag (like Ventilator said before).

My personal favorite is the following:

Tip #4: DO NOT have one entity for EACH block. Even when you zoom out to a certain maximal distance, you won't see all blocks. Differentiate between the rendered level and the level in memory: make a datastructure that stores your map and move around only blocks which get invisible due to screen movement.

This is contradicting with Tip #2 and #3, but HELL, there are near 19.000 entities in your scene. If you reduce it to e.g. 20x20 = 400 blocks and you have to update only the borders, you will have the same representation and everything is fine.

You might ask "how am I supposed to let the NPCs act in this environement?" ... do not base your calculation up on the rendered scene but on your data-representation of your map.

Best regards,
Christian

Many thanks for that tailored "tutorial" Heelix.
I havent been able to dig deep enough into Espers code
due to its complexity, and my lack of german.
im sure he'll thank you too.

This advise youve given, Im sure, will help me with similar processes
I have planned for future development in one of my projects too.

Again, many thanks wise one...

Those be great tips HeelX, thanks.

thanks too..

But a question:

Is it enough ti set the models invisible?? because i can´t remove them if they are not on the screen. Cause: All monsters that work in the background, need to ask for those blocks...

This should work, too.

Anyway, when you create an own datastructure for your map, your actors have actually access to the map data. You can for instance create a 2-dimensional pointer array with size M x N. Each pointer points to an instance of a block structure in which you could define the type (floor, wall,...), contents (nothing, gold, silver, water,...), texture type (solid rock, earth, ...) and other stuff.

In the end you have to test it out if it works for you in a hurry -- and in the long run.