next »

[fluffrabbit]

Yes.

Now answer this: In what situation (aside from a flip phone because I know support for those is spotty anyways) would there be a number pad but no cursor keys?

[JobLeonard]

Badly programmed software keyboards on phones in general maybe?

[fluffrabbit]

That would have to be a pretty bad software keyboard. I mean, accepting different scancodes for things like Wii controllers is probably a good idea, but the way I feel about it, treating the number pad as directional input is wrong. Usually it's used for other things, and with a number pad the keys are often upside-downn anyways. Don't know if this annoys me enough to switch to raw EGL or not.

[ProgramGamer]

[...]treating the number pad as directional input is wrong.

That's exactly what numlock does though.

Plus, you claim version 2.0.10 of SDL did this, but did you check if version 2.0.9 has the same behavior? It could be an error on either your part of your players'. If you didn't check, then you're baselessly assuming SDL is at fault.

[fluffrabbit]

I did not know that about num lock.

I have tested on both SDL 2.0.9 and 2.0.10, so what you are describing is called double-checking. Fine, I'll double-check.

No problems on desktop. 2.0.9 no longer builds with Emscripten due to updates with how the latter works, so I can no longer test that. With 2.0.10, num lock does change the behavior in a way that I am not in the right state of mind to deal with.

Sorry I can't be of more help. Something is going on. Ehhhhh....

Also, why defend any software component? I have several alternatives lined up for such eventualities as this. If SDL is something I don't like, I don't have to use it. If you have committed to a particular software component, you have made a strategic error.

[Daid]

On native windows the numpad keys are the same in 2.0.10 and 2.0.9 if I look at event.key.keysym.sym.

2.0.9 no longer builds with Emscripten due to updates with how the latter works

Nothing with my browser or Emscripten changed.

Like I said, SDL2 gets the keysym straight from Emscripten, so you updated Emscripten and that changed the behaviour.

[fluffrabbit]

I haven't tested on Windows yet, though cross-compiling and running on Wine is easy enough. No problems on desktop. Before we blame Emscripten, I think the issue might relate more to the interaction between SDL2 and Emscripten. In that case, Valve has the resources to keep things in ship shape, though they are more motivated to support desktop for obvious reasons. In any case, I'm not dependednt on SDL, so I'm not complaining for any particular reason.

[fluffrabbit]

Who else here has zero keyboard input with SDL 2.0.10 + Emscripten? It's kinda fucked. Good thing my game can function with mouse controls exclusively, but when it launches I can't make a web version available if this is the state things are in.

[Daid]

Who else here has zero keyboard input with SDL 2.0.10 + Emscripten? It's kinda fucked. Good thing my game can function with mouse controls exclusively, but when it launches I can't make a web version available if this is the state things are in.

How do you select the SDL version? I have keyboard input with "-s USE_SDL=2" as compile option to emcc.
(Installed a fresh emscripten emcc today, so latest releases of everything)

I do see the wrong mapping of the numpad keys, where numlock effects them and they map to the same keysym as the arrow keys.

[fluffrabbit]

I'm building SDL from source and doing the JavaScript version for IE and Falkon compatibility.

In any case, I'm glad to hear things are working for you with such ease. I'm in one of those mood swings where programming doesn't feel right so I'm sure what you're doing is making a lot more sense than what I'm doing. I'll need people like you when I've got 80+ employees, but right now it's just me.

[fluffrabbit]

Interesting. Using the USE_SDL flag results in a call to the Emscripten package manager, which connects to the net. It seems to work, and I'm assuming that's because this is a version of SDL that has been tested and verified by the Emscripten organization. Since it's all a hack anyways, I'm impressed. Keyboard keys work again. However, num lock seems to have no effect on the number pad being used as arrow keys, at least with Chromium and a Walmart wireless keyboard.

[Daid]

Without "-s USE_SDL=2" emscripten defaults to having SDL1.2, causing all kinds of possible header conflicts. So maybe you need to specify "-s USE_SDL=0" to disable the buildin SDL.

Not that I'm too happy about using some kind of magical package manager build into the compiler frontend that downloads shits.
But, as a hack, it works. Amount of patching I needed to get it to work was surprisingly low (but I did already target OpenGL ES 2.0)
https://github.com/daid/SeriousProton2/commit/39bb4da3d6eae9b86cf45b57a933211022556288

And then I could just build with:

Code:

emconfigure cmake .. -G Ninja
ninja

Version of SDL2 that then is used comes from: https://github.com/emscripten-ports/SDL2 I think.
I've filed an issue for the keyboard numpad mismatch.

[fluffrabbit]

I never enabled the built-in SDL before your suggestion. When you get Emscripten from non-official sources it's not guaranteed to have what you need, so building myself was the way to do it.

You filed an issue, but did you experience the same yourself? I should be taking responsibility for that as I'm the one who experienced it. I'll leave a comment on GitHub.

It also seems I spoke too soon about the keyboard stuff being fixed. It works when testing locally but not over the internet. Same browser and everything.

[Daid]

You filed an issue, but did you experience the same yourself?

Yes, I experienced the numpad issue myself as well. And it will mess up my text entry code.
My test is uploaded here:
http://daid.eu/dump/emtest/Mario.html
It also sends the pressed keys keysyms to the debug console, so you can see the issue there.

I never enabled the built-in SDL before your suggestion.

Well, check out this piece of "OMG THEY DID WHAT?!?"
https://emscripten.org/docs/compiling/Building-Projects.html?highlight=sdl2#emscripten-ports

Emscripten also has support for older SDL1, which is built-in. If you do not specify SDL2 as in the command above, then SDL1 is linked in and the SDL1 include paths are used.

So you always had some version of SDL, and when you supplied your own, you most likely had 2 versions at the same time...

[fluffrabbit]

Well, that's just retarded. 

[fluffrabbit]

Oh, and check out this fucking bullshit.

I'm seriously questioning the life choices that led me to cross-platform gamedev. There must be better things I can do with my time, like, I don't know, take ibuprofen or something.

[fluffrabbit]

There will be no further plans to support the web.

[JobLeonard]

 

(I feel you though)

[Daid]

Oh, and check out this fucking bullshit.

I'm seriously questioning the life choices that led me to cross-platform gamedev. There must be better things I can do with my time, like, I don't know, take ibuprofen or something.

Well, I understand the reason from chrome, auto playing sounds on ads are the worse. I remember opening 20 tabs and 1 was playing a load helecopter sound in an ad somewhere. This was before the "this tab is playing audio" indicator, and it caused me to close the browser to get rid of it.

Audio seems to work at random on my test, but always stutters, on android and on my windows desktop.



I like cross platform development. But my normal targets are:

• Windows
• Linux (desktop)
• Linux (raspberry pi)
• Android

In that order. I initially target linux with OpenGL 2.0. Meaning I can use the gcc mingw compiler to build for windows as long as I stay away from certain linux/posix calls. And need a few minor adjustments for OpenGL ES 2.0 for android.
Which is most likely also why I could build for emscripten so easy.

[qMopey]

Cross compiling with web was never really an option for me due to a lack of UDP and threads.