The SX Engine

Well, here's a quick todo list:

1. Remove D3DX stuff from public methods instead pass std::vector<float> or something, or your own Vec3, Mat4 type structures
2. Create some pure virtual base classes (interfaces) for anything that would need both a GL/DX subclass (e.g. the window)
3. Try to make classes that don't need to coupled to the graphics library completely independent (e.g. the Camera class could be made entirely portable for example)
4. Try to move DX init, window and event handling into a class. There is a neat trick you can do to make WndProc a member function which is normally the stumbling block here. Briefly: pass the window class pointer into SetWindowLongPtr() during initialization. Write a static thunk that uses GetWindowLongPtr() to return a pointer to your window which then forwards calls to window_ptr->RealWndProc(); if you need more info I can give you sample code.
5. Make your WinMain/main as few lines as possible.

That's the main stuff

 

I think Sonic X-treme should have been a side scrolling fish eye 3D game with very little in & out motion. The best level that showcases this is the early JG level that runs left and right. The JG in the video is too small and pointless, at best it is only a tech demo level.

If I had known it was to be leaked I would have put more effort into it.

I got tired of SEGA, but as for deleting source code, I was just cleaning out my HD. I recode from scratch a lot, and it allows me to attempt things from different angles. So losing code is no biggy.

 

Preferably main please. WinMain = no good. Portability = Good :D

 

I've been playing around with the fisheye using actual fish eye algorithms in ortho mode.

Been using this screenshot from Crystal Frost to tune the parameters. Notice how much Sonic X-treme's actual fisheye pushes the tree. I'm probably miscalculating the fish eye lens curvature offset.



The algorithm I implemented above was this one:


One thing I approached incorrectly is that, my layout draw routine converts each vertex to fisheye coordinates and then it uses them to draw quads. This is not the way to do it. If one of the points is outside the camera range, there is no need to draw the whole quad.

The way to do it would be to create a function called gfx_drawQuad(); and pass the non-fisheye coordinates of the quad to it. Inside it can convert each vertex to the fisheye coordinate and if one of them is outside the camera range or in front of the player, then use transparency, etc.

 

Be careful when rendering stuff in orthogonal projection. If the Z value of all the vertices is constant, it's basically the equivalent of affine texture mapping, which gives horrible warping ala PlayStation 1 era graphics. You can fix this using a set of S,T homogeneous coords in Open GL, but not all hardware supports this (e.g. iPhone)

EDIT: That's kind of why I prefer the vertex Z manipulation trick for fish eye that's used in the current SX level viewers. No problems with warping textures, and there's much less calculation on a per vertex basis (although not an issue with shaders obviously).

 

Yeah, I noticed, but it's only when the camera gets too close to the polygons. Although I do have an equation to calculate the Z so it is not a constant plane (even though the fish eye equations are intended for a plane).

 

We used a realtime curvature offset adjustment tool in our engine,
For our most recent fisheye we used multiple screen shots overlayed together with that tool,
the screen shots could be toggled on/off with keys on the keyboard, ( also had transparencies enabled to help see if the levels were matching up)
The results are pretty close, however not quite perfect,
so than we added some Debug mode camera rotation, distance from sonic, height as well as level scaling tools to scale the model depth.
this helped out quite a bit more in tweaking the final result.
however there is still 1 problem, its not so noticeable, but if we get the bottom of the level to match up, the top would still be off just a hair,

I'm sure if you guys set up some extra debug tools with the camera for realtime tweaking, I think it would make things so much essayer in finding a good algorithm.

 

What position does the tree end up in Crystal Frost in your setup?

 

Regrettably our engine doesn't use the DEF files.
I haven't had a chance to model that area just yet, Been concentrating on E3 and boss areas of the game,
the only 2 areas I've recreated from def files so far were, Jade gully and the small Cristal frost.(think it was named screen or something)

Would love to go about making a quick model.( for the tree screen u have above)
However, Right now I'm on the laptop,
have yet to unpack the computer containing all of the sonic project files. ( god I hate moving)
Not sure when I'll get some time to hook it all up.
When I get it all together, it shouldn't take more than 20 minutes to toss that level section together in Max.
unless Uhyve gets his level exporter finished first,

 

I just realized. Cross Y45 and Cross Y90.

Cross Y45 are the trees that make the X shape.
Cross Y90 had me stumped so I looked into it and realized that the spikes in Crystal Frost are Cross Y90 and instead of the X shape they use a <> shape: