Fog of War

[DerVVulfman]

Well, as I previously stated...

It needs some cleanup by my standing, and I want an optional means to flag events besides within the config page. So not done yet.  BUT it is performing the options you've requested... and more.

So additional work will be performed.

I was able to apply your options TO my demo, only the mild correction to the 'check_adjacent' method within Spriteset_Map being necessary.

Why my version has an altered 'check_adjacent' method

The original check_adjacent method asked for five parameters:

i : x-coordinates
j : y-coordinates
k : layer (whether dynamic or static)
grid : map grid
flag : a called flag

The thing is, in every instance, the grid was always $game_map.fow_grid.  And in every instance, the flag requested was the Fog_of_War::REVEALED flag.   To me, it didn't make sense that these two values would be requested every time when they could just be IN the method itself.

That's why my version just requests the i, j, and k parameters, and have both grid and flag defined in the method itself.

However, whilst it worked with your edits, I encountered an issue.  When the player moved about on the map, the player erased the fog within the 3-tile range prescribed by the FOW_RANGE_DEFAULT configuration variable.  After standing for some time, the area around the player erased more, returning to the 5-tile range defined within the FOG_MAPS array for map 3.  So it did not properly erase the  area around the player whilst moving as it should, only that around the player when standing still.


The update_fow_tilemap section does have long code, some quite similar to one another. Do note that he has comments that his work is designed to 'only process fow currently on the screen'. And for that, he used routines that had lines such as:

if @fow_tilemap.map_data[x, y, 1] == 96
    @fow_tilemap.map_data[x, y, 1] = 96
end

Now while it ensured that the data within the coordinates of x/y became whatever value it demanded, it only performed the data change if the x/y coordinate data wasn't.  Odd as it sounds, performing the check and skipping takes slightly less time than arbitrarily changing it every time.  Go figure. 


Some of the content you 'removed' thinking redundant within the update_fow_tilemap was was actually present to prevent errors and map glitches, particularly around the static secondary static map section when it indeed needed to see if areas needed to be SKIPped.  The SKIP flag is called into play both within this area and tested for when a map is initialize or re-initialized, this to reduce more lag and fog processing.

And further below is the area that updates the tileset based on 'range'... likely where it sees (at least within mine) the proper area range for the player or the NPCs and the area to erase.

Meanwhile, changes I made to  update_fow_tilemap include both the request of x/y coordinates of the target character (player or any event), and a speciic range for said player or event. The range passed into it directly related to the area you erased near the bottom of the method.


Again, I do state it needs some cleaning up.  But some facets of the script need remain in place, or optimized rather than wholly removed.

[Tepe]

You're probably right, but at the moment we have two different scripts and I don't have as much experience in RGSS programming as you do. So of course it may work differently in your script than in mine. But there has to be optimization in fow_update_tilemap. In the original code there are large fps drops. The difference is at least 2x in favor of my version of the script. Of course, as I mentioned earlier, I still have frequent drops but it doesn't reach less than 16 on a large map with more events, and in my case the additional load is generated by other scripts, some of which are for a specific fix. I will also add that in my case there are drops only when the fields are undiscovered, but if they are uncovered, the fps normalize, because in such a case the visibility is limited to the screen size and not the entire map. The maximum number of frames is about 36 but with frequent fluctuations, while in yours I have a stable 8-9 fps in all time.

[DerVVulfman]

But there has to be optimization in fow_update_tilemap. In the original code there are large fps drops. The difference is at least 2x in favor of my version of the script. Of course, as I mentioned earlier, I still have frequent drops but it doesn't reach less than 16 on a large map with more events, and in my case the additional load is generated by other scripts, some of which are for a specific fix.

THAT... is why I crafted the customized moving? method, one that checks to see if any NPC just 'starts' moving from one tile to another.
Were I to have the method that reveals the fog execute based on the default 'moving?' method, the 'fog-revealing' method would execute over-and-over from the start of the NPC's move into a tile space to when it finishes walking into the tile and stop.... That's a lot given it need to only reveal that area once, and not over and over for the same area.  With four NPCs, it reduced FPS from 39 to 36 on my PC.

