Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411423 Posts in 69363 Topics- by 58416 Members - Latest Member: JamesAGreen

April 19, 2024, 05:41:45 AM

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



View Profile
« Reply #5880 on: November 20, 2019, 06:46:06 AM »

As in C++ templates/metaprogramming, like the STL?
Logged

kason.xiv
Level 0
***


View Profile
« Reply #5881 on: November 26, 2019, 02:08:02 PM »

As in C++ templates/metaprogramming, like the STL?

yuppers.. the template code library itself compiles, and libraries that use that library compile and link as well... but I have an executable higher up the tree that uses this library and claims it's "not a template"

Honestly I think my cmake files are just spaghetti. I'm pretty inexperienced in cmake.
Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5882 on: November 29, 2020, 08:53:28 AM »

Heh, I posted here just over a year ago being grumpy about Windows audio APIs... Right now I'm in about the same place again, but this time on Linux.

I have a kiiiiiiinda soooooorta working implementation now using ALSA. Initially I was following the ALSA website's official sample code, but that led me down a road that turned out to be completely unusable - their sample code uses plughw:0:0 for output, which apparently requests exclusive access to the audio hardware. It would fail to initialize if anything else had been doing audio output recently, including multiple runs of my own program.

After studying the source code of portaudio and SDL2 for a while, I came up with another implementation that's a lot closer. It's able to output sound cooperatively without exclusive access, and uses the simpler snd_pcm_writei() API for sending audio data to the speakers instead of the much more complicated mmap option I was using with plughw. It's still not exactly right, though - if I want low latency audio (which I need if I'm going to use this in any game), I keep running into mysterious buffer underruns right as my audio stream starts. I found I can avoid outputting garbage if I just send silence for the first 8 writes on my audio thread and then start sending my actual audio data afterward, which feels super jank and hacky and I suspect is very specific to the computer I'm running on. Every once in a while, the snd_pcm_recover in my audio thread mysteriously fails with -ENOTDIR, which isn't even an error code that the documentation says it can return (and Google has exactly one barely-related result for "snd_pcm_recover ENOTDIR"). What?

When it works, it sounds fine and the latency is good. I have a Raspberry Pi I've been tinkering around with, and when I build this code for it, at best I get some horrible screeching instead of the sine wave I'm trying to play in my test code, and in most cases I just get silence. Even cranking up the latency to unusable levels doesn't stabilize it. I might be able to chalk that up to the Raspberry Pi's drivers being underdeveloped, but there are other applications I've tried that can play audio OK on the device, so it feels like I should be able to do something to work around its limitations. I'm just not sure what yet.

At this point, it's looking pretty tempting to just write an API layer that wraps around SDL2 or portaudio or something, and let them figure out the underlying system APIs for me. I'm just not sure that'll work OK latency-wise, and I've definitely seen portaudio just mysteriously fail to output audio in some cases, so I might still run into the same problems.

Audio code is a lot of fun when it works, but there are way too many separate system APIs for it on every operating system, and not a single one of them ever seems to actually work perfectly.
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #5883 on: November 29, 2020, 10:11:54 AM »

Quote
Right now I'm in about the same place again, but this time on Linux.
I don't even have to read the rest, lol. Audio APIs and Linux are a running gag for ages now
Logged
bayersglassey
Level 0
***



View Profile
« Reply #5884 on: December 10, 2020, 11:49:53 PM »

Oh man, I've been thinking about learning to program sound on Linux recently after getting inspired by the "bytebeat" genre.
http://canonical.org/~kragen/bytebeat/

So like, to output a triangle wave you can do:
Code:
echo 'main(t){for(;;t++)putchar(t);}' >main.c
gcc main.c
./a.out | aplay

...and the idea of piping stuff into aplay to generate sound seemed so beautiful and unix-y, I decided to see about adding sound to my SDL2 game project. No sdl_mixer nonsense, I wanted to stream bits directly into my speakers like you can with aplay.
Read the SDL2 sound API docs for a bit.
Backed away slowly, and went back to doing graphical/gameplay stuff to clear my mind. :/

But your mention of snd_pcm_writei makes me want to wade back into this stuff a bit; piping into aplay was fun, but seemed to require "exclusive access to the audio hardware" as you described. So maybe I need to read up on ALSA a bit more and understand its model a bit. Something about sinks and sources, as I recall.
Logged
JobLeonard
Level 10
*****



View Profile
« Reply #5885 on: December 11, 2020, 01:28:55 AM »

> bytebeat

Thanks for giving that a name, it was one of those things I saw years ago but couldn't find anymore because of a lack of search terms
Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5886 on: December 13, 2020, 08:37:05 PM »

I chased down a pretty bizarre bug today... I have a library function that brings up an open or save file dialog, using gtk_file_chooser_* on Linux. I had three different programs that all invoked it the exact same way, and one worked fine while the other two would crash instantly with some stderr output from GTK about malformed PNG IHDR data in a system location. Super weird.

I took one of the nonworking programs and stripped it down piece by piece until the crash stopped happening. Linking in a file that invokes my library function for loading a PNG turned out to be the difference between working and crash. Following a hunch, I checked the version of libpng being linked... The system version was 1.6.37, while the one I compiled myself and was linking to was 1.6.29. Fair enough. I updated, recompiled, and linked to 1.6.37, and...it still crashed the same way.

I've now replaced the libpng I compiled myself with a -lpng linker argument to use to the system-provided one instead, and everything works. I guess some behavior is still different between mine and whatever came with my system in a way the GTK really didn't like. Not really happy about giving up the control of compiling my own, but at least the fix was simple enough, and shouldn't end up being a problem? Stuff like this always makes my code feel so fragile, though. I wish I had a better way to understand why my library didn't work, but at this point it's probably not worth the effort.
Logged

oahda
Level 10
*****



View Profile
« Reply #5887 on: December 14, 2020, 02:10:57 AM »

That’s annoying. Sad Good that there’s a workaround at all at least.
Logged

pelle
Level 2
**



View Profile WWW
« Reply #5888 on: January 09, 2021, 08:20:31 AM »

Quote
Right now I'm in about the same place again, but this time on Linux.
I don't even have to read the rest, lol. Audio APIs and Linux are a running gag for ages now

I don't know how it is now, but JACK used to be very good, assuming you did some system configuration first... and in the old days you had to recompile the kernel with some special low latency patch (but I think that was worked into standard kernels later, or at least into common alternative kernels that you do not have to compile yourself?), but assuming you had done all that it was the way to go for low latency audio on any platform, and it had a sane API and implementation too. I think music applications like Renoise still defaults to JACK, but it runs on top of Portaudio probably that seems to like to own all the audio hardware on most linux systems these days.

Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5889 on: January 15, 2021, 10:21:56 AM »

X Windows has some design issues.

I want to create a window with its content rectangle in the center of the screen. I was noticing that on Linux, the window position I got always looked suspiciously low compared to other platforms. I finally dug into this today and took some measurements to figure out what was up. It turns out that XCreateWindow measures coordinates from the top left corner of the window including the title bar, so I have to offset by that amount to get my content area centered. Reasonable. This is what the AdjustWindowRect function in Win32 is for, so there must be some X11 equivalent...right?

After turning up nothing promising in headers or documentation, I stumbled across a Stack Overflow post that mentioned querying the _NET_FRAME_EXTENTS window property to figure out how large the title bar is. After figuring out how to use the weirdly verbose XGetWindowProperty API, I find out that the _NET_FRAME_EXTENTS property doesn't exist on my window right after creation. It turns out I have to wait for an asynchronous ConfigureNotify event after creating and displaying the window in order to be able to query it. Oof. After that, I'm able to use the result to make a second call to XMoveWindow to apply the offset.

It seems to work now, but it feels bad. Without a way to know ahead of time how much additional space the window frame is going to take up, I could end up in a situation where I'm trying to create a window whose content area would fit onscreen, but with the title bar added it would be too large. I also worry that depending on the window manager, this might the window to open in one place and then visibly move. At least it looks right on my fairly plain vanilla Ubuntu installation, so I'll just have to hope that's good enough.
Logged

Eggy
Level 0
**


View Profile WWW
« Reply #5890 on: August 04, 2021, 03:33:44 AM »

Been programming my first game using love2d, for a game jam called Lowrezjam. There was an issue that I somehow managed to fix completely by accident - I had pixel art asteroids that were programmed to rotate, but they looked crunchy and rough with the nearest neighbor filter and blurry without the filter. Then once I implemented game states, I moved on to globalize the canvas (long story short, I need it so that it applies to the whole application instead of each individual state). After doing so, I found my asteroids looking crispy clean... I had no clue what I exactly did differently for it to work, but I was happy. I showed it to my fellow jammers all excited... then they brought up the asteroids using a higher resolution to look crisp, meaning that it was going against the spirit of the jam. I didn't even do anything special, all I did was copy some code and I didn't directly touch anything in regards to the graphics. The engine seemed to vectorize them for some reason, and as a beginner programmer I have zero clue about how and why it even did that. So now I have to, again somehow, undo the thing I was so happy about Sad
Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5891 on: August 04, 2021, 06:49:45 AM »

Ah, nonuniform pixel sampling! A source of much contention. On the technical side, what makes the difference is whether you're drawing first to a fixed resolution canvas where 1 pixel in it matches the size of the graphic being drawn and then scaling that to screen size, or if you're directly drawing low resolution art at a higher resolution to the screen.

On the art side, low resolution graphics require some extra attention to look good. If you're doing any arbitrary scaling or rotation, you'll run into sampling artifacts. Choices are basically to either accept how this looks (as in your first attempt), or draw something higher resolution at a smaller size so that it can sample different areas while rotating, or draw at a higher resolution and violate the pixel grid and accept how that looks (as in your second attempt), or to avoid rotation altogether. Using multiple animation frames drawn at different rotations rather than drawing the same image with a transformation would also be an option.
Logged

Eggy
Level 0
**


View Profile WWW
« Reply #5892 on: August 10, 2021, 09:58:34 AM »

The game jam is coming to a close, and right now I'm having a really perturbing issue. Namely, I have a transition state that's supposed to make a custom wipe animation, and it in fact is functional. The issue however? For reasons beyond me, it bugs out if the gamestate command itself is in the update loop. Which is where I need it because it has to switch to the new state automatically. If it's in the load function or defined as a key press, it works fine. But when inside the update loop, it complains about a nil canvas as soon as the thing tries to switch. It doesn't even make any sense - the only difference is that the switch is automatic instead of manual. It's just making me wonder one thing: what on god's green earth is wrong with the update loop if specifically putting the command in there causes it to crash???  Waaagh!
EDIT: Resorted to going to love2d's official discord server and the folks there managed to help me out. What I ultimately had to do was axe the love.draw code (I technically commented it out but same diff) and copy over some of that code to individual states, and now it works like I want it to.
« Last Edit: August 10, 2021, 08:59:36 PM by Eggy » Logged
Pages: 1 ... 293 294 [295]
Print
Jump to:  

Theme orange-lt created by panic