Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (468)
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 ... 25
1  Java Game APIs & Engines / Engines, Libraries and Tools / Re: FFI JEP on: 2014-03-18 02:41:10
Project Panama. This post by John Rose "describes some of the many questions related to native interconnect, along with some approaches for solving them".
2  Game Development / Shared Code / Re: Multithreaded arithmetic benchmark on: 2014-03-17 22:53:43
I highly recommend JMH for all kinds of benchmarking, for many important reasons.
3  Java Game APIs & Engines / OpenGL Development / Re: LWJGL bug: Duplicate enums in GL43 on: 2014-03-11 12:03:26
Please try the next nightly build, I have removed all duplicate tokens from the core GL classes.
4  Discussions / Miscellaneous Topics / Re: C++ standard library is really lacking - good or bad? on: 2014-03-06 12:09:27
A new post on value types by John Rose.
5  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL check for available contexts on: 2014-03-02 16:04:22
The only way to do it in LWJGL 2 without a Display is to use a Pbuffer. In LWJGL 3 you're able to create invisible windows, so there isn't a need for a pbuffer context. In fact, 3 will not even provide a pbuffer API (the platform-specific pbuffer extensions will still be available though).
6  Java Game APIs & Engines / Engines, Libraries and Tools / FFI JEP on: 2014-02-24 20:53:01
JEP 191: Foreign Function Interface. If everything goes well, this is going to have major impact to Java gaming.

For those interested in LWJGL development, 3.0 has been designed to be forward compatible with having such functionality present in the JVM. I've also given feedback to the JEP's author (Charles Nutter, of JRuby fame) regarding LWJGL-specific requirements. Together with an official Unsafe that's also considered for Java 9, this could be the best thing that happened to Java gaming since NIO in JDK 1.4.
7  Discussions / General Discussions / Re: Someone brought up an interesting topic regarding the new JDK8 default methods. on: 2014-02-08 13:03:39
That example that turns the Comparator interface into a Builder feels.... misguided.

Wouldn't it be better to simply add a separate ComparatorBuilder library class?

If the main purpose of default methods is so that existing interfaces can be expanded without breaking binary compatibility, then I feel it's somewhat pointless as most interfaces shouldn't be able to provide a meaningful default implementation.
It'll just result in messy interface bodged with empty implementations and warning comments.

Assuming this is the example you're referring to:

1  
2  
3  
4  
myDeck.sort(
    Comparator
        .comparing(Card::getRank)
        .thenComparing(Comparator.comparing(Card::getSuit)));

These are not default methods, they are normal static methods which can now be added to interfaces with Java 8. A default implementation is not provided; the implementation is being passed in via a method handle (it could also be a lambda expression).

As to having a different builder/factory class vs static methods in the interface, it's just a matter of style I guess. My personal preference would be static in interface; more compact, a single source file, don't have to remember the builder class name.
8  Discussions / General Discussions / Re: Someone brought up an interesting topic regarding the new JDK8 default methods. on: 2014-02-08 10:12:34
The foo from A would be called, because normal methods take precedence over default methods. You can override this in C, by using:

