Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (715)
Games in Android Showcase (214)
games submitted by our members
Games in WIP (788)
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 ... 121
1  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-25 00:11:04
If you're going to have the variables inside the enums for speed, I'd use ServiceLoader to lookup the required implementation at runtime and request the underlying values from it, rather than have the implementation have to configure the enums itself - that's ... yuck!  persecutioncomplex
What is a ServiceLoader? How would that work with my enums? What kind of advantages are there here?

From my point of view, an abstraction layer shouldn't contain backend-specific data in the first place.

The abstract model should have its own, backend-independent way to differentiate between
geometry types (POINTS, LINES, TRIANGLES, QUADS, SPLINES, SPHERES, something completely different) and the backends
have to map it to their own model at some point.
I agree with this, which is why I want to go with enums for the abstraction to get compile time checking of arguments. My initial idea had the OpenGL and Vulkan constants in the enum, which was bad as it meant having backend specific data in the abstraction. However, I think putting an int field in the enum that the backend can use for mapping the enum to a constant isn't the same thing and shouldn't be bad design as it has the best performance and arguable the lowest complexity and maintenance requirements.

The mapping actually has to occur just once, for example when the geometry is read from a file.
Not in my abstraction. It's just a thin layer over OpenGL and Vulkan, so data in a buffer for example isn't tied to a specific geometry topology like triangles or points. The mapping has to be done every time you submit a draw call, and there are a lot of other cases where I'll be needing to map lots of enums to int constants for OGL and VK.

2  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-24 17:51:34
@CopyableCougar4: The problem is that I want the user to be able to pass in an enum (say PrimitiveTopology.Points) and the backend then converts that enum to the symbolic constant of the API it uses (either GL_POINTS or VK_PRIMITIVE_TOPOLOGY_POINT_LIST) on the fly. It's the problem of doing this mapping quickly that I'm worried about. I don't really see your example code solving that, as extracting the int constants to variables at initialization time doesn't really help when the user later passes in enums.
3  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-24 15:34:14
You would just use the hashmap when you first load the program. Then you could store that values in static variables and lookup in that class when you need to.
How do you mean? That doesn't make sense to me.
4  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-24 15:32:23
Benchmark for mapping enum to int:

HashMap: 5.521456 ms    hashMap.get(enum)
EnumMap: 1.240702 ms    enumMap.get(enum)
Array:   0.560504 ms    constants[enum.ordinal()]
Field:   0.338337 ms    enum.constant
5  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-24 15:13:21
The bad cache coherency comes from having the additional EnumMap object lying around. By keeping the raw int[] for conversion instead of an EnumMap, you end up getting a cache miss when looking for the EnumMap instance, then another one for the actual array the EnumMap object references. The impact is probably not that severe, but it's there.

