Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (686)
Games in Android Showcase (198)
games submitted by our members
Games in WIP (758)
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 ... 35
1  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-08-25 14:26:39
Modular maven artifacts are now available in the snapshot repository. More details and a request for feedback, here (you may also reply in this thread if you prefer).
2  Game Development / Newbie & Debugging Questions / Re: Floatbuffer memory leak on: 2016-08-21 12:28:53
I couldn't really find any tutorials on linking stacks with lwjgl and if anyone has any please let me know.

Not sure what you're looking for exactly. It's very simple:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
// Method 1: Explicit malloc/free, useful for "big" buffers and custom lifecycles 
FloatBuffer buffer = memAllocFloat(100);
// ..use buffer..
memFree(buffer); // buffer goes away (doesn't have to be in the same method)

// Method 2: Stack allocation, useful for "small" buffers, local-only
try ( MemoryStack stack = stackPush() ) {
   FloatBuffer buffer = stack.mallocFloat(100);
   // ..use buffer..
} // buffer goes away
3  Game Development / Newbie & Debugging Questions / Re: Floatbuffer memory leak on: 2016-08-21 08:22:24
when this is called it creates a float buffer and appears to leave it in memory , my test of just having a for loop call that ended up hogging memory.

The LWJGL recommendation for performance sensitive code is explicit allocation management (memAlloc/memFree methods in org.lwjgl.system.MemoryUtil) and stack allocations (org.lwjgl.system.MemoryStack). See #4 and #5 in this post for details.

Even if you explicitly invoke the Cleaner of buffers allocated via ByteBuffer.allocateDirect, performance is going to suffer in tight loops (allocateDirect itself is slow, objects always escape so more GC pressure). See this benchmark.
4  Game Development / Newbie & Debugging Questions / Re: Getting null pointer trying to load texture with LWJGL 3 w/ runnable jar on: 2016-08-19 11:20:17
I'm using

1  
ByteBuffer data = stbi_load(file, width, height, comp, 4);


to put my png files into the game but when I create a runnable jar the app can't find my files.

The stbi_load function only works with plain image files on a filesystem. It knows nothing about the classpath and JAR files. If you really want to pack images in JARs, you'll have to do your own IO and then use stbi_load_from_memory instead.

For now I'm loading them in as BufferedImages via ImageIO.read(getClass().getResourceAsStream(file)) method call

This completely defeats the point of using stb for image IO. The LWJGL demos provide a (simple, not production-ready) method for loading resources, here. It returns a ByteBuffer with the resource contents and it works with both plain files and resources on the classpath.
5  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-08-03 11:35:03
I did the LWJGL session at JCrete yesterday. Not a great turnout, but was good fun. I got most questions from Jaroslav Tulach (NetBeans architect, now working on Truffle/Graal). Spent a bit of the afternoon with him, building Graal and exploring its source code. It sounds like it might be a great alternative to Project Panama for native interop.

Apparently he also talked to Cliff Click about it and he decided to make a session this morning on "why JNI is slow". I'm familiar with the issues and I'd seen that presentation before, so not much to learn. An interesting note was on native-to-Java callbacks: they're slow because they're always interpreted. He wasn't familiar with Panama or JNI Critical Natives. Showed him some critical native code in LWJGL at the end, I think he was a bit surprised that it actually works.

I also did a session on Kotlin today, quite a few people showed up and most of them hadn't seen it before. Not much you can do in an hour, but I think it was enough to get them started.
6  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-07-30 16:33:37
Finished packing for JCrete 2016. Super-excited, been a Java developer for 16 years and this is my first Java (un)conference. Actually, first work-related conference of any kind.

If there's interest, I'll try to do a session on LWJGL (and maybe Kotlin). Will post again if a live stream is available.
7  Game Development / Newbie & Debugging Questions / Re: LWJGL 3 glfwSetWindowIcon does not work - at all on: 2016-07-20 14:05:54
You don't necessarily need to use BufferUtils, just use BytrBuffer.allocateDirect then use the put method of the ByteBuffer to load the array data in to the buffer. BufferUtils is a useful utility method but it hides things you should really know about.

