- Remove applet
- Remove webstart
- Refactor all generation to the `target` folder
- Remove eclipse-update
- Update java version in `.tool-versions`
- Update `.gitignore`
- Remove unused `res` folder
- Only macOS builds work currently
- TODO: finish the aforementioned changes to all other targets
- `build.sh` runs in headless mode to avoid the focus stealing and
performance issues on macOS
Note that javac still always recompiles everything. This makes the build process slower than before (apt was using the already compiled templates as input). Will investigate some other time if this can be mitigated.
This is a manual merge of request #86 by @b23prodtm. The original patch is fantastic, but as expected has a few issues that will be fixed in subsequent commits.
Modified the generator process to use relative paths. We were hitting the command line length limit on Windows.
Some extension improvements, fixes and spec updates.
Added support for AMD_name_gen_delete and AMD_debug_output. The AMDDebugOutputCallback class enables query-less message handling.
Added support for extension aliases.
Cleaned up Drawable interface and introduced a reusable base implementation.
Added support for disabling runtime function checks, buffer checks and state tracking. Activated with -Dorg.lwjgl.util.NoChecks=true
Added support for initializing extensions that are not exposed in GL_EXTENSIONS (enables EXT_direct_state_access and NV_primitive_restart on AMD GPUs, use at your own risk).
Updated @Optional functions for AMD GPUs (driver version: 10.3)
Changed shader tests to use the String APIs
Finished ARB_uniform_buffer_object shader test
Fixed native code compiler warnings
Made the generator check file timestamps to avoid unnecessary 3+ min builds
Removed support for indirect buffers as arguments to GL functions
Added missing tokens in GL30 & GL32
Added support for AMD_seamless_cubemap_per_texture & AMD_shader_stencil_export
Fixed AMD_vertex_shader_tessellator typo
Added AMD extensions to the build process >.<
1. We can now support calls like "glLight(..., ..., FloatBuffer.wrap(new float[] {...}));" without worrying about running out of direct memory heap,
since both the FloatBuffer and the array are allocated on the java heap. Future JVMs with stack allocation support could improve this even further.
2. We avoid getting in the way of users that doesn't (yet) know why direct buffers are important.
Obviously, we'd like direct support for arrays, but non-direct buffers are a nice compromise that avoids the API bloat that results when almost all
functions gain an overloaded versions that take arrays instead of buffers.
Notes:
1. Non-direct buffer support should not affect the performance in the direct buffer case, since the non-direct buffer code path is only activated
when the isDirect() check fails, and we were already checking isDirect() for sanity checking.
2. When using non-direct buffers, the buffer contents (remaining() bytes) are copied to a resizable ThreadLocal cached direct buffer (which is
resized as needed) and used instead of the non-direct buffer. Thus, performance of non-direct buffers is lower than direct buffers.