Writing a Simple Media Player with SDL, part 3: Draggin' and Droppin'
Вставка
- Опубліковано 28 лют 2022
- Now we're going to get rid of the hardcoded .wav file and give ourselves the ability to drag'n'drop new files onto the window.
Source code for today's efforts:
github.com/icculus/sdlamp/blo...
Music in today's video is from Kevin Hartnell, of Overlook Hotel Records, under a CC BY-SA 4.0 license. I got it from Bandcamp, but his main website with all the links is www.kevinhartnell.com/
Creative Commons is a force for good and lets this music show up in this video, but you should still throw a few bucks at Kevin, because publishing under the CC should be rewarded.
Kevin Hartnell - "CC BY-SA 4.0"
Overlook Hotel Records R237-0CC
©2016 Kevin Hartnell / Overlook Hotel Records
This is a collection of instrumental music released under the CC BY-SA 4.0 license.
Credit to: Kevin D. Hartnell
Please link back to www.kevinhartnell.com
I also should be rewarded, so check out my Patreon: / icculus - Наука та технологія
As someone that is looking to learn a little SDL this series hit at the exact right time for me with the exact right level of technical complexity. Thanks. Subscribed.
I like your style!
Love that SDL seems to be written to be fairly fail-safe. There are a lot of APIs out there that will simply return an exception if for example you try to close a device that's already closed or not yet open. I like the elegance of it just doing a noop in such a scenario instead. Gets rid of potential boilerplate most people don't need.
You're such a great entertainer haha. Also I was wondering seeing you code: do you always process this way, writing the simplest "dumbest" (for lack of a better word in my limited dictionnary) code and then reworking it to make it more modular (First play a single song looping, then a single song with play-pause-reward, then any song by drag and drop + play-pause-reward...)? This kind of iterative progress.
I always get stuck in personnal pet projects because I can't help but plan ahead and ahead and ... it's exhausting.
Like, "I want to make a game, I'm gonna need an actor/entity class, something to draw sprites, so also something to load assets, and then a level module, but wait how do I store levels, and" ... it never ends.
There are things in these videos I would skip in real life, because I'm trying to show simpler things so we can get to some sort of progress quickly, or I'm setting things up to build off of later for educational purposes...but specific details aside, "I did a little work and it's already making noise" is extremely gratifying for me as well. :)
I would have skipped over whole .wav files pushed to SDL_QueueAudio if I weren't doing this for an audience, as an example, but we are probably several steps away from replacing that code on here.
But yes, overplanning will stop any new project dead. This is the superstition about starting with the README that I mentioned in the first video (that's just a document describing a plan, not existing code, if you write it first). Have an solid idea of where you need to get to, and how to get there, and don't build any infrastructure that you don't immediately need for the trip. Those things should be the smallest, dirtiest thing you can throw away with no regrets when you have to write them.
Also: if you _do_ build that infrastructure first, be prepared to steal it for future projects. One time I fell down a rabbit hole writing the filesystem API for a physics-based game, and never actually wrote the _game_, but pulled out that piece into icculus.org/physfs/ :)
@@RyanGordon Thanks this seems solid! I shall keep it in mind. Write what you need. Don't write a plan, just keep the goal in mind, which should be a clear idea, if I gotcha
@@RyanGordon I have been wondering what the name of that library meant... Now I know. Very useful thing, was working on my toy game engine last weekend. It uses physiscfs for it's resource loading/asset server bit. Convinient way to take a bunch of locations into one virtual file system. Thanks a lot for this, and for it to be open source 🙂
@@RyanGordon That's so right, how many times have I started a project only go make a core feature, give up later, and then stole that very part for another project months later!...
Great video as always :-) One thing I got an error on VS. const SDL_Point pt declaration inside the MOUSEBUTTON case made the compiler unhappy because that declaration would be skipped by another case (the one below for DROPFILE). So I had to declare it before the loop and not as a const :)
That's strange, it's in its own scope and it doesn't have any constructor to run, being C. Is this a Visual Studio thing in general, or are you compiling the source code as C++?
@@RyanGordon I'm compiling the source code as C++ indeed, I forgot to mention this! It must be the reason for this issue :)
So essentially SDL "gives up ownership" of the drop file path to the application. Why can't SDL keep ownership and free the pointer after the event returns? It could even avoid copies potentially depending on the underlying Win32/GTK/etc. API. The only downside I can think of is the caller has to do a strcpy if they want to keep a copy of the path for later, but I think the safety makes up for that.
SDL doesn't know when the event loop has finished (and just freeing it on the next call to SDL_PollEvent() wouldn't work either for various reasons)...this was a design problem in SDL2, where we didn't plan on having unbounded allocation in events, so this was the compromise until we fix it later in SDL3.
In practice, you have to drop a lot of files on a program before a misbehaving one would leak enough data to be noticeable, but a memory leak is the worst case scenario here, so we decided it was acceptable for now.