1  
2  
3  
4  
@Override
public void foo() {
   B.super.foo();
}
9  Discussions / General Discussions / Re: Someone brought up an interesting topic regarding the new JDK8 default methods. on: 2014-02-08 09:48:13
The difference is that default methods are stateless. You can think about them as static methods with an implicit "this" parameter, than can be called on instances of the interface. This is a limited* version of "extension methods", a popular feature in modern languages (see C#, Kotlin, Xtend).

Ambiguity can arise with default methods, for example when you have a diamond shaped inheritance tree, but that can easily be resolved. It's nowhere close to the complexity of real multiple inheritance and has none of its drawbacks.

* Limited, because extension methods can be added to any class (not just interfaces) at any time/scope (outside the class definition).
10  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-02-01 02:40:09
I'm not sure I'm getting what he's trying to do? Redesign OpenGL to look more like Mantle? Would that actually bring any of the (performance) advantages of Mantle over to OpenGL?

According to a previous tweet, "an order of magnitude perf bump is a reasonable target".
11  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-01-31 16:27:49
and an attempt to apply Mantle's design to OpenGL.
12  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-01-31 13:10:18
Mantle functions, the list.
13  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-01-30 15:12:51
Interestingly John Carmack mentioned awhile back that he reckons Nvidia's OpenGL extensions (not sure which ones in particular) can give similar improvements. If so and such changes are incorporated into future OpenGL core then could be a problem for Mantle adoption.

You must be referring to this (this is all cross-platform btw, not Nvidia specific). Unfortunately, like Mantle, it's very limited in terms of hardware and driver support. And also requires a major rewrite of the rendering pipeline. I think it will all come down to availability and driver stability. Technically, it should be easier to write a robust driver for something like Mantle vs the beast that OpenGL is.

When can we see LWJGL support? I have my Mantle dedicated computer ready to be put together. xd

Whenever AMD releases a public specification, which I guess won't be soon. With the driver released today, Mantle will only work on R9/R7/Kavery parts. They'll probably wait for GCN 1.0 support first and also for any tweaks that will come up from the BF "beta test".

edit: The above is wrong. The driver will support Mantle on all GCN cards, but BF+Mantle will only run on GCN 1.1 (for now). Still no info on the Mantle spec.
14  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-01-30 12:03:30
First real-world results: Mantle renderer now available in Battlefield 4. Up to 58% faster in a high-end configuration.
15  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL: Random direction thoughts on: 2013-12-18 18:02:11
Absolutely. Thread safety responsibility is being moved from the library to the user, where appropriate (which is virtually everywhere). There's no plan to have AWT interop in LWJGL 3 and any other kind of interop (JavaFX, SWT, etc) will be strictly "non-core"/optional functionality.
16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL: Random direction thoughts on: 2013-12-18 17:33:14
It's 7 year old code related to AWT interop. Most horrible stuff in the LWJGL codebase are related to it.
17  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Wiki and a progress update on: 2013-12-01 20:01:03
I just completed a painful refactoring that breaks OpenCL API compatibility with LWJGL 2.x. All pointer wrapper classes have been removed and the bindings now use raw pointer values. I've been struggling with this issue since I started working on LWJGL 3 (there are pros and cons either way), but ultimately decided this is the best choice given the approach we're taking with 3.

On its own, this is obviously a major loss of utility, but I've tried to replace the old functionality as best as I could. Specifically:

  • The CLPlatform and CLDevice classes remain, but they're entirely optional. They're mainly containers for the CLCapabilities instances (which are expensive to create) and provide the familiar getPlatforms/getDevices methods. You can also create your own CLCapabilities instances if you prefer to store them in some other way.
  • There is a new generated class org.lwjgl.opencl.Info that can be statically imported. It provides custom glGet<object>Info<type> methods for easy information queries on OpenCL objects.
  • clSetKernelArg
    has been overloaded with primitive versions, for all types and up to vector of 4 values. You can see that here. I'm still not sure if these should be moved to a custom class, similar to Info.
18  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL: Random direction thoughts on: 2013-11-26 15:20:59
Btw, I have not been able to find a library for CPU feature detection, that is acceptably cross-platform/maintained/reliable. Only libcpuid comes close, but I'd like something for ARM CPUs as well. Anyone knows a decent alternative?
19  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL: Random direction thoughts on: 2013-11-26 15:15:30
I've been looking at hwloc. It has a simple C API (easily added to LWJGL), works on basically every OS and CPU out there and has great features. Among many others, you can query:

- Total physical memory.
- Number of cache levels, how big each level is, which cores share which level.
- Number of processing units per core (hyper-threading).
- Cache-line sizes and cache associativity.

It also provides a cross-platform API to pin threads/processes to CPU cores (affinity).

This might seem like too compute-oriented or for server workloads (e.g. hwloc exposes per-socket information but we'll never encounter multiple sockets on a gaming machine). I honestly have stopped treating LWJGL as a pure gaming library since we added support for OpenCL, so I really think this will be useful functionality to have. Even for games, core information can be quite helpful if secondary threads are used (for physics, sound processing, asset loading, etc). You generally don't want to mix two "compute-heavy" threads in the same hyper-threaded core, performance will suffer. Also, using a dedicated core for latency-sensitive stuff can be very beneficial.
20  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Wiki and a progress update on: 2013-11-23 22:11:52
I'm a huge proponent of the new
ngl*
methods, but I fear the function pointer parameter ruins it for practical use. I'd be thrilled with an ngl* like, non-native method, with the same parameters, except, ofcourse, the last one, which would set the function pointer in its body.

This is now implemented for all methods with pointer argument/return types. You can see the generated code diff here. (warning: 17MB of HTML content)
21  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Wiki and a progress update on: 2013-11-23 14:22:32
Why are the
ngl*
functions
public
?

It is briefly explained in this page, see the end of the first question. These functions enable direct pointer arithmetic, which means cleaner code or even better performance in some cases. I'll add examples in the wiki when I write the AL/GL/CL guides. They also can be used by anyone to create custom wrappers around the raw functions.
22  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Wiki and a progress update on: 2013-11-20 19:29:05
As I said, the main focus of LWJGL 3 is to expose useful functionality. It's a library, not a framework or engine. In this case, vendor and platform specific extensions useful to multi-GPU rendering, like AMD_gpu_association and NV_gpu_affinity, will be directly accessible. You can use them however you like and there won't be abstraction obstacles in the way, like in LWJGL 2. That's a feature. LWJGL makes no promises about performance and it's up to you, or high-level frameworks like libGDX, to make the most out of the exposed functionality.
23  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Wiki and a progress update on: 2013-11-20 01:02:11
LWJGL 3 is about features and robustness, not performance. You can do stuff with 3 that couldn't do with 2 (prime example: multiple native windows) and you'll get more features faster in the future. You'll be able to more easily implement custom features of your own (e.g. integration with SWT, multi-thread and multi-GPU rendering). LWJGL also directly benefits from how robust the GLFW implementation is and how many edge-cases it deals with, meaning you'll encounter less issues and less bug-reports from users.

From a pure performance perspective, technically LWJGL 3 does have a slight edge because it enables direct (and obviously unsafe) pointer management. If you're feeling adventurous, there can be situations where that flexibility enables skipping unnecessary work (e.g. in tight loops). But then you're also likely to be affected by JNI overhead and getting around that requires either custom native code (moving the loop to C) or JVM changes (a built-in FFI mechanism that eliminates the overhead completely).
24  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Wiki and a progress update on: 2013-11-19 16:46:53
If it's purely meant for optional / advanced functionality, are there advantages to doing this above suggesting JNA?

It's just a lightweight alternative that you could use with one less runtime dependency. Ideally you'd only need it for a couple of function calls that LWJGL bindings don't cover, so you can avoid bringing in another whole library just for that. It's a direct binding to libffi's functions, so it's close to the metal and has nowhere the user-friendliness (and complexity) of JNA. It roughly corresponds to a few methods exposed in com.sun.jna.Native, but you do get the standard LWJGL overloaded methods that accept ByteBuffer/PointerBuffer/etc and there are also helper classes for the ffi_cif and ffi_type structs. Performance should be ideal for what libffi does (roughly 30% slower than JNI in a few of my tests), but you do pay the price of going low-level (and unsafe) to use it.

Do note that libffi's "closures" (basically, runtime callback generation) have not been exposed, so if you need that feature you should stick with JNA anyway. There are a few good reasons to avoid closures, but I may end up revisiting this decision in the future.
25  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Wiki and a progress update on: 2013-11-19 15:38:52
Is this purely an optional binding, or is LWJGL shipping with / dependent on libffi?  If the latter (excuse my lack of understanding of linking!) then is this done in a way that wouldn't conflict with other loaded versions of libffi?  Thinking particularly that I know various applications (my own included) that use LWJGL and JNA.

libffi is very small, so it's currently statically linked into the LWJGL binary. It is there for users that would like to call native functions for which LWJGL does not provide bindings out of the box. So it is indeed meant to be optional/advanced functionality. If static linking causes trouble, it can easily be refactored to dynamic linking.
26  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3 - Wiki and a progress update on: 2013-11-19 01:14:29
LWJGL 3 now has a dedicated Wiki.

It is not complete, but it has important information that I felt should readily be available to potential users and contributors. Please let me know if you'd like anything fixed, if something requires better explanation or if I've missed an important aspect of the project that deserves to be documented.

Recent changes:

  • OS X is now supported.
  • Updated GLFW to v3.0.3.
  • Added JavaDoc generation.
  • Added libffi bindings.
  • The required minimum JDK version is now 7.
  • Many fixes and improvements to code generation & documentation.


The wiki now has a long to-do list, so there's plenty more work to be done. The current plan is to wait for GLFW 3.0.4 (contains many important fixes) and then we'll release an alpha build for all platforms. If you'd like to try it out sooner, feel free to clone the project and build manually, I've tried to make it as easy as possible. If you encounter any issues, please do let me know.
27  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2013-11-17 18:10:26
Without having seen any code, I'm sure I'll add it to LWJGL the same day it's out. Interestingly, we might have to start worrying about JNI. It's only noise with OpenGL, but if we're moving to 100k-1M draw calls per frame, JNI overhead could easily add up to a few milliseconds. An FFI mechanism would be nice in Java 9...

I think a multi-vendor, multi-platform Mantle would be a great opportunity for Linux to directly compete with Windows as a gaming platform. I also can't wait for lightweight drivers vs the 200+ MB monstrosities we have to download now every couple of weeks.
28  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2013-11-17 02:13:28
Q&A with developers, very interesting stuff.

Info from past couple of days: There is a validation layer on top of Mantle which is "indeed extremely important and very valuable. also makes it significantly easier than on PS4" according to DICE. Seems AMD is taking profiling, debugging and integration with other tools (e.g. PerfStudio) very seriously.
29  Discussions / General Discussions / Re: HSA and Java on: 2013-11-17 01:54:36
I think Project Sumatra and also Graal and Truffle will be very important for the future of the JVM. Oracle is not alone either, AMD has big plans for Java performance. For now though, the problem is two-fold:

a) We won't have a useful implementation until Java 9. That's 2016, 2+ years from now. Java 8 will be the major feature release (lambdas) and Java 9 the major performance one (HSA plus Arrays2.0/PackedObjects/Structs/whatever).

b) I personally don't think automatic offloading to GPU is going to fly on current PC architectures. The non uniform nature of memory, i.e. separate virtual address spaces for CPU and GPU, is very hard to program on and even harder to optimize for. Even with manual effort, very few types of workload are actually accelerated by taking advantage of the GPU, the transfers between CPU and GPU memory are simply too costly. Hacks like CUDA 6's Unified Memory may simplify programming, but do nothing about actual performance. Next-gen APUs (e.g. AMD's Kaveri) will fix this problem and only then can I see general purpose Java code easily optimizeable on there. So, we're again talking about a few (many?) years for such architectures to grab enough market share.

In any case, we'll have to wait.
30  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2013-11-15 14:16:22
More details in these slides: Mantle for Developers (Frostbite, DICE)

edit: more slides: How Mantle Changes the Game (Nitrous, Oxide)
Pages: [1] 2 3 ... 25
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

theagentd (6 views)
2014-04-24 23:00:44

xsi3rr4x (83 views)
2014-04-15 18:08:23

BurntPizza (75 views)
2014-04-15 03:46:01

UprightPath (86 views)
2014-04-14 17:39:50

UprightPath (69 views)
2014-04-14 17:35:47

Porlus (86 views)
2014-04-14 15:48:38

tom_mai78101 (109 views)
2014-04-10 04:04:31

BurntPizza (169 views)
2014-04-08 23:06:04

tom_mai78101 (265 views)
2014-04-05 13:34:39

trollwarrior1 (217 views)
2014-04-04 12:06:45
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!