Irrlicht Engine

JNI might not kill performance depending on how you do it. If you avoid writing the main loop in Java you should be OK. But as far as bindings go.. I'd also favor being minimal and leaving it up to the game developers to make their own and just providing sufficient hooks to get Irrlicht rendering ...

Well I'm really glad FuzzySpoon finally got the code to Hybrid. I was getting worried that I would be the only one *very* slowly trying to update the iPhone port :-(

Zenja, I get the impression you have a limited view as to what can/should be part of Irrlicht. And I suspect that if you search the ...

And if you are willing to do some extra work, and the OpenGL system API you are using allows it, you can switch the OpenGL rendering context from one thread to another. It's what I do for the iPhone port since the iPhone OS has the same single-thread "problem" in that the event system wants to run ...

I`m using iphone-dev toolchain (llvm-gcc), not mac+xcode.

I suspect that might be the source of your problems. I abandoned supporting the iphone-dev specific code a long while ago as it was a pita to keep the iphone-dev system going. But I also suspect that the recent trunk->ogles merge also ...

Personally I circumvent most of the annoyances of Xcode, and VS, by having it run my external build system which already supports much better multi-platform building. And edit all the files on Windows through a Samba share with a faster/simpler/better editor.

I'm still perplexed as to the horrible ...

How is it better / worse / different than Boost Variant and Boost Any?

Interesting... GL_EXT_texture_filter_anisotropic is defined without it having the extension.

seongnam wrote:11.PerPixelLighting is not working; the globe is not affected with the lighting... but, it worked well for the previous version.

Implementing the normal map materials is on my todo list, if that's what you are referring to.

The brief steps are:


Make a basic iPhone project to start with.
Compile Irrlicht by adding the sources to your project.
Initialize the Irrlicht device by passing in the UIWindow as the windowID in the creation params.
Do the usual Irrlicht rendering periodically.

I suggest you go through ...

It's been asked for before... But it still requires a patch: <http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32097> -- <http://sourceforge.net/tracker2/?func=d ... tid=540678>

benny53 wrote:It is, all in all, stealing from a company who has worked hard on it.

How is it stealing?

Regarding the STL-vs-irr::core issue, it's really up to an STL advocate to pull their finger out and actually do it. We're all peers here.

Another thing I would like to see (and this will be controversial) is the removal of IReferenceCounted in favour of a smart pointer template

See above ...

adding those #defines would not hurt. You already some defines, why not more? It would just give people more options.

Actually it does hurt. The more options there are, the more variables that need to be taken into consideration for testing and coding. Although I must admit I would like to add ...

bitplane wrote:You need a pixel shader that does-

Code: Select all

destination = (source1*mask) + (source2*(1-mask));

Or you could do it with a multi-texture op.

Truthfully I think adding more materials for such small, standard, features seems like a loosing proposition. Adding a flag seems like a better medium term choice. But ideally I'd merge the two alpha materials into one plus two options: EAO_ALPHA_REF (to turn on/off the alpha ref), and EAO_ALPHA ...