![[de]](/mwf/flags/de.png "Germany")
So then, go on.
We can generalize the Landscape Engine in an abstraction Class with some functions needed in General:
Here some examples:
void RenderLandscape(toRect)
bool LineFree(x1,y1,x2,y2)
void DrawBox(x,y,width,height,material)
when we have such a mask we can write any landscape type and any landscape technique for OC.
(pls move into an extra thread called "Landscape Generalization")
the idea is to make these functions virtual, that means f.e. K-Duke can also write a voxel-rendering-code for the pixel engine.
We can generalize the Landscape Engine in an abstraction Class with some functions needed in General:
Here some examples:
void RenderLandscape(toRect)
bool LineFree(x1,y1,x2,y2)
void DrawBox(x,y,width,height,material)
when we have such a mask we can write any landscape type and any landscape technique for OC.
(pls move into an extra thread called "Landscape Generalization")
the idea is to make these functions virtual, that means f.e. K-Duke can also write a voxel-rendering-code for the pixel engine.
![[es]](/mwf/flags/es.png "Spain")
That what you are talking about is an Interface. But for what exactly do you want to define a common interface - for rendering or what?
for general Landscape access.
It will have some general functions like Rendering or blasting a hole into it, drawing a polygon etc, simulating water.
I'm thinking of a Polygon Engine and a Pixel Engine where any developer can inherit one of these two engines and rewrite f.e. an own rendering code or a better water simulating.
The host or the gamer can decide which Engine will fit better into one Scenario.
It will have some general functions like Rendering or blasting a hole into it, drawing a polygon etc, simulating water.
I'm thinking of a Polygon Engine and a Pixel Engine where any developer can inherit one of these two engines and rewrite f.e. an own rendering code or a better water simulating.
The host or the gamer can decide which Engine will fit better into one Scenario.
As Sven2 said in #clonkdev, we already have a class C4Landscape. And it's one of the better abstracted ones in the engine because it already saw significant changes to the implementation which gave us the opportunity to design a workable interface. The fact that we could change the whole landscape render function with just a few lines of code changed in C4Landscape is proof of that.
But it is not general enough to also implement a polygon landscape.
a general landscape engine has to have no SetPixel/GetPixel-Routines. It has to have DrawPolygon or BlastHole, FillWaterAmmount etc, general functions that can be implemented as a pixel routine or as a polygon routine.
a general landscape engine has to have no SetPixel/GetPixel-Routines. It has to have DrawPolygon or BlastHole, FillWaterAmmount etc, general functions that can be implemented as a pixel routine or as a polygon routine.
![[us]](/mwf/flags/us.png "United States")
C4Landscape *is* an interface. An abstract interface using virtual function calls is only needed if there are different implementations. Right now, there is only one implementation, and if there will be a polygon landscape there will also be only one implementation.If the polygon landscape is written AND we decide to have both, then you could start doing the merge of the branches by building the abstract interface and two implementations instead. It doesn't make sense to split C4Landscape into an interface and an implementation part yet. In fact, we don't even know whether the polygon landscape will be imeplemented at all.
Concerning whether the interface should or should not contain SetPix/GetPix: Stuff like GetPix (or at least GetMaterial) is certainly needed by the rest of the engine. SetPix is currently used a lot (e.g. SolidMasks). If the interface is changed to become powerful enough to work without SetPix, SetPix may become private in the current implementation and not exist in a polygon implementation.
> SetPix is currently used a lot (e.g. SolidMasks)
That's kind of a bad example because it would be stupid to reuse the current solid mask implementation with a polygon landscape. Rain is a better example, because rain is truly pixel based and not just the PXS implementation :-)
And I'll say it again: I'm certain that we won't want to have two landscape implementations. Almost everything interacts with the landscape, and abstracting that will just make everything worse than it could be, or lead to enormous duplication and bloat.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
