Special Stage Development

Or perhaps we won't NEED to download a full DX runtime to play the game, hmm? The Special Stage engine will probably be rewritten to use OGL and DX8 libraries for non-graphics stuff. That way you don't have to depend on the latest DirectX.

 

I see the light now! While technically different, we are more on the same page now - the problem with the idea is the "extra logic" bit. Additionally, we can't put it on the same quad (more likely a triangle fan would work better here) as the skybox/background diamond texture because having it render partially through a turn would look strange. In order for it to look right in 3D (which honestly I don't think it will anyway) it probably has to stop when it comes to a curve and start blending away as sonic moves to reveal the curve. Even then, it's a crazy idea that should be attempted only after the simplest ones are exhausted.

 

If this goes into S2HD then there will be an OpenGL pathway for graphics, but for the DirectX route you'll still need to make sure your runtimes are up-to-date, like you would normally do anyway for drivers on your system and so on.

 

The problem with all the d3dx9 DLLs that keep getting updated with each new SDK, is that when you compile your game using the newer SDKs, you are linked to the newer d3dx9 DLLs by default. This is extremely difficult when you have multiple development machines (like I do), and move the code base around. And at one point one machine have another SDK setup.
And the DLLs take many MB, so you don't really want them to be part of the whole game experience.

S2HD's main engine dynamically links to D3D9.DLL (for the Direct3D 9 object) and D3DX9.DLL (for shader compiler), and this choice was made so that the engine will not need Direct3D pre-installed to run S2HD, as it then settles for OpenGL (if it finds those DLLs) or no render at all is done if no API can be detected (renderless is good for servers).
When dynamically linking to D3DX9.DLL, D3DX9 will load the newest installed DLLs automatically. So there is no need to have the latest runtimes to play S2HD, and you are not forced to have Direct3D on your computer while playing S2HD.
Also since Direct3D and DirectDraw are COM objects, they are so easy to dynamically link to, as the interfaces do all the work for you. For OpenGL, you need to keep track of every single API call address and cast to the right function (so that took a while).

 

Wow.. I recall having made some suggestion like one year ago :P

So, has this been through the whole DirectX vs OpenGL thing?

Laaate question, but is it going to be ported to linux?I know people must have asked this before.. but, this can't hurt anyone, can it?

 

Yep, dynamically linking is what I do.

And you are right about gl.h having the prototypes and typedefs. But only version 1.x (don't remember). After that you need glext.h, and there are so many different versions written by people out there, and most of them are hand written and some needs other GL libraries to check for extensions. So I did my own library so that it can be completely controlled by me and my ego (mostly my ego).

 

Yes, the OpenGL import libraries and headers that come with Microsoft Visual Studio only go to OpenGL 1.1, including glext.h. If you want OpenGL 2.1 (which is definitely what you want), you have to use different IMPORT LIBRARIES as well as headers.

The MinGW compiler toolchain includes an OpenGL import library for OpenGL 2.1, even though the headers included were brutally stripped of everything above OpenGL 1.2. You can add the OpenGL 2.1 headers back into MinGW by downloading the full OpenGL headers. These headers also include GLew, but GLee isn't included.

P.S.: If you are interested, I'd be willing to port the codebase over so that it can be compiled on both MSVC and MinGW easily. I've got plenty of experience on buildsystem stuff, and I even have one public project where the majority of the buildsystem maintenance is done by me.

 

What you want is GLew[1] or GLee[2] which have both had this problem sorted out for years.

[1] http://glew.sourceforge.net/
[2] http://elf-stone.com/glee.php

P.S. LOst if you are interested I'd be happy to do code reviews of the source and give you feedback, I've got plenty of GL/game programming experience. I don't have much time to contribute code, but adding an extra pair of eyes to give the code a once over are a way I could help. Just an idea.

 

As quite a few people seemed quite fond of the idea in principle, I took a brief detour into seeing how transparency would look if it were to be applied. This also shows the previously-discussed opacity fade at the end to mask the draw distance, along with the suggestion of setting the default draw distance to the "far" setting from the prototype; new pieces at the end fade gradually into view, so no more unexpected popping into existance.



Transparency test aside, it also still uses the distance scaling on the blobs as you can see, though I'll convert the blobs and decorations to just stay a constant size and fade in along with the tube as it looks more natural. However, I think the scaler should be kept (and set to an appropriate distance) for rings and mines because with the added draw distance, you can see them coming on a straight stretch from miles off. On a similar note about ease of seeing distant items or not, with transparency you can see even more such as roughly were items are around an oncoming bend, which may or may not be considered a good thing: just things to mull over.

 

Damn, I dunno about the whole transparency stuff yet, but I think I kinda like seeing how the tube curves around in the background.

 

I'm really loving the way that looks, transparency and all.

 

Not sure if transparency is a good idea, but I like being able to see the tubes in the background.

 

I'm not sure how this would look with the actual background. And seeing it as a screen looks really cool. But seeing all these tubes in the background while in motion could leave things looking cluttered and frantic. So judging it now is a bit premature, because it really needs to be seen in motion to be judge.

But at the same time whether it was game limitations or not, the special stage give an abrupt feel to curves and seeing what is ahead could completely change that for better or worse.

 

It looks beautiful to me. The long draw distance seems like a great way to bring it up to date visually at least. The transparency is nice when it's very subtle like that. So I really hope it doesn't end up affecting the challenge all that much...

 

Being able to see the track ahead isn't a problem, especially if you can't see rings/mines - after all, the game negotiates the track for you. I think it's a much-needed update that should stay in the HD version.

Also, the screenshot kinda reminds me of Rollcage:

 

Love the transparency and fading, but I'm not big on the elongated draw distance. I'm trying to work out in my brain a good way to make those turn into uphill slopes appear as surprising as in the original (one of the things that made collecting the rings on them hard) without them popping into view. Draw distance doesn't even really fix this problem since you can still see an uphill section coming at a turn.

Then again, it looks like I'm in the minority with the opinion on the "surprise" element. I'm just worried the special stages as they were designed in S2 will be a snooze fest if you can see all the obstacles that far ahead of time.

 

Quite a difference of opinion then. You can solve the "seeing the track in the distance" problem by narrowing the field-of-view and raising the height of the up/down pieces just a tad. For instance, below is the same point on the stage as the above, but with a 30 degree field-of-view as opposed to the original 40 (probably a bit too narrow, but it's just to illustrate a point).



This field-of-view more closely matches the original, but using a narrow field-of-view with real 3D doesn't feel particularly fast-moving because of how field-of-view affects perception of movement (in the prototype, pressing the "1" key to switch between narrow (35), normal (40) and wider angle (45) views shows how the same movement speed is affected, and this is exaggerated the more wide/narrow you go).

 

I'm kinda in agreement with what you say and do take your word for it about the rings and bombs affecting gameplay difficultly. But I really want to pass judgement when I get to see it in action when playing it. The transparency might not become an issue when playing because people might be more focused on getting rings and not losing them by avoiding bombs. Not only that but when the final art is put in it might make things more busy and distract the player better from far coming objects. I'm not against scaling in the objects. I just don't want to see the visuals crippled before seeing if it does affect the final version.


Also just had an idea. It would be neat to see shooting stars coming down the tube towards the screen for added flare.