The maximum number of frames is about 36 but with frequent fluctuations, while in yours I have a stable 8-9 fps in all time.

I gotta wonder... how are you getting that low a FPS with this?



I had to make 23 events all clean the map (300x250 tiles) at the same time.  Not one or two, but 23... and that's quite a number cleaning the map on your behalf. Under normal circumstances, it is 40fps, but switches to 30 FPS when the defined events move and clear out the map.  And that FPS reduction changes (increases faster) as the map is cleared.

But that is with 32 events flagged to clear the fog, a rather unusually high number indeed.

Again, I am still working.

Video difference of your version, and mine.  Yours with the FPS showing significant drops down to as low as 3.  Mine with a red fog with FPS drops no lower than 29.  Both using the same map with 23 keyed events that erase the fog.

  2024-11-13 18-56-38_Segment_0_x264_x264_x264_x264.mp4 (Size: 924.15 KB / Downloads: 1)

[Tepe]

Hmmm its really strange... So, I must test this again. Your code is without any changes?

[DerVVulfman]

My code is as I last posted. And your code is as you sent to me... though you did neglect the Scene_Map portion.

I basically made a COPY of my project bosting the 23 walking 'fog-erasing' sprites, and pasted yours in. Then added the additional NPC entries into your array, so yours would use the same 23 NPCs as mine.

That's all.

[Tepe]

In that case I don't know why my situation was/is the other way around. In that case I would have to send you my entire private project for review via PM. By the way, maybe you could help me with a few other things, but I don't want to impose on you either. :)

[DerVVulfman]

More work was done.    

First, I revised the way the map is revealed.   

Originally, it used to be revealed by the player, whereby he updates the entire grid, checks to see if the events are hidden unless in X-range tiles, and then redraws the remaining static and dynamic fogs within the field-map's spriteset.  The mechanics also worked for events, and each event... when it moved.. would do the same.  But with a large number of events, it would likely slow down (a little or a lot depending on the code).  Imagine if ten events moved in unison... it would attempt to refresh the fog ten times!

So I thought...    the field map gets updated after every event... Hrm..... 

Well, each event COULD... update the grid, sure enough.  It would perform the math of what map areas were erased or not.  But after that, I would have it set a form of "REFRESH THE MAP" flag.

So now, IF an event moves and erases some fog, it merely sets a flag rather than forcing the field to update.   And if five or eight events move and erase some fog, that one flag STILL gets set.  Executed within Game_Map itself, the fog will only be updated once no matter HOW many events have moved to trigger it.

---

Now in the demo, I set the opacity of the STATIC fog to something less than solid, whereby I can barely see the trees underneath.  However, I found that there was an area around my player that was a bit... tile wary.



It appears that Wachunga thought to 'erase/remove' the fog of the dynamic map where the static map existed with a scant amount of overlap.  However, the removal was ... in my opinion... JANKY!

So I made a new configuration variable to DISABLE the 'dynamic-fog-removal' feature.  Or precisely, to enable it as it is a feature wachunga put in by default.   Yes, allowing both the dynamic and static fog will make the static area darker and more solid, but it is a hella better trade-off.

---

I renamed a few CONFIG variables, but I did so much more in breaking up the system into bite-size pieces for easier observation and study. 

Soon... to release (I guess?)   I hate writing instructions... even if already partially written...


  Fog of War Demo.zip (Size: 953.81 KB / Downloads: 1)

[Tepe]

Okay i must see this. :D

EDIT:
I tested Your code and yea it work better but still we have two problems:

1. I signalized you earlier:
   

Change in Game_Character method update_move to