I will run some benchmarks.
6  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-24 14:56:49
OK, so I need to write more text  Roll Eyes  Why would you use an array indexed by ordinal() over an EnumMap?
Because evidently an EnumMap is just a wrapper around an array indexed with ordinal() anyway, and using EnumMap has too much overhead, bad cache coherency and will need autoboxing of the integer constants to fit them in.
    public V put(K key, V value) {
        int index = ((Enum)key).ordinal();
        Object oldValue = vals[index];
        vals[index] = maskNull(value);
        if (oldValue == null)
        return unmaskNull(oldValue);

@CoDi^R: I actually really like this approach. It'd actually even be "faster" than storing all values in the enum, as the enum would only need to store one value. Hmm. You would only be able to use one backend at a time, but that's fine. You could even live swap the backend by just calling initialize() again to switch out the values. I really like this approach. =P

@SHC: That could be solved by forcing the user to supply a mapping instead, so you'd pass in
initialize(new PrimitiveTopology[]{PointList, LineList, TriangleList}, new int[]{GL_POINTS, GL_LINES, GL_TRIANGLES});
, which in turn would simply loop over the two arrays doing
constants[enumArray[i].ordinal()] = constantArray[i];
. That'd be resistant to order changes, and you could make it cleanly error during runtime if you've added more enum values that the backend doesn't cover yet.

@CopyableCougar4: That's way too slow. A hashmap has a huge amount of overhead, and I'll be needing to look up 1-5 values per function call to the API. We're talking thousands of lookups per frame or even more. This is where holding the int constants in the enum really shines, because it means that the getter of that int can be completely inlined and the enum just becomes a wrapper around the int. That's essentially as fast as you can possibly get it (without having the user get the int themselves I guess, but I want the type safety of enums as well).
7  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-24 11:08:42
The problem with this system is as mentioned that it requires modifying the enum whenever you want to add a new backend, which makes it hard for people to add their own backend if someone would be crazy enough to want to do that.

My proposed solution would be to have the enum--->constant mapping in the backends instead. A hashmap is gonna be way too slow, but a simple array indexed by ordinal() could work.


public void render(PrimitiveTopology param){
    int constant = PRIMITIVE_TOPOLOGY_MAP[param.ordinal()];
    ... //use constant

I think this would have more overhead than having the data in the enum as a field though...

Ideas, anyone?
8  Games Center / Cube World Projects / Re: [LWJGL] Voxels - Display lists vs. Instanced Arrays on: 2017-03-24 09:15:21
Most likely the reason for the Java Powered logo on your PS4 is that Blu-ray menus are actually coded in Java. So yes, technically there are JVMs for most consoles and even just normal Blu-ray players, but they don't expose the raw graphics API there, only Java2D. It simply isn't suited for 3D graphics at all. See the Blu-Play thread here:

Yes, Minecraft was ported to quite a few languages AFAIK. The wikipedia place specifically mentions that the pocket edition version is coded in C++. It doesn't run on Java on consoles either AFAIK.

I don't think you come off as arrogant at all. It's not arrogant to have dreams and being aware of your potential. It's arrogant to think that you're infallible, and if that gets in the way of your learning because you can't accept criticism, you're an idiot. You don't seem that way at all; you just seem like you're determined to learn, and you haven't given up yet despite your attempts not working out. Good luck!
9  Games Center / Cube World Projects / Re: [LWJGL] Voxels - Display lists vs. Instanced Arrays on: 2017-03-23 21:58:17
As everyone's already said, display lists are deprecated since many years back. Vertex buffer objects is the way to go nowadays.

There's a reason why voxels are generally kept pretty big. Storing volume information requires huge amounts of memory usually. Consider a simple case where you want a 500 voxel view distance and you have a maximum height of 200 voxels. To allow the player to look around properly, you'd need to have all voxels within a 500 radius circle around the player loaded in. This is essentially a 1000x1000x200 volume of voxels, or two hundred MILLION voxels. Storing each voxel as an object will use at least 8 bytes per voxel (even an empty Java object uses 8 bytes), so you're already talking about 1000*1000*200*8 bytes, which is equal to 1.5GBs of memory right there. Let's say you want smaller voxels, so you cut each voxel into 8 smaller voxels. Well, now you have 8 times as many voxels, so that's 12GBs of memory you have now. There are a lot of tricks for reducing the memory usage of voxel worlds, and this should be your first focus (after you got basic rendering working).

Tessellation isn't really something you can use for voxel worlds effectively to get smaller voxels. Due to how most voxel world rendering techniques work, both the smallest and biggest piece of geometry you can render is a single voxel's face. The nature of voxel worlds makes it very hard to combine multiple voxels into a single surface without handling a lot of special cases, so it's an optimization that is rarely done. Tessellation allows you to dynamically divide one triangle or quad into more triangles or quads. This isn't really what you want to do in your voxel world, because it would require you to merge voxels ahead of time, then dynamically subdivide them again to get the original voxels back, which like I said is really hard to do. This means that tessellation doesn't really fill much of a function in voxel worlds. If none of what I just said makes sense to you, you should consider reading up more on tessellation and what it's actually used for nowadays, what its advantages and disadvantages are, etc.

Realistic physics can be a big challenge to do for big worlds. Again, memory usage can be a big issue, but performance is a more likely problem here as well. If you're hellbent on having physics, I'd recommend taking a look at the Bullet physics engine, as that's your best bet at achieving realistic physics. Still, it's definitely not an easy task.

Indeed, shaders are a must for the OpenGL 3 pipeline, because you literally need to have a shader program to be able to render anything at all. That is unless you use the compatibility profile, which is basically just the ability to use the older stuff that they removed from OpenGL 3 in OpenGL 3, which means... that it's not really OpenGL 3 in the first place. It sounds like you need to get some basic rendering working in the OpenGL 3 pipeline before you should start with your voxel world. Don't worry though; rendering a voxel world isn't that complicated once you actually got your first couple of triangles rendered properly.

If you want to target consoles, then Java is definitely the wrong platform for you. Although there are ways to run Java games on consoles, there's currently no known way of achieving hardware acceleration for the graphics (or OpenGL at all), so they're essentially limited to simple 2D graphics. You need to look elsewhere if you want to run your games on consoles, probably the Unity engine and Unreal engine. If you just want to run your game on phones and tablets (as well as PC), then Java is a great choice. LibGDX is the go-to library for that, but LWJGL is seeing initial support for Android right now. Exciting times!

I don't want to be negative, but you may want to take a step back and try to figure out what is actually achievable for you at your current skill level. It's good that you're trying to learn more to achieve your goals, so don't let me discourage you from continuing, but maybe consider starting with the basics and working yourself up from there at least.
10  Java Game APIs & Engines / OpenGL Development / Re: OpenGL - Draw multiple objects issue on: 2017-03-06 22:16:55
Err, sin() and cos() are pretty cheap in shaders. Also, vertex shaders are also often limited by the "export" cost of writing the output of the attributes to temporary memory, making all operations "free" up to a certain point. Even if cos/sin was that expensive, you could just precompute them on the CPU and upload them directly, then construct a rotation matrix from those two values.
11  Game Development / Newbie & Debugging Questions / Re: 2d Image Rotation lwjgl on: 2017-02-27 22:55:11
It seems like you just keep rotating the matrix more and more. Are you calling glLoadIdentity() somewhere to reset the matrix? glPush/PopMatrix() is really useful too.
12  Game Development / Newbie & Debugging Questions / Re: [LWJGL3/OpenGL] New window mode versus VAO on: 2017-02-24 12:33:28
The latest nightly build of LWJGL should include the 3.3 beta version of GLFW. I use it right now. =P
13  Game Development / Game Mechanics / Re: Simulating orbital gravity with a prediction of trajectory (Multiple attractors) on: 2017-02-23 19:43:56
I assume that what you're looking for is: given the data of a body, figure out what its position will be after N seconds given that it is attracted by these K other bodies. This is actually an unsolved mathematical problem:
To this purpose the two-body problem has been completely solved and is discussed below; as is the famous restricted 3-Body Problem.

The only real way of "solving" this with more than 2/3 bodies is to simulate the whole thing. There are no known formulas or algorithms that don't involve integrating with a certain time step (AKA simulating).
14  Game Development / Newbie & Debugging Questions / Re: mt object wouldnt load image on: 2017-02-21 14:06:53
You should never ever silently swallow an exception like that. You're probably getting an error telling you what the problem is.
15  Game Development / Newbie & Debugging Questions / Re: mt object wouldnt load image on: 2017-02-21 10:54:26
MediaTracker is a very outdated way of loading images. I strongly recommend using instead!
16  Games Center / WIP games, tools & toy projects / Re: FFP Software Rendered - GFX/Game Progress on: 2017-02-20 11:51:24
Can't think of any particular example, but I'd say the user should be able to access all functionalities of the engine, and to access them without having to go through a long process of invoking ten methods and using objects with confusing names just for one purpose... Do I even make sense at all?
No. Wink Are you referring to LWJGL specifically or just OpenGL?
17  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-19 15:17:38
Nice job)
I also may recommend try put draw in to DisplayList
– yes I know it deprecated – but you don’t lose anything trying)
Good idea, but testing that would require half a rewrite of my model renderer ingame, so I'd have to write an artifical test for it... Also, the amount of optimization the drivers do will vary a lot between vendors, so I'm not sure the information would be that valuable.

