Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (723)
Games in Android Showcase (216)
games submitted by our members
Games in WIP (790)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  C++/Java Engine without GC in graphics  (Read 960 times)
0 Members and 1 Guest are viewing this topic.
Offline bullen

Junior Devvie


Medals: 4
Projects: 2



« Posted 2017-03-25 19:10:47 »

So I'm thinking about building this C++ engine, but I really don't like working in C++/C, so I'm thinking of having the core engine be C++ and then you script the game in Java very similar to Unity but with the rendering thread in C++. Has anything like this been done before.

Also do you know if there are many other small open source game engines like this one out there:

http://www.gameplay3d.io

Offline DrHalfway
« Reply #1 - Posted 2017-03-25 20:59:26 »

Use a language you are comfortable with. You won't gain any immediate advantage just because you use C/C++. There will be some hurdles and problems that you will need to solve.

Offline Cero
« Reply #2 - Posted 2017-03-26 17:08:27 »

Don't.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nsigma
« Reply #3 - Posted 2017-03-27 10:18:24 »

You won't gain any immediate advantage just because you use C/C++.

Well, you'll probably gain an immediate disadvantage!  Wink  Yes, well written C/C++ might outperform Java, but you've got to get there first - it's easy to write C/C++ that underperforms Java.

And GC is probably not as much of an issue as you think it is.

As for "script" in Java ...  Undecided

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 116
Projects: 15


★★★★★


« Reply #4 - Posted 2017-03-27 11:37:21 »

The issue of Java's GC overhead has been around for a long time, any stuttering in game is usually automatically blamed on it (even though it might be something else). However recently there was a really interesting draft JEP for adding an option in the JVM to turn it off (i.e. allocation only GC).

This could be particularly interesting option for games as it could be used to test if any lag is being caused by the GC or where your code does not produce any garbage.
Offline princec

« JGO Spiffy Duke »


Medals: 903
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2017-03-27 12:57:37 »

Well, I can halve my frame rate just by turning on G1GC... it does indeed still have noticeable irritating effects when you start really pushing things a bit.

Cas Smiley

Offline nsigma
« Reply #6 - Posted 2017-03-27 13:14:53 »

Well, I can halve my frame rate just by turning on G1GC...

Anyone can halve the rate of anything by turning on G1GC  persecutioncomplex   Grin

Seriously, I hope they improve things a lot by the time Java 9 is out the door.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline bullen

Junior Devvie


Medals: 4
Projects: 2



« Reply #7 - Posted 2017-03-31 20:30:27 »

Ok, so I figure I will make the rendering in C++ and only interact with it asynchronously from Java.

That way I can avoid the GC pause but still hot-deploy changes directly into the running engine saving alot of development time.

And I need the performance of C++ because I want to build a VR MMO.

I already have the collada to OpenGL skinned mesh C++ code almost done (it works with a perfect example animation, but not with a real human made animation because there are bones that are unused and such)...

So the usage would look something like:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
public class Meadow extends Game {
    Animal fox;
    public void load() {
        camera.distance(3f);
        fox = new Animal("model/fox.dae", "texture/fox.tga");
        scene.add(fox);
    }
    public void tick() {
        if(key.up() && fox.velocity().x == 0) {
            fox.velocity().x = 1;
        }
        if(!key.up() && fox.velocity().x != 0) {
            fox.velocity().x = 0;
        }
        camera.rotation(mouse.rotation());
        camera.position(fox.position());
    }
}


And the C++ thread would just render automatically.

So basically a very high level control game engine from the Java perspective.

I'll see where the physics will happen, probably in Java first, then I'll move it when/if it becomes too slow.

So atleast the system will use 3 cores since it will have 3 threads interacting asynchronously.

Java -> Physics -> Rendering

Pages: [1]
  ignore  |  Print  
 
 

 
buddyBro (188 views)
2017-04-05 03:38:00

CopyableCougar4 (618 views)
2017-03-24 15:39:42

theagentd (611 views)
2017-03-24 15:32:08

Rule (662 views)
2017-03-19 12:43:22

Rule (636 views)
2017-03-19 12:42:17

Rule (640 views)
2017-03-19 12:36:21

theagentd (652 views)
2017-03-16 05:07:07

theagentd (586 views)
2017-03-15 22:37:06

theagentd (426 views)
2017-03-15 22:32:18

theagentd (355 views)
2017-03-15 22:31:11
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!