Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (697)
Games in Android Showcase (202)
games submitted by our members
Games in WIP (767)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: 1 ... 3 4 [5] 6 7 ... 10
 on: 2016-10-26 10:49:07 
Started by SolidGold - Last post by Spasi
The design of GLFW requires that all event handling happens on the main thread. So a loop that looks like:

while ( !glfwWindowShouldClose(window) ) {

    // ...

should go on the main thread.

Rendering can happen on any thread, main or secondary. You can do rendering on a secondary thread by passing the window handle to that thread and calling glfwMakeContextCurrent(window). This makes the OpenGL context associated with that window current in the secondary thread. GL.createCapabilities() will work after that and you can use the LWJGL OpenGL bindings to do rendering.

 on: 2016-10-26 10:22:55 
Started by SolidGold - Last post by SolidGold
I feel as though I understand what a context is. I'm having trouble finding information on how to work with them if anyone can help my understanding or answer any of these questions.

I have a main window. From that main window I spawn a new thread. I *cannot* pass the context from the original window to the new thread?
Contexts *cannot* be altered by different threads? I feel like I've seen it stated as possible for newer versions?
So then I need a new context for the new thread, yes?

Can you say the conceptual steps I need to transition as I describe?
That is: same window, switch from main screen context to game context.
What I'm doing is: Main window, make new game *in another thread*, that game object is loaded as the game for the new game launch.
I want the main window to then have the context of the game. This approach would seem to dictate it being possible to use a context between threads?

My specific current problem:
java.lang.IllegalStateException: No GLCapabilities instance set for the current thread. Possible solutions:
   a) Call GL.createCapabilities() after making a context current in the current thread.
   b) Call GL.setCapabilities() if a GLCapabilities instance already exists for the current context.
   at org.lwjgl.opengl.GL.getCapabilities(
   at org.lwjgl.opengl.GL11.nglGenTextures(
   at org.lwjgl.opengl.GL11.glGenTextures(

I tried to import the original context. No go. So I tried to make a new context (same launch method as first window/context), that still returned this error. Made a different method for trying to properly do it and that still returned this same error.

I also tried various combinations of the following to no avail.
   //window = GLFW.glfwGetCurrentContext();

I learn best by seeing working examples, but I've not see any. Thank you for any help!

 on: 2016-10-26 08:14:46 
Started by purenickery - Last post by J0

These look absolutely stunning! (as always heheh)

About the 3D thing... it seems like a strange decision so late in dev Roll Eyes
Please be careful about 3D though, we don't want that to come ruin the rest of the game! For example, my opinion is that your walls look totally out of place in that first screenshot (I think this is due to the fact that they seem oriented differently than the rest of the image; the trees and character are nearly seen from the side, whilst the walls are seen from higher, nearly in a top-down view fashion)...

J0 Smiley

 on: 2016-10-26 07:53:48 
Started by BurntPizza - Last post by Jono
Started work on a logic engine for use in (my) games. I got the main design done and unification working.

Parser p = new Parser();
Term f1 = p.parseTerm("foo(X,b)");
Term f2 = p.parseTerm("foo(a,Y)");


and Prolog-style lists:
Term t1 = p.parseTerm("[Y,b,c]");
Term t2 = p.parseTerm("[a|[X|[c|[]]]]");


Next up are knowledge bases, rules and backtracking.

 on: 2016-10-26 07:05:08 
Started by SteveSmith - Last post by SteveSmith
It shouldn't be too hard to show each other, although (as I think you allude to) I can imagine players just following each other.

Regarding the maze complication, I think I just increased the seed that your function used, which I assumed made it harder.  However, there is also the function to check the maze is valid by counting the distance between the start and exit.  Making a harder maze would just be a case of recreating a maze if this number was too low.

 on: 2016-10-26 06:53:53 
Started by purenickery - Last post by purenickery
It's been a little while since I've posted, but I've been hard at work on the new 3d stuff (We decided to just go ahead and make the game 3d! xD)

So let's get right to it:

By default, all object rotate to face the camera wherever it may be, acting as billboards essentially. However, this doesn't work for a lot of objects in the game, such as walls that need to appear flat, so I made a new resource loader that can load in different formats of boxes. Here is what the main castle wall image looks like and how it looks in the game:

resource file


There is also an improved entity visualization system in the editor to better visualize 3d objects!

Click to Play

you might have already noticed I implemented a new shadow system that works just like the big boys do it, now things like this are possible:

Click to Play

And last big update is I got reflections working in the new 3d environment. Only things left to get working again are mouse-picking, UI elements, and lighting.

 on: 2016-10-26 01:56:27 
Started by theagentd - Last post by theagentd
Ooooook... So there doesn't actually seem to be a batch size at all. In other words, Nvidia doesn't process 96 indices per block, then clears the cache between each block. Basically, forget everything I've said so far. Here is the pattern I've found:

 - Nvidia's cache size is 32.

 - Writing is done from the first element in the cache to the last element in order.

 - If the cache misses caused by a triangle (0 to 3) would cause it to write beyond the end of the cache, the entire cache is cleared. All unique vertices become cache misses and are then placed as elements 0 to (unique_verts - 1) in the cleared cache.
        - Example 1: If the cache is full and all 3 vertices of the next triangle are in the cache, it will not reset the cache.
        - Example 2: If only one free element is left in the cache and a triangle with 2 misses is drawn, then the cache is reset, all 3 vertices become cache misses and are placed in the cache.
        - Example 3: If the cache is full, contains vertex 0 and the degenerate triangle (0, 0, 1) is drawn, then the cache is cleared, 0 and 1 become cache misses and are placed in the cache.

 - Cache entries that are not used by any triangle become invalid after 16 triangles (48 indices) after their last use.

 - All cache entries have a maximum lifetime of 32 triangles (96 indices) after they were originally placed in the cache, no matter how many times they are used within that time.

 - Note that when a cache entry becomes invalid, it is not possible to write a new vertex to it until the entire cache is reset due to overflow. The entries simply are not usable for matching anymore, making the cache effectively smaller until reset.

 - The lifetimes of the vertices in the cache is based on the number of vertices of the geometry being drawn. For points, the entries become invalid after 16 points (16 indices) after their most recent use, or 32 points (32 indices) after they were first used. For lines, it's 16/32 lines (32/64 indices). For triangles, it's 16/32 triangles (48/96 indices).


If you draw 100 identical degenerate (5, 5, 5) triangles, 5 will be placed in the first slot (slot 0) of the cache. After 32 triangles, slot 0 becomes invalid. For the 33rd triangle, slot 0 will be unusable and 5 will again be placed in the cache, this time in slot 1. After 32*32=1024 triangles, the entire cache has slowly been filled with 5s that have gone invalid, and the last slot finally becomes invalid. When the 1025th triangle is drawn, the entire cache is reset and 5 is placed in slot 0 again.

If you draw the triangle (0, 1, 2), then repeatedly draw (0, 0, 0) triangles, the entries for 1 and 2 will become invalid after only 16 triangles as they are not used. This 16-triangle counter is reset each time the vertex is reused in a triangle, but regardless of if they're used or not they will become invalid after 32 triangles. In other words, 1 and 2 become invalid by the 17th triangle, and 0 becomes invalid by the 32th triangle.

Following all these rules I seem to be able to exactly simulate the results of every single index list I've tested so far.

 on: 2016-10-26 00:30:32 
Started by theagentd - Last post by theagentd
This is a follow-up of this thread.

Now that my exam is over I've taken a bit of time to look into this stuff again.

I wrote a simple vertex cache emulator that when given an index list can compute the number of cache misses that would occur if the list was used to render something. It has tweakable cache and batch sizes, so it should work decently, minus possibly the weird results of old-ish AMD cards. However, when comparing the emulator against the number of cache misses reported by using pipeline statistics I noticed discrepancies, sometimes massive ones. I quickly narrowed it down to which older entry to overwrite when the cache is full.

I tried numerous methods:
  • A FIFO cache: the element that was ADDED the longest time ago to the cache was overwritten by the new index.
  • Last-use cache: the element that was USED the longest time ago to the cache was overwritten by the new index.
  • CPU cache-ish: the cache element to overwrite was indexed with (indexValue%cachesize).
  • CPU cache-ish 2: the cache element to overwrite was indexed with (indexElement%cachesize).

All of these systems were incorrect in some case. Hence I developed a small "algorithm" for checking which values were in the hardware cache:
1. Draw N triangles of 3 indices each and check how many cache misses occurs using pipeline statistics.
2. For each possible index I, draw the original N triangles plus the triangle (I, I, I) (same index 3 times). If the number of cache misses is the same, I was in the cache.

My GPU has a cache size of 32 entries. Drawing 10 triangles (30 vertices) with the indices (0, 1, 2, ..., 29) makes the cache results look like this:
GPU:      [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29]
Emulated: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, -1, -1]

What happens when we draw 11 triangles with 33 different indices in total?
GPU:      [30, 31, 32]
Emulated: [32, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]

Wow. So basically, if <number of cache misses in triangle (0 to 3)> is more than what would fit in the cache, the entire cache is cleared, then the new entries are inserted. It doesn't even f**king try to overwrite an old index. It just starts a new cache. Wow. Just wow.

EDIT: This just in: It DOES clear the vertex cache. If a vertex isn't touched for 16 triangles (48 indices), it is cleared from the cache. This is getting hard as hell to code.

 on: 2016-10-26 00:08:30 
Started by theagentd - Last post by theagentd
Hey, man, sorry about the late reply. I just finished my massive exam yesterday, so now I'm free to start looking into this stuff. I knew I would've gotten stuck messing with Artemis for a day if I dived into this discussion again. x___x

Thanks for the info everyone.

I'm currently looking into integrating Artemis into our threading system, allowing systems to update and run in parallel, with each system possibly running on multiple threads too (processing individual entities in parallel). I already have a fancy system for setting up dependencies between tasks, so by simply turning each system into a task it can be run in parallel. I bet you're probably screaming right now from thinking about all the things I'm about to break with my threading, but for now I really only want to process entities within a system in parallel.

It would be cool if we could possibly work together to write some clear threading rules/documentation, AKA which functions are thread safe and which aren't so that I can expand my threading integration. Also, so far the InvocationStrategy system is enough to provide all the features I need, except some dependencies between systems for synchronization. Still haven't actually tested anything yet.

 on: 2016-10-25 22:12:13 
Started by HenBagel - Last post by ndnwarrior15
Crashing this gameā€¦ WITH NO SURVIVORS!!!

Nooo! They expect one of us in the wreckage brother.

Pages: 1 ... 3 4 [5] 6 7 ... 10
theagentd (32 views)
2016-10-24 17:51:53

theagentd (30 views)
2016-10-24 17:50:08

theagentd (30 views)
2016-10-24 17:43:15

CommanderKeith (50 views)
2016-10-22 15:22:05

Roquen (52 views)
2016-10-22 01:57:43

Roquen (61 views)
2016-10-17 12:09:13

Roquen (60 views)
2016-10-17 12:07:20

Icecore (78 views)
2016-10-15 19:51:22

theagentd (342 views)
2016-10-04 17:29:37

theagentd (346 views)
2016-10-04 17:27:27
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 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!