Forum Replies Created
-
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.I spent the last weekend porting the engine to Windows again because of some regressions due to huge restructuring. It works now on MinGW32-w64 and VS2013 while the Clang support on Windows is still bad.
There are still some issues on Windows that need to be fixed (NeoGui does not work somehow)
Another problem are translations. The current ones are still ok but nowhere near complete. It’s no blocker for 0.5 but important for the 1.0 release.
Akira_San: You mentioned that you want to work on the Bulgarian translation on GitHub. Just open the “bulgarian.csv” file with LibreOffice Calc or Excel and insert all new strings. The list is in the file “translations.txt” in the “Neo/NeoEditor” directory. Be sure to save as UTF8 with comma as the delimiter.
Have a nice day!
In the long run, yes. But for the short term we are better off with the current version since I have not much time to work on stuff right now.
By the way: You might want to test the new version a little. I will release a complete tutorial for using Neo soon since the way you use it changed completely.
One more thing:
Release 0.5 is near!Just a little more testing and fine-tuning left!
That library looks really nice!
This might just bring the new graphics I am trying to achieve.I will look into it any maybe create a small demo. First I need to do more API work though,
the C++ API needs work.Thank you for that link 🙂
I think materials should be handled similar to the Torque3D Game Engine. They put all information about the material in a script and simply execute that script to set up all textures and shaders.
We could achieve that by using Lua scripts and the new Lua API that gives you full control over the material. The material editor should be implemented as an external tool that is launched whenever the user wants to edit the material of an object, this way we can keep the editor small and fast.
The plan is not to re-create what Blender does but to merely give the opportunity to customize every object independently without switching to Blender. All UV maps need to be created in Blender and it will remain this way.
Btw: Thanks for the link. I had no problems with the default exporter yet, but I will try this script.
Exporting from Blender using the old plugin is outdated by now. You should export to DAE or something and use that directly. Animations need some testing though.
The material editor is non-functional for now because of that fact. If I have time I will create a new file format for saving material data for every object in the scene so every object can have unique textures defined in the Neo Editor.
Hey Akira_San!
You are right, those engines are now “gratis”.
1) That does not change their maleficent proprietary nature that forbids you to use your four freedoms
2) I’m doing this project for fun and I have no fun when using one of this ready-made solutions. I want to tinker 😀I will not stop working on Neo just because someone else decided to make their product “gratis”.
Neo is not competing with Unity and Unreal anyway due to a lack of man-hour and money.Have a nice day!
Thank you for pointing me to this project. I think we’ll keep using OpenAL-Soft for now though since we already have working code using it.
Now to something completely different: There are many huge changes since the last Neo release 0.4 but we are not ready to ship 0.5 yet. Should there be more frequent point releases to deliver a semi-stable experience between releases?
Thank you 🙂
There are still so many things to do, much more than I can do on my own. I hope to find some experienced programmers for a faster development cycle but I guess that’s far beyond reach.
Does your engine have a website? I would like to take a look at it 🙂
Hey sunnystormy!
I already experimented with RakNet for UDP connections but decided that it was an ugly and buggy mess so I threw that out again. The current plan is to write basic UDP support from scratch without using another middleware.
Data persistence can be implemented in Lua or C++ without problems. I don’t want that in the engine since this is very game dependent and likely to be useless for most cases.
Yes, the shader is hardcoded in the NeoGui library.
I have to admit that it looks quite nice if done well. Just one problem: A normal/spec map needs some sort of lighting to do those calculations. The current 2D renderer does not have any lighting support. I doubt that it would be useful in any GUI situation so I guess this feature would only be implemented for Sprites and Tiles.We need nothing fancy there. Just some 2D light sources with X/Y position and radius. Everything else can be calculated using that. And of course: Allow loading textures for normal and spec map 😀
One problem I encountered while designing an extensible toolbar is the problem of scripted plugins.
Should plugins have access to the toolbar contents? If yes, when and how?
A change could be triggered by selecting another type of object in the 3D view or for objects with certain properties.
Another problem is space management. I need to ensure that every plugin has enough space to place its content without compromising built-in functionality.
Not quite. Most rendering functionality is in Neo::StandardRenderer and Neo::FixedRenderer. Neo::NeoGame just sets up the environment for those classes to render correctly. This way it is possible to redirect the output to a texture or to allow layering two scenes. Neo::NeoGame also sets up post processing if it is active and redirects all output onto there.
Both renderers only access the abstract rendering context to allow API independence. You could write an interface for Direct3D, GLES, GL, Mantle or any other API for that matter this way, without changing one line of code anywhere else. The only problem would be replacing the GLSL shaders since those do not work with D3D of course.
Every behavior also has a “draw” method that allows you to draw custom graphics in your behaviors. The particle system behavior does that for example.
Well, the first place you can look at for things to do is the GitHub issue management:
https://github.com/Sponk/NeoEditor/issuesThere are not all things listed that I want to be done to 1.0 yet but a fairly good overview of what to do for 0.5.