RYG did an easy to understand breakdown of out-of-order optimization of some code by PhysX author Pierre Terdiman,
Hmm. Is there any way could write code that would take advantage of that info in Java? Some pattern that helps Hotspot do the same thing I mean.
18  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-18 16:05:05
Try the average of the 3 verts as the sort key.

Cas Smiley
It's the exact same thing. The average is (i1 + i2 + i3) / 3, so I'm just sorting based on <average>*3.
19  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-18 15:22:46
I seem to recall years and years ago getting perfectly decent performance optimisation just by the simple expedient of sorting triangles in order of their average vertex index number. And that's O(n log n) perf on average. It's not quite as fancy but it gets like 90% of the win for bugger all effort and the best bit is that it can be done in realtime with dynamic meshes. Food for thought. (Why not try it and compare?)

Cas Smiley
Actually, the first thing I did was sort based on the lowest index number. It couldn't compare to Tom's algorithm. Hmm... I'm gonna try something similar though.

EDIT: So I tried something really simple:

1. Sort triangles based on (i0 + i1 + i2).
2. Reorder vertices in the order they are used by the triangles (= the pre-transform cache coherency optimization, step 3 in my previous long post).
3. Repeat until the result gets stable.

The result was actually pretty good, but still not as good as Tom Forsyth's algorithm.

