Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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  Discussions / Miscellaneous Topics / Re: A rant on OpenGL's future on: 2014-07-15 20:49:50
For example, it'd probably be handy if OpenGL were a portable library on top of some other back end. OpenGL itself never needed to really be a "driver" as such. In fact a portable OpenGL library would just be the best thing ever.

Regal is moving in that direction, though I'm not sure if it'll ever get to the point of emulating OpenGL over a non-GL API (Mantle, Direct3D, etc).
2  Discussions / General Discussions / Re: [opengl] Why are LWJGL enums as integers? on: 2014-07-11 20:06:48
There will be a usable build for public testing after GLFW 3.1 is released.
3  Discussions / General Discussions / Re: [opengl] Why are LWJGL enums as integers? on: 2014-07-11 19:30:33
One of the improvements in LWJGL 3 is javadoc generation for all bindings. This includes links to enums that an OpenGL function argument supports. Imho, it makes a huge difference in productivity and it's not an issue anymore that GL enums are integers. I've tried to list all core GL enums and plan to keep them up-to-date as new versions are released. I've also included several extension enums, but that's obviously a huge task and requires help from the community. Feel free to submit documentation patches at any time.
4  Discussions / General Discussions / Re: Java 8 on Raspberry Pi on: 2014-06-18 23:16:57
Just a thought... LWJGL-ES... can it use any context passed to it from some other library?

Untested, but yes, it should be able to.
5  Discussions / Miscellaneous Topics / Re: Random syntax tweaks! on: 2014-06-03 21:05:28
It got worse, much worse... and not even close to C#'s approach... somebody point out my obvious mistake please. persecutioncomplex

It is indeed pointless, unless you use the functional APIs:

1  
2  
3  
4  
5  
6  
7  
String type =
   Optional.of(new Car(new Engine(Type.GASOLINE))) // Optional<Car>
     .flatMap(Car::getEngine) // Optional<Engine>
     .flatMap(Engine::getType) // Optional<Type>
     .map(Type::name) // Optional<String>
     .map(String::toLowerCase) // Optional<String>
     .orElse("<unknown type>"); // String

It becomes more interesting when the source is a stream, instead of a single value.
6  Discussions / General Discussions / Re: JEP for making Unsafe a public API on: 2014-05-09 17:03:58
So has anyone looked at how hotspot expands the various get/put methods after compiling?

They compile down to trival memory loads/stores. At least in the x86 disassemblies I've inspected. However...

The real problem with Unsafe access comes from hotspot NEVER reordering accesses in the JITed code. This has a measurable effect on performance and I first encountered it when doing performance testing with Riven's original mapped objects library. I'm not sure what the technical problem is, but it looks like all native calls (intrinsified or not) act as implicit code barriers and GC safepoints. Unsafe access disassembly looks exactly like the source Java code (same access order that is) and I don't know if this is a bug or a correctness/security issue. Definitely though, hotspot does not apply the same optimizations to Unsafe as it does to fields (of course I'm talking about plain access, not volatile/ordered) and any computation going in or out of off-heap memory will suffer a performance penalty.

I've written a JMH benchmark that showcases the problem. The baseline is Matrix4fJava.mul4f, which performs standard 4x4 matrix multiplication, where the target may be one of the operands. The matrix is represented as a POJO with float fields. It is compared to doing the exact same calculation with a float array, a FloatBuffer and finally, Unsafe. There are also optimized versions that have been manually tuned to minimize stack usage, close to what hotspot does automatically for field access. Results on Java 8 GA x64 (edit: added float vs int results and made more clear what the baseline is):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
// Floating point
Benchmark                       Mode   Samples         Mean   Mean error    Units
UnsafeBench.field               avgt        10       24.972        0.229    ns/op

UnsafeBench.array               avgt        10       30.871        1.331    ns/op
UnsafeBench.arrayOptimized      avgt        10       26.681        0.044    ns/op
UnsafeBench.buffer              avgt        10       31.548        0.493    ns/op
UnsafeBench.bufferOptimized     avgt        10       28.809        0.071    ns/op
UnsafeBench.unsafe              avgt        10       31.541        0.160    ns/op
UnsafeBench.unsafeOptimized     avgt        10       24.517        0.056    ns/op

// Integer
Benchmark                       Mode   Samples         Mean   Mean error    Units
UnsafeBench.field               avgt        10       29.582        0.153    ns/op

UnsafeBench.array               avgt        10       37.068        0.303    ns/op
UnsafeBench.arrayOptimized      avgt        10       31.804        0.125    ns/op
UnsafeBench.buffer              avgt        10       44.780        0.134    ns/op
UnsafeBench.bufferOptimized     avgt        10       39.070        0.175    ns/op
UnsafeBench.unsafe              avgt        10       37.281        0.343    ns/op
UnsafeBench.unsafeOptimized     avgt        10       29.032        0.194    ns/op

This is the reason I'm not particularly enthusiastic about this JEP. My only hope is seeing John Rose being involved with both value types and Project Panama. It's the best opportunity to highlight what a pain IPC and interacting with native APIs is, and somehow making value types/arrays possible to back with off-heap memory.
7  Discussions / General Discussions / Re: Value Types Proposal for Java on: 2014-05-03 12:49:43
The problem with the current proposal seems to be that you can't have pointers/references to value types. So yes, it's a problem for non-linear data structures. More discussion here.
8  Java Game APIs & Engines / OpenGL Development / Re: Cannot use offsets when Pixel Unpack Buffer Object is disabled? on: 2014-04-29 10:26:39
You might be able to pass "null" instead but I seem to recall there being an issue with the LWJGL impl that make that not possible. I might be wrong so you could try it.

In order to pass null to a method that has been overloaded with different buffer types, an explicit cast is required to compile, like so:

1  
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 800, 600, 0, GL_RGB, GL_UNSIGNED_BYTE, (ByteBuffer)null);
9  Game Development / Performance Tuning / Re: Taming Java GC to prevent stutter, an in-depth post on memory management on: 2014-04-25 19:08:49
This means DirectByteBuffers in particular, but if you're constructing and forgetting DirectByteBuffers every frame you're not using them as intended anyway.

The problem with direct ByteBuffers has been resolved, by making the allocating thread help with deallocations. Hopefully it'll be backported to JDK 7/8 soon.

This will have an effect on allocation performance, so princec's advice remains important.
10  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".
11  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.
12  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.
13  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.
14  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).
15  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.
16  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.
17  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();
}
18  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).
19  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".
20  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.
21  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.
22  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.
23  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.
24  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.
25  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.
26  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.
27  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?
28  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.
29  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)
30  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.
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.

CogWheelz (9 views)
2014-07-30 21:08:39

Riven (20 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (29 views)
2014-07-23 21:07:15

Riven (30 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!