Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1368217 Posts in 64213 Topics- by 56155 Members - Latest Member: Filipe Ferreira

October 23, 2019, 02:07:26 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 291 292 [293] 294
Print
Author Topic: The grumpy old programmer room  (Read 606408 times)
JobLeonard
Level 10
*****



View Profile
« Reply #5840 on: September 25, 2019, 08:49:21 AM »

 Cheesy

(I feel you though)
Logged
Daid
Level 3
***



View Profile
« Reply #5841 on: September 25, 2019, 10:35:49 AM »

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.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
qMopey
Level 5
*****


View Profile WWW
« Reply #5842 on: September 25, 2019, 01:45:09 PM »

Cross compiling with web was never really an option for me due to a lack of UDP and threads.
Logged
fluffrabbit
Guest
« Reply #5843 on: September 25, 2019, 05:19:40 PM »

I'm probably going to do an async multiplayer thing, so I don't need UDP. I'll pipe it all through HTTP if I can, that way there is proxy support and certain reliability guarantees, and I'm just used to HTTP in protocol. Mind you, that's HTTP, not the web. I hate the web.

Yeah, I'm developing on Linux with GCC and OpenGL/ES 2.0 as well. I also have a pretty solid GL/ES 3 backend, but I haven't found a need for it yet as 3D games take a bunch of time and I'm in business mode. Android is being investigated, but I can and should definitely target Linux and Windows.
Logged
qMopey
Level 5
*****


View Profile WWW
« Reply #5844 on: September 25, 2019, 05:57:53 PM »

I'm actually figuring out how to get C code to run on Android at work right now... It's extremely difficult for me to get MSVC debugger to connect to Google's emulator. However, I think this might be me just being completely unfamiliar with everything.

It does all seem 100% better than Apple's nightmare of proprietary control schisms, despite my initial present troubles.
Logged
fluffrabbit
Guest
« Reply #5845 on: September 25, 2019, 06:29:05 PM »

Generally, mixing Visual Studio with Android sounds like something one would not want to attempt. Android Studio with the NDK is the preferred way, but currently I can't get it to compile modules separately, so it rebuilds everything, including SDL, every time. Unacceptable. I have a book on it (Android NDK Second Edition by Sylain Ratabouil) but I'm not getting very deep into it right now because desktop is the priority.
Logged
qMopey
Level 5
*****


View Profile WWW
« Reply #5846 on: September 25, 2019, 06:49:10 PM »

I was hoping to not have to use Android Studio. At work all my colleagues (and myself) are not going to be familiar with Android Studio, so it would be much easier to use Visual Studio's debugger to save time. But I guess if it doesn't work we can just do all development on Windows, and only use Android Studio when absolutely necessary, like fixing portability bugs.
Logged
fluffrabbit
Guest
« Reply #5847 on: September 25, 2019, 07:16:00 PM »

The official Android tools on Linux is the only workflow they use internally at Google, and I have found that this is not a trivial platform to develop for. Much of the work will be done by scripts rather than the IDE; your ultimate goal should be to automate it from the command line so as not to deal with the less reliable graphical workflows. I have never used VS myself.

All that said, there are guides online for what you're trying to do, so if it makes your coworkers happy, go for it. It's not going to be easy either way.
Logged
Daid
Level 3
***



View Profile
« Reply #5848 on: September 25, 2019, 09:28:56 PM »

I gave up on trying to connect a debugger to Android, and went with the old proven "just add print statements" and grep on logcat in case something goes wrong. Few of the reasons:
  • The emulator fails to work for me.
  • I have 2 phones, an Samsung S3 (very old), Xaomi Pocophone F1 (pretty recent), debugging setup is completely different on both. Documentation for older setups is fragmented and broken.
  • Android studio and gradle are just a pain in the ass if you want just native code development. Gradle actually runs out of memory on my old media center that acts as CI server.
  • ndk-build used to work quite well, but broke in newer ndk versions

So, I set out on building for android without gradle or ndk-build. And I managed to do that, following a few different tutorials on how to manually build an android project and taking apart already build apk files.


The result of that is this android toolchain file:
https://github.com/daid/SeriousProton2/blob/master/cmake/toolchains/android.toolchain
Which downloads & installs the android SDK & NDK, and then includes the toolchain file from the android NDK.
And this large function in my cmake file to build the final APK:
https://github.com/daid/SeriousProton2/blob/master/SeriousProton2.include.cmake#L204

It's not a 100% perfect as for some reason cmake always rebuilds the full APK, including building the few java sources that SDL needs. But the overhead of that is limited.



@fluffrabbit for "acting as http", you might want to emulate the websocket protocol. It's packet based, it starts off as http but then becomes just a bidirectional TCP stream with specially encoded packets to ensure proxies and firewalls let it pass. Works with both http and https as starting connection, so allows for encryption as well.
Got a simple client implementation here: https://github.com/daid/SeriousProton2/blob/master/src/io/http/websocket.cpp
Also have a server implementation next to that, but that is a bit more code.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
fluffrabbit
Guest
« Reply #5849 on: September 25, 2019, 11:49:29 PM »

