Open source game engines suited for the Pyra?

[Urben]

Hi,


I'm getting into game development and also want to try around with on the Pyra once it comes out.


Which game engines work for it? I messed around with C++, C and C# but had no bigger projects yet. So no preffered language.


I'm currently aiming for Monogame (made from XNA) since its open source, has some (sadly not much) documentation and games are easily portable to other systems.


I'm also absolutely fine with using frameworks instead of full-sized engines like Unity, sicne I'm familiar with them. I just need some documentations how to work with it.


Any recommendations? Thanks!


(For future devs I will edit this posting to make a list, tell me if something is wrong)

• Monogame: c# framework, portable to multiple systems
  
• Simple DirectMedia Layer (SDL) 1.2 and 2.0 - Middleware
  
• Allegro: C & C++ 2D engine
  
• Irrlicht: C++ 3D engine
  
• Godot: 2D & 3D engine with a simple, own scriptlanguage. (Pandora port)
  
• JNGL: C++ 2D Engine, https://github.com/jhasse/jngl
  

 

[pmprog]

Yeah, monogame isn't so much as an engine, more of a framework. SDL 1.2 and 2.0 will undoubtly be available. I'm also hoping that Allegro v5 and Irrlicht (for 3D) will both be available, as those are the two that I generally consider when developing

 

[TrashyMG]

Yeah, monogame isn't so much as an engine, more of a framework. SDL 1.2 and 2.0 will undoubtly be available. I'm also hoping that Allegro v5 and Irrlicht (for 3D) will both be available, as those are the two that I generally consider when developing

Looks Good:

Spoiler

trashy@trashypyra:~$ sudo apt-cache search allegro
sudo: unable to resolve host trashypyra.twisted-schwartz.com
[sudo] password for trashy: 
allegro4-doc - documentation for the Allegro library
liballeggl4-dev - development files for the allegrogl library
liballeggl4.4 - library to mix OpenGL graphics with Allegro routines
liballegro4-dev - development files for the Allegro library
liballegro4.4 - portable library for cross-platform game and multimedia development
libjpgalleg4-dev - development files for the JPG loading addon for Allegro 4
libjpgalleg4.4 - JPG loading addon for Allegro 4
libloadpng4-dev - development files for the PNG loading addon for Allegro 4
libloadpng4.4 - PNG loading addon for Allegro 4
liblogg4-dev - development files for the OGG loading addon for Allegro 4
liblogg4.4 - OGG loading addon for Allegro 4
allegro5-doc - documentation for the Allegro 5 library
liballegro-acodec5-dev - header files for the Allegro 5 audio codec addon
liballegro-acodec5.0 - audio codec addon for the Allegro 5 library
liballegro-audio5-dev - header files for the Allegro 5 audio addon
liballegro-audio5.0 - audio addon for the Allegro 5 library
liballegro-dialog5-dev - header files for the Allegro 5 dialog addon
liballegro-dialog5.0 - dialog addon for the Allegro 5 library
liballegro-image5-dev - header files for the Allegro 5 image addon
liballegro-image5.0 - image addon for the Allegro 5 library
liballegro-physfs5-dev - header files for the Allegro 5 physfs addon
liballegro-physfs5.0 - physfs addon for the Allegro 5 library
liballegro-ttf5-dev - header files for the Allegro 5 TTF addon
liballegro-ttf5.0 - TTF addon for the Allegro 5 library
liballegro5-dev - development files for the Allegro 5 library
liballegro5.0 - portable library for cross-platform game and multimedia development
aseprite - sprite and pixel art editor
cl-closer-mop - Cross Implementation AMOP library
cl-launch - uniform frontend to running Common Lisp code from the shell
cl-modlisp - Common Lisp interface to the Apache mod-lisp module
cl-acl-compat - Compatibility layer for Allegro Common Lisp
cl-aserve - Portable Aserve
cl-postoffice - SMTP, POP, & IMAP interface library for Common Lisp Programs
cl-sql-aodbc - CLSQL database backend, AODBC
cl-sql-tests - Testing suite for CLSQL
cl-trivial-backtrace - generate a Common Lisp backtrace portably
cl-uffi - Universal Foreign Function Library for Common Lisp
libguichan-0.8.1-1 - small, efficient C++ GUI library
libguichan-0.8.1-1-dbg - small, efficient C++ GUI library (debugging symbols)
libguichan-allegro-0.8.1-1 - small, efficient C++ GUI library (allegro integration)
libguichan-dev - small, efficient C++ GUI library (development headers)
libguichan-opengl-0.8.1-1 - small, efficient C++ GUI library (OpenGL integration)
libguichan-sdl-0.8.1-1 - small, efficient C++ GUI library (SDL integration)
ilisp - Emacs interface to LISP implementations
libaldmb1 - dynamic universal music bibliotheque, Allegro version
libdumb1 - dynamic universal music bibliotheque
libopenlayer-dev - hardware accelerated 2D Graphics library : development files
libopenlayer2 - hardware accelerated 2D Graphics library
libportsmf-dev - Portable Standard Midi File Library (development files)
libportsmf0 - Portable Standard Midi File Library
cl-quicklisp - library manager for Common Lisp
trashy@trashypyra:~$ sudo apt-cache search irrlicht
sudo: unable to resolve host trashypyra.twisted-schwartz.com
libirrlicht-dev - High performance realtime 3D engine development library
libirrlicht-doc - High performance realtime 3D engine (API documentation)
libirrlicht1.8 - High performance realtime 3D engine
libirrlicht1.8-dbg - debugging symbols for irrlicht

 

[fusion_power]

Is Unity open source? It's usualy the first "cross platform" engine that comes in my mind when I think onto powerful engines suited for mobile usage.

 

