- This topic has 156 replies, 6 voices, and was last updated 8 years, 8 months ago by
.
-
Posts
-
I’m already writing some sort of “cookbook” with small examples on how to do the most common things with the new Lua API. I hope that this will help to build stuff that actually works.
The new API is actually just a bunch of glue code to pass the C++ API down to Lua. You can use the C++ documentation because both APIs are basically the same with the exception of namespaces. The API is completely native and split up in three parts for now: NeoCore, NeoEngine and NeoGui. You can load them as you wish by using the “require” function and it will just work.
Granted, the old API makes some things insanely simple. But it also hides loads of features that you can’t access even if you need to. The new API needs some work to become even better with the benefit that all changes are also reflected in C++.
There is one thing to be aware of: You now can have NULL pointers in Lua. That means: If you destroy an object, keep in mind to not use it any more!
Neo is in principle production ready. There won’t be any dealbreakers any more until 1.0 that make all your projects unusable like this release does. The API will be refined but not completely changed and all “under the hood” changes won’t show in your games at all (in form of incompatibilities).
The 2D engine needs some work to get to the top and the 3D rendering engine needs a rewrite for Vulcan/OpenGL 4. But that is nothing you should worry about when creating your game. They will just work when they arrive.My thoughts for the material editor. The Material editor should be made user friendly. That means just like any user, he would like to press buttons and add things the easy way, not write scripts. 🙂 Ive searched the net and found some interesting info about writing shaders:
A quote from the website code4k.blogspot.Shader languages like HLSL, Cg or GLSL are nowadays driving the most powerful processors in the world, but if you are developing with them, you may have been already a little bit frustrated by one of their expressiveness limitations: the common problem of abstraction and code reuse. In order to overcome this problem, solutions so far were mostly using a glue combination of #define/#include preprocessors directives in order to generate combinations of code, permutation of shaders, so called UberShaders. Recently, this problem has been addressed, for HLSL (new in Direct3D11), by providing the concept of Dynamic Linking, and for GLSL, the concept of SubRoutines, For Direct3D11, the new mechanism has been only available for Shader Model 5.0, meaning that even if this could greatly simplified the problem of abstraction, It is unfortunately only available for Direct3D11 class graphics card, which is of course a huge limitation…
Links here->
http://code4k.blogspot.com/2011/11/advanced-hlsl-using-closures-and.html
https://github.com/SiliconStudio/paradox/tree/f5c45f5855842d0fe0942032dc08230ce9bb034d/sources/engine/SiliconStudio.Paradox.Engine/Rendering – gpl, brdf shaders
https://github.com/aerys/minko/tree/master/framework/asset/effect
https://github.com/TriumphLLC/Blend4Web/tree/master/shadersNice links shows examples for inspiration and stuff. More later about the material editor.
Hey!
I already know about sub routines in GLSL and intend to use them in the rendering engine.
The whole material system will change in one of the next versions to become better:
a) Multithreading for occlusion and frustum culling and animation skinning
b) Deferred shading for high number of dynamic lights
c) Usage of GL4.x for advanced features
d) Physically based shading for more realistic graphics
e) Usage of hardware instancing (Automatic?)I already experimented with GL4 and deferred shading a little. It will take a while until the new rendering engine can replace the current one but it will be worth it. There will be no serious material editor until the new material system is fully functional.
Btw: Neo 0.5 is now in a feature freeze. Consider it being a beta version. I will upload some binaries this week when I have some time so it can be tested.
Neo 0.5.1 will be mainly about getting proper Android support due to some requests I got.
Another topic for the future will be the future of the Neo Editor. The current editor is written in C++ using FLTK. All logic is hidden in the EditorBackend class. When switching to OpenGL 4.x the toolkit will need to be modified manually to work with the new API. The question is: Stick with FLTK and improve it or change to another toolkit that has better support?I like FLTK but the development seems rather slow.
Anyway, have a nice day!
Yeah, i was thinking that you new about the subroutines, but had to post it for everyone. Will test the build when available. Perhaps, when it comes to the neoEditor, you could come back to the GLFW and use CEGUI -> http://cegui.org.uk
CEGUI is nice but I think it is better to improve our own GUI system that integrates perfectly with all existing code. CEGUI should be a plugin you can use if you want to.
I thought about what to do next, after 0.5 is finished. The first thing some people wanted me to tackle is Android support. Here we have the conflict: The rendering engine needs to be rewritten first or else it would mean porting the engine twice.
That means the following road map might be useful:
1) Rip out the old rendering pipeline and replace it by the new one
2) Get the 2D system to work with the new renderer
3) Rewrite the editor to use the new rendering engine (Which toolkit? Qt? Our own GUI system?)
4) Port the player to Android and EmscriptenCEGUI was just an idea. So it looks like the renderer will have to be rewritten first. When it comes to android, the android opengles 2 dont support deferred render, so how will that work?
The NeoEditor.exe from the zip archive won`t start only loads and have to end task it. Os Win 7 64b.
Thank you for testing. Could you please send me the debug log so I can examine the issue?
About GLES: Of course you can do deferred shading with OpenGL ES. The only prerequisite is having GLSL shaders and render to texture. Nothing more.
It might be useful to create a new forward renderer as well though, just for things like advanced custom shaders or transparency.
I dont see any debug files only a logfile.txt. I read, that the deferred render for android opengles 2 is too slow. My tablet with mali gpu only supports opengl es 2 and the zombie game dead trigger runs smoothly with some cool shaders, but anyway. Yeah, having 2 render backend might be useful. Some place said, that the Unreal engine uses forward render to render the transparency. I found this -> http://sourceforge.net/projects/isdge/ the render looks like neo to me.
The logfile.txt *is* the debug log 🙂
Well, I guess the issue is about cross compilation with gcc 5 on Fedora 22. Need to look into that.
Until it is fixed I will upload some VS compiled binaries later, I have no access to VS right now so it will probably happen tomorrow. I’ll keep you updated.Ok, im gonna try to compile too, log here http://www.pasteall.org/58767
I packed all dependencies including MinGW, CMake and git together into one package with some build scripts called “NeoBE”. I’ll upload it when I find some file host that allow me to upload such a big file, it is currently about 1.7GB uncompressed. Building with it is a mere double click on the build.bat file that is included.
I just uploaded an updated Windows version that was compiled using VisualStudio 2013, I tested it and it should work.
Happy Testing!
- You must be logged in to reply to this topic.