next »

[encelo]

The nCine source code and related projects have been released on GitHub under the MIT license at https://github.com/ncine just some days ago.

Website: https://ncine.github.io
Twitter: https://twitter.com/nCine2D
Dev Updates: https://encelo.github.io/tags/#nCine

nCine is a multi-platform 2D game engine written in C++11 that runs on Linux, Windows, macOS and Android. The work started eight years ago, in June 2011, and has continued since.

It is not intended, of course, as a replacement for big engines like Unity and Unreal but more like a lightweight alternative to LibGDX and Cocos2d-x or to frameworks like LÖVE, SFML and LWJGL.

It features a fast sprite blitter with automatic batching (that can also render particles, animated sprites or mesh based ones), music streaming and sound effects, Lua scripting, integration with ImGui, RenderDoc and Tracy, high-performance custom made templated containers, bitmap font rendering with kerning, joystick support with gamepad mappings, multi level logger and more.
You can have a look at the gallery or read more about its features on the website.



Dependency libraries for PC and Android can be easily compiled from sources with a set of custom CMake scripts.
Some of them are libogg, libvorbis and OpenAL-soft for sound, SDL2 and GLFW for window and input, libpng and WebP for images (but many GPU compressed formats are supported too) plus OpenGL 3.3 and OpenGL ES 3.0 for rendering.



The development takes place mainly on Qt Creator and ArchLinux with the help of a whole set of additional open source tools like CMake, cppcheck, Valgrind, Doxygen, GraphViz, clang-format, Google Test, gcovr and Google Benchmark.
Additional developing tools are RenderDoc, apitrace and Tracy.

On GitHub you will find the engine, a Pong example project, a particle editor, the CMake scripts for compiling the dependencies, the data sets, the Jekyll website and the continuous integration artifacts.

[kason.xiv]

Very cool! will definitely be snooping around this project. 

[encelo]

Very cool! will definitely be snooping around this project. 

I am very glad to hear that. 
Let me know if you need any help with it, for example about the compilation process or how to set up a project.

[encelo]

The engine can now target the web through Emscripten. You can read more about the port in the latest development update and try the web tests on the project site.

[encelo]

I have just published the twelfth dev update of the nCine, illustrating the latest changes dedicated to improving the quality of life of users.
You can find all previous articles here: https://encelo.github.io/tags/#nCine

[encelo]

The culmination of five months of work is finally here: nCine 2019.10.

Some of the highlights for this release are:

• Emscripten is supported as target platform: you can use the nCine for web games!
• New AngelCode’s FNT format parser
• When you compile the engine you can choose to disable the support for various dependency libraries and features
• The user can now query the available fullscreen video modes on PC and choose one
• Fixes and enhancements to OpenAL implementation
• It is possible to defer shader checks and queries for a decreased starting time
• Refactoring of the clock and timestamp classes
• Update of Tracy integration to v0.5
• Update of ImGui integration to v1.73

During the same time there has been a lot of work in side projects with the addition of:

• ncline, the nCine command line tool
• ncTemplate, a template project for applications and games made with the nCine
• ncInvaders, a simplified version of Space Invaders made with the nCine

The site have also been updated with:

• A web-tests page for you to run all tests, tools and games in the browser
• A gallery with a selection of screenshots and videos
• A download section
• A video tutorials page with a list of video from the YouTube channel
• A donate page that allows you to support and sponsor future development

[Daid]

 
I dove a bit into your code to see how your particle system worked. Pretty nice design, I might "borrow" some concepts for my own engine.

But I noticed something, your header files are one large flat directory. With your latest update, you say that you can disable certain features/library dependencies. But with the current structure, it's a bit hard to see what belongs with what.
You might want to move includes into subdirectories for which subsystems they belong to. I've done so with my engine:
https://github.com/daid/SeriousProton2/tree/master/include/sp2

Really helped once the code started growing even more.


Also, for your nctl, you might want to document with each class when to use it. For example, why would I use nctl over std::string? Same for all other replacements.

[encelo]

I dove a bit into your code to see how your particle system worked. Pretty nice design, I might "borrow" some concepts for my own engine.

Thank you for spending some time with the project.

