Author |
Message |
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 28 Mar 2005 10:42:40 pm Post subject: |
|
|
This is the latest thing I'm working on. Earlier I mentioned each pixel was split into 256 sub-pixels. 256 was overkill, so I'm limiting it to way less. This will also make Sonic appear to jump much higher and run faster. My goal is to make normal jumps around 56 pixels (3 1/2 times Sonic's height) and the springs do up to x4 that height. Right now, the biggest jump possible is only ~32 pixels. (D'oh!)
|
|
Back to top |
|
|
John Barrus
Member
Joined: 25 May 2003 Posts: 131
|
Posted: 29 Mar 2005 03:06:04 am Post subject: |
|
|
It seems to me that for the majority of the game, horizontal speed and acceleration will apply only to drawing the background, instead of the character. Maybe you should look into that, too. Nice job, though, that looks awesome. |
|
Back to top |
|
|
MeltedIce
Newbie
Joined: 17 Mar 2005 Posts: 8
|
Posted: 29 Mar 2005 04:00:21 pm Post subject: |
|
|
a, I never thought about that. Sonic never moves around the screen, its the backround that moves. |
|
Back to top |
|
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 29 Mar 2005 07:18:59 pm Post subject: |
|
|
Well, that's partly true. In our case, the physics code will control the tilemap's offsets and give the appearance of scrolling. This applies everywhere except when Sonic approaches an edge or corner of map; then we would need to disallow scrolling and let Sonic move off-center. So in summary, you either move the background, or you move the character. (But never both at the same time.)
I'll be able to do backgrounds as soon as we agree on a tile-mapper and draw a test map.
Last edited by Guest on 29 Mar 2005 07:20:06 pm; edited 1 time in total |
|
Back to top |
|
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 31 Mar 2005 12:25:33 am Post subject: |
|
|
I'm having trouble visualizing the forces that make an object can go through these loops physically. It know it's a combination of gravity and the normal force from the surface--but beyond that, I'm uncertain.
Also, I'm not 100% certain about how an object gets driven "up" the loop if these are the only forces at work. Momentum was something to do with it, but that's not a force.
Anyway, I need to get this stuff to work before loops will be possible. |
|
Back to top |
|
|
CoBB
Active Member
Joined: 30 Jun 2003 Posts: 720
|
Posted: 31 Mar 2005 10:51:38 am Post subject: |
|
|
Momentum is provided automatically if you maintain the position and velocity vectors. To go through a loop it's enough if you have a large enough initial horizontal velocity and simply bounce off the surface. That's practically a rotation whose angle can be calculated from the current direction and the surface normal, which is basically what AG does (it also places the ball a bit away from the wall to prevent it from getting stuck). You can also cheat a bit and add some extra velocity to Sonic at each collision, but I don't think that's necessary. If you do it properly, it will be possible to fall back from the top with too little initial speed. |
|
Back to top |
|
|
Adm.Wiggin aka Tianon
Know-It-All
Joined: 02 Jun 2003 Posts: 1874
|
Posted: 31 Mar 2005 01:10:13 pm Post subject: |
|
|
Listen to CoBB, he's a genious... He already did it with AG.
That screenshot looked awesome... I loved how the slow screen update made the ball appear to stretch out when it moved. Way awesome, keep it up! |
|
Back to top |
|
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 31 Mar 2005 04:47:48 pm Post subject: |
|
|
So I guess when Sonic rolls up a loop, it's sort of like he's like constantly colliding and bouncing off the the surface? |
|
Back to top |
|
|
CoBB
Active Member
Joined: 30 Jun 2003 Posts: 720
|
Posted: 04 Apr 2005 11:02:20 am Post subject: |
|
|
That's how it works in a quasi-physical simulation. Of course sometimes hacks are better than the straight way, like getting the coordinates from a time function or a LUT for these special cases. But I'd deal with only those special cases that can't be handled by the general code, so my advice is to test first. |
|
Back to top |
|
|
Raiser
Advanced Newbie
Joined: 06 Sep 2004 Posts: 51
|
Posted: 10 Apr 2005 12:40:03 pm Post subject: |
|
|
I'm no physics expert, so I can't help much in this department, but I can give you something that can help.
http://www.hacking-cult.org/?disasm/x
It's a disassembly of Sonic 1 for the Genesis. Perhaps it can be used as a reference for programming Sonic's physics. |
|
Back to top |
|
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 16 Apr 2005 07:40:38 pm Post subject: |
|
|
I just made a major breakthrough with the physics code. Now the code can redirect Sonic's path as he goes from one surface angle to another. This is the part that will make loops possible.
...the movie simulates what happens if you hit a 45° "ramp" with a speed of 100 (this is not jump like before). There are some aliasing problems due to rounding, but it's only a problem at long distances. I'll send the latest code to the key programmers and the member forum as soon as the code is generalized. |
|
Back to top |
|
|
Madskillz
Active Member
Joined: 02 Jan 2004 Posts: 608
|
Posted: 16 Apr 2005 09:31:36 pm Post subject: |
|
|
wow...sweet looks awesome! |
|
Back to top |
|
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 18 Apr 2005 09:32:28 pm Post subject: |
|
|
I found a few problems involving the graphics vs. angles.
At first, I wanted to do angles in 22.5° increments, but it looks like we can reduce our tileset size if we stick to even numbers. Basically, I had two possiblities in mind for possible surface angles:
#1 {0°, 30°, 45°, 60°, 90°, 115°, 135°, and so on}
#2 {0°, 15°, 45°, 75°, 90°, 120°, 135°, and so on}
Basically he's how a quarter-pipe might look using system 1 and 2...
#1 used 7 tiles and #2 needed 11. Anyway, my trig codes use sine tables, so none of these will cost us any size or speed. Also, I'm being experimenting with tile masks, and #1 and #2 will require fewer masks.
Last edited by Guest on 18 Apr 2005 09:33:15 pm; edited 1 time in total |
|
Back to top |
|
|
John Barrus
Member
Joined: 25 May 2003 Posts: 131
|
Posted: 19 Apr 2005 12:04:01 am Post subject: |
|
|
What about just doing 15 degree increments? {0,15,30,45,60....} |
|
Back to top |
|
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 19 Apr 2005 12:17:14 am Post subject: |
|
|
I'm glad you brought this up because that will work equally as well. The problem with my previous 22.5 system was that angles not divisible by 15 would not "link" together (graphically) unless the sprites were 9 pixels wide instead of eight.
Here's how my physics code would draw a 22.5-degree angle...
And he's how that slope would look like if it were "stacked" to create a hill. Once I used the 15-deg increments this was no longer a problem with 8-pixel sprites.
|
|
Back to top |
|
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 26 Aug 2005 01:00:30 pm Post subject: |
|
|
Animated the rolling sprite for the physics prog. The rolling speed is adjustable on a 0-255 scale.
Also took CoBB's advice and added adjustable screen refresh rates now that will keep the graphics load from becoming excessive. Map-hit detection is in, but buggy at the moment.
[Update]
The friction code was finished this past weekend, making the physics package complete. I'll start documenting the code so the 83+ team can port it.
Last edited by Guest on 30 Aug 2005 09:06:04 pm; edited 1 time in total |
|
Back to top |
|
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 29 Dec 2005 01:07:05 am Post subject: |
|
|
Trouble in the physics department, Batman. Because of school commitments, it doesn't look like I'll have much time to program without my GPA taking another hit. My report card already looks like it was wearing a 'kick me' sign, so I'm gonna have to buckle down and avoid these major projects.
Basically, what we've got is a finished physics engine, and the start of map collsions. I can work on collisions until the yeah gets started again, but I'll need someone to take over after that. Also, I think we need someone to handle map compression so we can expand our test areas to more than 32x32. Until then, I've got an update for the physics code in the works that ~should be a little easier to port than the previous one. |
|
Back to top |
|
|
Madskillz
Active Member
Joined: 02 Jan 2004 Posts: 608
|
Posted: 29 Dec 2005 05:28:28 pm Post subject: |
|
|
Digi...well I hope you get your grades up mate, school is always more important! I did get the second physics engine ported...But if you can make the next one even easier, I have no complaints here! :biggrin: |
|
Back to top |
|
|
kalan_vod
Advanced Member
Joined: 04 Sep 2005 Posts: 446
|
Posted: 29 Dec 2005 09:25:07 pm Post subject: |
|
|
Sorry to hear digi, but look on the bright side we do appreciate your work . |
|
Back to top |
|
|
DigiTan Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003 Posts: 4468
|
Posted: 30 Dec 2005 01:42:19 am Post subject: |
|
|
Thanks. It's not really the grades I'm worried about, I have a lot of doubts over whether I could add more code at a decent pace. I'll try a few ideas on the collision code to see if we can set left/right collisions to work. That might give us enough momentum to move on to level design. |
|
Back to top |
|
|
|