[pmprog]

Is Unity open source? It's usualy the first "cross platform" engine that comes in my mind when I think onto powerful engines suited for mobile usage.

No, it's not.

 

[MrJustreborn]

I think Godot is one of the best OpenSource Engines, and it has a port for the Pandora.

 

[kojack]

Don't forget Ogre3D (open source graphics engine).
It's on a bunch of ARM platforms, has GLES/GLES2 and should be able to run on the Pyra.

(I may be biased, I'm an admin of the Ogre3D forum and I use it in my teaching job)

 

[ptitSeb]

Don't forget Ogre3D (open source graphics engine).
It's on a bunch of ARM platforms, has GLES/GLES2 and should be able to run on the Pyra.

(I may be biased, I'm an admin of the Ogre3D forum and I use it in my teaching job)

I'm sorry, but I have some difficulties with Ogre3D on Arm/GLES(2). Do you have some opensource game that work on this configuration so I can try build and run something with it ?

 

[Kev2442]

Hey guys, sorry to bring this topic back but I didn't want to add another topic to the boards. And of course it's about 3D development.

First, I'd like to know what you guys have to say about the following engines : Torque3D, Godot and Urho3D. Godot has been ported on Pandora, how does it perform ?
Is one better than the other regarding optimization, 3D capabilities, ease of use... ?

Second, what can we do with the 2D BitBLT ? Is this capable of managing GUI rendering or generating mipmaps or whatever ? Is this a real 2D GPU or just a dedicated functions accelerator ?
Can we harness the computing power of the NEON, IVA-HD and Cortex-M4 coprocessors ? Can we access the framebuffer ? If so, when ?
Is there anything else I forgot which could help gather some power ?

 

[ibisum]

MOAI will definitely be ported, I'll do it myself .. and there are a ton of good commercial games done in MOAI ..

 

[slaeshjag]

Hey guys, sorry to bring this topic back but I didn't want to add another topic to the boards. And of course it's about 3D development.

First, I'd like to know what you guys have to say about the following engines : Torque3D, Godot and Urho3D. Godot has been ported on Pandora, how does it perform ?
Is one better than the other regarding optimization, 3D capabilities, ease of use... ?

Second, what can we do with the 2D BitBLT ? Is this capable of managing GUI rendering or generating mipmaps or whatever ? Is this a real 2D GPU or just a dedicated functions accelerator ?
Can we harness the computing power of the NEON, IVA-HD and Cortex-M4 coprocessors ? Can we access the framebuffer ? If so, when ?
Is there anything else I forgot which could help gather some power ?

The BitBLT can do some basic blitting and format conversions. Think of the rendering capabilities of a stock SDL 1.2 and you'll be in the right ball-park feature wise. There's information online to read up on about it. It currently lacks drivers in the Pyra kernel.
NEON is an instruction set on the main CPU cores. Its there if anyone tries to do anything with it.
The Cortex-M4 cores have the computational power of the average potato, they're not something you accelerate anything with. You can't access these yet with the pyra kernel.

 

[Kev2442]

Thanks torpor, but I was thinking about 3D engines. I forgot those three also did 2D.

AFAIK, 3D gaming is about using as much power as you can get. I was hoping that the M4s could offload the CPU on basic calculations. Maybe inputs or such could free some operations/second for the CPU to use on physics or AI, etc.
After all, if games like Gran Turismo 2 have been made with a 33 MHz CPU, I guess you can still put these to use in some way.

So the BitBLT seems to be capable of managing 2D stuff along with a bit of 3D. Good.

 

[slaeshjag]

Not really, the BitBLT is lacking any kind polygon draw afaik.
The M2's are not trivial to interface from a userspace program, and moreso difficult to access any kind of userspace from the M4s. Per cycle they are many times slower than the main CPU cores. Using them to "save a few cycles on the main cores" is not worth the hassle, and may even slow things down due to the complicated synchronization.

 

[Kev2442]

So we'd better put as much of the OS as we can on them, to free the A15s for more needy and time-based apps.

By the way, I forgot the Atomic Game Engine in the trio. Is it much better/worse than Urho3D ? Any idea of the best 3D engine for the Pyra ?

 

[slaeshjag]

No. You don't get it.

I'm not going to bother explaining this any further.
Only the main two cores are viable to run anything on at all. The 3D GPU is what pretty much everything will use for graphics acceleration, whenever that works.
Anything else is not worth the hassle unless a really specific usecase shows up (read: probably never).

The M4's are not fully features cores and can not run the same stuff as the main ones, and are more or less sticky-taped on top of the physical memory bus. I doubt anything will be able to use them for something worthwhile.

 

[Kev2442]

Oh. Okay then.
Sorry for the trouble, but I thought we could do something with them instead of simply leave then on idle in the background.

I was thinking about outputting the PowerVR framebuffer to the BitBLT to add 2D effects and GUI before screen rendering. Maybe a slight blur as a basic form of AA would be worth the added render time and complex implementation. What do you guys think ?

 

[rohezal]

Unreal 4 is open source, not sure what kind of open  gl es version it needs.

 

[ekianjo]

LOVE is a good option as well. 

 

[Letalis Sonus]

Unreal 4 is open source

It is NOT open source, it isn't even publicly accessible - access is still strictly regulated by Epic Games, they need to explicitly grant you the right to access the code. The code itself isn't using an open source license, either, you have to follow their rather strict EULA. For example, you can only share (modified) engine code with others who have been granted access to the code.

 

[Jan-Nik]

I'm using my own library which is zlib licensed and I plan to port it the Pyra as soon as I get it.

Maybe someone is interested:

• JNGL: C++ 2D Engine, https://github.com/jhasse/jngl