Simple algorithm after 86 iterations: invocations: 38544 --> 26902 --> 14308 (62.878788% reduction, 54.71454% more than optimal)
Tom Forsyth's algorithm: 38544 --> 26902 --> 11904 (69.115814% reduction, 28.719727% more than optimal)

EDIT 2: According to Forsyth, his algorithm can be implemented in linear time.

EDIT 3: Note that all the invocations counts are reported by the hardware of my Nvidia GPU. The numbers may be very different on AMD and Intel GPUs.
20  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-18 13:44:48
You never fail to amaze me, agent. Never thought that index ordering could have such an impact. This topic is now definitely on my (long) list of TODOs. Are games nowadays always optimizing this? And....since you implement so much stuff, why don't you share your repository or your code?  Pointing
Thanks. =P

I'd imagine most games do something to optimize this since the gains can be so huge. In my case, it was really going from the worst possible case to almost optimal reuse, so my gains were a bit exaggerated.

Here's the code for my triangle order optimizer: My implementation is O(n^2), so not entirely optimal according to the original paper. Still, it's fast enough for my uses. A 12 848 triangle mesh took 260ms to optimize for me, so good enough for an offline tool. There's some low-hanging fruit in there to optimize.

Here's the pre-vertex cache optimizer code. Very simple, there's probably much better algorithms out there, but I couldn't measure significant gains from running this anyway.

Note: You should always run the triangle order optimizer FIRST, then run the pre-vertex cache optimizer. The triangle order optimizer messes up the vertex order, which the pre-vertex cache optimizer fixes without changing the triangle order.
21  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-17 16:40:02
Today, I wrote a mesh optimizer in Java to be used on the output of my Blender export plugin.

I'm not too proficient in Python and it's just so goddamn slow at everything, so instead of completely ruining the fast export times I've managed to get so far, I opted for writing a simple optimizer that takes in a model file, optimizes it, then writes it out again. This is done in 3 steps:

1. In the first step, I simply eliminate all duplicated vertices and leave just one of each, then reference the same one with an index buffer. The mesh I output from Blender is mostly unoptimized with lots of duplicated vertices, and this step reduces the vertex count by about 75% percent. This saves a lot of memory on the harddrive and reduces loadtimes a lot, but it actually does not improve performance very much. For example, in one of the submeshes of the giant robots of Robot Farm, the vertex count goes from 38544 --> 9248, a 76% reduction, but the number of vertex shader invocations only drop from 38544 --> 26902, a 30% drop. This leads to the next step...

2. In the next step, the triangles in the mesh is reordered to improve the effectiveness of the hardware vertex cache. As some people might remember, I've done a lot of experiments on the hardware vertex caches of Nvidia, AMD and Intel GPUs, and basically concluded that Nvidia's is f**king weird, AMD's is kinda weird and Intel's is the only sane one. In the end, I concluded that optimizing the meshes for each graphics vendor was too much work, so I simply went with a mainstream algorithm. I ended up implementing Tom Forsyth's simple algorithm, and it works really well. This algorithm simply reorders the triangles in the mesh (by reordering the indices in the index buffer) to increase the chance that vertices are reused as much as possible without specializing it too much to a specific cache size. It's pretty much a general-purpose optimization that should be better than nothing. Anyway, this step further reduced the vertex shader invocation count from 26902 --> 11847, which together with step 1 was a total reduction of 70%! Now, optimally, the number of invocations should be equal to the number of vertices in the mesh, which would mean that there is perfect reuse of vertices and no vertex had to be transformed more than once, but it may not be possible to achieve this. In the end, for this particular mesh the number of invocations is 28% more than optimal, which is acceptable to me.

