Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1373113 Posts in 64826 Topics- by 57009 Members - Latest Member: nights007

February 21, 2020, 01:07:53 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)nCine is a new 2D multi-platfom game engine
Pages: [1]
Print
Author Topic: nCine is a new 2D multi-platfom game engine  (Read 1247 times)
encelo
Level 0
**

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« on: June 11, 2019, 01:31:37 AM »

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.
« Last Edit: June 11, 2019, 04:37:00 AM by ProgramGamer » Logged
kason.xiv
Level 0
**


View Profile
« Reply #1 on: June 19, 2019, 09:13:05 AM »

Very cool! will definitely be snooping around this project.  Noir
Logged
encelo
Level 0
**

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« Reply #2 on: June 20, 2019, 08:44:01 AM »

Very cool! will definitely be snooping around this project.  Noir
I am very glad to hear that.  Wink
Let me know if you need any help with it, for example about the compilation process or how to set up a project.
Logged
encelo
Level 0
**

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« Reply #3 on: July 16, 2019, 06:11:08 AM »

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.
Logged
encelo
Level 0
**

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« Reply #4 on: September 21, 2019, 02:28:31 AM »

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

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« Reply #5 on: October 22, 2019, 12:16:28 AM »

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
« Last Edit: October 22, 2019, 12:24:47 AM by encelo » Logged
Daid
Level 3
***



View Profile
« Reply #6 on: October 22, 2019, 01:19:03 AM »

 Beer!
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.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
encelo
Level 0
**

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« Reply #7 on: October 22, 2019, 08:08:57 AM »

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. Wink

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. Smiley
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. Grin
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.
Logged
Daid
Level 3
***



View Profile
« Reply #8 on: October 22, 2019, 12:11:34 PM »

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.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
encelo
Level 0
**

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« Reply #9 on: October 22, 2019, 01:59:05 PM »

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?
Logged
Daid
Level 3
***



View Profile
« Reply #10 on: October 22, 2019, 11:19:14 PM »

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.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
encelo
Level 0
**

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« Reply #11 on: October 23, 2019, 08:53:36 AM »

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. Hand Thumbs Up Right
Logged
Daid
Level 3
***



View Profile
« Reply #12 on: October 23, 2019, 09:42:36 AM »

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.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
encelo
Level 0
**

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« Reply #13 on: October 24, 2019, 09:37:11 AM »

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. Cry
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. Lips Sealed
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.
Logged
encelo
Level 0
**

An Amiga and demoscene lover, an Arch Linux and 3d


View Profile WWW
« Reply #14 on: November 03, 2019, 03:48:51 AM »

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.
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic