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:45 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 292 293 [294]
Print
Author Topic: The grumpy old programmer room  (Read 606409 times)
fluffrabbit
Guest
« Reply #5860 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
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #5861 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 #5862 on: October 02, 2019, 03:57:13 AM »

Binary data is not null-terminated, so the above would only apply to text.
Logged
qMopey
Level 5
*****


View Profile WWW
« Reply #5863 on: October 02, 2019, 01:45:12 PM »

I often nul-terminate my binary data  Huh?
Logged
fluffrabbit
Guest
« Reply #5864 on: October 02, 2019, 02:08:57 PM »

But a null byte, AKA \0, is literally a byte with a value of 0. How do you avoid that byte randomly existing in a buffer? Isn't the number 0 rather common?
Logged
qMopey
Level 5
*****


View Profile WWW
« Reply #5865 on: October 02, 2019, 03:56:04 PM »

It’s fine if it’s already in the data, but generally also harmless to add onto the end.
Logged
fluffrabbit
Guest
« Reply #5866 on: October 03, 2019, 02:47:39 AM »

Then you have a buffer with multiple null bytes in it, which is useless if you don't know its length.
Logged
Daid
Level 3
***



View Profile
« Reply #5867 on: October 03, 2019, 04:01:31 AM »

null terminated data is quite common even in binary data, but then generally with fixed structures.

Did you know that the "argv" to main is actually terminated with a null pointer?
https://stackoverflow.com/a/3772826/7533710
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 #5868 on: October 03, 2019, 04:07:38 AM »

When you get into operating systems and the C language, the situation is different. A command line parameter equal to null is unlikely to exist, so null-terminating argv might be useful in some cases (not sure where as each string within it is also null-terminated).

When sending data over the network, a byte with a value of 0 could be interpreted as 0, or if the data type is int32_t* and you have a value of 500, 2 of the 4 bytes are going to be 0, or null. If the value is 0, all 4 bytes are null.
Logged
ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #5869 on: October 19, 2019, 08:38:10 PM »

Windows audio APIs.

I had what I thought was a working DirectSound implementation, but it turned out to be pretty garbage - extremely high latency, occasional buffer underflows, and sometimes output would just break and never recover. The last two problems are probably fixable if I wanted to spend time messing with them, but the latency problem seems more fundamental, so I'm going to have to throw this one away and start from scratch.

waveOut looks like it might do the trick. It's pretty old-school, and I'm trying to adapt it to work in a new-school way - my audio layer needs to expose a callback function that allows the consumer of it to fill a buffer with raw PCM data, then have that sent to a device to be played. waveOut wants to work on a more static paradigm of playing loaded WAV files, and it's turning out to be pretty fiddly to get it to work the way I need it to. Can't evaluate its latency and reliability until I have the implementation basically done, so I don't even know if I'm going to have to throw away all of this work again.

XAudio2 was brought to my attention. It looks a lot heftier than what I'm after, but it'll probably be my next choice if waveOut can't do the job. Why are there so many different options, and why do none of them actually seem to be any good?
Logged

Schrompf
Level 6
*

C++ professional, game dev sparetime


View Profile WWW
« Reply #5870 on: October 19, 2019, 11:53:46 PM »

I'm stuck with FModEx for ages now, but I still vividly remember trying to get something running with the convoluted DirectSound API. I think MS deprecated it, as it did with DirectInput, but a proper replacement is nowhere to be seen. I wonder what law-abiding people nowadays use for sound? Or is everyone using Unity and the likes now, and those use a carefully maintained clutch of deprecated stuff which MS is too sober to remove?
Logged

Snake World, multiplayer worm eats stuff and grows DevLog
Daid
Level 3
***



View Profile
« Reply #5871 on: October 20, 2019, 03:21:58 AM »

SDL2 offers an audio API like that. Seems they have implementation with directsound, wasapi and winmm. In a quick scroll trough, the winmm looks like the simplest. But you could test all 3 for latency.
Logged

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


The archivest master, leader of all documents


View Profile
« Reply #5872 on: October 20, 2019, 05:50:11 AM »

custom render texture is really not well documented in unity :sad_emoji:
Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #5873 on: October 21, 2019, 09:01:12 AM »

Slightly less grumpy update: I got my waveOut implementation working, and it's...OK, I guess? It's more stable and slightly lower latency than DirectSound, but not 100% ideal. I'll probably still need to look into XAudio2 at some point. At least I have something that's reasonably workable until I'm ready to put in that extra effort.

This was all part of the process of compiling my game for Windows for the first time in months after developing it primarily on a Mac. I was seeing a lot of unexpected performance issues that weren't all related to audio. I traced one source of the problem back to gamepad detection, and figured I'd spin it off into a secondary thread so that it wouldn't have to block execution if it took too long to complete. Somehow, this didn't seem to help.

I got a hunch that CreateThread might actually be slow on its own, so instead of spawning a new thread each time I wanted to poll for gamepads, I started just one thread on initialization, and implemented some semaphore communication to pause and resume it when I needed it to do some work. This seemed to fix the problem. Lesson of the day is that thread creation is expensive, so do it just once at startup and keep using the same thread(s) for ongoing work whenever possible instead of starting new ones.
Logged

gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #5874 on: Today at 12:29:10 PM »

I hope you can get it to happy programmer room territory
Logged

Pages: 1 ... 292 293 [294]
Print
Jump to:  

Theme orange-lt created by panic