Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (702)
Games in Android Showcase (203)
games submitted by our members
Games in WIP (774)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 119
1  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Assimp bindings on: 2016-11-30 20:27:09
@Elect: I'm not trying to discourage you when it comes to jAssimp; I'm just saying that I don't think the benefits (no native code, smaller file size) outweighs the drawbacks (porting effort, maintenance as new features come out, etc).

I will be evaluating Assimp and jAssimp at some point decently soon, presumably mid-end January next year. I'm completely drowned in school work ATM and my exams are in January, but once they're done I'm gonna try to sit down and look through the documentation and get some simple stuff working. I'm fairly sure that jAssimp will be easier to use than the huge amount of interaction with native code and data that the Assimp binding will need, so I may try jAssimp first. However, do realize that if we were to adopt jAssimp for our modeling importing we'd need pretty speedy bug fixes and possibly feature requests (not likely though).

I really don't envy your project, man. 3D modeling formats are a frigging nightmare. That's why I'm worried about how long you'll be able to "last" after a couple of months of debugging why the that FBX file doesn't look like the spec says it should look, or that .blend file is completely different when a new version of Blender comes out, or why the hell you have to implement an entire programming language parser to decode a .x 3D model file. It's nothing about you personally; I just know that *I* wouldn't be able to do that for long. >___> If you seem to be able to handle it and maintain it, jAssimp would be my first choice.
2  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Assimp bindings on: 2016-11-30 19:15:42
A rant worthy of a medal.

As for the Java vs native discussion - there is no such thing as time "wasted" on a Java implementation. I like things being in Java because they're easy to debug, easy to build, easy to maintain, easy to fix, easy to steal bits of code from. Native code adds a thick layer of impedance over all of that. And native code is pretty frequently fraught with the exact sorts of bugs that we switched to Java to avoid in the first place.

Cas Smiley

Thanks. =P

That's a good point, and I agree with that opinion 100%. However, in this case we're talking about replicating existing functionality in Java. I'm assuming that Assimp has its fair number of users already, so most bugs should be fixed by now. Manually converting the whole thing to Java would just add an extra layer of possible bugs on top of the original code, and cause my engine to rely on even more people that I have no real influence over. I see no real benefit in this situation from a Java version of jAssimp.
3  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Assimp bindings on: 2016-11-30 18:46:49
You are clearly not the target, theagenttd
Do you mean Assimp or jAssimp?

Assimp itself is perfect for my use. My problem has always been that 3D model formats contain way too much useless information that I have to sift through, and all the actually useful information is in a wrong format and extremely hard to decode unless your engine/tool uses the exact same data/object structures as the 3D model format assumes.

Example: I don't want to have 30 different light types (or any lights at all), crazy quaternion interpolation b├ęzier parameters, complete scene graphs with interleaved mesh "nodes" and skeleton "nodes" and texture "nodes" with 637 different matrices in each node used for different purposes with no clear explanation for what does what, support for four different animation systems, baked in textures in the model file, and even more shit. I just want a number of meshes grouped by material (1 mesh per material), simple key framed skeleton animation support and that's it.

