![[de]](/mwf/flags/de.png "Germany")
I wrote a high-quality landscape zooming shader:
To my implementation:
there is yet a filter that transports Landscape-Pixel information to Blue-buffer of Surface32. I do also have a Shader that filters a special color but i do not know where the TexID of each landscape material is stored.
just import this diff with
I hereby license the following file(s) under the CC-by license
To my implementation:
there is yet a filter that transports Landscape-Pixel information to Blue-buffer of Surface32. I do also have a Shader that filters a special color but i do not know where the TexID of each landscape material is stored.
just import this diff with
hg import file.diff and recompile the code.I hereby license the following file(s) under the CC-by license
Attachment: shaderpatch.diff (23k)
You shouldn't even try to upload binaries, the source is all that counts.The textures are in CPattern::sfcPattern32::ppTex. If that surface isn't locked. You might have to unlock it in C4TextureMap::LoadTextures first.
thanks for your help. maybe in 2-3 days i will need to upload my code. but how?
are you able to merge differences from some .cpp-files?
i changed espeacially C4ConfigStartup, StdGL and C4Materials
are you able to merge differences from some .cpp-files?
i changed espeacially C4ConfigStartup, StdGL and C4Materials
![[us]](/mwf/flags/us.png "United States")
You should ask Isilkor for a write-enabled account. Just make sure to check any experimental stuff into its own branch.
I'd recommend a (free) account at http://bitbucket.org/. Simply commit your changes and push.
here is the beta of landscape shaders
try in options
you have to import both changesets
try in options
you have to import both changesets
Attachment: Shader-LandscapeOpenclonk.zip (93k)
Attachment: landscape.diff (18k)
Attachment: landscape2.diff (5k)
I cleaned the patches up, fixed the FoW and pushed it to my bitbucket repository (hg pull http://bitbucket.org/guenther/openclonk/; hg update b075a6efbb52). I'm still not sure whether 128 fullscreen blits per frame are a good idea, but my new graphics card seems to manage, so I can't complain too much. I still have to test it on my notebook, though.
as i said, you can decide in options menu wether this feature will be used or not.
sry for GL_NEAREST bug (see at Newtons post) when not using shaders
shall I fix it or do you want to?
sry for GL_NEAREST bug (see at Newtons post) when not using shaders
shall I fix it or do you want to?
your file dosen't work.
C4AulDebug.cpp:(.text+0x16a4)||undefined reference to `C4AulScriptContext::Dump(StdStrBuf)'|
C4Update.cpp:(.text+0x4dde)||undefined reference to `GetCfg()'|
I reinstalled minGW and it works.
3 things:
1. my work is under CC-by, that means my name should by in the sourcecode (as comment)
2. i fixed the nearest-bug without shaders
3. i fixed some undersized Textures
3 things:
1. my work is under CC-by, that means my name should by in the sourcecode (as comment)
2. i fixed the nearest-bug without shaders
3. i fixed some undersized Textures
Attachment: nearestbug.diff (6k)
Attachment: textures.diff (424k)
Please license your code as ISC and provide a patch which adds your copyright statement to the relevant files after the " * Copyright (c) 2001-2009, RedWolf Design GmbH, http://www.clonk.de" line. For example, I'll use " * Copyright (c) 2009 Günther Brammer <gbrammer@gmx.de>" when I remember to actually add that line.I don't think that we should require power-of-two-textures. The number of cards/drivers that are fast enough for all those blits but don't support GL_ARB_texture_non_power_of_two shouldn't be that big.
You also cannot just change the default TexParameter. PerformBlt relies on the default of GL_NEAREST. We might want to change that because GL_LINEAR is much more common with zoom. DDrawCfg.Shader is also the wrong thing to query, that might be set even without shader support, and the use will be able to choose to use shaders with the old landscape drawing method.
![[es]](/mwf/flags/es.png "Spain")
http://www.westnordost.de/misc/zoomed.png <= blockyness intended?
you did not activate shaders in options menu
there is also the possibility to add more filters to the shader which also increases image quality (but in your screenshot the shader isn't activated - look in optionsmenu)
there is also the possibility to add more filters to the shader which also increases image quality (but in your screenshot the shader isn't activated - look in optionsmenu)
Ah, now I did. But with the shader, the game is running with something like 5 FPS. The shader thinks that the textures are all 512x512, that's why there are image errors.
druck s-abf on his keyboard? Look here: fourteenth key to left from esc
I separated the "highreslandscape" option from the shader option and pushed the result, together with some further cleanups. I think it it's ready for the main branch. Except that in it's current state it's somewhat of a feature regression: We trade the liquid animation and landscape shadows for higher resolution textures. Ideally we could have both. The main reason we haven't is that we weren't willing to use multiple landscape blits (for good reason: They won't be usable on low end GPUs for quite some time). So I'd like to have one more cute feature before merging :-)On the other hand the old liquid animation was kind of unsatisfying, the landscape shadows are still there if the option is disabled, and it's not a big chunk of code, so I'll merge it anyway in a few days if nobody has any objections.
that was is standing here is not what i wanted to reach.
my aim was a weighted map each material with a lower resolution
advantages:
- calcing landscape normals
- less memory need
- better image quality
- no pixel stuck
it would be a good alternative to polygon landscapes.
but i did not reach that target because of not so much knowledge of the CZ-Engine (and such a fatal change would be ..... fatal :) )
my aim was a weighted map each material with a lower resolution
advantages:
- calcing landscape normals
- less memory need
- better image quality
- no pixel stuck
it would be a good alternative to polygon landscapes.
but i did not reach that target because of not so much knowledge of the CZ-Engine (and such a fatal change would be ..... fatal :) )
What, exactly, do you mean with "weighted map"? If you mean "every pixel has a material and a number describing how much of it is that material and how much of it is air" that doesn't help with earth<->gold transitions. If you mean "each pixel has a separate number for every material", that wouldn't need less memory.You can also get smooth "landscape normals" by factoring more pixels into the calculation, better image quality by using a better magnification algorithm, and a Clonk can get stuck in an one-quarter pixel just as easily as in a full pixel.
Couldn't you simply use the current implementation and just pretend that a 2x2 block of three earth and one tunnel pixels is one pixel with 3/4 earth to demonstrate your approach?
On the other hand, can I persuade you to implement landscape shadows or liquid animations on top of the current data structure? I could do that myself, but one of the goals of this project is to involve new engine coders :-)
-i'm looking for a good starting point where i can implement landscape shadows, liquid animation etc.
but i do not really think that my current implementation will make it (it's too slow)
-a weighted map means every pixel descripts how many air and how many gold etc. is there. so we do not need such a high landscape resolution
-@landscape normals: see my formula at (i forgot where i put it)
-a clonk can not stuck in pixels that are as large as the clonk itself
hm. i will think over what is the best landscape data structure to get realistic (graphics+physics) results.
but i do not really think that my current implementation will make it (it's too slow)
-a weighted map means every pixel descripts how many air and how many gold etc. is there. so we do not need such a high landscape resolution
-@landscape normals: see my formula at (i forgot where i put it)
-a clonk can not stuck in pixels that are as large as the clonk itself
hm. i will think over what is the best landscape data structure to get realistic (graphics+physics) results.
I seriously doubt that pixels as big as a Clonk are a good idea. You simply cannot get a grid that big to behave similar to a finer one.
it's an extreme example, but look at gwx, aren't there 5x2x2 voxels as great as one clonk?
> i'm looking for a good starting point where i can implement landscape shadows, liquid animation etc.
Well, what do you need? You know already where the main landscape texture is updated, and where it is drawn. If you need more auxiliary textures, I can write code to put specially named landscape textures into the texture array for BlitLandscape, or multiple texturs per material if liquid animations need them.
i'm thinking of an abstraction: how to write a landscape rendering code that is as general as that i just have to write a few lines of code.
in the moment i have to do with gwx network games (yes, they're working!) and so i will wait for newtons polygon landscape implementation.
in the moment i have to do with gwx network games (yes, they're working!) and so i will wait for newtons polygon landscape implementation.
The polygon landscape won't be finished any time soon, so waiting for it is not a good idea in my humble opinion. I'd also guess that it will be easier to rewrite the rendering code than trying to generalize it. It's not as if we'll have two types of landscapes at the same time in the same engine :-)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
