Save RNG settings to SRAM and add Next Room transition lag option#267
Conversation
|
I liked that my Phantoon settings go back to normal after a reset. Are we running out of persistent RAM space? |
|
No, but thanks for the feedback. The way RNG settings work now should be pretty similar to how it was originally, but it's different than how it worked last year. The way it worked originally is more popular (I think) but there has been a request to make it work more like it did last year. Moving RNG settings to SRAM was seen as a potential compromise... but it is fixing the problem by making yet a third way that RNG settings work. I think we make it an option to have RNG settings work either how they did last year or how they do now (with how they do now being the default) and in both cases settings go back to normal after a full reset (they are retained after a soft reset). We don't have to move RNG settings to SRAM. One wrinkle in this discussion is the SD2SNES firmware. I'm on 1.11.0 firmware, but there's a 1.11.1 firmware that changes how/when SRAM is saved. That's another thing driving the discussion; I guess the way the practice hack RNG works now doesn't play as well with 1.11.1 firmware... for some reason... I think I need to re-read the discussion on that... Anyway thanks for the feedback. |
|
Okay I've thought about it some more and I don't think anyone really wants it to work like it did last year when there's an option to save to SRAM. I think SRAM is the answer, and the toggle should be whether or not a hard reset also resets RNG. This toggle can be defaulted on. |
|
This is ready to go now. I may merge it later today. |
|
I need to do some more testing on the most recent adjustment to door transition artificial lag. Backstory: I've been playing around with a strat to both enter WRITG faster and potentially reduce lag. Human testing was looking good, although I did run into the sound queue issue. I'll post a link to my clip of two attempts where one got hit with the sound queue lag. This is why I want the NEXT ROOM mode. With NEXT ROOM these were both 122. However when I did some TAS comparisons with vanilla, I found vanilla was giving NEXT ROOM times of 133. The prac hack was not as laggy. I did some fine tuning and got prac hack to match up with vanilla most of the time; not perfect but good enough. Tonight I did some human testing of the strat, and I was getting 126 and 127 times; I don't even think I saw a 133 with it. This prompted me to go back to the TAS. I couldn't find the exact one I used for the fall test so I made two similar new ones. One gave a 133 in vanilla, and one gave a 124! I wasn't expecting vanilla to have that much variance. The prac hack gave 126 and 123 for those two scenarios, so the prac hack is still a bit less laggy than vanilla, but not completely off base. The real fun came when I made adjustments. If I bump the LDX starting loop count from 002E to 003E then the 126 became a 133, but I knew from other tests that 003E was too much lag in other cases. I then tried 0036 which gave 130, 0032 which gave 129, 0030 which gave 127, and then I tried 0034... and it gave me a 127 (!!) I had to double check this to be sure. Setting the loop counter to 0032 gave a 129, and when I increased artificial lag by increasing counter to 0034, it decreased the actual lag by two frames! So this particular falling through the door use case seems to be right on the knife's edge of lag frames. It would explain how vanilla could give a 133 and a 124 for practically the same scenario. Anyway I need to do more testing with the adjustment from 002E to 0032 to make sure it doesn't adversely impact other scenarios. If it does I might go back to 002E. I don't like seeing the prac hack 7 frames off, but at the same time if vanilla can show that much variance then might not be much we can do about this falling through door scenario. Many of the other scenarios I tested were spot-on with the 002E value, although hopefully 0032 also works; it is a pretty small change in the artificial lag. |
idlechild
changed the title
|
I made one more adjustment to increase lag a bit more. Out of 20 head-to-head TAS comparisons, I have one where prac hack had one extra lag frame, three where prac hack had two fewer lag frames, and the other 16 matched. I'm just going to do some local testing and then will merge. |
2 participants
TODO: Save RNG settings to SRAM. Not done yet but that's an idea being kicked around so wanted to bring it up here. I may work on that next.
In the meantime, this simple change gives a way to measure door transition lag entering WRITG without adding in the sound queue lag from fast pillars. The sound queue lag is suspected to be a random and unavoidable cost, whereas lag entering WRITG can be reduced based on how we enter the room.