Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (769)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (855)
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  
  Possible to manually "start X" instead of -XstartOnFirstThread?  (Read 2915 times)
0 Members and 1 Guest are viewing this topic.
Offline theagentd
« Posted 2016-08-22 22:37:37 »

Hello.

I've made this fancy-schmancy GLFW event handling system with LWJGL 3 that dedicates a thread to input processing while respecting all the threading limitations of GLFW (trust me, that was hard). I'd fire up a new thread and dedicate it to GLFW commands so that rendering/updating doesn't affect the responsiveness of the window or input event recording precision. However, when running this code on Mac it's broken since I need to use the -XstartOnFirstThread VM command... which breaks everything since I want to "start X" (whatever that means) on different thread than the main thread: the dedicated GLFW thread. This leads to the extremely awkward position where I need to do everything backwards, and dedicate the main thread to GLFW and transfer control of the entire game to a new thread instead. This is intrusive as f**k, reduces readability and has already caused hard-to-find bugs for us.

Is there any way of manually doing the equivalent of -XstartOnFirstThread but on a thread of our choosing?

Myomyomyo.
Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #1 - Posted 2016-08-22 23:51:21 »

It's Apple (specifically, the Cocoa API developers/designers) being a special snowflake, and AFAIK there's nothing you can do about it.

Same problem occurs no matter what language you use. It's just that most (native) languages don't start on a new thread by default, so single-threaded applications aren't affected.

Offline Ecumene

JGO Kernel


Medals: 197
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #2 - Posted 2016-08-23 00:07:35 »

Why not move the GLFW stuff to start on the main thread, and the game run on a separate thread? ( That may take a ludicrous amount of time, depending on the game )

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #3 - Posted 2016-08-23 01:22:58 »

Why not move the GLFW stuff to start on the main thread, and the game run on a separate thread? ( That may take a ludicrous amount of time, depending on the game )
That's exactly what I'm doing right now, but it's ugly. Forcing the user to move the entire game to a new thread and doing some seemingly arbitrary unintuitive calls is what I'm trying to avoid. The cleanest solution of this kind is to abstract the entire thing away and have the player give a "game interface" to an engine, which handles the thread hand-over. I don't want to force the user to do this shit, and I don't want to surprise them 6 months into development with having to do hacky shit like this to make it work on Apple.

I had a long chat session with Spasi over Skype, and got some more info on why this is required on Mac and how to work around it. The "cleanest" solution for the user is to create a small native C program which fires up a JVM using the Invocation API. It'd create a new thread for the application and call the application's main() method, then start the GLFW event handling loop on the main thread. The Java code then just needs to realize that the event handling thread will be created externally.

I'd prefer this solution in the long run since I'd rather require a hack for getting the engine to run on Mac than have the user manually work around limitations of Mac to get anything at all to run.

Myomyomyo.
Offline nsigma
« Reply #4 - Posted 2016-08-23 09:23:01 »

Just to make this clearer, or to be a complete pedant  Grin

This has nothing to do with anything called "X".  -X just means this is a non-standard option for the JVM.

http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline theagentd
« Reply #5 - Posted 2016-08-23 12:05:02 »

Yeah, I realized that from Spasi's explanation. It just forces the entire VM to start on the first thread of the process, which due to Mac's stupid limitations is the only thread that can do UI stuff. Usually it'd dedicate the first thread to AWT/Swing just for this purpose. It's just stupid.

Myomyomyo.
Pages: [1]
  ignore  |  Print  
 
 

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

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

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

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

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

nelsongames (1705 views)
2018-04-24 18:14:32

ivj94 (2513 views)
2018-03-24 14:47:39

ivj94 (1730 views)
2018-03-24 14:46:31

ivj94 (2811 views)
2018-03-24 14:43:53

Solater (951 views)
2018-03-17 05:04:08
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

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
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!