Red dots while traveling on the worldmap about fo1in2

[wipe2238]

Random Idea 403958230

Instead of trying to (re)introduce abandoned mechanics by hacking engine all over the place, how about one big dirty hack. Take a shower or two before reading further.

Script stuff

• translate dude's current zone to tile
  tiles data from worldmap.txt contains art_idx which is what we need here

  art_idx indicates which image (art/intrface/wrldmp*.frm) is to be displayed for this tile

  aaand we already keep track of (some) tile data for each zone, just with no actual use other than debug spam; adding art_idx there is just one extra line

• translate art_idx to .frm filename
  thats probably obvious knowledge (which i don't have) for average Fallout2 modders so i blindly assume there will be no problems with that

• translate zone position to .frm xy position

That way we have dude's position converted to exact pixel in specific .frm; that's where our dot should appear. Preventing dotspam shouldn't be hard either; global script which runs only once every 1000-2000ms cooldown should do the trick. All scriptable so far.

Sooo... Why so much care about .frm in a first place? Four words.

Runtime editing .frm files

I fully aware that it still sounds batshit crazy, but (i think) less crazy than asking asm wizards to implement and hack in whole red dots mechanics from scratch. In the end of the day, our dreamlist narrows to "only" two points:

• allow scripts to change single pixel color of selected .frm file
  input (required): .frm filename, x and y positon, rgb color
  input (optional): frame number (defaults to first frame), alpha?

Changes should be as permament as possible; while here we need them for max few minutes, and on worldmap only, it could (in theory) be useful for other things, totally unrelated to WM. Making edits in "set once, use everywhere" fashion (probably) wouldn't require to touch any other frm-related functions, but that's just a wild guess :)

• allow scripts to force reloading .frm file
  input (required): .frm filename

While keeping all dots for a whole game session would be a funny feature, novelty would die after half hour, so we need to clean up worldmap for a next trip. Easiest way is to simply load .frm from disk, be it inside .dat or in random folder somewhere.

---

That's it, the whole idea. Took some time to come up with anything which have realistic chance to happen during our lifetime; any other ideas which we happily produced while working on mod was, well, very mod-specific. Editing .frm in-memory isn't - it's up to modders to build own features basing on it. And if scripts would be able to read .frm pixel color as well, that's a whole new world opening.

And it's just an idea so far, there's not a single line of code in scripts to back it up yet. I have less than zero clue how engine handles graphics as well. Is there sprites cache separated loaded .dat content? Are unused sprites cleared? How hard whole thing sounds for people who know how engine works? And so on, and so on. That's the question to assembler wizards :)

[FakelsHub]

Why wasn't it added directly to sfall?

[Lexx2k]

Yeah, merging it into Sfall directly, and / or adding support to load custom *.dll files would be good.

For ddraw.ini I suggest:

[Misc]
;Set to 1 to enable Fallout 1-styled travel markers on the worldmap.
;Default color index is 133 - red
;Default delay between dot creation (in ticks) is 150.
;Default amount of max. dots drawn is 1024.
EnableTravelMarker=1
TravelMarkerColor=133
TravelMarkerDelay=150
TravelMarkerCount=1024

That should cover our needs at this point. By default EnableTravelMarker could be set to 0 for anything outside of Fo1in2.

[Lexx2k]

Red dots are a thing now. Ticket closed. \o/

[FakelsHub]

Impossible. :-)
Too much will have to hack the engine code.

[Lexx2k]

And if scripts would be able to read .frm pixel color as well, that's a whole new world opening.

Isn't Fo1 using pixel color to determine travel speed? :>

[wipe2238]

I was more thinking about using it to copy (parts of?) one frm into another. Also could be nice way to prevent unneeded reloading - if pixel at XY does not have color RGB, it means it has been edited and should be reloaded. Something like that.

