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),
but the .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 .h
files.
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.
For example, 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 constexpr
variables).
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).