Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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 ... 26
1  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3; how's it getting along? on: 2014-09-27 11:16:42
I just pushed a commit that completes the support for all ARB and KHR extensions. The OpenGL core (1.1 to 4.5), all ARB/KHR extensions and the OpenCL core (1.0 to 2.0) include full documentation. This has been the bottleneck so far, but totally worth the effort imho. I'm sure many improvements and fixes will be needed in the future, but I consider that work done for the first LWJGL 3 release.

The next step is adding support for EXT and vendor-specific extensions. I'll skip documentation for those, to speed things up, it can be added at a later point (hopefully by contributors). I'll also aggressively cull obsolete extensions. There are hundreds of extensions, so let me know if you have specific needs and I'll try to prioritize those.

Note that I plan to make the build process configurable, so that only a specific subset of the supported bindings is included in the final binaries. This will allow advanced users to create custom LWJGL builds, with only the functionality they care about. So, I'm open to supporting any extension or API (Mantle? D3D12?), as long as there's someone out there whose going to find it useful.

As for the first beta release, recently I've been investigating options for setting up nightly builds. Both for LWJGL itself and its binary dependencies (currently GLFW, libFFI and OpenAL Soft). I'm hoping that by the time GLFW 3.1 is released, the nightly builds will be up and running. I'll also try to freshen up the wiki.
2  Discussions / General Discussions / Re: Java 8 Default Methods and Multiple Inheritance on: 2014-09-15 19:28:48
The only benefit is arguably IDE code completion. IMO, this value doesn't justify a new feature. default implementations are arguably better because implementations can override behavior

You can "override" extension methods in subclasses. Assuming both of these are available in the current scope:

fun <T: CharSequence> { ... }
fun { ... }

doing a
invokes the second implementation, the extension method on the most specific type.
3  Discussions / General Discussions / Re: Java 8 Default Methods and Multiple Inheritance on: 2014-09-15 16:04:17
Adding something to an interface, whether its a normal or a default method, is a design choice. A choice you'll have trouble taking back later. In that sense, I agree with the view that default methods is a workaround for safely extending legacy APIs and that's how I intend to use them.

For new systems, for fresh design choices, I have moved away from Java to other JVM languages that support more powerful features. Kotlin and Xtend for example support extension methods, which have the same benefits as default methods, but without polluting the interface. They have their own scope and their own visibility level. You can even define them locally inside another method. So, if you're thinking about designing a system around default methods, what you really want is extension methods. C# had them for a long time, but we can now have them on the JVM. Kotlin also has extension properties, which are fantastic for writing cleaner code. My favourite example would be:

public val Int.b: Byte get() = (this and 0xFF).toByte()

which is great for graphics when dealing with unsigned bytes, e.g. you can write
. Will become even more useful when we get value types in the JVM.
4  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LibStruct on: 2014-09-11 14:37:47
should i still hope for primitive-generics in java ?

Yes, it's part of Project Valhalla.
5  Game Development / Newbie & Debugging Questions / Re: opengl MSAA resolve efficient ? on: 2014-08-19 21:46:59
You might want to have a look at the latest AA techniques presented at Siggraph 2014:

High Quality Temporal Supersampling (there's a link to the presentation in "About")
Hybrid Reconstruction AA

Lots of info on the technical difficulties and various trade-offs in there. Temporal AA easily beats anything you can do in post, so current research focus is on how to make it work better and combine it with other techniques. I believe it's a must, especially for deferred.
6  Discussions / Miscellaneous Topics / Re: A rant on OpenGL's future on: 2014-08-16 13:02:04
When's LWJGL 2.9.2 releasing so I can start playing around with GL 4.5? Smiley

Support for OpenGL 4.5, as well as the new extensions released with it, has been added to both LWJGL 3.0 and LWJGL 2.9.2 (see the next nightly build).
7  Discussions / Miscellaneous Topics / Re: A rant on OpenGL's future on: 2014-08-11 17:42:51
ARB_clip_control: Except for the purely convenience features this provides when porting from DX, it can also be used to improve depth precision slightly. This could be solved before as well, but was a bit unclear and hacky.

A detailed explanation of why this is useful.
8  Discussions / Miscellaneous Topics / Re: A rant on OpenGL's future on: 2014-08-11 14:35:38
if there's any near future hope

Yes, there is.
9  Discussions / Miscellaneous Topics / Re: A rant on OpenGL's future on: 2014-07-15 18: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).
10  Discussions / General Discussions / Re: [opengl] Why are LWJGL enums as integers? on: 2014-07-11 18:06:48
There will be a usable build for public testing after GLFW 3.1 is released.
11  Discussions / General Discussions / Re: [opengl] Why are LWJGL enums as integers? on: 2014-07-11 17: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.
12  Discussions / General Discussions / Re: Java 8 on Raspberry Pi on: 2014-06-18 21: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.
13  Discussions / Miscellaneous Topics / Re: Random syntax tweaks! on: 2014-06-03 19: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:

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.
14  Discussions / General Discussions / Re: JEP for making Unsafe a public API on: 2014-05-09 15: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):

// 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.
15  Discussions / General Discussions / Re: Value Types Proposal for Java on: 2014-05-03 10: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.
16  Java Game APIs & Engines / OpenGL Development / Re: Cannot use offsets when Pixel Unpack Buffer Object is disabled? on: 2014-04-29 08: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:

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 800, 600, 0, GL_RGB, GL_UNSIGNED_BYTE, (ByteBuffer)null);
17  Game Development / Performance Tuning / Re: Taming Java GC to prevent stutter, an in-depth post on memory management on: 2014-04-25 17: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.
18  Java Game APIs & Engines / Engines, Libraries and Tools / Re: FFI JEP on: 2014-03-18 01: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".
19  Game Development / Shared Code / Re: Multithreaded arithmetic benchmark on: 2014-03-17 21:53:43
I highly recommend JMH for all kinds of benchmarking, for many important reasons.
20  Java Game APIs & Engines / OpenGL Development / Re: LWJGL bug: Duplicate enums in GL43 on: 2014-03-11 11:03:26
Please try the next nightly build, I have removed all duplicate tokens from the core GL classes.
21  Discussions / Miscellaneous Topics / Re: C++ standard library is really lacking - good or bad? on: 2014-03-06 11:09:27
A new post on value types by John Rose.
22  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL check for available contexts on: 2014-03-02 15: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).
23  Java Game APIs & Engines / Engines, Libraries and Tools / FFI JEP on: 2014-02-24 19: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.
24  Discussions / General Discussions / Re: Someone brought up an interesting topic regarding the new JDK8 default methods. on: 2014-02-08 12: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:


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.
25  Discussions / General Discussions / Re: Someone brought up an interesting topic regarding the new JDK8 default methods. on: 2014-02-08 09: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:

public void foo() {;
26  Discussions / General Discussions / Re: Someone brought up an interesting topic regarding the new JDK8 default methods. on: 2014-02-08 08: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).
27  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-02-01 01: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".
28  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-01-31 15:27:49
and an attempt to apply Mantle's design to OpenGL.
29  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-01-31 12:10:18
Mantle functions, the list.
30  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-01-30 14: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.
Pages: [1] 2 3 ... 26

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

The first screenshot will be displayed as a thumbnail.

Longarmx (39 views)
2014-10-17 21:59:02

Norakomi (30 views)
2014-10-17 09:22:06

Norakomi (24 views)
2014-10-17 09:20:20

lcass (28 views)
2014-10-16 10:18:58

TehJavaDev (57 views)
2014-10-14 18:39:48

TehJavaDev (58 views)
2014-10-14 18:35:47

TehJavaDev (48 views)
2014-10-14 18:32:37

BurntPizza (64 views)
2014-10-12 17:24:42

BurntPizza (36 views)
2014-10-12 17:10:45

BurntPizza (78 views)
2014-10-12 16:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06 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!