Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411281 Posts in 69324 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 11:11:51 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 295
Print
Author Topic: The grumpy old programmer room  (Read 733387 times)
fluffrabbit
Guest
« Reply #5840 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 6
*


View Profile WWW
« Reply #5841 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 #5842 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 6
*


View Profile WWW
« Reply #5843 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 #5844 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 #5845 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 #5846 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 #5847 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 #5848 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 #5849 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 #5850 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 #5851 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 #5852 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 #5853 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 #5854 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 #5855 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 #5856 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
fluffrabbit
Guest
« Reply #5857 on: October 01, 2019, 02:12:20 AM »

You can also either not support Emscripten, or use Websockets for everything. Though IMHO, SHA-1 is a bit hefty for a non-secure nonce and there seem to be other complications typical of Google, so implementations are more complex than I want. You could just use plain old HTTP. For everything.
Logged
oahda
Level 10
*****



View Profile
« Reply #5858 on: October 02, 2019, 01:17:37 AM »

Disclaimer: I don't know much about networking or really what I'm doing. But! For what it's worth I got my debug client (game is client, server is on my PC receiving console output from the game and can theoretically communicate back too) thing working on web as well as the normal platforms, using websockify and my normal SDL_net code in the client (the server uses Asio since it doesn't use anything SDL at all).

Since things are not necessarily always sent in full, what my code does is to put everything it gets into a string until it hits a null character, at which point it processes the string as one message and resets it to start building the next string. Whether the web version always sends single nice and clean null-terminated strings in one go every time and other versions send them in haphazard bits and pieces I really don't know, but it works either way. Who, Me?

But of course I have no idea how this would work out in a more critical scenario or if it works well or at all across any other connection than a local network over TCP/IP.
Logged

fluffrabbit
Guest
« Reply #5859 on: October 02, 2019, 03:57:13 AM »

Binary data is not null-terminated, so the above would only apply to text.
Logged
Pages: 1 ... 291 292 [293] 294 295
Print
Jump to:  

Theme orange-lt created by panic