I was watching this video for Super Mario 64 when he started explaining something that seemed familiar. He explains what they call 'parallel universes' in SM64.
His explanation is very similar to an exploit we use in Portal called Save Glitch where we separate the 'camera' from the 'hitboxes'. In this case in SM64, they use 'floor detection' and 'Mario's position', but the concept seems to be the same.
Check it out. Jump to 10:45 directly here: youtu.be/kpk2tdsPh0A?t=645
So, could there be some similar kind of calculation error going on? Converting between different numeric types and causing an overflow so that we aren't bound to our 'floor position' anymore?
Yeah those different. They may have similar effects but they aren't the same. Based on the explanation in the video it is very different than our current understanding of Save Glitch.
Memory overflow in PC games often cause crashes and doing that would be likely to happen if Portal was on the NES. Various observations can negate that kind of theory : the floor detection operates on blocks around a certain range around the portals and with that kind of theory, the sg would be independent of the portals positions. Also I am glad to see you talking about sg theorizing.
A few weeks ago I worked out why the collision for save glitch is only for certain world "blocks" around the portals, and the reason why is based on a sort of parallel universe. It's not what you're talking about, although going extremely far Out of Bounds along any given axis gives something similar to what you're talking, but the other way around: Your camera shows an object-less entity-less copy of the original world, but the player still treats it as Out of Bounds space.
The reason that the collision of save glitch is only close to the portal you save glitched on is because (as is given a long explanation in chamber 04 of the developer commentary), to make the collision transformations required with portals run smoothly, they made it that all parts of the world within a certain radius of a portal could have this hyprid collision system for props and the player close to the portals that was accurate enough in the context of the game, but quick enough for it to run smoothly. Somehow, save glitch results in you only receiving the hyprid collision of the portal you save glitched on.
@PackSciences The situation described above in necessarily 'memory overflow'. The mention it is simple type conversion, which happens a lot in PC applications. For example, C# has implicit type conversion between certain numeric types. Also, the devs could explicitly truncate an int to a short. I used to do a lot of that kind of work when calling low-level functions (COM) or interacting with hardware directly.
I doubt VPhysics has that kind of error. Check Valve Dev Software Wiki & the VPhysics code if you want to find something, but I doubt you'll find anything. https://developer.valvesoftware.com/wiki/VPhysics You can find VPhysics code in Source SDK if I recall correctly.
Starting now and currently being grandfathered, all console runs will be manually retimed with load times removed. This process will be redone by the verification team anyway, so don't worry about doing it yourself when submitting. Massive shoutouts to Tactix1 for doing this basically single handedl