It's just "nice to have" category as of now. We don't need it honestly, but if scripts could change pixels like they please, function for checking them feels just natural. I believe writing .frm data in-memory is harder to do than reading it.

[Lexx2k]

Random Idea 403958231

Use town location draw code to paint fake-locations with 1x1px red_dot.frm graphic on player position.

We can enable/disable locations on the worldmap, and we can move location position via script. Maybe it's possible to abuse this mechanic and "create" new ghost-locations via global script on player position?

Once the player stops moving, they will be deleted again.

[FakelsHub]

Random idea always is bad ideas :-)

[Lexx2k]

Random ideas are good for brainstorming possible solutions to tricky problems. :>

[Lexx2k]

Random Idea 403958232

(See image here)
We need to get the center screen x,y (red color) on the worldmap interface.
From there on, we can calculate the visual area on screen, see the valid border region (blue color).
 
We create a new array "draw_image_wm" which contains coordinates and (optional) the graphic file: [x,y,image]
 
Now, on every frame we calculate the relative position of the wm interface on the worldmap and cycle through our draw_image_wm array.
 
If coordinates inside the array are within our valid border region, and the image does not exist yet, we create the image on the relative x,y coordinates.
If the image already exists, we adjust the x,y coordinates relative to the screen center x,y.
 
Once the player stops moving or leaves the worldmap, all images will be deleted and the draw_image_wm array gets cleared.
 
What do we need for that?

• The only thing we need for a prototype is to get the current screen center x,y on the worldmap interface.

 
I don't know how hard this idea would hit on performance, but in worse case we could limit it to a maximum of x images. Still, I think it would be useful to get the relative center screen x,y.
 
PS:
Unrelated to that, it would also be nice to get the current mouse cursor x,y at any time. It is already possible to get the current mouse x,y but as far as I am aware, only with the MouseClick-hook?
This in combination with the relative coordinates from above could allow more unique features
Example: show text on wm screen when hoovering over a location circle, or show ingame hints when hoovering over an object.

[wipe2238]

Wouldn't you have to worry about player moving whole WM away from dude's position?

[Lexx2k]

That's why we calculate x,y based on current view and not based on player position. We only use the player position to push the initial coordinates into the image array.

Not gonna lie, it requires some math magic that I am probably too dumb for. But in theory it should be possible? After all, the red dots are "fixed" on the wm. They will never move by themselves. We "only" need to know if the image (initial x,y) is in the current wm screen view and then offset their x,y accordingly (or delete / hide the image, if it is outside our current view).

The only thing I'd worry about is that the refresh cycle might be too slow and produce jiggly / shaking dots. But this is something that should be tested in a prototype...

/Edit:
Now that I'm thinking about it... can we even move existing windows / images? If not, we'd have to delete and recreate the images in every frame, which might cause an additional performance drain.

[ghost2238]

https://i.imgur.com/01pXbdB.png is the current implementation with 250ms delay between each dot.

Fallout 1 for reference: https://i.imgur.com/ROCKYDi.png

[Lexx2k]

Here is another one: https://i.imgur.com/md2V8iU.png
Top is Fo1, bottom is Fo2, 300% zoom.
Transition is from mountains to desert tiles in the center.

Maybe a delay of 200 or 150ms would get it a tad closer?

[ghost2238]

We weren't sure it was going to be accepted, so this was made as a proof of concept. If you want to integrate it directly to sfall feel free. We've been thinking of a number of things that can be exposed as config options as well:

• Choosing what color index to use for drawing.
• Setting the amount of delay between each dot drawn.
• Amount of dots drawn. Not sure if this is really needed but why not...

This is a side note, but it would help greatly for small experiments like this if there had been a setting in sfall to load arbitrary DLLs by setting a config option. It'll be a simple LoadLibrary call to load additional DLLs after attach to the process.

Forcing everything to be built via sfall is not ideal since it's starting to become a fairly large project and I sometime have build issues due the older platform targets not being available and what not.