Unless you've written a rendering system on the level of Blender or Maya or something like that, 75% of all 3D file formats are so much overkill and/or stores the data in a completely different much more complicated way that it'll make you cry yourself to sleep for months after trying (and failing) to implement them (assuming implementing the rendering system itself didn't already break you), and such a rendering system would perform so badly for a game that it'd be completely useless. The other 25% of 3D formats don't support skeleton animation and are useless to me.

Since all 3D model formats are overkill and/or not immediately compatible with my rendering systems, I need to do a lot of conversion. This means implementing a crapload of very complicated functionality: Flattening a scene graph and merging mesh nodes based on material but not the ones that are separately animated, make up material names, figuring out how this particular model format f**ked up bone matrices, bone-vertex mappings, bone indices, etc, baking the IK-joints into the normal joints, implementing advanced joint/quaternion interpolation that exactly matches whatever the program used to generate the file format uses, etc. This takes months if not years to implement for a complete model format, and it's slow as f**k to do every time you import something. If you are ever planning on releasing anything to the general public, you NEED to use a custom file format that only contains what you need in the right format already, or you're looking at several minutes of load times for each level.

Nobody has unlimited time or money, no matter what their goal is. This is not something that will improve my games if I do it "right". I just want something that works (as in does everything I need it to do) with the minimal amount of work invested by me. Investing more time isn't gonna make my games better. Currently, my by far simplest solution was to skip working with existing 3D model formats completely and just writing a Blender plugin that extracts what I need and generates a file in my custom model format. It took me around 2 weeks to get the essentials working.

My worry here is that if Assimp can support all of these completely crazy Blender, Maya and Autodesk that you can fit the entirety of the Toy Story 1-53 movies, their PC games, console ports of said games, music files, autographs and dinosaur fossil discoveries since the medieval ages in them, then Assimp must support essentially everything that every single model format has ever supported. This would essentially mean that Assimp's internal objects are by far the hardest thing ever to port to your own minimal custom format. If I need a team of 10 people and 2 years to extract 5 pieces of information from it, then it doesn't actually solve any real problems. In the end, all you need is a single solid workflow from one 3D modeling software to your game, and everything else can be funneled through that path.

In light of all this, I can not agree that jAssimp is significantly more useful than Assimp in any regard. On Android, the performance/memory usage/load time argument is 10x more important so a custom file format is even more required. This means that (j)Assimp's only real usage is in engine tools/editors running on beefy PCs used to export stuff into your own custom formats, at which point the convenience of having a pure Java implementation is far outweighed by having an automatically generated binding to a maintained project with no manual work/maintenance.

EDIT: Please be aware that this is my opinion from an indie game developer perspective. If you are just making a small game for fun where you just want to be able to throw in whatever 3D model format you have lying around........ you'll still be doing 99% of the job of writing your own custom format. No matter what you use, you will be taking the data returned by (j)Assimp when it loads the file and extract the stuff you need into your own custom Model object that you can actually render. From there on, it's a very small step to add binary serialization so you can save that Model object to disk and load it directly again.
4  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Assimp bindings on: 2016-11-30 16:40:54
Assimp is slow. Converting the same thing to Java is still slow. If you're loading random file formats into your final game build, you're doing it wrong. Just convert your models to your own internal format and load those instead. Much much faster, no unnecessary data, no library asset --> game asset converting overhead, etc. IMO, we don't need a pure Java implementation of an offline tool.
5  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Assimp bindings on: 2016-11-28 21:15:28
Looks nice, but forgive my skepticism... 3D models are a nightmare. I'm worried that writing a converter to my own format will essentially be the same amount of work as writing an importer for one of the big formats, like .blend, .fbx or something. That's impossible enough to do for one format, but I'll look into it when I have the time, AKA not soon. =/
6  Game Development / Newbie & Debugging Questions / Re: Updating VBO bogging down system on: 2016-11-21 04:39:34
How much data are we talking about here?
7  Game Development / Newbie & Debugging Questions / Re: Starcraft 2 Map and Path Finder. on: 2016-11-20 21:22:29
Hmm. I guess they could be using a 2D navmesh. Usually navmeshes are used to solving more complicated problems. Most games have simple heightmap based terrain which fits very well with grid-based pathfinding. Navmeshes are mostly useful when solving much more complicated problems, where you could be having multiple layers/floors that overlap, or need to pathfind in 3D environment in general. My intuition tells me that there's no way SC2 uses it, but I guess it is possible.

Again, what SC2 uses for finding the path from point A to B is really not that important. The overall approach/algorithm is the same; the rest is just changing the data or optimizing performance. Examples: grid vs navmesh, A* vs Dijkstra's, hierarchical pathfinding, etc. You shouldn't be aiming to copy SC2, but rather to code the pathfinder that you need. In most cases a simple Dijkstra's/breadth-first-search is good enough. A* is just an optimization. If you have extremely long paths, hierarchical pathfinding can improve performance a lot.

The actual complexity and problem that SC2 solved in a new way was keeping the units grouped together as they follow their paths. This really has nothing to do with HOW you calculate the path. It's simply a different AI for following the path while maintaining formation.
8  Game Development / Newbie & Debugging Questions / Re: Starcraft 2 Map and Path Finder. on: 2016-11-20 03:56:22
They do NOT use a navmesh. That would make zero sense in a game with 2D gameplay (everything is technically confined to a 2D heightmap after all).

The article has a few dead image links, but it's still correct. Basically, they use a modified version of pathfinding that helps with flocking. If you remember SC1, you'll remember how it was impractical to send units on long trips, because after pathfinding around a couple of corners your massive zergling rush would now be a long line of zerglings walking into the enemy base one by one and getting picked off easily. This is due to each zergling pathfinding independently, bumping into each other and then forming a line as they pretty much all have identical paths and need to wait for each other after a couple of corners. SC2 solved this by adding flocking behaviour to the pathfinding, so that the units maintain their "formation" as they follow their paths. This prevents a line of units from forming. How they actually find paths is not really a big deal. The simplest solution, A* on a grid, will be more than good enough for you.
9  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-11-17 16:18:22
More texturing.

10  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-11-17 03:59:20
Terrain shenanigans.

Simple linear texture blending. Looks blurry as hell.

Advanced heightmap blending. Note how the grass fills in the cracks as it fades in instead of being blended in.

Automatic PN-triangle tessellation. Notice how nice and round the edges look instead of the obvious sharp edges from before.
11  Game Development / Newbie & Debugging Questions / Re: LWJGL GL30.glGenVertexArrays() returns duplicate ids on: 2016-11-09 13:42:09
Did you read my first post? You are using a shared OpenGL context (SharedDrawable) to load things on a background thread. Then you use things in the main thread later. The problem is that not everything is shared between contexts. The rule of thumb is that things that contain data (textures, buffers, samplers, renderbuffers, queries) are shared, but things that contain references to other objects (framebuffer objects, VAOs, a couple of others) are NOT shared. This means that although the data objects you've loaded in the background are shared (VBOs, textures) are visible to the main context, the VAOs and FBOs you use to actually read and write to them are NOT visible.

In other words:
 - If you create a buffer on the background thread with ID 1, that exact same buffer can be used on the main thread as well.
 - If you create a VAO on the background thread with ID 1, it is NOT shared with the main thread. If the main thread then creates its own VAOs, it is free to return ID 1 "again", because ID 1 refers to two different VAOs depending on the OpenGL context.

The solution is to load your buffers and textures on the background thread, create VAOs and FBOs on the main thread afterwards.
12  Game Development / Newbie & Debugging Questions / Re: LWJGL GL30.glGenVertexArrays() returns duplicate ids on: 2016-11-09 12:47:42
glGenVertexArrays(IntBuffer) fills the given buffer with new VAO IDs. If your buffer can fit 5 values, glGenVertexArrays(IntBuffer) will create 5 VAOs for you.

The point of this is to improve performance. If you're creating thousands of VAOs you can avoid an expensive JNI call and involving the driver for each and every one of those VAOs, but in reality there is a VERY minor difference in performance. Since it increases the complexity of your code a lot, it is much easier to use the simplified
int glGenVertexArrays()
method that returns a single new VAO as an int directly.
13  Java Game APIs & Engines / Java 2D / Re: Anything new on vsync in window mode? on: 2016-11-05 22:25:48
Chill, it's a good question.

As far as I know, If you use BufferStrategy you'll get V-sync enabled if it's available. There's no explicit control for it AFAIK.
14  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-03 12:24:44
Argh, I suck at this typing thing. xD

If you're missing V1, you can just set L1 to L2 for example.

EDIT: Also, I strongly STRONGLY recommend JOML. JOML is the best thing that has happened to Java game development in a decent time. It's fast, KaiHH that develops it is super responsive and helpful if you're missing some feature, it generates zero garbage when used correctly and has pretty much anything that you could ever ask for. However, in this case you're probably better off just using raw floats as the vectors are kinda unnecessary in this case.
15  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-03 12:11:17
That looks 100% correct! Good job! I'm glad you got it working.

Note that there are a couple of special cases you should be aware of.

 - As the angle between L1 and L2 gets smaller, x tends to infinity. This makes sense if you want a pointy end to the line (as is the case for your box rendering), but it may not always give the best result. In essence, it can cause the line to be drawn as much longer than it really is, which could be problematic.
 - Since you need four points in total draw a single line between the middle two points, it can become difficult to draw line strips where the first and last lines are missing one neighbor. In this case, you can either introduce a special case or generate the missing points from the ones you have.

Here is some more information:

 - Since you have 100% control of the vertices, it actually becomes possible to pick a line width per vertex. This allows you to draw continuous lines with varying thickness, which can look really nice.
 - Again, since you're emulating lines with triangles, there are no limit to the line width. Usually it's limited to between 1 and 16 or something like that.
 - This system does not work with line smoothing.
 - You can however use both MSAA and shader-based anti-aliasing to achieve extremely high-quality anti-aliasing.
 - Although the line width can be under 1 pixel, doing so will cause bad aliasing. It's a good idea to clamp the line width to 1 pixel and instead reduce the alpha of thin lines. Example: line width is 0.5 ---> make line width 1.0 and multiply alpha by 0.5.
16  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-02 14:31:14
Assuming you're using JOML, your vector math code is completely broken. add(), scale(), normalize(), subtract(), etc all modify the current object; they don't return a new object.

Here are a few of the problems your code has:
 - On line 10, you take V1, subtract V2 from it, then normalize it. In other words, L1 and V1 are the same objects, and you've permanently modified V1 so that the computation on line 8 will be wrong.
- On line 15, G1 is ALSO the same object as V1. rotate90Degrees() actually does return a new vector, but L1 still gets L2 added to it and is normalized permanently.
 - On line 40, you're again modifying V1 like crazy.

Honestly, this kind of math is so simple that it doesn't really warrant using vector classes to accomplish it. I'd recommend you start with something simpler: A function for drawing a single line given four points (V1 to V4). It should only draw a single line between the V2 and V3, but needs V1 and V4 to get the ends of the line right. Using such a function, you can easily draw a box by just calling it 4 times for each side.
17  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-02 09:44:41
I use Fraps personally. You can also easily implement this in code using glReadPixels(). glReadPixels() reads pixels from the currently bound framebuffer (or the window's backbuffer if you have no FBO bound). Just read pixels back to a ByteBuffer, copy the result to a BufferedImage, write it out using ImageIO.
18  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-02 07:14:17
At least show a screenshot so we can see what happens.
19  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-01 15:32:49
Two reasons:

1. You probably already know this, but dot(A, B) = |A|*|B|*cos(angle between A and B). If we normalize A and B, |A| and |B| will both become 1.0, so we end up with just cos(angle), which is what we need in point 4.

2. When calculating the direction of G1 and G2, we essentially add two line directions together and normalize the result to get the "average" direction. If the two vectors aren't normalized, the result will be skewed by the length of the two lines. If we have that L1 = (1 000 000, 0) and L2 = (0, 1), we want the result to still be exactly inbetween the two lines (0.707, 0.707). However, normalizing (1 000 000 + 0, 0 + 1) without normalizing the inputs first will massively skew the results as L1 is so much longer, so the result is something like (0.9999..., 0.0000...). This would in turn screw up the calculation for x and y because of the assumptions there.
20  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-01 15:02:18
Good luck!
21  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-01 10:05:53
Sorry, was stupid of me to write "B1=" and "B2=". I've modified the original post again.

As you can see on the image, there are 4 points we're interested in. They are located at the intersection points of the red lines, and also intersecting the green lines (G1 and G2). The two points that are on G1 are generated by taking V2 and moving in both directions along G1 a certain distance, which is where the +- comes from.

Sorry about that; I hope this clarifies it.
22  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-01 08:10:24
Concerning the L1-L4 lines: Yes, copy paste error. I've edited my original post.

Concerning B1 and B2: No, you construct 4 vertices due to the +- there. One of B1 is V2 - G1*lineWidth/2*x and one is V2 + G1*lineWidth/2*x.

Yes, all values listed except lineWidth, x and y are vectors here.
23  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-01 05:29:21
You basically draw lines using triangles to accomplish this. A line is defined by two points and a line width, which in turn forms a quad. To get the result I did, you need extra information. The shape of a line's corners depends not just on the line itself, but also on the previous and next lines that we're connecting it to.

So, given four input 2D vertex positions (V1-V4) and a line width, we need to do the following:

1. Calculate the normalized vectors of each line: L1 = normalize(V2-V1), L2 = normalize(V3-V2), L3 = normalize(V4-V3).

2. We then calculate the directions of the green lines. This is done by normalizing the average of two line directions and rotating it 90 degrees (= calculate the normal of a line): G1 = rotate90Degrees(normalize(L1+L2)), G2 = rotate90Degrees(normalize(L2+L3)). rotate90Degrees() takes in (x, y) and returns (-y, x).

3. We now know that the four blue dots we're looking for are equal to
B1 and B2 = V2 +- G1*lineWidth/2 * x
B3 and B4 = V3 +- G2*lineWidth/2 * y

If we set x and y to 1.0, the system works for straight lines, but as the angles at V2 and V3 get smaller we'll get thinner and thinner lines, so we need to compensate for that. Let's imagine some cases and try to come up with how x (and y) should be calculate:
 - If L2 just continues in the exact same direction as L1 (180 degree angle), no compensation is necessary in that case. In this case we want x to be equal to 1.0.
 - If L1 and L2 form a 90 degree corner, it's clear that the green line needs to cover the hypothenuse of a right triangle. Given two sides of 1 and 1, the hypothenuse becomes sqrt(2), so in this case we want x=sqrt(2).
 - As the angle between L1 and L2 goes towards 0, the green lines become more and more aligned with the red lines, so the compensation will tend to infinity in this case. Hence, it makes sense that a division by 0 occurs.

Let's try x = 1 / (dot(L1, L2)*0.5+0.5). If the two vectors are going in the same direction, the result is 1/(1.0*0.5+0.5) = 1.0 as it should. For a 0 angle, the dot product is -1: 1/(-1*0.5+0.5) = 1/0, again as it should. However, for a 90 degree angle, the dot product is zero: 1/(0*0.5+0.5) = 1/0.5 = 2, which is wrong. We need to pass the divider through sqrt(), which results in:

4. Calculate x = 1 / sqrt(dot(L1, L2)*0.5+0.5) and y = 1 / sqrt(dot(L2, L3)*0.5+0.5).

5. At this point, we have everything we need to calculate the four blue points using the formulas in 3. These four points are then used to construct two triangles that form a quad.
24  Game Development / Newbie & Debugging Questions / Re: Polygon corners with GL_LINE on: 2016-11-01 03:35:03
You have to do it manually. Here's an example:

25  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-10-30 03:40:31
Going to bed, quick dump of PN triangle tessellation:

26  Games Center / Showcase / Re: Halo 3 Remake on: 2016-10-30 03:38:12
Halo 4: Fhloston Paradise
27  Game Development / Newbie & Debugging Questions / Re: LWJGL GL30.glGenVertexArrays() returns duplicate ids on: 2016-10-28 19:13:49
VAO's aren't shared, even with shared contexts. The same ID can refer to different VAOs in different contexts.
28  Java Game APIs & Engines / OpenGL Development / Re: Vertex cache shenanigans 2 - WTF, Nvidia??? on: 2016-10-26 01:56:27
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.
29  Java Game APIs & Engines / OpenGL Development / Vertex cache shenanigans 2 - WTF, Nvidia??? on: 2016-10-26 00:30:32
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.
30  Game Development / Newbie & Debugging Questions / Re: Artemis-odb, how to initialize components? on: 2016-10-26 00:08:30
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.
Pages: [1] 2 3 ... 119
Lunch (51 views)
2016-12-06 16:01:40

ral0r2 (278 views)
2016-11-23 16:08:26

ClaasJG (411 views)
2016-11-10 17:36:32

CoffeeChemist (504 views)
2016-11-05 00:46:53

jay4842 (551 views)
2016-11-01 19:04:52

theagentd (576 views)
2016-10-24 17:51:53

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

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

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

Roquen (463 views)
2016-10-22 01:57:43
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!