![[de]](/mwf/flags/de.png "Germany")
> My suggestion to replace the generic tunnel texture with a darker version of the actual material didn't appeal?
I tried to implement that - it's theoretically possible with the current setup - but gave up because I kept getting weird results. We are also still limited to 126 or so material-texture-combinations, wether wasting half of them for tunnel is a good idea I don't know. I might try again, but we still need a good tunnel texture for caves and stuff ;-)
>We are also still limited to 126
Now the question: why not more? :(
We use only one byte per pixel, and one bit is used to indicate whether there's sky or tunnel behind the material. One entry is occupied by the sky, another one by the solidmasks.
![[es]](/mwf/flags/es.png "Spain")
Hm, probably write a new landscapeengine would be a good idea?
I think you more have to think of the sheer amout of data, the landscape has got.If you have got a simple 1000x1000 landscape you already have got one million types of materials to save.
[Edit]
Idea! Why don't you save the landscape more like a vectorgrafic with big cubes, and then fat lines as tunnels + a few single pixels?
This would reduce the amount of data extremly. Is that possible?
It would increase processing time.
No, one million pixels, and every pixel can carry 256 different states.
>you already have got one million types of materials to save.
No, one million pixels, and every pixel can carry 256 different states.
Well, the idea of saving the landscape as a a bunch of polygons like e.g. Soldat has been going around for some time now. This would reduce memory usage a lot as well as making the rendering the landscape easier. PeterW said, that he wants to avoid using polygons for storing the landscape as long as possible for reasons I don't know - but he is the specialist there.Probably because it's a lot of re-coding work. I think if/when we want to use an advanced physics engine for Clonk would be the right moment to do this. The current physics engine with vertices, solidmasks, collision checks etc. (of course) as well as landscape operations like DigFree etc. assume and use the landscape pixel-wise and it would be very slow to try to use a polygon-based landscape as a data model but break it all down to pixel-wise access for all the routines working on it.
Soldat is a bad example because the landscape is static - and Soldat maps already use a lot of tricks that be decidedly can't use. And I don't think I have to explain to another veteran Soldat player that they have issues with their collision detection... ;)
My point is that I don't want to buy that "reduced memory usage / easier landscape rendering (/everybody is doing it?)" just like that. While optimizing large amounts of PXS - read: rain in Seven Keys - I looked into making the PXS collision checks faster, because they were clearly eating most of the performance. I tried to use Quad-Trees just for having a fast "is /anything/ there" check. My implementation was hand-optimized to the best of my knowledge. Yet simple pixel checks still were only marginally slower. I then introduced a trivial counter array that sums up pixel counts for 255 groups of landscape pixels - and made rain skip the collision check when the count was 0. Performance went through the roof.
Lesson: We should give good consideration before switching to a more complicated data structure. Chances are that we are hurting both program maintainability and performance.
My point is that I don't want to buy that "reduced memory usage / easier landscape rendering (/everybody is doing it?)" just like that. While optimizing large amounts of PXS - read: rain in Seven Keys - I looked into making the PXS collision checks faster, because they were clearly eating most of the performance. I tried to use Quad-Trees just for having a fast "is /anything/ there" check. My implementation was hand-optimized to the best of my knowledge. Yet simple pixel checks still were only marginally slower. I then introduced a trivial counter array that sums up pixel counts for 255 groups of landscape pixels - and made rain skip the collision check when the count was 0. Performance went through the roof.
Lesson: We should give good consideration before switching to a more complicated data structure. Chances are that we are hurting both program maintainability and performance.
Maybe 32bit aligned memory access would be faster. ;)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
