Except you're still talking about the incorrect 3.5x jump height despite being told three or four times that it's only 2.5x. There's no point trying to school us about jump height when you're fucking it up yourself
No, I'm not. Here, have some diagrams: When Sonic is running straight, on the ground, gravity does not affect his running speed. The only two variables that affect his speed are friction and drive, which should be constant in your engine (and probably simplified to a single "acceleration" value). When Sonic is running on the wall, gravity affects his running speed. If he's running up the wall, he slows down, because F+g>a. When Sonic is running on the ceiling, gravity does not affect his running speed. The only two variables that affect his speed are friction and drive, which should be constant in your engine (and probably simplified to a single "acceleration" value). There's no magical force slowing Sonic down when he's on the ceiling. Why add one?
If you don't show me the log file I can't do anything for you. (Launch.log) And which graphics card do you have? Ok, this is what I think how 3D Sonic Physics should be (thanks for the pics): When Sonic is running straight on the ground, gravity does not affect his running speed because... he's on ground and can stand gravity force; otherwise he would be lurking. When Sonic is running on the ceiling, gravity must affect his running speed because... he's not as light as a fly and doesn't have hooks below his foot. The same for walls. So Sonic must use his speed and inertia to overlook gravity.
The reason gravity affects Sonic's running speed when he's on a wall: Gravity is pulling him against his acceleration, and the force of friction and gravity combined is stronger than the force Sonic's legs exert, thus he cannot accelerate up walls. However: When he's on the ceiling, gravity is not pulling him against his acceleration, it's pulling him directly away from the ceiling. Presumably there's some downforce created by Sonic when moving at speed that allows him to stay running on the ceiling. The only things affecting his running speed are friction and his own power, which should be identical to the situation on the ground. Thus Sonic shouldn't slow down when running on a ceiling. According to your engine, when Sonic is running on a ceiling, gravity is acting in the direction marked by "F" on that diagram.
Think of it like this: go both your way AND DD's way. If Sonic is still accelerating when hitting upside down make it where he slows down. If he's at top speed let it continue to stay top speed. Shouldn't that work? That sounds just about like classic Sonic physics to me.
My system specs: Windows Vista 32-bit 200 GB of storage 2 GB of RAM AMD Turion 64 X2 Mobile Technology TL-56 1.80 GHz ATI Radeon X1200 series Also I will note that the older version of the program did work on my machine.
No, I'm not. I'm not talking about multiplication or any of your 3.5x crap. I'm including the first Sonic sprite in the multiplication. There's no need or cause on your part to be rude, and I suggest you stop that. I also wasn't trying to "school" you about anything (though you may need it), but I'm trying to create a point of reference. My point of reference is in the height of Sonic's sprite, which I'm referring to as a single unit here. His max jump height is 3.5 units (3.5 Sonic sprites stacked onto each other). The height in Sonic GDK is only 2 units (the max jump height is equal to 2 Sonics standing on top of each other). This is not the "3.5x" that you're accusing me of. I didn't fuck anything up. I'm including the base Sonic sprite in this calculation so there's not multiplication bullshit mistakes here (there wasn't ever). Sonic 3's max jump height- 3.5 Sonic sprites stacked on top of each other Sonic GDK's max jump height- 2 Sonic models stacked on top of each other. Is that still too hard to comprehend? I was told only once before about a "multiplication mistake", which is why I used another point of reference since people seemed not to understand. Seemed to not help though. I'm simply trying to state that the jump height in the GDK engine needs to be higher. Which it does as it's too low if you want to make it like the classic games are. It still seems too low though even if you don't want to retain a classic feel. Maybe I SHOULD school you on how multiplication works though, because it sounds like you're the one who doesn't even understand basic multiplication- 1 x 3.5 = 3.5 1 Sonic x 3.5 Sonics = 3.5 Sonics So there was actually NOTHING wrong with my math. Only if you don't include the base Sonic sprite on the first level does the math become different. The problem is that I AM including this sprite, because the top is still a distance of the ground. Anything off the ground is height. So either you don't understand basic math, or you totally misunderstood my point of reference (which starts from the ground up, not from the top of the first sprite and up). Either way, keep the rudeness out please, too many good topics have been destroyed by comments like that. All I say is that the jump height needs to be higher and you make accusations about not understanding math or fucking things up. Take a chill pill dude.
No. You're wrong. If you'd bothered to actually read what other people had posted, you'd see that EVERYONE is including the base sprite. Your problem is that you're measuring to the top of the jumping sprite, and you should be measuring to the bottom. Observe: The purple line I've added to the diagram is Sonic's jump height. Tell me, how many Sonics are below the purple line? EDIT: In fact, how could you possibly misinterpret this post the way you did?
Ok, NOW I know your point of reference on the highest point- the bottom of the sprite on the highest jump. As for the reason for the misinterpretation- I believe a minor form dyslexia. I don't expect people to understand that as an excuse, but the way I read a sentence can change the meaning in my head. Take that how you will though, call me stupid if you want. It WAS a misinterpretation though, and now I can see the writing on the wall. I had thought it said from the bottom of the standing sprite up, not the bottom of the highest point in the air. What I was doing was measuring the lowest point on the standing sprite (ground) to the highest tip point on the jumping sprite (air). I see what you mean now. I guess it won't matter to you, but sorry. I doubt you were looking for an apology but there it is. It's easy for me to misinterpret things, especially when I don't understand your point of reference and mix it up when comparing it with mine. My original point still stands though, the maximum jump height needs to be higher. It feels way too low compared to almost any other Sonic game, 2D or 3D. I may not read words or math correctly all the time, but I can use my eyes to judge when something is amiss. I didn't mean to take it as far as that though, so apologies.
Sonic's speed alone wouldn't allow him to stay on a ceiling, so there must be another force at work, one that would keep him against a surface that he is traveling along. The obvious assumption is that Sonic creates some form of aerodynamic downforce while at speed which would allow him to do such things. This is how it worked in the Genesis games as well, if Sonic could run on the ceiling, he could reach top speed. This is a pretty bad idea because you would then have forces at work that aren't obvious to the player, and the set up that DigitalDuck is suggesting is the one used in previous Sonic games.
The physics that applied to sonic would most likely be similar to rollercoaster physics, in my own opinion. http://www.funderstanding.com/coaster http://tlc.howstuffworks.com/family/roller-coaster7.htm
The thing holding a roller coaster up when it's suspended upside down is not just the friction, deceleration, and application of gravity. It's the fact that the thing is on rails, and is holding it in place. I don't know who it was, but whoever said that Sonic creates downforce to keep him on a surface even when upside down is correct. The reason why this downforce does not keep Sonic on walls is because the pressure applying him to the wall is not enough to combat the combined forces of air resistance and gravity. Thus, Sonic cannot accelerate up walls (though he doesn't decelerate as quickly as he should either, due to the downforce). It perfectly explains why Sonic is able to run upside down. What is a little harder to explain is how he can run through a convex loop (or around a ball, as in your engine). Sonic isn't sticky, so it's hard to figure out how he is able to retain enough centrifugal force to run through convex loops. Indeed, at a high enough speed, he should just fly off the damn thing. But that's okay, because it's fun to look at. Also, not to nitpick at all, and I'm really hoping it'll drop right here, as I'm just stating something I'm observing but.... Sonic's jump height is a little more than 2.5x his own. More like 2.6x really, unless my math is off. I never paid attention to figuring out what percentage of one number is another number. But this is just a really small observation, don't mind me.
Both Phos and I have suggested downforce is at work; it doesn't make sense for him to stay on a surface otherwise. In fact, in the classic games, if you're running too fast, or too slow, you do fly off a convex curve. There's a small range of speeds where you don't, it's about 3-7 pixels/frame. It doesn't really need to be exact. Just close.
I didn't even know there were convex areas in the classic games. Whereabouts? And yea, I know it doesn't need to be exact, I was just throwing it out there for general knowledge. Thought it was interesting when I noticed myself.
There are a lot of convex curves in Carnival Night, but ColinC10 also created a level hack of Metropolis Zone that's essentially a physics playground. His original link is broken, but you can get it here.
So are you all telling me that Sonic is capable of creating an aerodynamic downforce that lets him ignore gravity and thus accelerate and move exactly as if he would stand on normal ground and want this back in a 3D game engine where walls and ceilings are treated equally? Try this please: 1. Open UDKEngine.ini file of ...\SonicGDK\UDKGame\Config folder. 2. Search for "[Engine.ISVHacks]" section. 3. Set bInitializeShadersOnDemand to True. 4. Save, close and test.
And the downforce should be proportional to the speed he's travelling at. If he slows down while on a ceiling, gravity becomes stronger than the downforce and he drops back down.
Can anyone help, here? I set "bInitializeShadersOnDemand" to true and it still comes up with that "UDK.exe has encountered a problem and has to close" bullcrap message.