BufferUtils doesn't hide anything. It uses ByteBuffer.allocateDirect and sets the byte order to ByteOrder.nativeOrder(). Unless you're doing something very specialized (e.g. low-level networking), using the native byte order is exactly what you want. Actually, not setting the byte order has always been one of the most common issues new LWJGL users face.

As for allocateDirect itself, the post explains why avoiding it is a good idea. In LWJGL code I write, this is my decision process (from most-to-least preferred):

1) Is it a short buffer/struct that is created, used and discarded locally*? Use MemoryStack for stack allocations.
2) Is it trivial to manually free the buffer/struct? Or, is the allocation in a performance sensitive path? Use MemoryUtil for the explicit alloc/free functionality.
3) Use BufferUtils.
...
32767) Use ByteBuffer.allocateDirect() directly.

* "Local" could apply to any allocation with a lifetime of a single method up to a single frame (e.g. in the scope of the main loop).
8  Game Development / Newbie & Debugging Questions / Re: LWJGL 3 glfwSetWindowIcon does not work - at all on: 2016-07-19 20:29:17
You're using ByteBuffer.wrap in loadImageToByteBuffer. This returns a heap ByteBuffer, which is not supported by LWJGL 3. This post explains why.
9  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-07-16 17:25:23
Wrote a post on how LWJGL 3's approach to memory management enables clean and efficient code.
10  Game Development / Articles & tutorials / Re: Basics of gamma correction on: 2016-07-10 10:51:03
Another often overlooked aspect is gamma-correct mipmap creation. For the same reasons you can't do lighting and blending calculations in gamma-space, you can't do texture filtering. The mathematically correct way to downscale sRGB textures is to first convert them to linear-space, do the filtering, then store the new mip level in sRGB again. The quality difference can be significant for many textures.

Also, do not use glGenerate(Texture)Mipmap offline. It is tuned for speed and should only be called at runtime (if ever). It doesn't do gamma-correct downscaling (unless the texture is in an sRGB format and the driver feels like it) and you have no control over filtering. If you do it manually, you can always do it in linear-space and use a high-quality filter (hint: even bicubic is not a good choice for most textures).
11  Game Development / Articles & tutorials / Re: Basics of gamma correction on: 2016-07-10 10:30:03
More reading resources:

The Importance of Terminology and sRGB Uncertainty
The sRGB Learning Curve
Effective OpenGL (pdf, sections 7, 8, 9)
UHD Color for Games (pdf)
12  Game Development / Newbie & Debugging Questions / Re: [LWJGL 3] GLFW Cursor Input on: 2016-06-29 23:52:50
The most likely reason is that you're calling GLFW functions in threads that are only supposed to be called on the main thread. Please read the GLFW documentation and make sure you follow the rules. The LWJGL javadoc on each method also mentions if it can be called on any thread or only on the main thread. If you really do everything correctly and it still doesn't work, I'd be very interested to see sample code the reproduces the problem.
13  Game Development / Newbie & Debugging Questions / Re: [LWJGL 3] GLFW Cursor Input on: 2016-06-29 18:27:55
-am I still able to get mouse movement if I use GLFW_CURSOR_DISABLED? also I am calling glfwSetCursorPos every frame so ...

Yes, you still get cursor events via the callbacks. You also don't have to call glfwSetCursorPos at all.

-but the cursor doesn't even get invisible, it just stays as usual

GLFW_CURSOR_HIDDEN hides the cursor when it passes over the client area of the window. If it moves to the border or outside the window, it is visible. Isn't that what you see?
14  Game Development / Newbie & Debugging Questions / Re: [LWJGL 3] GLFW Cursor Input on: 2016-06-29 15:48:18
Your ability to recenter the mouse depends on how often your event loop runs. In most cases, even without vsync, it's not often enough. That's why using glfwSetCursorPos is not meant to be used for centering the mouse. You should try to use glfwSetInputMode with GLFW_CURSOR_DISABLED.

A few other notes:

- Using createDoubleBuffer in a loop is not efficient. Consider stack allocation (see MemoryStack) or caching the buffers.
- You don't have to rewind() or flip() after calling LWJGL methods.
- GLFW_CURSOR_HIDDEN does not restrict mouse movement, within or outside the window. It simply makes the cursor invisible.
15  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-25 18:10:27
Build 3.0.1 #6 is now available with modular artifacts. More details and progress update here.

This is what you get with the current structure:

16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-17 19:24:42
Progress update:



Needs a lot more work, but all tests and demos run fine.

The resulting binaries are roughly 2x the original lwjgl.dll size, because the CRT is statically linked in every module. It shouldn't be a problem if only a subset of them is used. Some may be merged into the core library, they're tiny without the CRT. For example JAWT and jemalloc add about 1kb to lwjgl.dll, but are 83kb and 84kb standalone (note: this is just for the JNI functions, not the libraries themselves). The corresponding modules will still be optional.
17  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 15:30:22
I think you're being a little defensive about my observations, Spasi! I'm quite aware of the 3.0.1 goals already.

I guessed so, I'm just trying to address your concerns in a way that will be understandable to everyone reading. I fully appreciate your input btw!

It's a pity to de-motivate the project lead like that.

Don't worry, there's no demotivation going on. Cas has strong opinions and gives honest advice. It's always helpful.
18  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 15:21:46
it appears to be largely driven by you and your own personal needs and as such seems to me to have become a giant git repository with all of your open source work in it.

Let's be fair here.

LWJGL 2 bindings that we ought to have in LWJGL 3:

- OpenAL
- OpenCL
- OpenGL
- OpenGL ES
- EGL

Bindings that were absolutely necessary in LWJGL 3:

- GLFW (Display + input API replacement)
- Vulkan (a good match for LWJGL and also the most user requested API)
- dyncall (FFI + dynamically generated native-to-Java callbacks)
- Basic system calls

Bindings requested by users:

- JAWT
- LibOVR (Oculus SDK)
- NanoVG
- SSE(3)
- Misc system calls

Bindings that I added without anyone asking, but everyone agreed were extremely useful:

- jemalloc
- stb (image IO, font rendering, vorbis decoding, etc)

Bindings that I added without anyone asking, are not that exciting, but try to solve real problems LWJGL users face:

- NativeFileDialog
- Nuklear
- libstem_gamepad (in a branch, failed experiment, to satisfy concerns about GLFW's gamepad support)

Bindings that I added without anyone asking, either from curiosity or because I needed them for personal work:

- xxHash (tiny & fast non-cryptographic hash functions)
- LMDB (post 3.0.0)
- ODBC (mostly complete branch)
- hwloc (incomplete branch)

I hope it's obvious that the majority of the work I did was driven by user needs. The only personal binding that made it to 3.0.0 is negligible compared to the rest.

What it definitely isn't, modular or not, is a lightweight Java games/graphics library! It's no longer a lightweight project as it covers everything from GUIs to compute to audio to in-memory databases to hacking the Java language to get structs in.

I would argue that it is indeed lightweight because it doesn't do anything. None of the APIs or functionality provided by LWJGL has been designed or written by LWJGL developers. The only thing the LWJGL core provides is a half-decent way to interact with native APIs and data from Java/JVM.

Also, why is any of the above an issue if #100 allows you to download LWJGL core, GLFW, OpenGL and OpenAL and nothing else?

It's not Java any more as it now contains multiple binary libraries. It's not a single library now but a whole multitude of libraries.

I don't get this. Why does it matter how many binaries there are? Deployment issues are a thing of the past with the SharedLibraryLoader. LWJGL 2 also had two native binaries (lwjgl + OpenAL Soft), now there are 2 more (GLFW and the optional jemalloc). How's that less Java than before?

What LWJGL 3 is now is a vast collection of bindings, most of which are irrelevant to most people. What this means is that maintenance effort is going to be simply non-existent on it, and once you (eventually) grow tired of it, and you will, it'll just stagnate and get bitrot and become a large legacy which will distract people from otherwise creating separate efforts to solve specific issues.

There is a very critical difference. Once Elias stopped working on LWJGL we were screwed, because there was no one with the experience to improve/fix the OS-specific functionality. There's no expertise required to maintain LWJGL 3. Someone has a problem with GLFW? Open an issue on their github and (if it's legit) elmindreda will fix it eventually. It's not our problem anymore.

