The screen is an array of pixels (usually each pixel is an unsigned 32-bit value, with bits 0-7 being red, 8-15 green, 16-23 blue, and 24-31 unused). All you really need SDL for is to provide you with a pointer to such an array that will show up on the actual screen. Then try drawing simple shapes like rectangles:
void DrawRect(unsigned long *screen, int screenWidth, int x, int y, int w, int h, unsigned long color)
{
for(int j = 0; j < h; j++)
for(int i = 0; i < w; i++)
screen[(y + j) * screenWidth + (x + i)] = color;
}
The SDL image loading and blitting functions aren't really necessary, although they might save you some time compared to learning how to load .bmp files yourself, and write your own blitting functions.
After that, you'll need to figure out how to take keyboard input with SDL. Then you can change the position where you draw the rectangle when the arrow keys are pressed, and you have the beginnings of a game 
As Dunge says, understanding pointers and classes will be the next big leap in your programming abilities. I had trouble with pointers at first too, but they're pretty straightforward once you understand understand what memory is. Again, it's more or less one massive array of bytes. Say you have 1GB of RAM in your computer, then memory is like a 1 billion byte array. A memory address is just a number... an index into that array.
All variables are stored somewhere in memory. Different variable types (char, int, float, double) are different sizes, but all pointers are the same size (4 bytes) because they all just store the address of another variable. The pointer type tells the compiler how to interpret the data at that address.
Classes are the natural evolution of structs in C. But first let's see where structs came from Say you have 4 player characters in your RPG, and each of them has a hit point variable, and max hit points, and attack power. You could do like this:
int hp[4];
int hpMax[4];
int attack[4];
But that can get very messy because those arrays pretty much have to be global variables, so you can pass a player number to a function and the function will be able to access the player's hit points and such, like this
void AdjustPlayerHP(int player, int change)
{
hp[player] += change;
if (hp[player] >= hpMax[player])
hp[player] = hpMax[player];
else if (hp[player] <= 0)
SetPlayerDead(player);
}
Much better to do this
struct Player
{
int hp;
int hpMax;
int attack;
};
Player player[4];
void AdjustPlayerHP(Player *player, int change)
{
player->hp += change;
if (player->hp >= player->hpMax)
player->hp = player->hpMax;
else if (player->hp <= 0)
SetPlayerDead(player);
}
That way, the player functions don't need to know about any global variables, and can operate on any Player struct, rather than only the ones in a specific global array.
This is what is known as "object oriented programming". Classes are an even more convenient way of implementing this pattern:
class Player
{
public:
void adjustHP(int change);
void setDead();
int hp;
int hpMax;
int attack;
};
Player player[4];
void Player::adjustHP(int change)
{
hp += change;
if (hp >= hpMax)
hp = hpMax;
else if (hp <= 0)
setDead();
}
Class member functions have an implicit first argument which is the same as the Player *player argument in the struct version of this code. So instead of calling AdjustPlayerHP(&player[2], -10), you'd call player[2].adjustHP(-10), and &player[2] is implicitly passed as the first argument of the function. And as you can see inside the function, you can access member variables like they're locals, rather than having to put player-> before them. And when setDead() is called, the implicit this pointer is passed along to it as well.
