Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (754)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
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  
  Prepper and handler thread rendering.  (Read 1210 times)
0 Members and 1 Guest are viewing this topic.
Offline lcass
« Posted 2013-11-30 18:46:29 »

I had an idea not long ago, whilst watching a lowely tv show. I sat at my desk and pondered a thought , a solution to a problem I sought.   ok poems over.

I sat down and was thinking of methods of optimising code on modern multicore computers specifically for rendering large amounts of objects such as that in an enaconadodecahedron . The idea I came up with was to create two threads , the first being the main game thread and the second being a "Handler" thread.

What would happen is the prepper thread would run through all render tasks that had to be performed and write them to an array that the Handler thread read. When the prepper had started it would tell the Handler to begin reading the array. When the prepper thread had finished it would wait for the Handler to complete its task or for further optimisation check how far the handler is and designate some tasks to the prepper thread. Of course this would require lots of careful coding to make sure both threads were in sync at the end and that the handler did skip infront of the prepper and not render stuff.
Offline ClickerMonkey

JGO Coder

Medals: 26
Exp: 10 years

Game Engineer

« Reply #1 - Posted 2013-12-02 13:34:36 »

(If I understand this correctly) this is something I do for my current game I'm working on.

I have a thread that's responsible for building a ByteBuffer for a chunk. That thread is responsible for determining face visibility, how lighting affects the faces, etc. Once the ByteBuffer is ready to be loaded to the VBO it's put on a queue which the main rendering thread reads every iteration.

So essentially my code is organized like this.

Main Thread
1. Rebuild chunks? Place on queue for Build Thread
2. Any built chunks? Take ByteBuffer and update appropriate VBO

Build Thread
1. Wait for chunk to build
2. Build chunk to ByteBuffers
3. Place ByteBuffers on queue for Main Thread

This only works nicely because the building part is done in such a way that it doesn't modify any game state information... AND if a chunk is being built while it's modified the building process for that chunk is restarted. For every block I do a simple check to see whether the chunk has changed since I started (just a simple volatile boolean flag).

Pages: [1]
  ignore  |  Print  

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

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

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

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

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

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

Solater (97 views)
2018-03-17 05:04:08

nelsongames (170 views)
2018-03-05 17:56:34

Gornova (388 views)
2018-03-02 22:15:33

buddyBro (1048 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

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 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‑
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!