[Kde-games-devel] Kolf Art?

[Arturo Silva]

Okay, I'm back, though not 100% ready to work (dead tired). We'll see.....  :D

In the meantime, there are replies to be had:


> I'm pretty sure that we can't have feature parity. Because Kolf 2 is
> physically correct, we'll lose all Kolf 1 courses, and some objects will be
> missing. The editor might have some rough edges, and the OpenGL parts will not
> be in the first release. Still, I think we'll perform better on other fronts,
> and the codebase will be much better.

I'm sure with a little creativity we can still find some way to
salvage at least the look and feel of the original courses.  Then
again, I'm very excited to see the enhancements to the engine overall
-- no doubt I'll be so floored by the new abilities I'll be more
inclined to try creating some exciting new courses from scratch. ^^b


> Actually, my long-term plan is to split off the basic parts into some library.
> Everything is fairly generic.

I am still surprised there is no kpinball yet.  Unless there is one
being worked on under the radar.  :|


> Something like a separate green is not planned (after all, this is minigolf,
> not real golf). For bridges and fences, I'd rather have the designer put these
> on the course separately. The textures should really only be used for flat
> stuff on the ground, because these textures are reused in the 3D view.

Oh, I've seen minigolf courses with green (more for silliness really).  :)
Either way, the hope is to provide a sampling a different textures
(including green, snow, metal, maybe even lava, bamboo, moon rock,
etc) so that course builders can get pretty creative with theming.

And thank you for confirming that there will indeed be foreground
elements as well (including bridges and fences), since this opens the
door to more dynamic add-ons.


> I hoped to get enough depth perception through the texture blending, i.e.
> through usage of different textures for different height levels and by making
> these textures darker and lighter at lower and higher points. Of course, this
> concept benefits from different textures being available for different height
> levels.

The visual marker idea I mentioned earlier would indeed benefit
greatly from this height level texturing now that you mention it.  And
it wouldn't even require any additional texture work -- if I took the
same grass texture (for example) and saved it in three different
resolution (64x64, 128x128, and 256x256), then we can quickly simulate
the appearance of grass that's far, intermediate and close from the
viewer respectively!

Great idea, I'll try that out ASAP once I get my heightmap up and running!  :D


> Yes, that was my idea. ;-) I want everything around the course being shipped
> in one single file. The heightmap is already packed inside the course file
> (i.e., "test1-terrain.kolf"). To change it, do the following with your
> heightmap:
> $ base64 test1-heightmap.png | xargs echo | sed 's/ //g' > test1-heightmap.enc
> Then open test1-heightmap.enc and paste its content in line 18, after the
> "Heightmap=".

I see, yes I'll try that this evening.  :)

Just to make sure, though, the final version will allow course
builders to import custom heightmaps correct?

> The problem is that creating a single background texture already takes one
> full second on my system. With animations, we have to prerender several
> frames, which might make this part of the editor incredibly slow.

Ah, just to reiterate my earlier comment, the animation need only be
in the add-on textures. I can live with static backgrounds.  :)