But I noticed something, your header files are one large flat directory. With your latest update, you say that you can disable certain features/library dependencies. But with the current structure, it's a bit hard to see what belongs with what.

Yes, you are right, at the moment all headers reside in one directory, but I might change this in the future.
When you create a binary distribution of the engine the includes of the disabled system will not be part of it, thanks to the ncine_extra_sources.cmake script.

Also, for your nctl, you might want to document with each class when to use it. For example, why would I use nctl over std::string? Same for all other replacements.

The engine, the tests and the side projects don't use STL at all, but your code can still use it.
If you are interested in performance then there are a bunch of microbenchmarks that you can enable to assess the speed of an STL container compared to the nCTL version.
You can read about one of those comparison in the 7th development update article.

[Daid]

Ah, a no stl codebase. That's fine.

Few other things I noticed:
None of your emscripten examples render anything but DearImGUI on my laptop. It's a pretty new laptop, with a Intel UHD 630 and a GTX 1050 Ti. Not sure which one will be used by webgl. But looks like something is amiss in your rendering pipeline, no errors in the javascript console.

Also, I see you have OpenAL-soft as dependency. SFML uses this as well, and it has been a huge pain, I got random crashes for certain people, never managed to trace them down. Only happened on certain setups, never found the common thing that caused it.

[encelo]

None of your emscripten examples render anything but DearImGUI on my laptop. It's a pretty new laptop, with a Intel UHD 630 and a GTX 1050 Ti. Not sure which one will be used by webgl. But looks like something is amiss in your rendering pipeline, no errors in the javascript console.

I have had some problems in the past with WebGL shader compilation but this shouldn't be your case as you said you can see the ImGui interface on screen in some examples.
Just to have all the details, are you trying the web tests on the website or did you try to compile them from source? By the way, I have an Intel+Nvidia laptop and those examples work well for me on Windows and Linux, both on Chrome and Firefox. What's your OS and browser?

Also, I see you have OpenAL-soft as dependency. SFML uses this as well, and it has been a huge pain, I got random crashes for certain people, never managed to trace them down. Only happened on certain setups, never found the common thing that caused it.

Mmm, I don't think I have encountered any OpenAL-soft related crash yet but I agree it might be a problematic dependency in the future as it doesn't seem to experience any evolution. Do you know of an alternative that works across all supported platforms?

[Daid]

I have had some problems in the past with WebGL shader compilation but this shouldn't be your case as you said you can see the ImGui interface on screen in some examples.
Just to have all the details, are you trying the web tests on the website or did you try to compile them from source? By the way, I have an Intel+Nvidia laptop and those examples work well for me on Windows and Linux, both on Chrome and Firefox. What's your OS and browser?

I used the webtests website. Windows 10 with chrome.

On my work laptop, Intel UHD P630 and NVIDIA Quadro P1000 it works fine.

Mmm, I don't think I have encountered any OpenAL-soft related crash yet but I agree it might be a problematic dependency in the future as it doesn't seem to experience any evolution. Do you know of an alternative that works across all supported platforms?

My issue with OpenAL was that I also encountered no crashes myself, on like 10 different systems. But I had other people reporting regular crashes, and the crash reports always point to the OpenAL dll. We tried different versions, but without any result.

I'm now using SDL2 audio system. It requires doing everything in software as it is quite primitive, but it works.

[encelo]

I used the webtests website. Windows 10 with chrome.

On my work laptop, Intel UHD P630 and NVIDIA Quadro P1000 it works fine.

That's strange, both laptops with Intel and NVIDIA and only one of them does not work.
Could it be something related with drivers, maybe the Quadro one? Are you starting Chrome with the Intel or the NVIDIA GPU?
I have uploaded an updated version of the web tests (except the particle editor for now), compiled with a newer version of both Emscripten and the engine. Do they fix the issue?

I'm now using SDL2 audio system. It requires doing everything in software as it is quite primitive, but it works.

It might be the only other open source alternative that works over all my supported platforms.

[Daid]

