Maybe you had a DX game engine free for us Mr Homer? I think Im going to abandon my OpenGL research. It already had lots of great feature like Physic and lightmap, but I guess I'll switch to another one.
Posted on 2012-02-22 04:36:07 by Farabi
OK so yes we can go with the DirectX way but...

No Bad Idea!
OpenGL runs on all sorts of platforms and devices, say the same about directx!

You are on the right path, you just need to become more methodical.
For a kick start I would send you to spacesimulator.net to steal the opengl 3.3 ports !!!

Whether you wish to use directx or not, you will always have to provide low quality fallbacks if you want the software to run on crap machines.
Posted on 2012-03-08 01:28:20 by Homer

OpenGL runs on all sorts of platforms and devices, say the same about directx!


Which is OpenGL's only redeeming value.
But if you're only targeting Windows anyway, OpenGL is more trouble than it's worth.
Posted on 2012-03-08 06:56:31 by Scali
With that SiS Mirage 3, you can forget about GL completely. DX is better supported on hardware that isn't backed by good large-enough software teams, situated outside India. The reason is simple: Microsoft provide a full front-end for the drivers, concise functionality and a single full compiler; that only gives ARB-asm like code for the driver to compile into native gpu code. A DX driver is ~ 50k lines of code, a GL driver is 1+ million lines.

GL context versions not being specified by authors: if they use 2.1 functionality (glBindFramebufferEXT), it's 2.1, if they use VAO (glBindVertexArray) it's 3.1+, otherwise it's a mish-mash of 1.5-2.0 . Yet, with a compatibility context, users can do whatever the hell they want >_<. (and it's my job to implement support for almost every whim they get lol)

He needs just DX9 COM support for asm, which I'm sure is available somewhere. Or is easy to generate with some simple script.

Should you ever need to port to GL, it's easy if you target 3.2+ as long as you don't mix'n'match random vtx shaders with random frag shaders. But you're not going to be in need to port any time soon - make the game/app work first. :)
Posted on 2012-03-17 11:14:10 by Ultrano

With that SiS Mirage 3, you can forget about GL completely. DX is better supported on hardware that isn't backed by good large-enough software teams, situated outside India. The reason is simple: Microsoft provide a full front-end for the drivers, concise functionality and a single full compiler; that only gives ARB-asm like code for the driver to compile into native gpu code. A DX driver is ~ 50k lines of code, a GL driver is 1+ million lines.


Indeed, let's hope that the Gallium3D project becomes a success, then GL drivers will be much more like DX drivers, implementing only the bare functionality, with a shared runtime implementing the API.


Yet, with a compatibility context, users can do whatever the hell they want >_<.


This seems to be the most common situation.
Especially since frameworks such as GLUT don't even allow you to specify a context anyway. You just get whatever the driver defaults to.


He needs just DX9 COM support for asm, which I'm sure is available somewhere.


I suppose Homer will know about that. Is it part of the OA package?
Else I think Scronty used to be involved with converting the DX9 header files to MASM syntax.
I personally never bothered with calling DX directly from ASM (despite having written one of the first DirectDraw tutorials, with one of the first ddraw.inc headers for MASM).
I just use C++ to communicate with DX, and use inline assembly or link to MASM routines when required. There's nothing to gain anyway from calling a COM function with an assembly macro rather than just using C++.
Posted on 2012-03-17 13:31:07 by Scali
Scronty supported DX8, not sure he ever touched DX9..

ObjAsm32 supports DX9(.3c), I constructed the dx9 headers it includes, and wrote a bunch of examples that I think got published along the way into its Demos folder, it also supports a pure software rendering engine for systems that don't have DirectX9 but are intel based.
OA32 has a complete application framework, optionally providing D3D support,  and optionally provides RadASM IDE project files , making it very easy to create application GUIs using RadASM's gui editor thingy, as well as the intellisense and other features you learn to expect from your code environment.

Otherwise I can also provide a DX9 framework for masm, on request.

If you want to use a DX10 or higher, you will need to create updated headers for asm from the api .h files, I can help, there is a tool that will partly do it, and leave a little to be done by hand..

My own current framework is written for OpenGL in C++ with single inheritance (so compliant with OA32) and uses SDL and a custom 'glext' to provide support from 3.3 to 4.1 contexts, with no support for older contexts, but if bullied enough I could provide graceful fallback.
I don't like compatibility contexts, if I can help it.
GLSL Shaders are automatically generated (via a pretty-printer) to meet the demands of the surface materials you created as well as any (multiple) lighting and shadowing of the scene, and can optionally be loaded from files (eg the final render step, from texture to fullscreen quad). Shadows are PCF, and the scene can optionally be post-processed for screenspace ambient occlusion (SSAO) and shadow enhancement (2-pass blur and bloom), into a very high precision texture (HDR), baked down to regular precision for presentation (tone-mapping) while supporting translucent colored (stained glass) surfaces and ambient reflection on surfaces (environmental cubemapping via volumetric textures).
Framerates are not wonderful, but my hardware is old.

Have a nice day :)
Posted on 2012-03-18 00:28:33 by Homer