I lost interest in maintaining LWJGL after a few years of developing on it, largely because it did everything I needed it to by that point, and also because I was seeing virtually no return on my efforts. I watched Markus accumulate two and a half billion dollars on the back of the literally months and months of effort I'd put in on the library he used to catapult himself into the realms of the unspeakably rich with barely so much as a thankyou, and that, for me, was the point at which I decided I couldn't be arsed with open source any more. I only have so much time left in the world and a lot of things I'd like to do, and making Markus richer wasn't on the list, so I diverted my efforts elsewhere. At some point, you too will find something more interesting and distracting, and you'll be leaving behind a huge, huge pile of stuff which no-one except you really cares too much about.

Oh, I do have something a lot more interesting to work on. Wink That's why I've put a huge effort into making LWJGL 3 easily maintanable.

On seeing a return on open-source efforts... I don't know, that's not what open-source is about I guess. I even removed the option to donate to LWJGL when I took over. Didn't feel right without having something to deliver. On the other hand, what we have been doing in LWJGL isn't just open-source... Writing JNI bindings is on its own level of masochism. It's the kind of open-source that no one wants to be doing. That usually has value. When my wife asks what I'm doing, I wish I had something better to say than "omg I'm writing Vulkan bindings, do you know how IMPORTANT this is?". Especially with the economy in Greece being what it is.

On Minecraft, I cannot claim any credit for what LWJGL was when Minecraft happened. Maybe Cas is right, I don't know. What I do know is that post-Minecraft success, its users had lots of trouble because of LWJGL and we didn't do much for them. We never had much of a contact with Marcus or their devs either, which I found strange given how critical LWJGL was for the game. Strange situation.

I strongly advise you to split LWJGL up into the bare minimum and then create separate, independent projects that build on top of or besides LWJGL for GUI libraries, structs, OpenCL, in-memory databases, vector math, etc.

Having everything in the same repo, in branches, or in different repos, is just a technicality. The only thing that matters is how the software is deployed. With #100 + a few other ideas we had recently, I believe everyone will be satisfied.
19  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 10:33:53
I might actually rip a lot out of the jar if thats the case.

This is possible and some users do it. You can remove any binding package you don't need from lwjgl.jar and you can also delete the jemalloc/GLFW/OpenAL shared libraries. #100 will make it so that you don't have to do it manually and will also split the lwjgl shared library itself (which contains the core functionality + statically linked bindings).
20  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 10:16:32
This is why I waited for the 3.0.0 release before merging the LMDB branch. I expected some controversy and wanted to see if enough users would find it useful first. Currently LMDB only exists in a nightly build of 3.0.1. No harm has been done. This is also the 3rd time I have to mention in this forum that 3.0.1 will not be released without a solution for #100, which will break the LWJGL distribution in separate artifacts for each binding; you will be able to choose what you want or don't want in your application.

I'm really not at all sure how this fits in with LWJGL, either in a gaming context, a general purpose graphics context

Offering solutions for gaming and graphics has always been LWJGL's primary objective and what most people in this forum care about. But it's not only about that. Which makes sense since I'm (almost) the sole developer, I use it a lot in my projects and I don't make games.

I bet no more than 5 users have ever used LWJGL's OpenCL bindings, yet I find them super-important and have spent countless hours working on them. Why aren't there any complains about those?

or even in a Java context... I'm very reluctant to bind to native code to do stuff that Java code can do. The LWJGL was all about binding to native APIs that could not otherwise be done in Java

I don't agree with this either. Just because something can be implemented in Java does not mean it should. I've actually done it: JGLFW. It was a GLFW implementation written entirely in Java, using only bindings to OS functionality. It was an experiment to validate LWJGL 3's approach to JNI and I gladly deleted it when I became satisfied it worked nicely. Why?

- Look at the mess LWJGL 2 was in. There were dozens of bugs and no one to fix them. Who's going to write a decent windowing system in Java (or anything that touches lots of OS-specific APIs like GLFW and LMDB) and maintain it?
- A Java binding to a native library means that Java developers benefit from the existing community in many ways: more example code out there to get you started, more users testing the same code, more users contributing fixes. The existing community benefits too, Java developers can contribute feedback and fixes to the native library (there are many examples of that in GLFW already). Overall, the bigger the ecosystem around a library the better for everyone involved.
- Why reinvent the wheel?
21  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-06 18:31:53
1. This link doesn't work :

