I recommend this tutorial: http://lazyfoo.net/tutorials/SDL/
And the ‘API by Category’ part of the docs: https://wiki.libsdl.org/APIByCategory
SDL is actually a really easy API to learn,
basic setting up and tearing down of a window and basic shape drawing can be learnt in less than a day.
Loading images and handling sound are a bit trickier.
That said, I agree that trying to make a library that would compile for both SDL and Pokitto is probably a bit over-the-top if you haven’t got much free time (and not a simple thing to attempt if you do).
It’s not just bad because lying is bad, but more importantly it could be setting them up for a fall later on.
If they turned up to a job thinking “I can program in C” and then they started working and discovered that what they learnt wasn’t C then they might be in trouble.
Hiding it by compiling it to machine code (as a static library) isn’t too bad, because although you’re hiding the implementation details from them, you don’t have to lie about it and you’re actually giving them some real-world experience (they would no doubt have to
You don’t need any special ‘precompiler’, the regular compiler should already be capable of it,
you’d just need to be able to set it up in a particular way.
In all honesty I’m not quite sure how to do that in GCC,
but I’m sure I could figure it out from reading the docs,
and @FManga or @drummyfish might know how given their experience with makefiles and command line compiling.
The code itself would be pretty much the same as what I posted before
(possibly a few extra function decorations),
.cpp files would all be compiled into a static library
(which is a
.lib file on Windows, and an
.a file on Linux),
so your students would end up only seeing the
To be honest I still think the beter options are:
- Teach them C++ instead of C
- Teach them a subset of C++ instead of C and explain that you are only teaching them part of the language
- Teach them C and just trust the students to ignore the
.cpp files (and explain the situation to them if they get curious, reminding them that understanding those files won’t earn them any extra marks)
But if you want to go down the static library route then I’m reasonably confident we can figure it out.
I’m not saying it’s a bad option as such, I just think it’s a lot of work for something that might not be necessary.
I would hope 16-18 year olds could be trusted to not get distracted by a library wrapper.
They shouldn’t have too much trouble then.
Do you mind if I ask which country as well?
It shouldn’t make too much difference really, but I’m interested.
(And I suppose technically different nationalities have different amounts of foreknowledge.)
And while I think of it, have you decided what IDE you’re going to be using?
Unfortunately we are still lacking guides on how to set up some of the IDEs
(hopefully we’ll work on that in the new year) but we can explain the options.
EmBitz is the most popular, but it’s Windows-only.
We have various different PlatformIO-oriented solutions in use,
and we also have makefiles (or a makefile), which can usually be combined with most IDEs.
@FManga is right about this, a lot of the more simple code examples aren’t too heavy on C++ features.
In fact in all honestly a lot of these are very C-like (to the point that I’m actually disappointed at the lack of C++-isms).
Again, I agree with @FManga, I think C++ would actually be easier to learn because access to the C++ library would make things easier for the students.
std::vector is a dynamically resizing array,
std::swap for swapping variables,
std::array (assuming you’re using C++11) for better arrays -
crucially they provide an easy way of getting the size of the array.
You could still use C++ without going into the advanced stuff like inheritance and virtuality (and templates).
And like I say, if you’ve got C++11 then some of the newer features would be really useful without being too difficult to understand (like
When I was at college they taught us Visual Basic,
and to begin with they made us work entirely on command line programs in the ‘procedural programming’ unit.
We didn’t do any UI work until ‘event driven programming’ and even at that point we had no idea what a class was until the ‘object oriented programming’ unit came the next year (depite having been using static methods on classes for a long time).