3. Now, the meshes are optimized for the vertex cache and need a minimal number of vertex shader invocations, but there is one last thing that can be optimized. Inspecting the actual index buffer generated after step 2 reordered the triangles, it's pretty damn random.
..., 6031, 5989, 5991, 5992, 5993, 5991, 6032, 5992, 5994, 5995, 5996, 5994, 6033, 5995, 8387, 8388, 8389, 8387, 8409, 8388, 8390, 8391, 8392, 8390...
There's a lot of good reuse happening here, but also very huge jumps in which vertex each triangle uses. It essentially reads a completely random vertex from the vertex buffer each execution. This is bad for the GPU, as the vertex data from the VBO is read in with a certain cache line size depending on the GPU. In short, if you reference vertex 1000 and 1001, there's a big chance that the memory read for the data of vertex 1000 will cause the data for vertex 1001 to also be loaded into the cache. Therefore, it is a good idea to try to minimize the "distance" between each subsequent index in the index buffer to increase the chance of the input data of the vertex shader already being in the cache. I did this by simply reordering the vertices in the data to so that they are in the order that the index buffer references them. This does not change the triangle order; it simply changes where the vertices of each triangle lies in memory. Here's an excerpt from the output index buffer:
..., 2571, 2565, 2571, 2568, 2566, 2567, 2572, 2571, 2566, 2572, 2572, 2567, 2573, 2571, 2574, 2568, 2569, 2568, 2574, 2569, 2575, 2570, 2569, 2574, 2575, 2575, 2576, 2570, 2571, 2572, ...
Much better! This works super well with the optimized triangle order from step 2, as the algorithm tries to place all uses of a given vertex in one place so that it can be reused, so there's a very low risk of a very old vertex being referenced again. To measure the effectiveness of this step, I measured the average "index distance", which is the average
abs(currentIndex - previousIndex)
over the entire index buffer. The average index distance went from 42.82251 --> 5.490958, a very significant improvement to cache coherency!

All in all, here are the final results for the mesh:
Eliminating duplicate vertices...
Optimizing for post-transform vertex cache...
Optimizing for pre-transform vertex cache...
Vertex count: 38544 --> 9248 (76.00664% reduction)
Invocations: 38544 --> 26902 --> 11847 (69.2637% reduction, 28.103378% more than optimal)
Average index distance: 42.82251 --> 5.490958

Placing 500 of those high-poly robots with no LOD or anything in a test program, my FPS went from 12 to 32 when I switched to the optimized mesh, a ~62.5% reduction in frame time, which matches very well with the ~~70% invocation reduction when you add postprocessing and everything else taking up a bit of time in the first place.
22  Game Development / Newbie & Debugging Questions / Re: [LWJGL3/OpenGL] New window mode versus VAO on: 2017-02-16 22:59:32
I'm assuming you're doing this with shared contexts, basically trying to pass on the old objects to the new context before destroying the old one. Sadly, not all OpenGL objects are shared. Anything that by itself doesn't contain any actual data is not shared between contexts. In other words, things like textures and buffers are shared because they contain data, but FBOs and VAOs are not because they only contain references to other objects.

There are lots of functions in GLFW to change the setup of the window without recreating it. You can go fullscreen, disable the decoration to make a window borderless, etc. See glfwSetWindowMonitor() and glfwSetWindowAttrib().
23  Games Center / WIP games, tools & toy projects / Re: Robot Farm on: 2017-02-16 18:24:45
24  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-16 13:14:20
These last few days, I've worked on improving the RF graphics, since that's one of the main criticisms we got for it.

We don't really draw our houses in RF; we just draw the walls on the ground and leave the rest to the user's imagination. Now, some time ago I added a day/night-cycle, where the ambient light changes over the course of the day, with nice orange mornings and sunsets, and really dark nights. It's really nice, but didn't really have much impact due to the lack of shadows. I realized that I could really easily draw some sun shadows using the same shader and system as for point lights, allowing for a full day/night-cycle with the sun casting long shadows from the buildings, which even have faked roofs casting shadows now, which helps conveying the actual size and shape of the house even though we don't draw it.

