Horde3D

It was for the Wii, which uses a very "GL like" graphics API and has approximately DX7-level capabilities.The text files are converted into data structures, which basically just hold the parameters needed for the fixed function pipeline.
So the bit for setting up the texture combiners might look something like:^^The above code just made up on the spot because I obviously can't post my actual code, and I also can't remember how the GL FFP works these days

Kudos for making a proper topic for this DDd!

I was thinking in my head that an offline tool to build assets based on the target platform might be the ideal solution for a multiplatform app (maybe not horde itself), for instance, on ARM/PowerVR SGX hardware you'd vouch for using PVR texture compression wherever possible, but on the snapdragon/AMD hardware you'd use AMD-supplied extensions for texture compression methods like 3Dc or what have you. There is definitely a correlation to be wanting to make your own glsl shaders per platform especially when it comes down to making fragment shaders which might choose to use different parts of a BGRA texture for certain parts like when making normal maps with DXT5, you'd use X & Y from the green and alpha channels and make up the blue from the remainder in glsl instead of feeding a raw BGRA texture or using DXT5 without changes.

Another thing which comes to mind, in the materials xml files is there already a way for the engine to auto-detect which texture file to load or could an order of preference be set which can choose in order which textue file to use? For instance, you have a materials.xml file which points to myTexture.tga but you also have myTexture.dds or myTexture.pvr in that directory. Can you make the engine detect the right one by passing a certain preference value or would you rather make an offline tool which can modify the xml file at build time for a given platform? This can get complicated fast DDd, you're right!

iD software I think just does compression at load time so their pk4 files store raw .tga's and the loader will make them .dds if you ticked that option or used non-ultra quality in the menu. That sounds like a good desktop solution but not a good handheld solution.

From what I saw from the changelog and I hope I understand this correctly, marciano has made making GLSL shaders a boatload easier as the parser will glue small "utilities" together to make the final shader program for any given combination already. As an example, it looks like vertCommon.glsl already does all the world transform matrix type stuff and can be glued to other glsl code like vertSkinning.glsl at compile time by reading the .shader FX file first. So having separate glsl branches may not be necessary if they are made correctly, or at least have special shader FX files written for a given platform.

Something else I read, it looks like Carmack made a wrapper for glBegin/glEnd type stuff for wolfenstein iphone:
http://fabiensanglard.net/wolf3d/index.php

Could be good for running debug type stuff on GLES but most likely conflicts with horde's ideals of having a small and efficient codebase.

_________________
-Alex
Website

Actually. You can thank Volker for splitting up the topic


Yes it does. Perhaps the best approach is to try and port for each platform since it's a simpler and then try to come up with a unified way of building for different devices. I have tried the bottoms up approach in the past. Design the unified framework first and then create the ports for each backend without success.

Horde now uses a ubershader system and that is actually a good thing for us. You still need seperate branches because GLSL differs from GLSL ES. I am still unclear on how to best approach a hybrid shader system. Since shaders have to be compiled and linked for ES.


Could be an option. Though marciano and Volker have discussed that they would like to build a debug framework for H3D.

DarkAngle input also brings up the topic of making the decission of supporting OpenGL ES 1.1 backends (for older iphones) or to cut it totally from the port and focus only on opengl es 2.x as Horde3D has done with desktop opengl 2.x.

Wow, that thread has grown quickly.

First off, I really like the idea of having an ES port of horde. I think that fits very well to the small size of the engine and the fact that it is very OGL centric. Furthermore, it would help to make horde more mature since several multi-platform related challenges have to be solved. Also, it will be required to optimize the resource usage due to the limitations of mobile devices (hard memory limit, in-order CPUs, etc.) which are actually not so different from those of consoles. And, considering the amount of mobile games that are currently produced, I could imagine that a lot of people would be interested in a modern graphics engine for these platforms, especially since the "competition" there is not yet too strong.

A few comments:


Actually it is better to use precompiled shaders that are stored in some sort of cache. It is a pity that those are not available for desktop GL.


I think that is a good approach. I guess I would do the same (in fact I proposed something similar when people asked about support for non-shader hardware). That approach would require the least modifications to the way horde is currently working.


I agree, for a multi-platform engine an asset/resource/content compiler/conditioner (however you want to call it) is almost a requirement. ColladaConv is already close to that but it could become part of a centralized tool which can do fully automated content builds (platform-specific texture conversion, animation compression, endian conversion, etc.).


I would say that usually, you don't have different platform-specific versions of a single asset in the same folder (only one, depending on the platform your build is targeted at). I would always reference the source assets in the materials (e.g. tga textures) and the engine would have some platform-specific rules and always find the right target asset (e.g. dds instead of tga). If the dds is not found or outdated, it could even be created on demand by the engine calling the asset compiler (gives hot reloading support, shorter iteration times for artists). More of a challenge is where the meta information is stored for an asset (for a texture, that would be compression, sRGB space, mip map settings, etc.) .

I think that could be easily solved by just not using any file extension for the textures (or is the loader extension dependent?). Than you could just change the texture resource directory and depending on the platform the correct texture will be loaded.

Wow, looks like there are now 3 mobile platforms (PowerVR, ARM Mali, and nVidia Tegra2)

The Tegra 2 website is still in it's infancy, but the Malideveloper website is quite good.

To all that are interested in mobile development, if you haven't done so take a look at http://www.malideveloper.com/tools/soft ... engine.php

My idea would be to do something similar to this for Horde3D. Where you have a "managed" application.

Take a look at the Mali Demo Engine code for a better overview. My problem is that this sort of design will look allot like spaghetti code. The amount of macros grows exponentially, and if you add DX9/10 to the mix, it can get really ugly. I would prefer to solve this with a smart build system, but have not found an elegant way to handle diff platforms, and now with 3 mobile platforms things get even more confusing... really need to sit down and put something together.

EDIT: Oh yeah forgot to mention that each platform has it's own preference for texture format, and binary asset format, comes with it's own tools, etc... It's just a huge mess

Abstraction is the key here


This can be handled by the content build process which compiles assets from intermediate to final platform-specific formats (see this thread).

I've started to work on an OpenGL ES 1.1 port (using subset of OpenGL 1.5 on desktop machine).

I've decided to modify only utOpenGL and egRendererBase.
(As far as I can see, the intent is to remove OpenGL functionality from egRenderer. )
This causes me some problems because egRenderer still depends on OpenGL (2.0) functionality. I have problem with glUniform functions. I think this could be implemented using with rendererBase's getShaderVar and setShaderVar(adding multiple version with int variable index) functions.
Some other problems with egRendererBase are that in OGLES1.1 there is no cubemap, polygonmode(used in debug mode only) support.

But the biggest problem is the lack of shaders. I like the idea of fixed function shaders that DarkAngel suggested.
A fixed function setup could emulate the interface of shaders (get/set variables and apply)
I'm still thinking of an easily parseable/editable format for this.
Any suggestion?

I'm also planning to support pvrtc (the file format and the texture extensions).

I hope it will render something soon. I will share the sources when I'm satisfied with the
results.

Nice to see some action again in this thread,... but may I ask you why you want to support ES 1.1? It would be much work to do and does not represent the features Horde3D does normally offer by using shaders. ES 2.0 should be much less work and nearly all mid-high end smart phones released today have an ES 2.0 chip inside.

We decided to port to OpenGL ES 1.1 because we think that it has much larger market share currently (and in the near future).
OpenGL ES 2.0 is gaining popularity. So it would be great to have an OpenGL ES 2.0 renderer too, I've read somewhere in forums that someone is already working on it.

Horde3D is not designed for non-shader hardware, but we would like to use Horde3D for PC and high-end phones too, and creating a whole new renderengine for lowend machines would be much more work.

I've decided to create a lowlevel fixed function shader "extension" with an API that is similar to current opengl vertex/fragment shaders. The text language will be something like the FX section in the material: uniform/attribute definitions and name/value pairs like in the D3D FX files. But for the texenv setup I'm thinking something much more flexible, something like this:
RGB[0] = MODULATE(1-PREV.A, TEX.RGB) * 2;
It would be much more readable than 5-6 name/value pairs.

Hi attila,


That's true - and I think limiting the modifications to these files (and maybe a new one) is a good way as it keeps your changes very encapsulated.


Yeah, having a common base of core functionality is one of the reasons that we start at SM2 (or even SM3 in practice - HDR pipeline for instance). I guess for lower end hardware you have to drop some features. The challenge is how to handle the optional features in a way that minimizes divergent code paths.


Creating a custom shader format is the way I would go as well. Although it requires some effort on writing a parser, it should make integration with the rest of horde a lot easier.


Just out of curiosity, do you plan to save the data manually or automate conversion using the content build pipeline?


This is great, thanks a lot in advance!

I've read the "Asset pipeline improvements" thread, but still haven't tried it. Is this the content build pipeline that you asked about?
It would be great to automate the conversion. We probably won't have too many models for the current project, but for a larger project it is a must have tool.
Will there be any way to add parameters to the conversions? For example specify the target pixel format for each plaform and each texture? (probably I should have asked this in the other forum. sorry)

Is anyone experimenting with this? http://code.google.com/p/nativeclient-s ... ingStarted
They have OpenGL ES 2.0 support right now. I don't know if this project will succeed or not but as a c/c++
developer I hope it will.

Yes, that's what I was referring to. The pipeline works for models and animations but we don't have support for textures yet as it is not that important as long as you support just a single platform. Meta data for the assets is a problem. There are several approaches but none of them is perfect. Just to list a few:

• Store metadata directly in image file (not supported by many formats and image editing tools)
• Separate files for meta information (e.g. mytex.tga.prop for mytex.tga)
• Profiles referenced in filename (e.g. mytex_diffhq.tga where diffhq is a high quality diffuse profile with parameters that can be different per platform)

I've been mucking around with trying to compile horde onto my N900.

I guess the renderbuffer code will need to be changed, there's a lack of glReadBuffers/glDrawBuffers which means multiple render targets are out. I'm not sure what the best way out of this is design-wise as I'm still learning how it is working.

The knight demo running on my phone is feeling close though!

_________________
-Alex
Website

The PowerVR chip in the N900 actually does support MRT, but unfortunately they haven't exposed this functionality through OpenGL ES.

Going forward in time, most OpenGL ES devices are likely to support MRT - Nvidia's Tegra already does, via the GL_ARB_draw_buffers extension to ES 2.0.

_________________
Tristam MacDonald - [swiftcoding]