This topic contains 1 reply, has 0 voices, and was last updated by  Rommel 9 years, 3 months ago.

  • Author
    Posts
  • #6589

    Rommel
    Participant

    Dear Gavin:

    As you may have read in my recent notes in your screen shot thread, it is almost impossible to sculpt the surround to properly conform to elevation changes in the playfield.

    This appears to be due to the preset smoothing for non generated surrounds and also partially due to the way the scaling algorithm applies to the surround and the playfield maps.

    It would be much easier to fashion a custom surround and make it seamless if the smoothing and scaling were either user adjustable or preset such that the same process can be applied to both maps. If having some nice landscapes where the surround is indistinguishable from the playfield, is something that interests you, then perhaps this can be made easier to accomplish.

    In addition to the river valley concept, where the water meanders across the surround and through the playfield using a single texture for everything close to the surround elevation, I have attempted mountain landscapes where the surround joins the mountains in the playfield.

    Mountians are even more difficult to blend due to the numerous changes in elevation. There is also the problem of allowing only one texture for the surround. Although I have had some success at force fitting the junctions, the appearence is horrid where the elevation change causes a texture change to the playfield.

    By treating the custom surround and height maps the same, it appears possible to create landscapes that contain both the playfield and the surround as a single bump map with the playfield area simply being designated as the central portion. If this is too much trouble, perhaps we could continue to use two seperate maps by making a copy of the center of the combination surround/playfield height map and saving it as the playfield map. The surround/playfield height map could then act as the surround by masking the playfield portion if required.

      NOTE: This should not be required. A solid surround map with no masking applied was how I made the “Nile Pond” map appear the most seamless.

    Also, while I’m on maps, if we had a way to declare a geographic or relative location to the maps, it would make the direct placement code much easier to use with a variety of map sizes. As an example:

    The Apocalypse modification uses direct placement to locate a city in the center of the map by hard coding it to map coordinates (128, 128) instead of being coded to a relative location. As you might imagine, this causes great distress when the map is resized.

    At this time the only solution available to the map designer is to make seperate placement files for each of the possible map sizes contemplated. In addition to creating a great deal more work for the designer, this method also requires that a large amount of basically redundant information is required to be downloaded by the players.

    What I’m thinking about here is a way to designate reference locations that are not changed by scaling the map size. For instance:

    Int (Map-Height-X / My Float X) and Int (Map-Height-Y / My Float Y) for the location of the city instead of using fixed locations such as 128, 128.

    If any of this is of interest to you, or might be if it was explained a little better, let me know and I’ll send additional photos of my experiments and see if I can explain myself in more detail.

    Now for the Naplam. Although the overlapping object placements are more bothersome to me in light of the crater problem I detailed earlier, the object overlap has been addressed before and I assume it is being addressed again. Not wanting to spend time on something that wouldn’t be beneficial to any of us and not finding //fixme in the napalm code, it was simply irresistable.

    The simulate addstep code in the Naplam.CPP file appears to be making the napalm run due south, whether it is on a 15 degree slope rising to the south or even a single, 50 point rise (a cliff) because it always defaults to add the napalm step to the X_ , Y_-1 cooridate if all four points evaluted to the same elevation. Perhaps the problem with the elevation check is due to the tiling required to alter bump map elevations but that is only a guess at this point and it is an entirely seperate function.

    To make a more realistic effect, perhaps instead of adding all of the napalm to the southern most point (if all points are deemed the same) it could be divided such that equal portions are placed on all points adjacent to and at the same elevation as the impact point. Each succesive step could perform as currently designed except the scan would allow the napalm to expand in a radial fashion, taking into account, any dips or rises encountered along the way, while moving the approriate percentage of napalm to the proper location(s) depending on the amount of variance in the elevations of the points checked.

    It seems plausible that, by reworking the add step scanning sequence, firing napalm onto a perfectly flat map with a 15 degree slope upwards to the south, could result in a spread to the north, east and west with the majority of the flow going to the north instead of unnaturally running due south.

    If this isn’t currently being addressed but sounds interesting, let me know if you’d like for me to take a stab at it. It seems like an interesting project and one that I should enjoy.

    In the alternative, perhaps changing the code from this :

    	else if (heightD < height)
    {
    // Move down
    y_ -= 1;
    }

    to this :

    else if (heightD < height &&
    heightD < heightL &&
    heightD< heightR &&
    heightD< heightU))
    {
    // Move down
    y_ -= 1;
    }

    Would work a little better for the time being.

    Best Wishes,

    Rommel

    #53002

    Thrax
    Participant

    I won’t bother quoting it, there was just a bit more than I needed.
    In short, Rommel, We’ve already fixed most of it..

    In the v42 alpha, we totally recored how landscaping is processed.
    Besides a overall rendering switch, the Surround and texturing is also
    completely redone..or rather, Deleted..
    Instead, we switched to a one landform option.

    Using one grey-scale landform image of your creation, you can now
    define the Total dimensions, and then a second Play-area dimensions.
    A box within a box idea. Using your own landform image as the
    Surround, and the play-field.

    No more generated surrounds or mis-matched edges, simply all one
    giant map with a battle-field in the middle.

    -note: This however does not address your placement location issue.
    Instead, it make’s it even worse.. As the current placing patterns
    would be ruined if you stretched the total-size wider. (1024x map with
    512x play-area)
    I will also be looking for a simper solution to this, as the placing in
    Swars is 10x more complex than anything in Apoc.
    Possibly a center-point origin (0,0 being dead-center) would stay put no
    matter what scaling was done.

    Napalm itself has also been looked at and redone somewhat; spreading
    more circular, and reducing the “Due-South” aspect.
    Add to it a lowering of the napalm-hight to 1, and the pooling of it is
    almost natural in most cases.

    #53003

    Rommel
    Participant

    Hi Thrax:

    Hey, I’m sorry you find quoting me to be a pain, I rather enjoy quoting you.@thrax wrote:

    I won’t bother quoting it, there was just a bit more than I needed.
    In short, Rommel, We’ve already fixed most of it..

    In the v42 alpha, we totally recored how landscaping is processed.
    Besides a overall rendering switch, the Surround and texturing is also
    completely redone..or rather, Deleted..
    Instead, we switched to a one landform option.

    Using one grey-scale landform image of your creation, you can now
    define the Total dimensions, and then a second Play-area dimensions.
    A box within a box idea. Using your own landform image as the
    Surround, and the play-field.

    No more generated surrounds or mis-matched edges, simply all one
    giant map with a battle-field in the middle.

    -note: This however does not address your placement location issue.
    Instead, it make’s it even worse.. As the current placing patterns
    would be ruined if you stretched the total-size wider. (1024x map with
    512x play-area)
    I will also be looking for a simper solution to this, as the placing in
    Swars is 10x more complex than anything in Apoc.
    Possibly a center-point origin (0,0 being dead-center) would stay put no
    matter what scaling was done.

    Napalm itself has also been looked at and redone somewhat; spreading
    more circular, and reducing the “Due-South” aspect.
    Add to it a lowering of the napalm-hight to 1, and the pooling of it is
    almost natural in most cases.

    The napalm code I proposed at the end of my post, requires no testing and could be implemented immediately. This would provide a fairly painless subversion release (41.4) that could be easily staged to coincide with the stat reset that is swiftly approaching, while making a substancial improvement to an old problem.

    It sounds like you have more than enough changes completed on your own to implement a subversion upgrade along with the stat reset but if not, this might be a nice interim solution to both the southbound napalm and the stats.

    Making the center of the map coordinate zero isn’t a valid solution for the overall problem. Deviation from standard practices should generally be avoided and considered extremely carefully before implementation as this often complicates things more than it helps.

    Hoping to hog you soon,

    Rommel

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.