I also added cloud shadows that slowly float over the screen and change shape, and added a cloudiness parameter that allows the clouds to be slowly faded in and out, allowing for transitions from a sunny day to a cloudy day over a couple of minutes of playtime, with really good results. I had to make a few compromises on the clouds though, as I really needed bicubic filtering to get them to look good. Still, I'm happy with the results.

Today I added "raytraced" god rays based on said clouds. It's pretty crazy heavy, but done at 1/16th the normal tile resolution so it's not too slow. They're accurate and follow the shape of the clouds as they float by. The intensity of the clouds are faded in based on the cloudiness parameter, so on clear days the god rays will essentially disappear to avoid turning the entire screen white, while on cloudy days the intensity ramps up so that a tiny hole in the cloud cover will cast a glorious pillar of light to the ground.

Here's a pic showing off all the new features:

25  Game Development / Newbie & Debugging Questions / Re: FBO Blending on: 2017-02-13 08:02:21
You'll need to describe your problem better. Show us some screenshots of the problem and most important of all tell us exactly what result you're expecting.
26  Java Game APIs & Engines / Java 2D / Re: Blu-Play: An introduction to developers on: 2017-02-13 00:10:53
Still, PS4 should logically be a great deal faster than the PS3, so I wouldn't rule out the possibility. In any case, it's always bad practice to rule anything out before having tried. That's the whole reason why no one here has ever heard of BD-J before - because everyone wrote it off, claiming it couldn't do anything. But I'm proving everyone wrong now, when I release "Ukko's Journey".
That's probably not true... The PS3 CPU was a really weird beast. It had 1 fast main 3.2GHz CPU core, and then 7 extremely specialized computing cores of which 1 was reserved for the OS, leaving 6 for games to utilize. However, the PS3's GPU was extremely slow, so the SPUs were used to compensate for that. At the end of the PS3's lifetime they even started doing shading and postprocessing on the CPU just to free the GPU from some work, but I digress. The PS4 has a 1.6GHz octa-core CPU, which uses GDDR5 memory (GPU memory) even for the CPU. This means that a single core on the PS4 cannot beat the beefy main core of the PS3, and in addition it has RAM that is worse for CPU computations. I doubt you're gonna be able to do fancy threading on BD-J to utilize all the PS4's cores, and when comparing single-threaded performance I'm afraid the PS3 is actually gonna be the fastest.

Since my engine is a software renderer I believe it can run on BD-J
Now that would be really cool to see! =P
27  Java Game APIs & Engines / Java 2D / Re: Blu-Play: An introduction to developers on: 2017-02-12 15:35:28
From what I can tell, they implemented a software OpenGL renderer over Java2D. That's simply not even close to good enough for 3D games.
28  Java Game APIs & Engines / Engines, Libraries and Tools / Re: GLFW Key Event Bouncing on: 2017-02-11 10:37:19
GLFW includes GLFW_REPEAT which is for repeat keys. It could be a bug in GLFW. Consider opening a ticket on their repo on Github.
29  Java Game APIs & Engines / Java 2D / Re: Blu-Play: An introduction to developers on: 2017-02-11 10:16:39
This is limited to Java2D? Any OpenGL/OpenAL?
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Ongoing project: Type-Safe access to ByteBuffers on: 2017-02-05 15:14:47
And talking about intrusiveness .. having another build step is intrusive as well .. don't you think?
Not if I can use the runtime compilation of the helper classes for debugging, then seamlessly switch to the prebuilt one for actual releases.
Pages: [1] 2 3 ... 121
CopyableCougar4 (161 views)
2017-03-24 15:39:42

theagentd (144 views)
2017-03-24 15:32:08

Rule (200 views)
2017-03-19 12:43:22

Rule (188 views)
2017-03-19 12:42:17

Rule (191 views)
2017-03-19 12:36:21

theagentd (209 views)
2017-03-16 05:07:07

theagentd (204 views)
2017-03-15 22:37:06

theagentd (159 views)
2017-03-15 22:32:18

theagentd (153 views)
2017-03-15 22:31:11

ral0r2 (163 views)
2017-03-03 11:52:41
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

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51 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!