I'm only two minutes in and I feel the need to comment. I've watched a few introductory SDL videos from various authors in the last few days. Most are bad. Yours are good. I feel like the fact that you go into these videos blind is one of the reasons they're good. And I applaud your decision to approach them that way. To maybe belabor the obvious, it's not "what" you are typing that's important (anyone could just look at some source code and see that) it's "why" you are typing what you are typing that has value. I'd wager that since you are capturing that context as it happens there is less of chance of some it being lost. Bad videos of this kind narrate what is being typed at that moment without adding any further commentary. I suspect that this happens because a lot of the authors of the videos are rather new to the subject themselves and don't have any additional information to offer. You are clearly a SDL subject matter expert and any insights that you have about how the SDL library works or about how it should be used in a real world scenario add value to your videos. I guess that this my longwinded way of saying that I appreciate the style of content you are making and to humbly suggest that you take care to not give in to the natural temptation to streamline the videos into the straight ahead implementation of a project but rather favor a style that favors tangents and digressions because those are what add valuable broader context.
Today I learned audio streams exist. I had only used the convert audio function before. I seem to remember it required manually allocating a buffer that was 5-10x the size of the input/output because I guess SDL needed that memory for its conversion routine. This API seems nicer.
Yay, new episode! Haven't watched the entire thing yet, but... 1:50 Instead of putting it in an else statement, why not break early? Just to reduce the nested complexity a little. Or is this considered bad practice?
My initial instinct was to add a break statement, but no matter what we have to free e.drop.file, so I decided to make sure the code flows to the end no matter what. But explicitly free'ing the string and then breaking would have been valid, too! It was a coin-flip. :)
Honestly the sdfsdfsdf trick is quite handy, it's like super secure net against our own stupidity as programmers. Oh and your vids are the perfect length for a lunch break + coffee! Also, if you want an interesting C game programming series with a similar vibe of going-with-the-flow, first making it work, then refactoring etc, I can only recommend the series Making a game in C by ua-cam.com/users/ryanries09 !
I'm only two minutes in and I feel the need to comment. I've watched a few introductory SDL videos from various authors in the last few days. Most are bad. Yours are good. I feel like the fact that you go into these videos blind is one of the reasons they're good. And I applaud your decision to approach them that way.
To maybe belabor the obvious, it's not "what" you are typing that's important (anyone could just look at some source code and see that) it's "why" you are typing what you are typing that has value. I'd wager that since you are capturing that context as it happens there is less of chance of some it being lost.
Bad videos of this kind narrate what is being typed at that moment without adding any further commentary. I suspect that this happens because a lot of the authors of the videos are rather new to the subject themselves and don't have any additional information to offer.
You are clearly a SDL subject matter expert and any insights that you have about how the SDL library works or about how it should be used in a real world scenario add value to your videos.
I guess that this my longwinded way of saying that I appreciate the style of content you are making and to humbly suggest that you take care to not give in to the natural temptation to streamline the videos into the straight ahead implementation of a project but rather favor a style that favors tangents and digressions because those are what add valuable broader context.
Tentative name for "sdfsdfsdf" code, compiler door stoppers.
Learning a lot with this series, thank you!
Thanks for this video series, this has really helped me grok the thought process around using SDL2
The ending (“both of you”) made me laugh out loud. 😂
Thanks for the streams, they’re very helpful.
Nice work! Intresting to see your work!
Today I learned audio streams exist. I had only used the convert audio function before. I seem to remember it required manually allocating a buffer that was 5-10x the size of the input/output because I guess SDL needed that memory for its conversion routine. This API seems nicer.
Yay, new episode! Haven't watched the entire thing yet, but...
1:50 Instead of putting it in an else statement, why not break early? Just to reduce the nested complexity a little. Or is this considered bad practice?
Oh, I see you deal with that a little later by simply refactoring it all. 😁
I think I'm going to start using sdf's as well. They seem like very helpful compiler-powered reminders.
My initial instinct was to add a break statement, but no matter what we have to free e.drop.file, so I decided to make sure the code flows to the end no matter what.
But explicitly free'ing the string and then breaking would have been valid, too! It was a coin-flip. :)
Honestly the sdfsdfsdf trick is quite handy, it's like super secure net against our own stupidity as programmers. Oh and your vids are the perfect length for a lunch break + coffee!
Also, if you want an interesting C game programming series with a similar vibe of going-with-the-flow, first making it work, then refactoring etc, I can only recommend the series Making a game in C by ua-cam.com/users/ryanries09 !
I'll check it out, thanks!