I've been hunting for something like websockets for a while. My only complaints would be that it can't do P2P and it's not raw TCP; there is some overhead, not quite a pure socket protocol AFAIK. But it's full duplex so that's exciting.
Logged
Daid
Level 3
***



View Profile
« Reply #5850 on: September 26, 2019, 02:10:38 AM »

Well, I like client/server much better then P2P for networking. I do wrote a websocket switchboard:
https://github.com/daid/WebsocketSwitchboard
To allow clients and servers to both connect to the publicy accessible switchboard and work trough NAT and firewalls without needing port forwarding.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
fluffrabbit
Guest
« Reply #5851 on: September 26, 2019, 02:14:56 AM »

Sounds neat! Not a great way to do a DHT (one of my fantasy projects) but sounds interesting, though that repo doesn't seem to be accessible to the public. Or rather, it's a 404.
« Last Edit: September 26, 2019, 02:23:55 AM by fluffrabbit » Logged
Daid
Level 3
***



View Profile
« Reply #5852 on: September 26, 2019, 04:44:26 AM »

Oh, yes, the repo was private, it's public now. I do warn, it's python code...

It's not ideal, but the concept is that it needs to be easy for people to match up with games. So I kind followed what the Jackbox games do, just enter a 5 letter code and you can join the game.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
fluffrabbit
Guest
« Reply #5853 on: September 26, 2019, 08:03:34 AM »

You have codified a fairly ideal game server using standard protocols. Well done. Because it is Python and would require a fair amount of client-side boilerplate, I do not plan to use it, but it gets one thinking about the structure of the network.
Logged
Daid
Level 3
***



View Profile
« Reply #5854 on: September 26, 2019, 10:01:11 AM »

You have codified a fairly ideal game server using standard protocols. Well done. Because it is Python and would require a fair amount of client-side boilerplate, I do not plan to use it, but it gets one thinking about the structure of the network.
It's not intended as a game server, but as a middle man. So both the server and the client connect to it. And after the initial handshake make it as transparent as possible. It also supports connections that start as http connection and then upgrade to raw tcp connections, the concept is that you just have a normal client->server game, and for both the client and the server both direct connections or trough the switchboard are equal, except for the initial handshake.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
fluffrabbit
Guest
« Reply #5855 on: September 26, 2019, 06:16:11 PM »

For my particular use case, it could function quite well as the game server for a distributed system with a simulated network of devices, but it's still in the planning stage.
Logged
fluffrabbit
Guest
« Reply #5856 on: September 27, 2019, 11:08:50 PM »

Turns out the keyboard wasn't being recognized because I embedded the app in an iframe. Can't do that, apparently. The numpad is of course a separate issue.
Logged
Daid
Level 3
***



View Profile
« Reply #5857 on: September 28, 2019, 09:18:06 AM »

My numpad fix was merged, not sure how to deploy it now. But at least it's in the SDL2 for emscripten.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
fluffrabbit
Guest
« Reply #5858 on: September 28, 2019, 04:52:52 PM »

If the guy pushes a new build, under certain circumstances USE_SDL=2 should download it. Or there could be a tool like empkg or something. Frankly, I don't much care. Kinda wish people would just download and run an EXE these days. Remember those days? I do.

You have done a great service for your country, less insulting me on GitHub. Anyhow, you seem to know what you're doing. I just can't appreciate it since my change of heart about the web.
« Last Edit: September 28, 2019, 05:01:03 PM by fluffrabbit » Logged
Daid
Level 3
***



View Profile
« Reply #5859 on: October 01, 2019, 01:36:24 AM »

Well, check out this piece of "OMG THEY DID WHAT?!?"
Got another one in this group:

https://emscripten.org/docs/porting/guidelines/api_limitations.html#networking
Quote
Networking
Emscripten supports libc networking functions but you must limit yourself to asynchronous (non-blocking) operations. This is required because the underlying JavaScript networking functions are asynchronous.


Ok, that's odd. You say the network functions work? But browsers shouldn't be able to open just any socket to anywhere and send any data?  Concerned

But, after digging more into it. They mapped the normal bsd socket functions to websockets. Waaagh! Which has a bit of the same name, but is vastly different:
  • Websockets are always TCP/IP, while normal sockets can be UDP.
  • Websockets are packet oriented, while TCP/IP is a stream. A single send() might become multiple recv() calls and the other way around in normal sockets.
  • Websockets do not support listening.
  • Websockets need to comply to cross origin policies, meaning you cannot connect to everything.


So, this simple means, I have to disable all socket related stuff in my engine for emscripten, as none of it makes sense, except for the websocket client, which needs a much simpler implementation.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
Pages: 1 ... 291 292 [293] 294
Print
Jump to:  

Theme orange-lt created by panic