Damizean

If you were to use the HW accelerated MMF version, a simple pixel shader could do it very easily.

Yeah, it seems to change the velocity to a fixed value of $700 (wich is 7.0 pixels, as the game uses a .8 fixed point system). So the code would be: // Calculate the bounce vector CVec2 vecBounce = Sonic->vecPosition - Bumper->vecPosition; vecBounce.normalize(); // Set new speed Sonic->vecSpeed = vecBounce * 7.0 Edit: Seems to be correct. Tested out by checking the Spring Yard ones.

Edit: Seems I really need to stop doing this while half asleep. Anyway, isn't just bouncing off the bumper good enough for this? I don't think the games did much more calculations than this. // Calculate the bounce vector CVec2 vecBounce = Sonic->vecPosition - Bumper->vecPosition; vecBounce.normalize(); // Retrieve magnitude of the speed vector float fSpeedMag = Sonic->vecSpeed.magnitude(); // Set new speed Sonic->vecSpeed = vecBounce * fSpeedMag

Nope, the game changes the priority settings to high. Use the task manager to change it back to normal. And Ironrind, never change the priority settings, please xD

I'm surprised this hasn't been posted yet on here. Basically, copy pasta from the Sonic Retro thread: Before anything -- Yes, these seem to be the original levels (textures) Chris Senn and Ofer Alon were working on back then. Sanik is the one who made the viewer to explore the levels. Seems like Sonic X-treme still has a lot of secrets to be found

Sonic physics are achieved simply by changing the direction of gravity (or the object's up vector) to the ground's normal. If you want to do a 3D in rails Sonic style engine (like in Sonic Rivals), the easiest method would be using invisible walls and their normal contact points as the right vector, and the ground as up. After that, it's simply finding the forward and move the object with these.

You know the Pythagoras theorem, right? The one that says: Well, basically, to calculate the distance between two points, you need to cast a line directly from a point to another and measure it. The theorem can be applied to know the distance between two points in cartesian coordinates. Substituting the "c" term as the distance, "a" term with the difference between x coordinates and the "b" term with the the difference between y coordinates, the formula ends up being like this. This will give you the distance between the two points given. The code, a bit more desglossated. DifferenceX = Point1X - Point2X DifferenceY = Point1Y - Point2Y SquaredDistance = DifferenceX*DifferenceX + DifferenceY*DifferenceY Distance = Sqrt(SquaredDistance) Test.rar

Distance = Sqrt((Xsound - Xcamera)^2 + (Ysound - Ycamera)^2) Volume = 100 - Min(Distance/SoundFalloffDistance*100, 100) Where: - Volume = Volume of the sample - Distance = Distance from the camera/player to the sound emitter. Just the basic pythagoras formula. - SoundFalloffDistance = Maxium distance at wich the sound can be heard

It's slow as hell, though :/

Personally, what I find unfitting is the general art style (not the actual graphics quality, they look amazing), doesn't feel right. Other than that, I'm eagerly awaiting for this game, I've been wanting a sequel of RKA for years!

I'm 12 and what's this?

It's not broken, your polygon smoothing groups are wrongly set. Change all the polygons to the same smoothing group and you'll see. Also... they don't seem that high poly, are you sure you properly welded the face vertexes?

Well, gargabe cans props are important if you want a city setting.

Nope, I didn't (I didn't even care to look into it). Damn, I've been fooled. All that's left is to find the motherfucker who did that art and make him do some for me!

It wont though, in the teaser website some low poly art can be seen, hinting it may be a 3D game with 2D gameplay.

var trunkSpiralHeight = 128; var trunkTravelAngle = 2*pi*((yStart - y)/trunkSpiralHeight); var trunkSpiralHalfWidth = 64; y -= XSpeed; x = trunkCenterX + sin(trunkTravelAngle)*trunkSpiralHalfWidth;

Perhaps he could just normalize the penetration vector and use the speed as bounce strength.

I could implement the basic mechanics of the Sonic 2 camera if you needed that.

To convert from world space coordinates to screen coordinates, it's a matter of simple the substraction of the top-left coordinates of the camera to the object/tile position. ScreenX = ObjectX - CameraX; ScreenY = ObjectY - CameraY; However, when it comes down to determine the visibility of tiles, since they're stored in a 2D array where each tile has the same size, you can easily know wich ranges in the array are visible by translating the world coordinates into tile coordinates TileMinX = CameraX / TileSize; TileMaxX = (CameraX + ScreenWidth) / TileSize; TileMinY = CameraY / TileSize; TileMaxY = (CameraY + ScreenHeight) / TileSize; So those are the coordinates wich you need to render on screen. Of course, depending on the scroll values, it might interesting to add 1 to the MaxX so you also render tiles that are in between. Code example for a simple scroller: #define MAX_WIDTH Whatever #define MAX_HEIGHT Whatever #define MAX_TILES Whatever #define TILE_SIZE Whatever unsigned short LevelWidth; unsigned short LevelHeight; unsigned short Level[MAX_HEIGHT][MAX_WIDTH]; SDL_Surface * Tileset[MAX_TILES]; void RenderMap(SDL_Surface * Output, int CameraX, int CameraY) { // Determine ranges int MinX = CameraX / TILE_SIZE; int MinY = CameraY / TILE_SIZE; int MaxX = (CameraX+Output->width) / TILE_SIZE + 1; int MaxY = (CameraY+Output->height) / TILE_SIZE + 1; // Clip if out of range if (MinX < 0) MinX = 0; if (MinY < 0) MinY = 0; if (MaxX >= LevelWidth) MaxX = LevelWidth - 1; if (MaxY >= LevelHeight) MaxY = LevelHeight - 1; // Iterate through the level array for (int y = MinY; y < MaxY; y++) { for (int x = MinX; x < MaxX; x++) { // Determine if the tile we're about to draw is the transparent tile. If so, skip. if (Level[y][x] == 0) continue; // Render RenderImage(Tileset[Level[y][x]], Output, x * TILE_SIZE - CameraX, y * TILE_SIZE - CameraY); } } } void RenderImage(SDL_Surface * Input, SDL_Surface * Output, int x, int y) { .... }

Happy birthday, Brad =D

You've been at Spain... and you didn't tell me about it!?

Here's an example on how to do frustum culling based in the planes equations all 3D engines use. The culling is done in 2D through the use of camera planes calculated off the camera's Yaw and aperture (not the best way, but it works). Doing the tests in 2D simplifies the maths involved and requires less processing power (something needed due the terribly slow scripting engine Game Maker has) and offers flexibility enough to be able to test if either: A point is in the visible frustum. A rectangle is in the visible frustum. A sphere is in the visible frustum. To find out how to adapt it to your game, check out the example (both objCamera and objTest. Ignore objTimeDelta as it is used to keep movement consistency regardless the FPSs) However, be warned. Due the amount of calculations that need to be done, the scripting engine may slow down a lot when there's a lot of objects around, so much in some occasions where the object to draw isn't that very high poly. In those occasions, it's just better to render directly, without culling testing. A good optimization would be using this in conjuntion of an instance deactivation system, though. So this system is useful if you want to discard models with a lot of triangles (characters, objects, enemies, etc). FrustumCulling.zip

It doesn't at all, not the type of clipping we're talking about. It does perform clipping on triangle basis, but not on object basis, wich is what you guys should be doing to discard large amounts of triangles.

No?

No need to, I already implemented a camera wich works exactly like the one in Sonic 2.