Code:

  def update_move
    # Calling the original method
    wachunga_fow_gch_update_move
 
    if $game_map.fow
      if $game_map.fow_dynamic && (@x != @last_x || @y != @last_y) && self != $game_player
        # Let's assume that `$scene` is the scene of `Scene_Map` and `spriteset`
        if $scene.is_a?(Scene_Map) && $scene.spriteset
          # Checks if a character has entered or left the player's line of sight
          $scene.spriteset.update_event_transparency(self)
        end
      end
    end
 
    @last_x = @x
    @last_y = @y
  end

2. When player reveal fog then fps still drops but it is level up because in my project fps drops only then player move and reveal fog.

Change Class Game_Player < Game_Character to this

Code:

class Game_Player < Game_Character
  #--------------------------------------------------------------------------
  # * Frame Update (jump)
  #--------------------------------------------------------------------------
  def update_jump
    # Inherit original method statements from the Game_Character superclass
    super
   
    # Update fog of war when jump is completed and FOW is active
    if $game_map.fow && @jump_count == 0
      $game_map.update_fow_grid(@x, @y, $game_map.fow_player_range)
      $scene.spriteset.update_event_transparency if $game_map.fow_dynamic
      $scene.spriteset.update_fow_tilemap
    end
  end

  #--------------------------------------------------------------------------
  # * Frame Update (move)
  #--------------------------------------------------------------------------
  def update_move
    # Update fog of war if player moved to a new position and is not jumping
    if $game_map.fow && (@x != @last_fow_x || @y != @last_fow_y) && !jumping?
      $game_map.update_fow_grid(@x, @y, $game_map.fow_player_range)
      $scene.spriteset.update_event_transparency if $game_map.fow_dynamic
      $scene.spriteset.update_fow_tilemap
    end

    # Inherit original method statements from the Game_Character superclass
    super

    # Update last recorded FOW position
    @last_fow_x, @last_fow_y = @x, @y
  end
end

[DerVVulfman]

The changes recommended actually do nothing.  Allow me to explain.

Within the Game_Character class, the code already reads:

  def update_move
    #
    # Perform the original method
    wachunga_fow_gch_update_move
    #
    # Perform only for dynamic maps (must be FOW)
    if $game_map.fow_dynamic
      # If character moved and not game player
      if (@x != @last_fow_x or @y != @last_fow_y) and self != $game_player
        # Check if character entered or exited player's visual range
        $scene.spriteset.update_event_transparency(self)
      end
    end
    #
    # Record last position
    @last_fow_x = @x
    @last_fow_y = @y
    #
  end

Minor note: I used  @last_fow_x and  @last_fow_x, an alteration if another Game_Character script uses like variables, these specific for the FOG script alone.

By the fact that it first must check that the $game_map.fow_dynamic flag must be on, the map must have fog-of-war engaged.  As such, the inclusion of your  if $game_map.fow condition is actually unnecessary.


Insofar as the changes to GAME_PLAYER, combining the $game_map.fow and  @jump_count == 0 upon a single line within the update_jump method offers no actual change except cosmetic.

For the update_move method within GAME_PLAYER, your line that handles $game_map.fow, the X/Y coordinates and the jumping? test does the same as within this version, so it too is only cosmetic. 

The inclusion of...

    # Update last recorded FOW position
    @last_fow_x, @last_fow_y = @x, @y

... actually means nothing.  Its already been taken care of.

Do recall that before this line, it has the line reading "super".  This means that this method inherits from its superclass, the Game_Character class.   And within Game_Character's own update_move, this update of the player's position is already handled.

Ergo, these changes would do nothing.

---

EDIT: I just found out that Wachunga released a version after what had been discussed, minor changes within Game Player to accommodate anyone 'else' adding code to the move and jump methods. An easy update.

Also, stack-error preventative code has been added to Game_Map and Game_Player to what I now have

[Tepe]

I see that I have to show you in a video and actually prove that they do something since thanks to them the fps meter in my specific case went up a lot. I wouldn't have turned it on if it really didn't do anything... but that's OK, nobody has to use it anyway... however, as I mentioned earlier in my specific case it makes a significant difference.