Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
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  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.
2  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).
3  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.
4  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.
5  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).
6  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.
7  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.
8  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.
9  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:

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.
10  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):

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.
11  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.
12  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:

1  
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 800, 600, 0, GL_RGB, GL_UNSIGNED_BYTE, (ByteBuffer)null);
13  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.
14  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".
15  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.
16  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.
17  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.
18  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).
19  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.
20  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:

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.
21  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:

1  
2  
3  
4  
@Override
public void foo() {
   B.super.foo();
}
22  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).
23  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".
24  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.
25  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.
26  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.
27  Discussions / General Discussions / Re: AMD has revealed an API that gives developers direct access to GPUs using ... on: 2014-01-30 11:03:30
First real-world results: Mantle renderer now available in Battlefield 4. Up to 58% faster in a high-end configuration.
28  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL: Random direction thoughts on: 2013-12-18 17: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.
29  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL: Random direction thoughts on: 2013-12-18 16:33:14
It's 7 year old code related to AWT interop. Most horrible stuff in the LWJGL codebase are related to it.
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Wiki and a progress update on: 2013-12-01 19: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.
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.

Nickropheliac (16 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (42 views)
2014-08-19 09:29:53

Tekkerue (41 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (26 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (73 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!