In a nutshell, what's not working actually ?

[Moe]

3. love.event.quit/love.event.push('q') (some way to quit)

Just wrote the code for it. Pray for bad weather tomorrow so that I will test and commit it. If not ... nah, you don't want me to do "if it compiles, ship it".

After some JNI hell it is implemented and works fine.

[T-Bone]

3. love.event.quit/love.event.push('q') (some way to quit)

Just wrote the code for it. Pray for bad weather tomorrow so that I will test and commit it. If not ... nah, you don't want me to do "if it compiles, ship it".

After some JNI hell it is implemented and works fine.

Awesomesauce! Will check it out this afternoon (as well as installing the SDK/NDK on my new Ubuntu install).

That means only two more features to go!

[T-Bone]

Quitting does NOT work with the latest version on github. Instead, unlike before, love.event.push('q')/love.event.quit() simply crashes the app. Was the quitting fix submitted to github?

[bartbes]

love.event.push('q')

I seriously hope you're using 'quit', though. (If not, and you are referring to 0.7.2, then quit() isn't there.)

[T-Bone]

love.event.push('q')

I seriously hope you're using 'quit', though. (If not, and you are referring to 0.7.2, then quit() isn't there.)

Well, it's still built on 0.7.2 so love.event.push('q') is probably the one we're using. But since both have been mentioned, I guess he could have implemented love.event.quit somehow as well, which is why I didn't call it love.event.push('q') straight away. My game makes no difference between the two so I wouldn't know which one is used.

[Moe]

I implemented the quit of 0.7.2 and the example I used worked fine with it. Can you please provide stack traces or other crash information? A sample app? A "I had a crash" did not happen.

[kalle2990]

3. love.event.quit/love.event.push('q') (some way to quit)

Just wrote the code for it. Pray for bad weather tomorrow so that I will test and commit it. If not ... nah, you don't want me to do "if it compiles, ship it".

After some JNI hell it is implemented and works fine.

Took a look at your commit, and I must say I'm impressed! I can imagine that JNI hell you're talking about, seems rather complicated.
However, shouldn't this be uncommented?

Code: Select all

if(mAndroidActivity != null)
    mAndroidActivity.finish();

As far as I can see, the mAndroidActivity is the Activity which holds the game/love, and when we don't "finish" this one, we experience something related to what T-Bone said.

Quitting does NOT work with the latest version on github. Instead, unlike before, love.event.push('q')/love.event.quit() simply crashes the app. Was the quitting fix submitted to github?

This is not tested in any way, but I think it might be a good consideration. I will however give it a test on my Ubuntu VM tomorrow, so if you can wait for that, you don't have to test it yourselves

[Moe]

Took a look at your commit, and I must say I'm impressed! I can imagine that JNI hell you're talking about, seems rather complicated.

Actually it is okay after you spend a while to understand it. Unfortunately, I do rarely JNI... and since a former colleague showed me the C# way, JNI seems very clumsy...

However, shouldn't this be uncommented?

Code: Select all

if(mAndroidActivity != null)
    mAndroidActivity.finish();

Only for stand-alone games. It kills the launcher.

As far as I can see, the mAndroidActivity is the Activity which holds the game/love, and when we don't "finish" this one, we experience something related to what T-Bone said.

That is not correct. The complete Lua virtual machine is hold on the native layer. So the idea is to remove the Lua VM on exit and to create a new one as soon as we start a new game. Worked fine on my tests...

Quitting does NOT work with the latest version on github. Instead, unlike before, love.event.push('q')/love.event.quit() simply crashes the app. Was the quitting fix submitted to github?

This is not tested in any way, but I think it might be a good consideration. I will however give it a test on my Ubuntu VM tomorrow, so if you can wait for that, you don't have to test it yourselves

If you test it, provide more than a short comment. As I mentioned before, I only accept bugreports that are either easy to reproduce or give a stack trace. You can always use PM or E-Mail if the trace containts data that you do not want to become public.

[T-Bone]

I didn't know if a more detailed bug report was necessary, since I didn't know if the fix was posted on github or not. Will do a logcat.

EDIT: The only thing that pops up on logcat as it freezes when I press my "quit" button in the game is

Code: Select all

D/PhoneListener(  260): Signal type: GSM
D/PhoneListener(  260): Signal type: GSM
I/liblove (12214): onMouseDown
I/liblove (12214): deinit
I/liblove (12214): onMouseUp
D/PhoneListener(  260): Signal type: GSM
D/AudioHardwareQSD(  118): AudioHardware pcm playback is going to standby.
D/PhoneListener(  260): Signal type: GSM
D/dalvikvm(  260): GC_EXPLICIT freed 451K, 61% free 3858K/9799K, external 10314K/11851K, paused 66ms
D/PhoneListener(  260): Signal type: GSM
D/dalvikvm( 9127): GC_EXPLICIT freed 3K, 52% free 2900K/6023K, external 0K/0K, paused 56ms
D/dalvikvm(11865): GC_EXPLICIT freed 27K, 50% free 2823K/5639K, external 0K/0K, paused 69ms

I tried it several times with the same results. Also, I not that I/liblove: onMouseDown/onMouseUp keeps appearing even after a crash, even though the game has completely crashed (although graphics are still shown).

I get identical results with this .love:

[kalle2990]

*missclicked Sumbit, whole post coming soon *