Nope, no output, except for the UI. Nothing in the logs. Note, I had a problem like that as well when I added emscripten support, I have the option to call glError after each gl* call and output the error and the call if there is an issue. In my case, it was using repeating texture wrap on "non power of 2" textures, which isn't allowed in WebGL apparently.

It does work on my Pocophone F1. I also noticed that the aspect ratio looks off on the phone. Few things that could be wrong, one of them could be that your canvas internal size is different from the rendered size (yes, html is strange like that, if you resize the canvas with css, it does not change the internal buffer size)

Could also be that your projection matrix isn't properly setup with the actual aspect ratio of the screen.

[encelo]

Nope, no output, except for the UI. Nothing in the logs. Note, I had a problem like that as well when I added emscripten support, I have the option to call glError after each gl* call and output the error and the call if there is an issue. In my case, it was using repeating texture wrap on "non power of 2" textures, which isn't allowed in WebGL apparently.

Maybe I should try to recompile those tests with a lower logger level so that more things will be printed in the console.

It does work on my Pocophone F1. I also noticed that the aspect ratio looks off on the phone. Few things that could be wrong, one of them could be that your canvas internal size is different from the rendered size (yes, html is strange like that, if you resize the canvas with css, it does not change the internal buffer size)

Could also be that your projection matrix isn't properly setup with the actual aspect ratio of the screen.

Yes, I'm aware of the stretching issue.
In the beginning I thought that the special Emscripten versions of GLFW and SDL2 would have returned the canvas size when queried for "window size" and that they would have reported browser full screen events. Apparently this is not the case and it should be addressed explicitly using the HTML5 Emscripten API.

So what happens is that most tests use a default window size of 720p, resulting in both stretching and scaling.
When you go full screen the stretching issue is resolved though. In particular the space invaders game has a window size of 1080p and thus it suffers less from scaling when the browser is full screen.

[encelo]

It does work on my Pocophone F1. I also noticed that the aspect ratio looks off on the phone. Few things that could be wrong, one of them could be that your canvas internal size is different from the rendered size (yes, html is strange like that, if you resize the canvas with css, it does not change the internal buffer size)

Could also be that your projection matrix isn't properly setup with the actual aspect ratio of the screen.

On Emscripten the engine now ignores what the user has chosen as the initial window size and uses the browser one, this way there is no stretching or scaling, like on Android.
Even though it might be useful in the future to add an option to scale the content.
It now also handles the resize event by updating the projection matrix.

I have also recompiled all tests with Emscripten 1.39 that enables the upstream LLVM WebAssembly backend by default.

[encelo]

Hi everyone. I have just added Qt5 as a backend on desktop platforms.
It means that, besides GLFW and SDL, you can now also choose Qt5 for window handling and input dispatching.

The engine can now render inside a custom QOpenGLWidget so that it is now possible to create a Qt5 application with the engine embedded inside it.
I imagine this feature to be useful in case you want to do a tool like a map or a game editor and need a fast and small 2D engine to handle the rendering of your sprites or if you want to do a game or a prototype while using Qt5 for the interface.
If you have the Qt5 Gamepad library installed then gamepad input events will also be dispatched.

As you can see in this

the ImGui and Nuklear integrations still work so that you can have all three GUI toolkits working at the same time.

[encelo]

I have just published a new release: nCine 2020.05.

Some of its highlights are covered in this video.

• JugiMap API supports the nCine
• Sprite system enhancements
• Qt5 desktop backend
• Nuklear GUI integration
• FileSystem API
• Support for ANGLE rendering libraries on Windows

For a more detailed list of changes and improvements you can refer to the Release 2020.05 page.

Don't forget to check the updated DoxyGen documentation and the Lua API functions list.

[encelo]

I have published the Development Update #16, with updates from the second half of May to the first half of November 2020.

Some of the highlights:

• A new fault-tolerant loading API for resources
• The migration to GitHub Actions
  
• The new Gui Demo for the JugiMap Framework
  
• An UTF-8 decoder for Unicode text rendering
• The support for Tracy v0.7.3 multiple memory pools tracking
  
  
  
  

[Golds]

looks like a cool little engine!

[encelo]

Thank you for your comment, Golds. 
If you, or anyone else, want to know more about the project, please feel free to join our Discord server.