Message Boards

I was wondering if there was any talk of using DirectX instead of or along side openGL for the Advanced Rendering.

The ability to run on any operating system under the sun is probably the greatest feature in Odamex.  I would rather have a portable port (FINALLY) then an opensource port, but the fact that Odamex is both, is quite uber.

Direct3D is far overrated aswell. I have heard bitching and moaning from coders who have used the API, and I, also as a consumer, frown whenever I come across a program that uses it because that means I need to boot windows to use it as opposed to gentoo.  Whatever D3D is capable of, OpenGL and a little effort can do aswell.  Take a look at the visuals in sauerbraten, for example.

OpenGL is a standard, D3D is a proprietary, unportable library created by microsoft to "jump aout infront of OpenGL". OpenGl was already around when D3D emerged in windows95, but microsoft did not want to introduce it into the game development market. Once D3D exsisted on windows, microsoft spread propaganda about OpenGL not being good or fast enough for games, being better for CAD and engneering, and pushed it off to the side.  I dont know, but architects and animators dont like waiting all day for their renders to complete either.

I always question every new "microsoft innovation."  Many times, the technology already exists in a more, possibly unpolished, but open and free form, and then it comes from microsoft as a way to garentee that you need to feed their pockets before you can use other people's software.

I'm not sure if this affects accelerated rendering or not, however.

SDL 2.0 supposedly is going to be fully based on OpenGL.  :)

Your are ignorant. Here is the reason why opengl would be good: because the way hardware rendering will allow graphics card to handle the graphics and free the cpu from having to do all the computing for the graphics. This will allow the cpu to spend more time on other things like sending and receiving packets. This will allow better performance for multilayer and will reduce the amount of bugs that occur due to high ping and lag.

Of course not, unless you are playing nuts.wad. The point I am making is that every little bit helps, especially in Odamex with all the packets that have to be dealt with. In a large game spanning multiple continents I can see it being beneficial to the performance.

If technology is that fast then why do I still experience lag in zdaemon or odamex? And noticeable lag at that.

So OpenGL rendering is just useless here.

Not necessarily.  There are many obscure problems under the hood with the Doom rendering engine, which can cause it to act funny under certain circumstances.  To fix certain bugs and add new, vital features can be a major pain in the ass for a software renderer that is as old as Doom's.  A new renderer could be very helpful to solve such problems.  Take for instance this very famous Odamex bug.  Note that this bug not only exists in Odamex, but in every single Doom port that uses software rendering at high resolutions ever.  ZDoom has it, ZDaemon has it, Eternity has it, Legacy has it, they all have it.  Months have passed, and the team has been wracking our brains from here to kingdom come trying to come up with a solution, but so far the solution has been elusive.  A similar problem has been found by the developers of Eternity where lines above a certain length could be rendered inaccurately in the software renderer, and it was finally decided that it was a fundamental problem with the Doom renderer, and had no conceivable solution.  None.  No way to fix it.  The only solution is to write an alternate renderer.

The fundamental problem here is that when you think "OpenGL", you automatically think "GZDoom" and "Doomsday Engine", which you don't necessarily care for.  I understand, I prefer to use software-rendered engines myself.  However, have you considered that OpenGL doesn't have to necessarily be "colored lighting and special effects galore"?

OpenGL allows easy ways of doing graphics intensive things for purpose-built GPU's that were a huge pain in the butt 13 years ago when the routines had to be built for a general purpose CPU's.  What if an OpenGL renderer was written that didn't filter textures, scaled light and darkness like the original renderer, and for all intents and purposes looked exactly like the original engine, but under the hood was much easier to understand and maintain?  If written carefully enough, you might not be even be able to tell you were USING the new engine (except you wouldn't run into mentioned problems).  "Impossible!" you say.  Nope, I've seen screenshots of denis' ogl_hack branch of Odamex, and it's so close to the original software renderer, it's scary.

I'm not saying that Odamex is going to have an OpenGL renderer (or not, for that matter, it's still in the experimental stage at the moment).  However, please don't misrepresent what an "OpenGL renderer" is.

AlexMax, thank you for explanation.
Yeah, nonfiltered OpenGL rendering is great, but won't there be some new bugs on introducing OpenGL renderer?
I tried once to make GZdoom look totally like Zdoom. Even when i turned off all opengl features in GZ leaving only rendering itself, the picture looked almost like software rendering, but the feeling of actions, motion, mouselook was absolutely different. It really can change gameplay.

That is up to the author of the renderer.  If he considers such inaccuracies 'bugs' then he'll fix them.  Otherwise no.  I would think that if Odamex ever considered introducing an OpenGL renderer that was meant to replace (instead of compliment) the software renderer, such inaccuracies would be considered bugs.  But you still can't equivocate ogl_hack to GZDoom's OpenGL renderer, since they were made by two different people and made with two differnt goals in mind.

heh, I think that 'distortion' is fine, it's natural when you're playing a game not natively formatted for 4:3 aspect ratio resolutions. (320x200, 640x400, 1280x800 and 2560x1600 are proper dooming resolutions)

Why is it 'fine'? It shouldn't be there.