-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Red dots while traveling on the worldmap #3
Comments
Impossible. :-) |
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
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 filesI 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:
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 :)
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 :) |
Isn't Fo1 using pixel color to determine travel speed? :> |
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. |
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. |
Random idea always is bad ideas :-) |
Random ideas are good for brainstorming possible solutions to tricky problems. :> |
Random Idea 403958232 (See image here)
|
Wouldn't you have to worry about player moving whole WM away from dude's position? |
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: |
Implemented #3 - There are a lot of improvements that can be made, this is an early proof of concept...
#3 - A bit better register usage, no EBP and removed some redundant instructions. - draw up to 1024 dots instead of 512.
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 |
Here is another one: https://i.imgur.com/md2V8iU.png Maybe a delay of 200 or 150ms would get it a tad closer? |
Why wasn't it added directly to sfall? |
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:
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. |
Yeah, merging it into Sfall directly, and / or adding support to load custom *.dll files would be good. For ddraw.ini I suggest:
That should cover our needs at this point. By default EnableTravelMarker could be set to 0 for anything outside of Fo1in2. |
(from rotators/Fo1in2#3 by ghost22238)
Red dots are a thing now. Ticket closed. \o/ |
Unlike Fallout 1, there are no red dots marking the path traveled in Fallout 2.
This feature requires some serious hacking skills, which makes it very unlikely to get implemented.
Still keeping the issue ticket, though, just in case.
The text was updated successfully, but these errors were encountered: