Also adding to the addition of the level deco, audio really could make a difference in a levels difficulty. I don't know if there's any fps in these levels, but if you came across a frame perfect in trollmachine or agite, it wouldn't be as hard as a frame perfect in a level like sakupen circles or silent clubstep.
there are a lot of factors that go into determining a level's difficulty. of course, more frame perfects generally mean it's harder, but there's other factors too, such as the level's length, decoration obscuring gameplay, time to react to an input, the timings of every input in the level, and plenty more.
I am genuinely mindblown. This is crazy. Skoe should be known as the legend of the mystery bug or something. He did his best at the game regardless. If it only happens with the mouse, it could be in some settings somewhere and GD's ability to detect a mouse. It could also have something to do with wired vs wireless mice maybe.
To me as a progressive this looks like somewhere in the input chain inputs get delayed and then not getting to the frame in time so they get push to the next frame as from what i see here its different people so i think its hardware related i think the discord screenshare or obs thing are just the system is doing more input and output as the obs is mentioned as only whem visible on the so i needs to read the screen then write ti it again so more operations and keyboard and mouse input is normally handled diffrently i think if they tiook the engine gd is made on used the input lib that gd uses and made the counter it would show the confusing bug results Anyways if there is anything thats confusingly writen here i apologise english is not my first language and fell free to ask questions and lets hope youtube will notify me about it also great video
Hello i am Aj A computer technician i belive this beg happens because of internal lag caused by obs or discord being picked up and causing a bug in gd that replicates fps multiplier to understand more i would have to crack open gd
welcome to low-level input implementation hell. obs recording and screenshare you say? this is my guess, it's something to do with the kernel behavior. of course differences in hardware may have something to do with this, but that's a way bigger rabbit hole and i consider investigating that unfeasible for a such community. im not really interested in gd community, but as a developer with a little experience in low-level library development, here are some points to get you somewhere. i can't tell you enough that this is a very valuable investigation for all kinds of precision game developers and i hope it succeeds. you need to: 1. find someone knowledged with how low-level input system generally works. i know no one, but that could be you if you study hard enough. they may give a better advice than me. 2. see how gd implements inputs. find out what method the game specifically uses, and if possible, what kernel actually does with it. im assuming all of you use windows. since it's not open source, you may have to do your own digging painstakingly. i'm sorry, that's just how it works when we're dealing with windows kernel-level problems. 3. create a software that verbosely logs each processed polling tick, with multiple environments on mind. maybe see if that happens on linux or macos. maybe see if any other software than gd is causing a similar problem. try to create a dataset with as much info as you can get. maybe common implementations lead to that same behavior in gd. i'm still yet to understand the vast maze of internal behaviors, so i can't give a quality advice that may lead straight into the cause. but if you guys are fully prepared for that knowing what kind of this issue potentially is, then good luck! i can assure you that you're certainly in the most ride that has ever existed. lol
dude i used to feel like the game felt different while recording during like 2.0 times and now like 9 years later youre telling me there is a tiny chance it wasnt all in my head???
I think what's happening is the game locked to the hz of the monitor. And when obs or screen share is used, the game gets locked to that which is usually 60hz.
The reason the bug happened to Skoe specifically is because the Kai Cenat fairy blessed Skoe with GD Rizz, and for those with specific circumstances, they were simply using the Skibidi LTSC versions of Windows 10, based on 1809
I swear, some people would make amazing government agents (CIA, FBI, Detective, etc), and they dont even realize it... Y'all get information from an informant, perform independent investigations, examine and study statistical factors, test theories, and conjoine evidence to find out what happened or whether someone's guilty of something. Just... something for you guys to consider.
I assume it could be windows full screen optimisation bugging out the game, or obs is recording in 60 fps causing the frame times to have locked to 60 fps, also with discord it's screen sharing at 60 fps. Both OBS and Discord uses the same apis to capture the screen. Maybe try using the legacy screen sharing api? Could also be the GPU locking to 60 fps when recording at 60 fps. Have they tried using Linux and see if that bug persists?
I'm not sure if it's been looked into but I had an issue with very minor stuttering while streaming Valorant on Discord where it felt like I was playing on 60hz monitor when I have a 240hz monitor. I have a pretty powerful CPU and so I maintain 500 fps in game but even though it displays 500 fps, there is a noticeable microstuttering which may or may not be related. I've seen some discussion on Windows GameBar Presence Writer causing this issue or Discord's in-game presence feature, and after turning both off it seems to have gotten a bit better but its purely anecdotal evidence. Might be worth looking into though.
Brooo… a while ago I was convinced that something was different about the physics of the game whenever I had OBS open. It just felt much less precise and more difficult to play than it did otherwise. I even remembering noticing that if I switched to up arrow it felt fine. Now I realise this was probably this exact bug. As a programmer the only common denominator I can see is that there is another program which is using up computer resources. OBS and screen share are both either capturing or playing a live feed, which can be fairly intensive depending on your hardware and settings. I would note that when I disabled the preview from OBS, the bug seems to go away, and this was my fix for a long time, so I am very confident it comes down to the screen. Personally I think this suggests that the bug is triggered when GD is not running completely smoothly, when there is some kind of interference by another program meaning some part of the game is being starved of resources or another program is somehow causing most mouse inputs to never make it the game. This could even be an OS level bug, as I’m assuming all of these players were using Windows, but that seems unlikely given no other game has been found which replicates it. But why did Skoe experience the bug then? I would suggest investigating his computer’s hardware further. Perhaps CPU architecture or another configuration means this bug is consistently triggered for him, or perhaps he is using integrated graphics? Or is there some background program replicating the issue, especially considering he streamed most of his gameplay, right? I believe this theory is further supported by the changing of alignment in this case, which I would argue comes down to usual hardware fluctuations, maybe brief moments where the game is able to run properly for a few frames but then having the bug triggered again. The best course of action I can see is to investigate the game’s source code. There may be some dodgy API that other tested games just don’t use, or perhaps a poorly implemented API that OBS and Discord use, or it may be apparent in the physics engine itself. But that’s just a theory…
Some more things to note- I had this same problem when screen sharing GD on Discord, it might be relevant that I had multiple triggers on the same PC. More importantly, the other common denominator is Megahack. In fact, it seems more likely to me that this is down to Megahack’s bypass implementation being affected by other apps, rather than the game itself, given its nature and its appearance in all of these cases. I only experienced this issue whilst I played on 60hz native and 360 bypass. Some time ago I bought a 240hz native monitor and I have not noticed the same problem since (although, assuming the alignment is to native, this would be much less noticeable). Has anyone experienced the same issue with any other tool or configuration? And I also want to clarify, is this fixed in 2.2 with RobTop’s implementation? Or is there testing needed to determine that?
have you taken a look at gpu settings such as nvidia's ulta low latency and AMD's reduce input lag settings, those settings queue up and overwrite the frame buffer under gpu limited circumstances providing the most up to date frame and dropping previous ones within the refresh window on the pipeline... just a thought from outside the mouse, or the game itself. It would make sense if the player were playing on a 60hz display to run into a situation where the buffer just so happens to align with 60 fps if its only getting the most recent frame data instead of a constant feed of unrendered frames like normal. Just and idea... I dont even play the game lul.
i've definitely started to realise much more recently just how bad of an impact Space has left on the levels of trust within the community, literally anyone can point a finger, lie with 0 proof and kick off a controversy for a little bit of clout. total shame tbh loved your vids recently btw keep it up <33
ive never even heard of people trying to call levels hard based on the amount of 60 fps frame perfects, but I guess I'm not really in that part of the community. explaining how 60 fps and 240 fps frame perfects differ did help a lot though, thanks
This kinda reminds me of how for some time windows would lock all games to 60fps as soon as something like OBS preview or a Discord stream was running on the other screen - WITHOUT showing it on any FPS counters, you could just see it.
My new set of ideas includes: Hardware accelleration between Discord and Geometry Dash causing a bottleneck somewhere that stops the computer from reading mouse inputs at a specific time; Geometry Dash being set as high priority in the task manager or windows fullscreen optimization; and testing the various devices using different monitors, a controller, a wireless mouse, a wired mouse, a drawing tablet, and a simulated mouse.
I feel like i missed somthing big or key to the video because i came to a wildly different conclusion. Before i get into it. Im not of the mentality that the generally has which is once a cheater always a cheater and that cheaters are the scum of the earth. Ive cheated in the past when i was teen on cs source (A Game you can skin your self and make most walls and doors and objects transparent although css servers had the option to disallowthis most community servers didnt disable skins in their configs . i dont cheat anymore. ANYWAY BACK TO THE VIDEO. They knew about the alignment bug when they made their own variations OF THE MAP and took advantage of that. to me thats enough to say cheated intentionally imo. Like discovering a glitch intentionally, it feels like and then choosing to use it even though yiure not sure how it works
I'm not to well versed into geometry dash but Love content like this deep diving into themes of cheating or issues with games. You managed to keep my interest throughout the whole 32 minutes and honestly love the way you speak, articulate and explain the story. Earned my sub, hope you keep going and get a better mic because that alone would raise the quality enormously!
I don't know if I'm right, but here's a possible hypothesis related to screen recording software let's imagine that you're screensharing on discord. discord needs a way of receiving the picture and audio of the game. so what discord could do is a number of things, but in particular one type of method would have discord interrupt the main thread of a game to basically create a copy of everything it sees on-screen and the audio, so it can later do it's own processing to stream the video (it could also possibly do the processing as it interrupts). In theory, this could stop the main thread of Geometry Dash for a number of milliseconds, depending on the GPU, CPU speed and the size of the window in pixels. let's say hypothetically it's a low end system so it takes 8 milliseconds. The main thread is typically used for many things, such as receiving messages from the OS. messages typically are also used for detecting keyboard input and mouse input. Because we're streaming, typically sometime after vsync occurs, Discord will suspend the game processing any input, to do it's screensharing work. For 8 whole milliseconds, physics run but no input can be processed. This delay sometimes makes 60fps games feel more choppy than normal, sometimes could make input not register for part of a 60hz frame. it's possible that while screensharing, recording, or anything that captures the video of the game, this could cause the alignment we see. higher the fps, the more noticeable one way to test would be to try reducing the window size. if the alignment becomes less noticeable, it's evidence that this hypothesis is a possibility
making a level with 1000 2-frame timings in the span of 3 minutes and calling it easier than a 2 second level with a single frame perfect in it and nothing else
