Horde3D

That's better

Pretty much it is how mipmap autogen worked (or didn't work in this case). I'll update the sources as soon as I bring back features I've disabled.

I'm not too sure where to start with converting overlays and particles to use GL_TRIANGLES instead of GL_QUADS but I think horde mainline will get this in future so that's good!

Very excited now! I'll try to get normal mapping to work properly (figure out RGBA/BGRA conversions and things) and fix up PVR support. Also with shadowmaps & encoding depth to RGBA, has anyone done this before?

Edit:

In utImage how do you set it so it doesn't output the BGRA result and instead does RGBA? Thanks!

_________________
-Alex
Website

There we go!

Oddly I still can't get mip maps from the PVR file to load, but cube maps without any mip maps work fine. I replaced GL_QUADS with GL_TRIANGLES so particles & overlays partially work.

_________________
-Alex
Website

I've checked the cubemap texture you use and it contains mipmap levels only down to 8x8.
For mipmapping it must contain images down to 1x1 because AFAIK there is no TEXTURE BASE LEVEL,TEXTURE MAX LEVEL texparameter in OpenGL ES.

So I would check with a pvr that has full mipmap chain and see if it works.

The screenshot looks great. Good job.

Hello MistaED,
Congrats.
I have the N900. I have tried to compile the (probably old) sources I have found on windows and Linux but without success.
- Any defines to add ?
- where are the latest sources ?
- do you work on windows ?
- which version of qtcreator ?
- which version of MADDE ?
- which version of firmware PR : 1.1, 1.2 ?
- I could perhaps write the Linux support code. Any git repository ?
- Does the GLES2 code break the Horde SDK ?
- If not, could nt we push to official Horde repository ?
Regards,
Skai

attila:

thanks for the tip, the reason why they don't go down to 1x1 is because loading 4x4 and under textures using PVRTC fails, however I think you might be right and it is something to do with the issue. I'm guessing maybe that the offset needs to be always 32-bit even though when it reaches about 4x4 res it is less than that, so I'll try adding some code which always makes it have at least a 32-bit offset. It is guesswork at the moment here.

skaiware:

Pretty much I'm not using cmake (what horde uses) I made my own build files for qtcreator which uses qmake.

I use the latest Nokia SDK RC1.0 on ubuntu and windows 7 which bundles MADDE and QtCreator and they work well enough for most things. I have PR1.2 installed but PR1.1 would work if you install the Qt 4.6 libs manually or don't use Qt at all (I currently use Qt for the GL window but I do have code which uses SDL instead).

I use the source code from the community branch not the sourceforge one, but I've modified the code too much that it would break the desktop version unfortunately. I have code posted here somewhere but it is a bit old and it was before I fixed texture loading, I'll package what I've currently got but I really wanted to get PVR texture loading to work first. I've been a bit busy the past few days so I haven't had time to look at it further.

Volker: I guess the code at this point might be good enough to have its own branch? If you could give me access that would be good!

_________________
-Alex
Website

Worth keeping in mind that CMake was developed as the build system for KDE, which is itself based directly on QT. As such, CMake makes a fantastic build system for use with QT

_________________
Tristam MacDonald - [swiftcoding]

Concerning the build system, dont worry at all :
- qtcreator can import/read cmake files
- qtcreator can generate Makefiles from .pro files
- pushing to Horde repository few little qtcreator (.pro) files for the guys using it should be allow : just recalling qtcreator is fully cross platform (even Mac), so Linux, Windows, N900,... and that you can use it even if you dont use Qt SDK. And of course it is free and openSource.

Horde admin : any news concerning an access to a branch on your repository for the GLES2 / N900 codes ?

I found this about pvrtc:
http://www.imgtec.com/forum/forum_posts ... D=366&PN=2

From this forum:






So as I understand you must upload the levels down to 1x1 but because there is a fixed block size the imageSize will be at least 32 or 64 depending on the format.

Also your texture level size is different that the one in the extension specification:
http://www.khronos.org/registry/gles/ex ... _pvrtc.txt


You use:
PVRTC 2BPP:
return std::max( width / 8, 1 ) * std::max( height / 8, 1 ) * 8;
PVRTC 4BPP:
return std::max( width / 4, 1 ) * std::max( height / 4, 1 ) * 8;

While your 4bpp calculation gives similar result for larger images it seems to be broken from 4x4. Also your 2bpp calc for an 8x8 texture gives 8 bytes which means 1 bit per pixel instead of 2.

Maybe I'm wrong, but I hope it helps.

I hope I will be able to test it soon on a device too and help more with testing.

attila you legend, I added that change plus I realised the mipCount calculation was wrong (had to add +1 to get the last mip) and I've fixed up the pvr textures to go down to 1x1 mip.

Here's the current code on mine, it should work with the .pro qmake files in qtcreator, and most likely you could get it to work with the cmake files, just I've hacked the extensions system a bit to always compile terrain so you might need to fix that first, not 100% sure.

http://boberfly.com/hordeGLES2.7z

Particles and overlays somewhat work if you like them to be triangles maybe someone else can replace the GL_QUADS with a working GL_TRIANGLES system.

swiftcoder: that may be true but working with CMake and the Nokia Qt SDK I just found it a lot easier to use qmake, at least on windows I can never get cmake+qtcreator to play nice with MADDE, it always wants to find my desktop mingw (which oddly doesn't work either) so for fast turnarounds that's why I'm using qmake.

_________________
-Alex
Website

Hi,

I've just uploaded the updates to the community SVN under the ES_Test branch for testing. While I was cleaning the code I might of made a silly mistake so I'll test it later or if anyone else wants to test feel free and tell me if it works or not.

Also feel free to stress-test PVR file loading support with other formats like DXT1,3,5, alphas, cubemaps, 16-bit formats (RGB565, RGBA4 & RGB5_A1 has support at the moment).

_________________
-Alex
Website

Good news, we continued removing deprecated functionality from the renderer and replaced the quads by indexed triangle lists. The change will be submitted very soon. Actually the only place which still uses deprecated functionality now is the visualization of the skeleton in debug view which can easily be commented out.

Keep up the great work!

I've just submitted to the ES_Test community branch the updates you and Volker have made for the indexed triangle lists. Particles behave a lot better now, as well as the overlays!

Cheers guys!

_________________
-Alex
Website

Thanks for the update.

I recently discussed with marciano, about initialization of different rendering backends. We thought about making Horde able to optionally create the rendering context. This may be especially useful if we want to have a DirectX backend some day. We ended up with the idea of enhencing the init() function of Horde3D with a void* pointer that can contain a window handle. If it's zero the user is responsible for the rendering context creation, otherwise Horde3D will create the context based on the choosen rendering backend. To unify the context creation within Horde3D, we thought about creating an EGL wrapper library for platforms where it's not available and use the already existing libEGL where available.

I just wrote an EGL wrapper for the wgl methods needed for creating a windows opengl context. It's just a quick hack to allow the context creation and does not comply completly with the EGL specification, but at least it works for the most common cases and should be usable in the same way for native libEGL under GL ES.

If we would finally implement this proposition in Horde3D we could remove the dependency to glfw, but have to write a thin window creation library to allow the samples to be usable out of the box on every platform. So there's still much to do and I guess we will completly test the concept first before we will submit anything to the svn.

That sounds like an interesting idea, horde makes an EGL-compliant context which is wrapped over WGL/GLX/AGL so that it will work on the desktop and on the mobile platforms which utilize EGL it uses native calls directly. I think mesa's EGL does something like this for GLX wrapping. I've never used Direct3D before but how do contexts get created for that API, does it just make a direct-draw surface or something? Would it make sense for this EGL wrapper to wrap Direct3D context-creation as well or are they too different?

_________________
-Alex
Website

I don't have much experience with DirectX either, but I guess since the rendering backend would differ a lot from the one in OpenGL, it does not make to much sense to wrap DX with EGL methods. And I think one wouldn't expect to have a EGL library that creates DirectX rendering contexts, so a user might be irritated, if he/she needs an EGL library for a DirectX rendering backend.