Topic: Attempting world-specific new roads

I was immediately thinking about your buildings and shared your concerns initially -
but on second thought, I hope it will not matter.

My idea is, that anything moving along the roads does not really care about the road graphics.

• I assume that, carriers will check whether a road to coordinates x|y does exist, and if so simply are given the permission to use it.
• I go on assuming that they will then check the altitude coordinates to determine the time the animation should be played to reach these coordinates (road steepness).
  Knowing these things, I expect the carrier animation will steer a direct line to this spot. So they will use the "center line" of the road, and since carriers, beasts of burdon, wares etc. are usualy wider than 5 pixels anyhow, they, and not the road texture will conflict with any building. So there is no change in this respect.

Could anyone knowledgable please verify this from code, and correct my thoughts if necessary!

The extra 2 pixels that I am proposing here, are not meant to visually broaden the road. (in any case not the "normal" ones)
Instead, I had in mind to have them semitransparent and so do some modest blending with the underlying terrain.
Alternatively, or may be in addition, I am thinking about using these to let the roads vary a bit in width (at flags and where carriers stand) in order to overcome the "straight cut" impression a bit.
For high-traffic roads I am playing with the idea of a lining and paving, and maybe an increased width. But that will only be possible if those roads can be broadend.

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

Thanks a lot, SirVer
I'm always thankful to be so reliably supported when we get stuck here with code-related questions.

Now -- who can give us his preliminary assessment, whether transparency with software rendering will be feasable?

Or is it to be replaced anyhow with OpenGL on the long run, and we should not care much about it?
I have learned that some still prefer it for its softer borders.

My problem is that WL itsself is the only testing environment for my graphic changes, and as long as none of the changes mentioned above are implemented, I can not verify any results.

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

Ixprefect has kindly already reacted to my request for his assessment.

Without further investigation so far, he thinks that a border transparency might be possible by doing something with "the offset inside the inner loop"
I've no idea what that means, but I trust him in any case

"Real alpha transparency" could be too expensive though, he continues (workload for the CPU or the programmer?)
He'll come back when he has looked deeper inside the code.
So ... keep you fingers crossed, everyone...

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

Note that shevonar takes a shot at improving the !OpenGL renderer. As a side effect, better road display at least for !OpenGL might fall out.

Top

Quote

Okay, thanks very much, Ixprefect.
Trying to summarize what I have understood:

On the OpenGL side, alpha blending is not supported currently, but you are seeing a way to implement it.
A precondition for that is that the width of the roads should be limited to a fixed 8Px.
I would have hoped for something a bit wider than that, to have some freedom for border variation, but it will do.
OpenGL would then allow that road texture can adapt to the underlying terrain.
Seen from the graphic side, this would open up so many options for the road system, that waiting for such an implementation seems very worthwhile.

Ixprefect, would you please be so kind as to write down your idea, as a suggestion on the bugtracker, a blueprint, or whatever, at a place and in a form that it won't be lost, and other programmers understand your concept?

The SDL side will be a lot harder to fix if the same functionality needs to be supported.
This is espicially true, if the support for 16bit color mode must be retained.
(A palleted image with one fully transparent color, would be no match for the OpenGl side but a severe limitation and effectivly forbid most techniques.)

In the light of a fading importance of the SDL rendering, see https://bugs.launchpad.net/widelands/+bug/887093,
I personally would not have a problem to accept that the full beauty of the roads only comes with OpenGl, much less with
the suggestion that 16bit color modes should no longer be supported.
However, all of this is not for me to decide, instead, the guys with the master plan - most prominently SirVer - are kindly asked to speak up on this topic.

Other than that -- is there anyone interested and capable (as in "skill" and "spare time") to actually make Ixprefects ideas come alive?

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote