On the discord we’ve had some discussion around potential alternative renders.
To my knowledge, right now GD5 uses PixiJS. However, some conversations have come up about potential benefits of moving over to something like Three.js or LiteScene.js
While both of these are full WebGL renderers (meaning they include 3D functionality), having something capable of 3D could add benefits even if we’re not going to push polygons/do 3D Support in the engine. Stuff like:
Splitscreen/multiple viewports becomes much easier to implement
Skewing sprites
Full depth/layer distortion (like a Monkey Island adventure game, when going moving into the background/foreground).
As far as the renderers, Three.js is one of the most well known/used WebGL renderers out there (https://threejs.org/) and has a lot of active support.
All of the above said, adding/changing to a new renderer is a ton of work, so it was suggested to post the info here to see if @4ian and the contributors even had an appetite for this.
I think the engine isn’t ready for an change on a other renderer.
As you know we use currently pixi 4.8.6.
In the next months/weeks the version will up to 5.2.4, the current lastest version of pixi.
Seeing other solutions is interesting, the applied is a very huge decision and indeed require a lot of investissement.
Add a new renderer can be interresting but i would like see an native renderer multi-platform for pc app, mobile and web.
Maybe something how allow to the dev to avoid an app with a browser included (ie: Electron/NW.js).
This kind of app are limited by the rule in place in the browsers.
I think to the sound and the video, these are limited, that why you need to click before launch any sound/video.
Oh, I thought electron patched chromium to remove pretty much all those limitations for a more native feeling.
I don’t think it is about changing, it is about providing an alternative, like cocos2d. The engine is made with multiple renderers in mind, and it wouldn’t hurt to try potentially more powerful and efficient ones. We don’t need to convert every object for this renderer directly too, so I think it wouldn’t be that difficult to provide a PoC of a new renderer (only need to make a renderer for runtimeGame, runtimeScene, layers and SpriteRuntineObject to have a working one)
Using multiple render engine is nice…It will provide many kinds of benefit
About using multiple render engine I remember 3ds max which can add multiple render engine as add-ones.
I’m also prefer to see a native renderer for desktop and mobile. The original idea behind Cocos2D was to replace both Pixi and SFML so need to maintain only 1 renderer, 1 code base for both HTML5 and Desktop and may even add Mobile support but don’t know why 4ian decided to focus on Pixi only and dropped SFML and Cocos2D been never get in to the focus, contributors do implement staff for Cocos but 4ian doesn’t really care but Pixi.
So yeah, +1 for a native renderer but if 4ian prefer to maintain a single code base could target a trans compiler like Haxe or Cerberus would do. Both is a custom programming language that is get compiled down to native JS, C++, Java code and both also has a cross-platform renderer that also get compiled for each language natively no Cordova or Emscripten or other bull*** that make your hair fall out but pure native code on all platforms with a single code base.
Of course I know it is never going to happen because 4ian is a JS guy but I like to unload my thoughts on forums and then I can sleep better
I don’t know anything about it but I think maybe we could also use GraalVM (https://www.graalvm.org/docs/reference-manual/languages/js/), it could potentially be more performant as it is designed to run real big programs unlike v8 which is designed to run smaller programs. Then I don’t know anything I may be wrong and I don’t know if it’s even really possible to put it in electron
Interesting. I can’t say I fully understand this but it is sounds like some sort of server side solution it is not really meant for making mobile and desktop apps. It is seems to be some sort of VM platform to execute different languages in one shared runtime. So you can write your program in one language say JavaScript and run it inside GraalVM and then inside this VM you can interface with libraries written in an other languages say Java or C++.that is normally not possible but GraalVM give you the integration tools to make this possible and also take care of garbage collection for you but then it doesn’t really say you can build desktop or mobile apps out of this but to run this on Linux and Windows servers and inside JVM. They also have an Enterprise plan so I’m sure it is not targeting us but would be cool.
There had been some additional conversation in the discord around this, and it was mentioned that Haxe could be an interesting option.
I wanted to just chime in here that if Haxe was looked into, it may be simpler to implement than other renderer/code engines, as there appears to be a direct PixiJS to Haxe module out there: GitHub - pixijs/pixi-haxe: Externs of Pixi.js for Haxe
Haxe would also be interesting, because this could mean the alternative renderer could be Heaps.io. Which can build natively to JS, Windows/Mac/iOS, AND all current consoles. It’s also a battle tested renderer used for numerous commercial games (Dead Cells probably being the most well known): About - Haxe Game Engine - Heaps.io Game Engine
As mentioned, any of this is obviously a huge undertaking, but it sounds like the Pixi > Haxe code above might make it much easier.
But did he seem interested in the implementation himself? He is the only one knows GD in and out so he need be actively participating, providing some guidelines to contributors how to go about it “if interested” not going to be enough imo.
Haxe is not the current subject, renderers are. Haxe would be a different platform.
I am 99% sure I was the one who brouht it up. I would prefer to stick with the current Platform for the same reason the cpp one got abandoned: one platform which can export everywhere is enough, and we don’t have the time and enough contributors to keep multiple platforms. The JS platform can export everywhere and is pretty complete. Rewriting a whole new platform would take massive amounts of time porting everything, and we would probably loose contributors as it is possible some only know JS or don’t want to learn Haxe. This change is not necessary, potentially dangerous for the contributors number, and time consuming.
This is not the first time 4ian mentioned WebAssembly, I think he really would like to explore that.
In that case it could be interesting to look in to Sokol:
This library seems interresting but has a problem: It is just Open GL, so rendering with it would be a pain and make implementing any object renderer a real pain
I see. However you need to go through the pain only once and it is certainly have advantages. From my experience with most native C/C++ graphics libs compiled for the web you get 90% performance drop due to poor optimization so if something runs at 60 FPS on desktop it runs at 6 FPS in the browser. At the moment I can’t find any easy native solution that both easy to code and also fast in the browser. Most engines put the HTML5 logo on their website “hay we support that too yey” but the engine is not actually optimised for web that is the problem.
Atm, Sokol seems to be the most performant solution.
Of course we can always pick a JS lib but I leave that discussion to you and others because I am not so much interested in that and there is so many. Sure the first thing everyone would mention is 3D, but I remember blurymind mentioned the dev of Pixi is looking in to bringing some level of 3D support to Pixi, so maybe it is better to wait for that instead of rushing and add a second 3D renderer. Not sure if the Pixi team started the development already or not but maybe worth checking that before start any work on bringing a 3D renderer in to GD without having any plans for a dedicated 3D level editor too.
The funny thing is however, if we really want to target desktop, mobile, web natively with a single code base, GD already support Cocos2D but don’t know why it was never received serious attention from 4ian beyond getting it up and running. Not sure what happened there, 4ian and Victor worked really hard to bring Cocos2D for us with the intention to target all platforms natively with a single code base but then the moment they got it up and running in the browser, Victor disappeared and 4ian choose to focus on Pixi and JS instead and now he seems to be more interested in WebAssembly but as of today I don’t know any easy to code solution that also fast in the browser.
The Cocos2d mention reminds me that I never could get a game to compile properly when I attempted. I’d love to see if some of the issues I’ve experienced with PixiJS went away with Cocos.
I’ve managed to get a more or less running platformer example. I struggled really hard butr I managed to have the scene bg clor working and the stage too but not the sprite rendering. Like when I jumped I could hear the jump sound, and when I moved whle jumping up to the enemies I could hear the enemy stomping sound, but the sprites were not visible.
