Hello Guest

Recent Posts

Pages: 1 [2] 3 4 ... 10
General Java Game Development / Re: Framebuffer debug
« Last post by Evgeny on January 24, 2021, 14:39:17 »
Does somebody know something else about it ? Developers where are you ? :)
Lightweight Java Gaming Library / Re: Interpreting Crash Logs
« Last post by spasi on January 23, 2021, 20:46:10 »
When crashing in the graphics driver (like this example), your best bet is an OpenGL debug context or Vulkan's validation layers. You should be able to get some helpful output before the crash happens.
Lightweight Java Gaming Library / Interpreting Crash Logs
« Last post by mudlee on January 23, 2021, 14:57:00 »
Hi Guys!

In my spare time when my health issues give me free brain, I'm experiencing with a Vulkan & OpenGL basic renderer. OpenGL is "easy", but I'm a beginner at Vulkan. I think I now know how to use LWJGL, its memory management, but looks like I just cannot find, where I freed up something that shouldn't be freed up.

I attach the crash log here: https://gist.github.com/mudlee/3c4ca97eb28bc4e8315b39d4c490dff7. My question is not just which object is freed up it ain't not be, but also how can I interpret such a crash log to understand similar problems in the future? :)

The log, clearly says that vkCreateImageView fails, but I can't harvest out the info, which object it depends on which is not available anymore.

The project is btw available here: https://github.com/mudlee/spck-framework

Thanks for help!
Bug Reports / RFE / Re: [SOLVED] GLSL error with smoothstep
« Last post by Deornoth on January 23, 2021, 13:52:14 »
I see that a resolution was not reached.

I had the same problem: linking my shader caused this same stack overflow, and it only occurred on older machines.  It seems to be relatively common, as it occurred independently on most of the laptops I tested it on.

The issue was with the smoothstep function.  I was able to workaround the issue by implementing my own smoothstep function:

Code: [Select]
float happy_smoothstep(float a, float b, float x) {
    float t = clamp((x - a) / (b - a), 0.0, 1.0);
    return t * t * (3.0 - (2.0 * t));

Lightweight Java Gaming Library / Re: Apple M1 Support
« Last post by spasi on January 21, 2021, 16:34:15 »
Thanks mudlee! I'll post in that issue when/if I need help with testing.
Lightweight Java Gaming Library / Apple M1 Support
« Last post by mudlee on January 21, 2021, 15:30:39 »
Hi Guys!

I saw a github issue, where you started to discuss with a Minecraft (or MS) developer, how can Minecraft run on the new Apple M1. As I remember, some of you wrote that currently you don't have any M1 device available.

Here, I'm volunteering to test if you need any help as I got a macbook pro with M1 chip. If you need help in testing, please ping me.

General Java Game Development / Framebuffer debug
« Last post by Evgeny on January 17, 2021, 19:36:01 »
I use lwjgl 3.2.3 and I have some problems with fbo. How can I enable debug mode for fbo ? I found  glCheckFramebufferStatus only.
This thread is somewhere between a discussion and a question thread, please speak your mind freely...

One of Java's strength is the fact that the JRE exists on multiple platforms. As such, assume we have our nice Java game up and running, playing great and having zero bugs  ;)

Now, how to we pack it together and deploy it best? Users (or customers even) do not want to play through a programming IDE or fiddle with arguments in the command line. They want to double-click on an Exe, a launch-script or a button/link in Steam (or whatever their favorite platform is, mine is GoG). Furthermore, they do not want to manually install any dependencies, ideally they do not want to "install" anything at all, it should just magically "work"  ::).

Granted, of course we still have installers today. Granted, of course we still install dependencies today, just remember how often you installed some Visual C++ Redistributable today. But the purpose of this topic is to discuss how to deal with the problem best in a Java context, an LWJGL-context even, leveraging the fact that our code runs on all the big OS out there if a compatible JRE is tagging along.

In short, we need to deploy the following things to a user's machine:
* our compiled Java Source Code (in some shape or form, e.g a JAR)
* our native codes, e.g. LWJGL or the STB-library, in a distribution matching the platform of the user
* a Java Runtime in a distribution matching the platform of the user
* our game assets, that means its graphics, its sounds and the whatnot

Depending on our build system, aka how we manage our code during development, some of this stuff might be easier, harder or just different. A Maven build works differently from a Gradle one, a manually managed project is an entirely different beast ...

For sake of example, assume we have a Maven-managed project with LWJGL (and thus its natives) only, some graphics and of course some Java Code. If we manage to distribute this, the more complex cases will follow. Furthermore, assume that our distribution simply takes the form of a (zipable) directory which is supposed to run standalone on any somewhat modern PC of today onto which we copy said folder. No "installer", no custom compression, no registering the game in same OS-specific registry, no programmatic removal...

The way I see it, there are two big approaches pre-Java 14:

1.) doing it by hand
You download the JRE for the target OS and place your compiled JARs of your maven-target next to it. Furthermore, you place your game's assets there as well (in the dir-structure your game requires) and you do the same with OS-compatible LWJGL natives you need.
Finally, you write a little native program in some other programming language that, on launch, executes the JRE with your JAR (and potentially all the other relevant file locations) as input.

2.) the build-system approach
This is similar to the above, but you leave the asset management to your build system, e.g. Maven. This probably has benefits if you are using classpath-resources. Natives and graphics get packed into your JARs as well or are already part of a JAR, like lwjgl-natives. Note however that since most OS only load native libraries from a "true" file, files from lwjgl-native will be regularly unarchived into a user's temporary directory by LWJGL.
For the rest, you procced as you did above, that means having the JRE somewhere in your distribution and writing a little launcher application.

With Java 14, a new way has arisen (or came back) and as such, the rather new JPackager needs to be discussed. This thing is supposed to construct a pseudo-native Application containing the relevant parts of the JRE necessary for your program, but I have little experience with this technology thus far. With respect to our example, it seemingly overcommits, since it does in fact build an installer around the distribution, but everything else sounds good. How it interoperates with existing native code of the project, like LWJGL, is unclear to me. If somebody here has experience with the thing, please share your thoughts or even a practical example.

So, considering our goal of deploying a hassle-free, runable distribution, what are your thoughts on the matter?  :)
Is there an established practice for LWJGL programs? Is it worth to check out what libgdx does or is that too far removed from the pure Java with a little lightweight native that LWJGL represents?
Lightweight Java Gaming Library / Re: Does LWJGL 3 officially run on M1 Mac?
« Last post by spasi on January 12, 2021, 06:47:56 »
Not yet, but ARM support for macOS and Windows is being worked on for the next release.
Lightweight Java Gaming Library / Does LWJGL 3 officially run on M1 Mac?
« Last post by seokhyun0504 on January 11, 2021, 14:20:41 »
When I run on the M1 mac with the tutorial code, I got this Error Message

Code: [Select]
Description : Cocoa: Failed to find service port for display
Stacktrace  :

How this Message is appeared and how can I fix it?
i dont know the m1 architecture system and macos environment

(sorry for my english writting, cuz i'm learning english now)
Pages: 1 [2] 3 4 ... 10