Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (791)
Games in Android Showcase (234)
games submitted by our members
Games in WIP (864)
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 4345 times)
0 Members and 1 Guest are viewing this topic.
Offline bullen

Senior Devvie


Medals: 15
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: 123
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: 1085
Projects: 3
Exp: 20 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

Senior Devvie


Medals: 15
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 init() {
        fox = new Animal("model/fox.dae", "texture/fox.tga");
        scene.add(fox);
        camera.distance(3f);
        camera.position(fox);
        camera.rotation(mouse.rotation());
    }
    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;
        }
    }
}


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

Offline bullen

Senior Devvie


Medals: 15
Projects: 2



« Reply #8 - Posted 2019-03-19 11:02:28 »

Some progress has been made:

Click to Play

Offline VaTTeRGeR
« Reply #9 - Posted 2019-03-19 11:32:36 »

Looks good Smiley Has it paid off performance wise?

I wanna see some stress tests Grin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bullen

Senior Devvie


Medals: 15
Projects: 2



« Reply #10 - Posted 2019-03-19 13:39:12 »

Performance is just one reason.

More important are:

1) Portability: I realized that if you limit your Java code to the exposed C++ library; a equivalent of Unitys C#2CPP would be really trivial to make. This way you can hot-deploy code with Java during development (see 2) and then release binaries for all platforms without bloat.

2) GC and single threading: I'm still convinced that the biggest flaw in Unity is that the same thread that renders also executes the MonoBehaviours! You need an async. API between render thread and game scripting thread! I'm unsure how/if it will work but I'm going to try it in C++ first and then if it works well enough I'll add a Java server with a JNI interface for hot-deployment of game code which will allow <1 second turnaround even after the game is released with a lot of resources, at which point Unity becomes unusable.

So the point is not to avoid the GC stutter, but rather allow for a better programmer (and later content creator) workflow even after you add alot of content (code)!

Today we don't build games and then throw them away, we build games that last/are maintained/improved for decades... eventually we will build games/worlds that never die because peak Moore's law makes return on new hardware marginal!

Projects are more probable to fail because of technical debt and slow iteration times rather than obsolete technology.

Offline h.pernpeintner

JGO Ninja


Medals: 107



« Reply #11 - Posted 2019-03-20 15:11:14 »

Hmmm. I'm not sure I got all arguments here. And I'm not an advocate for using jvm for games (although I'm doing it exclusively myself), but I think you can get rid of all the negative things that were mentioned here.

* GC: You can make your engine garbeless. It's hard, it's easier with C++ because you can make and reuse your own heap, but it's doable. Lack of value types is an issue, but can be avoided with object pooling and/or excessive ByteBuffer usage.
* Hot reloading: There's a ton of mechanisms to load, compile, run code during runtime. Most certainly not with zero garbage, but I doubt it's toooooo important for example for a game editor. For runtime, all the assets can be compiled and packaged at build time.
* Portability: I don't think there's a big difference, but with C++ you need to cross compile, so it could be a disadvantage.
* Maybe totally personally biased, but weaving two platforms together is almost never a lot of fun, so staying either completely C++ or completely Java/JVM seems to be more fun and less overhead.

EDIT: I may not have the best implementation but my hobby engine (quite advanced) uses triple buffering for renderstate, where the state is mostly backed by either copyable objects or ByteBuffers... the renderer runs in its own loop completely independent, passes said ByteBuffers to OpenGL (or your favourite API) and never allocates anything. Of course only possible if you model you renderstate in a way that is mostly mutable/reusing memory.
Offline princec

« JGO Spiffy Duke »


Medals: 1085
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2019-03-20 15:40:20 »

What @h.pernpeintner said.

I see virtually no advantage to using C++ in games regarding performance because frankly I'm not at the level of being able to push a AAA-agenda graphics pipeline full o' graphics. At the level we're operating at, there is no noticeable difference in performance between C++ and Java but we don't half get stuff working a lot faster. GC is only an issue when you screw up in some spectacular way (haha, remember once upon a time how Java2D would create tons of contexts that had finalizers in that would eventually stop a game's main rendering loop while they got cleared...). Interfacing between C++ and Java is fraught with hassle and irritation and almost never pays off.


Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 

 
hadezbladez (2847 views)
2018-11-16 13:46:03

hadezbladez (1030 views)
2018-11-16 13:41:33

hadezbladez (2814 views)
2018-11-16 13:35:35

hadezbladez (553 views)
2018-11-16 13:32:03

EgonOlsen (3826 views)
2018-06-10 19:43:48

EgonOlsen (4241 views)
2018-06-10 19:43:44

EgonOlsen (2545 views)
2018-06-10 19:43:20

DesertCoockie (3357 views)
2018-05-13 18:23:11

nelsongames (3471 views)
2018-04-24 18:15:36

nelsongames (4470 views)
2018-04-24 18:14:32
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45
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!