Thanks, fixed.

2. I understand what the LMDB is, I can think of non gaming scenario's where this is very useful. But what do you see as the use case in a gaming sense for a database (and one that is super fast)?

I mentioned some ideas in the first post. I often see game developers creating custom solutions for storing user settings, game saves, metadata for shaders/models/textures, game levels, etc. I think replacing all that with a robust, easy-to-use and very efficient database like LMDB would be useful. It can even be used to store binary blobs (meshes, textures, sounds, shader binaries).
22  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Nuklear bindings on: 2016-06-06 15:08:37
I wouldn't recommend this become part of "core" LWJGL but it'd be a welcome bolt-on library. That said... it would maybe just be better off as an entirely separate project dependent on LWJGL3?

The 3.0.1 release will have a solution for #100. The LWJGL core and most of the "heavyweight" bindings (including Nuklear) will be separate artifacts.
23  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-05 13:44:44
tho' i'd be more intersted in LMDB stand-alone bindings.

That will be 3.0.1's primary feature.
24  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3 - Nuklear bindings on: 2016-06-05 11:29:47
As part of the effort to add a useful GUI solution to LWJGL (see #101), the first LWJGL 3.0.1 build includes bindings to Nuklear, a minimal state immediate mode GUI toolkit. It is similar to imgui, but with a C API.

This is an experimental binding. Please post any impressions or problems you might have here (or open an issue on Github).
25  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-05 11:21:44
The first LWJGL 3.0.1 nightly build is now available and it includes LMDB.
26  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.0.0 released on: 2016-06-03 18:30:55
Visit the download page to get it. You can also get it from Maven Central or this direct link.

Release notes (since 3.0.0b):

BINDINGS

- Added support for Java array parameters and HotSpot Critical Natives. (#175)
- Added Vulkan bindings. (#50)
- Added NanoVG bindings. (#99)
- Added NativeFileDialog bindings.
- Added par_shapes.h bindings.
- Added dyncall bindings.
- Added jawt bindings for AWT/Swing integration. (#125)
- Added simple OS-specific window creation bindings, for custom window/context creation. (#105)
- Added missing OpenCL and OpenAL extensions.
- Fully documented OpenCL and OpenAL.
- Moved WGL and GLX capabilities to the new WGLCapabilities and GLXCapabilities classes, respectively. Functionality in WGL, GLX and corresponding extensions that does not require a current context can now be used without creating a dummy context first. (#171)

IMPROVEMENTS

- Added stack allocation APIs (the MemoryStack class and new allocation methods in struct classes and MemoryUtil).
- Made the implementations of PointerBuffer and Struct/StructBuffer subclasses as lightweight as possible. This makes it easier for escape analysis to eliminate allocations.
- Minor struct API improvements.
- Added nullability information to struct members, to protect against buggy code crashing the JVM.
- All bindings are updated to the latest versions of the corresponding libraries. Notably, GLFW now has glfwSetWindowIcon and glfwSetWindowMonitor, it now doesn't lack anything compared to LWJGL 2's Display.
- Refactored callbacks for Java 8. (#182)
- Added NativeResource interface and made freeable objects usable as resources in try-with-resources statements. (#186)
- Faster thread-local lookups for the stack and current capabilities. New options in Configuration can be used to complete eliminate thread-local lookup in OpenGL, OpenGL ES and OpenAL, when it is known that only a single context will be used, or that all contexts will be compatible (same capabilities and same function pointers).
- Added memSlice for all buffers types in MemoryUtil. (#179)
- Refactored the Configuration class for type safety and added more options.
- JDK 9 can now be used to build and run LWJGL.
- Javadoc is now generated with JDK 9. The API is fully indexed and search functionality is available. Also made multiple Javadoc formatting improvements.
- Improved debug diagnostics on startup and when loading the LWJGL shared library fails.
- Optimized memSet and memCopy for small buffers.

FIXES

- Stopped using UPX compression for binaries. This eliminates various integration issues and virus scanning false-positives.
- The SharedLibraryLoader now works with any shared library, not only libraries LWJGL knows about. (#176)

BREAKING CHANGES

- LWJGL now requires Java 8 to build and run. Certain custom interfaces have been replaced with java.util.function interfaces. (#177)
- Dropped support for Linux x86. (#162)
- Dropped libffi bindings.
- Dropped ALDevice/ALContext wrappers from OpenAL and CLPlatform/CLDevice wrappers from OpenCL. (#152)
- Dropped the getInstance() method from bindings loaded from shared libraries. Function pointers are now stored either in capabilities classes or in a nested Functions inner class.
- Dropped infrequently used method overloads in bindings. Full javadoc is now generated on (almost) all overloads.
- Dropped utility classes that were not useful.
- Added AutoSize support to struct members. Instance setters for the corresponding count/size members were removed to avoid bugs and confusion.
- Replaced MemoryUtil.memFree(StructBuffer) with StructBuffer.free().
- Renamed __ALIGNMENT to ALIGNOF in struct classes.
- Removed org.lwjgl.system.Retainable interface. Closure and FunctionProvider subclasses are now destroyed using .free() instead of .release().
- Moved xxHash and SSE bindings to the org.lwjgl.util package.
- Integer-boolean native types (0 or 1 are the only legal values) are now mapped to Java booleans. (#181)
- Macros without parameters are now generated as static final values, not methods.
27  Game Development / Newbie & Debugging Questions / Re: LWJGL3 Jar Unable to extract LWJGL natives on: 2016-06-02 11:09:34
For the SharedLibraryLoader to work, the native libraries must be in the classpath.

I tried adding the following to the first line of my static void main(String... args) method:
1  
Configuration.LIBRARY_PATH.set(new File("libs/LWJGL 3.0.0b/native").getAbsolutePath());

Note that
new File("libs/LWJGL 3.0.0b/native")
will create a path relative to the working directory. Make sure it is the root of your project and it should work.
28  Java Game APIs & Engines / JavaFX / Re: JavaFX For Pixel Games on: 2016-06-02 11:00:54
I gave up JavaFX when I ported prism to LWJGL3. With such a horrible backend design and implementation, it's not surprising that progress is slow, performance suffers and simple features cannot be added easily.
29  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-05-27 20:11:59
Some examples:

SnippetTest
Vector
UnixSystem

Btw, a Scope object is "a unit of resources allocation that can be released all together". The current prototype has the NativeScope and HeapScope classes. The later uses long[] as the backing memory (on which you can map structs etc).
30  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-05-27 14:15:41
Any mention of stack allocation and value types in the same sentence makes me wonder whether they're going to design what we actually need or whether they're just going to go off on one and make something almost but not quite entirely wrong.

The current Panama prototype supports "machine code snippets". You can write some code outside the JVM/JDK that makes the JVM inline and JIT-compile a method handle to one or more native CPU instructions (of your choice) that also play well with the JVM register allocator. This functionality alone could be used by a library to do amazing things.

API-wise, I wouldn't expect anything pretty without syntactic sugar. But it is true that it is designed under the assumption that Java 10 will have value types and any-generics. This, in theory, will allow Java-ish code to perform just like native C.
Pages: [1] 2 3 ... 35
 
roseslayer (568 views)
2016-08-06 11:43:29

roseslayer (524 views)
2016-08-06 09:43:11

xTheGamerCodes (596 views)
2016-08-04 15:40:59

xTheGamerCodes (591 views)
2016-08-04 15:40:24

orrenravid (937 views)
2016-07-16 03:57:23

theagentd (1014 views)
2016-07-11 14:28:54

Hydroque (1112 views)
2016-07-06 05:56:57

Hydroque (1068 views)
2016-07-03 08:52:54

GrandCastle (886 views)
2016-07-01 09:13:47

GrandCastle (647 views)
2016-07-01 09:09:45
Rendering resources
by Roquen
2016-08-08 05:55:21

Rendering resources
by Roquen
2016-08-08 05:52:42

Rendering resources
by Roquen
2016-08-08 05:50:38

Rendering resources
by Roquen
2016-08-08 05:49:53

Rendering resources
by Roquen
2016-08-08 05:32:39

Making a Dynamic Plugin System
by Hydroque
2016-06-25 00:13:25

Java Data structures
by BinaryMonkL
2016-06-13 21:22:09

Java Data structures
by BinaryMonkL
2016-06-13 21:20:42
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!