I honestly wasn't even expecting my name suggestion to pop up. It wasn't even a proper suggestion :specialed: It's difficult to follow but, can you describe anything else you have in mind for the renderer, Gen?
One thing I intend to implement from the start, is a gamma correct rendering pipeline. What this basically entails, is reading in diffuse textures (and sometimes specular, ambient occlusion, and some others) as sRGB, writing everything to an sRGB render target, and "correcting" shading along the way (with OpenGL, you basically enable a state called GL_FRAMEBUFFER_SRGB during blending to correct the values output by a pixel shader into the appropriate color space). The benefit to this, is technically more correct shading. That's not to say that many of the tried and true algorithms are "wrong" per se, but more along the lines of most people's monitor gamma *making them* appear incorrect. This is an old (but still good) article that explains the concept of gamma correction: http://www.cgsd.com/papers/gamma_intro.html Of course, now days it's more for correcting the results of linear equations to take into account a computer monitor's gamma curve. There's different ways to implement it. Some use shaders to implement the effect (usually modifying textures as pow(diffuseTex, 2.2); and "correcting" the final fragment color with pow(fragColor, 1.0/2.2); will do the job), though others tend to take advantage of native hardware sampling so to not waste any available instructions on something that can be done "for free" on the hardware.
Sounds good Gen. Sounds real good. I'm honestly considering dropping my pursuit of Java and learning a language more conducive to this project to try and help out, though things are quite likely going to go above and beyond my skill level. Even if I did learn C++ quickly enough, I know jack shit about graphics programming and my 3D mathematics leave a lot to be desired! But really. I want this to come to fruition so badly it hurts. It'd be good for the programmers involved too. Taxman is awesome, but I don't want him to be the only Retro success story!
I myself know some C++, but not THAT much. Also... Huh. Seems Retro3D as a name is gaining traction. Even though it makes no goddamn sense to me, since this isn't gonna be anywhere near 'retro'. :v:
Well, the Retro in Retro3D is supposed to reference Sonic Retro itself but don't harp on the names so much. I mean, the engine isn't going to be doing any "Blast Processing" either .
You mean this, right? http://www.rorydriscoll.com/2009/01/25/energy-conservation-in-games/ No energy conservation: Fancy energy conservation: It looks like this basically amounts to more visually correct intensities of light reflecting off shiny(specular) materials. Like the article mentions, it can help make materials created by different designers appear more uniform and visually coherent together, and you've already started implementing it, Gen? Nice! ---------------------- Now Gen, when you mentioned that the hardest part will be creating fallbacks for older hardware, how are you going to handle that? What would be the minimum OpenGL version you plan to support? There's still a (possibly) large user base that has OpenGL 2.1 hardware with only GLSL 120 support. For example, to make the engine cross compatabtitle with most Mac users, you'd be restricted to writing GLSL 120. You could always of course, conform to OpenGL 3 by not using fixed function as a fallback for anything, and open an OpenGL 3 context for hardware that supports it. I'm not exactly sure how much an OpenGL 2.1 implementation with no fixed/depreciated functionality would limit what you want to do with the engine. I'm pretty sure you want to make it OpenGL 4.1 / OpenGL ES 2.0 compatible, is it possible that you can do that while making the engine work with OpenGL 2.1 too?
Basically, yes. I've implemented the slightly more optimized variation that Ruud van Gaal posted later in the comments on that article before. The more accurate one is great and all, but I haven't seen a huge benefit in terms of the accuracy boost to justify the additional ALUs. The less accurate normalization function of (0.0397887357729839 * n + 0.3183) is usually "good enough". What I'm thinking, is OpenGL 3.x core profile compliant, using a 2.1 context where a 3.2 context just isn't available (I mention 3.2 specifically for Mac support, since that's the highest Apple currently supports as of OS X 10.7; by the time we have something usable, most people will be running 10.7 at the very least anyways). A 3.2 context would come in handy for a more extended feature set, and would likely be the version that would make use of mixed color formats for the higher precision light buffer (since pretty much all OpenGL 3.x supporting hardware and drivers can do this). Though I doubt that the first few versions of the engine would really take full advantage of a GL 3.x context. It'd mostly be something implemented looking forward (I'm actually trying to decide how best to handle the context creation that'll work across platforms in this way; may resort to SDL or one of the various OpenGL toolkits out there to assist in this). After looking around a bit, I'm heavily leaning towards using GLM as well as the math library of choice, since it has a lot of functionality built-in, makes no compromises in terms of functionality (it can generate practically any kind of random noise! this comes in handy for soft shadow sampling!), and to top it all off, even provides SSE2 optimized libraries and C++11 support. It also functions a lot like GLSL, and uses many of the same naming conventions (I.e., vec2/3/4, mat4, and so on to define the various vector and matrix types commonly used in 3D programming). EDIT: Second round of voting has started one hour (EST) early. Our top three were Blast Pro, Mobius, and Retro3D. All three were tied at 14 votes.
I wouldn't mind seeing an Application Programming Interface for that. Although, have you guys decided on a standard model format, or you're going make one? Like how the Xbox306's are .xno, and the Wii's are .brres.
Those are typically the final format that the engine tends to use on a given platform. We will have a source format that the engine reads from (which may just be one format, or it may be many if we can find a stable enough library to support it).
What's your stance on source code licensing, Gen? You're the lead of this project and you can choose any license you want with your code. Personally, I think ZLIB or MIT might be the best for this type of project. It's kind of knee-jerk to say GPL because of the fan-game intention of this project, but when you think about, there would be perfectly good rendering code and later a physics system that could be useful for people wanting to make other kinds of games. (Skateboarding, pinball, etc. - games that use loop/ramp physics). Making the code license permissive like ZLIB would let people be able to learn from / use this engine for things outside just fangames. (Any default artwork or assets included with this project would be under different licenses of course, especially since Sonic-related artwork would not be something you'd want to put under a permissive license.) To my knowledge there are currently no open source engines(and I mean engines, not APIs like Ogre) that really have a good graphics system, so I see your work on this project as a new opportunity for more impressive open source games. And who knows? Having a permissive license for source code could attract new developers and make the project get support from other programmers, making the engine into more of a truly open source, community driven, general purpose game engine. On the other side, if you make it GPL, you'll have any other projects that use the engine stay open source, meaning all games that use the engine be fangames/free games. But then again, there's open source game engines with ZLIB licensing that have derived projects that are still free and open source. So I guess there's not really any negative side to using ZLIB vs using GPL, if anything, ZLIB might attract more programmers to use the engine.
I'd go for LGPL. Reason being, is it allows for the linking of libraries of different licensing types without automatically considering them to be "derivative works" as opposed to GPL, and still encourages people to release their code back to community.
The other very important thing to mention is that GPL/LGPL projects are not likely to get the banhammer thrown at them in the form of cease-and-desist notices. One thing that the S2HD project should be worried about is the fact that the instant a release with a full level is made (aka Alpha release), SEGA can and will likely immediately throw the banhammer straight at it. As a closed source project, the cease-and-desist letter can include the destruction of all infringing property. Open source code typically cannot have its sources destroyed that way. Then again, I doubt they care. For this project, implementing an engine to make it possible to develop Sonic games means that we're on the radar. As long as the project is GPL or LGPL, then SEGA will not care. The reason is that companies are extremely unlikely to pick up a GPL/LGPL licensed game engine for commercial works. I mean, there's no reason that it can't be done, it just isn't done because game companies freak so much at GPL code that they try hard not to incorporate it in critical engine code (aka, within engine itself). Out of necessity, I believe it is best that it is either licensed as a GPL or LGPL project. If we want to use libraries like FMOD (guuuh), then LGPL it is. Otherwise, use the GPL.
We could potentially just license the core engine as LGPL, which would allow plugins and other dynamically linked modules to take on whatever licensing the author chooses. An SDK separate from the core engine to create such modules could be licensed under a much more permissive license, such as MIT or BSD to better enable their authors to keep their code to themselves.
Alright, so, what now, now that we have a name picked out? Discuss ideas for features and stuff, and set up a roadmap for development?
Importing heightmaps for terrain. Vertex panting for detail layers. Auto LOD of terrain to not assrape memory.