JME 3.3 beta2 pet issues?

I’m off work on Monday and I’m hoping to spend some time going through the commits since 3.3 beta1 to see what needs to go into beta2. I’d really like beta2 to be the last 3.3 release before just renaming it stable and pushing a stable release.

Consequently, I want to make sure that I don’t miss some critical commit as I’m going through them. My criteria for choosing may be different than yours but that doesn’t mean I can’t be talked into something. :wink:

If you have a commit that you know needs to go into beta2 then please let me know.

Base criteria for 3.3 beta2 cherry-picking:

  • the commit does not add a new feature, 3.3 is feature-frozen
  • the commit does not break or alter existing API behavior (other than fixing a bug)

The second one is where there is sometimes a narrow gray area worth discussing.

We have about 48 hours before I’m going to think about tagging the branch. Hopefully that’s enough time to weigh in.


@pspeed thank you for your work on this.

I feel this is a issue that should get resolved before a 3.3-stable.
Causes the context to not be resizable. Thus resolution cannot be changed after launch, and resizing the window has no effect on the context. No PR currently available.

I know it has been broken a long time, but it would be really nice to get this fixed as it is a basic function.

Anyways, thank you for working on this!


A few commits I’d particularly like to see included in v3.3:


If it’s not fixed then it I can’t cherry-pick it in. And I’m not fixing things just releasing what’s there.

So the choice is release what’s there or wait until someone fixes this… ie: wait indefinitely. Which I’m also fine with because that’s 0 work for me.

Either way, if someone wants this fixed then they’ll need to fix it. It doesn’t affect me personally so it’s not likely an itch that will bubble up in my personal priority… though I do think it’s important.

What about these ones?



yay! beta 2! :slight_smile:

i dont know more issues than a described one.

b059c7c0 Fix #1236 non-lvalue cannot be out parameter

is just very important for myself. Could be good if issue 1303 would go forward, but i belive its too late for beta2.

Yeah, to be clear I’m not fixing anything new… just looking at what I should cherry-pick from master into the 3.3 branch. The commit has to exist first before I can do that.

I will add the commit you mention to my list, though.

1 Like

In the past 24 hours, @tonihele developed a fix for issue 1191 (TestResizableApp crash with LWJGL3 on Windows), @Murph9 reviewed it, and I integrated and tested the PR. Teamwork!

So please add one more commit to the v3.3 cherry-picking wishlist:


Looks like the 3.3 beta2 build worked:

Release info here:

I included a change log of the commits I cherry-picked if anyone wants to double check my work.

I’ll post a real beta2 thread later, I guess.


Thank you, Paul.


Damn, I just realized we should’ve added the PBR Shader fix to beta2, but I guess it’s too late now?

1 Like

Awesome, Mr. Speed! Should I or someone else make a blog post for this? We have not had one in a month anyways.

1 Like

good point. everyone forget about homepage blog.

1 Like

Should I add it now?

if you have good idea how to write it :slight_smile: it will anyway need to be peer review before.

Who would review it?
And would that be before/after I make the .md file in the website directory on gh?

you have direct access to make commits? or you make Pull request first?

(i thought the second one)

if it gonna be pull request, then someone will need look at it anyway to approve.

To me at least looks like I can directly make a new file if
this is what your talking about

Forgive me I am new to using gh if I don’t know something

Of course if I need to I’ll make a pull request.

huh, now im surprised, i also have this button in every possible github project.

But i dont think it will just work, because then everyone could push files into someone repos(without approve)…

1 Like