Well no. Working at that level is simple. I work in JS, HTML, CSS, Java, Python, C++, SQL and a bunch of other languages. And it's not just coding -- I design and develop the features, test them with our users and build things to solve their problems.
And I'm definitely making more than $40k.
" the pay listed for most "help wanted" sections was $20 - $40 per page."
They're not going to fire you for a couple of small mistakes if you've only got 7 months experience. That's what's expected from a junior dev. Hell, two mistakes is doing pretty well.
If they are inclined to fire you, they're assholes and you don't want to work there anyway -- the only thing worse than feeling a bit insecure is when the whole of the rest of the company is jumpy as well because no-one works well when they're on edge and everyone's tempers get frayed.
The guy who's shouting in public about your mistakes is already demonstrating assholeness. Just accept that he's an over-reactor. Learn some strategies for coping with the over-reactions. That's not how you train people and bluntly he needs moving somewhere where his personal issues won't damage the company's investment in taking on and training new people. Chances are you'll just have him explode at you every couple of weeks. Sorry about that, that's people. There is a chance it's not actually permanent; he may be under other stresses you can't see which may go away.
And yeah, like Erik says, just let it lie. Honestly, if he goes off the wall every other week the rest of the team are probably used to just ignoring the content of the noise anyway; their reaction's not going to be judging you, more gratitude that it's not THEM being yelled at.
 Alcohol works, but I'm not sure I'd recommend it. Meditation helps. Lunch-time shoe shopping used to get me through bad times but that's a girl thing. Put up with it for a few years, get some credit on your CV from having been involved in stuff and then leave. If you're feeling brave, you could mention the mutual support within the team not being all you'd hoped for in your exit interview and let HR fill in the blanks.
"The current way I do this is by using an STL map using a string as a key. "
Use something faster as your key? Or store the positions in an array, and now you can index into them using a symbolic name. Instead of using "u_pvmMat" as the key, use a constant called U_PVM_MAT. You're not losing flexibility because you've got hardcoded strings at the moment.
Define the constants in an enum somewhere with them.
For bonus points, autogenerate the source file containing the enum by scanning your shader sources...
Don't start founding companies yet. You'll just spend all your time doing paperwork and not enough writing code. Seriously; you have NO IDEA how much paperwork the inland revenue can throw at you. PAYE takes either a lot of doing or a lot of paying accountants to do. You can avoid it by not operating payroll, but then you just have to constantly have arguments with HMRC about how you're "not allowed" to do that (you are, but they don't like it) and that chews up time as well.
Get on with writing code. When the games are running and saleable, THEN you can go do the company founding thing.
Sampling textures is something that GPUs are very specifically designed to be good at. It's cheaper than computation in a lot of cases. It's WAY better than conditionals on SIMD architectures; you're better off doing samples and multiplying by zeros at the end than making jumps which cause a bunch of pipelines to be parked and run later. Basically at each decision, one path is taken. All the pixels in the current batch which would go the other way are parked and will be restarted when the chosen path has finished. You can see how decisions are expensive.
On MIMD GPUs, there are usually massively specialised pipelines for doing texture fetches. The individual latency isn't great on these. But you don't care. You've got millions of pixels to paint. You don't care about the latency on each paint, you care about the total pixel throughput; and that can be insane. It's not unusual for 100 or 200 pixels at a time to be doing texture fetches... each one takes 200 cycles to complete, but one completes every cycle if you can keep the pipeline loaded..
Seriously; make the fetches efficient is what keeps GPU designers awake at night, so you don't have to.
"basically, I want my item system and inventory system to work 100% like runescape."
Why not aspire to be better? If people want to play Runescape, they know where it is...
"you could use something like java's/c++ instanceof opperator"
This is exactly why virtual dispatching was invented. So you don't have to look at the types of the objects. You create an interface for doing this and your object types implement it and then you simply call through the interface.
Rule of OO design; if you're using instanceof or dynamic casts or similar monkey business, you've gone wrong in your OO design somewhere. You must find the error and either describe it accurately in the documentation or fix the problem.
Your abstract object needs to specify a way to populate a list of possible command names and actions; probably takes a pointer/ref to the object instance instance (the language object which represents the game object which is of this game type). The names are displayed. When the user picks one, the action is executed. It's probably going to be some simple interface like Java's Runnable or a C++ function object taking no parameters. (The object to apply the work to is encoded i the function object by the menu item factory)
The actual game-object-type classes implement this interface, providing suitably configured command objects as the second part of their pair.
This way, later, when you tire of implementing objects in a hard programming language you can start doing them in softer ones.. like say Lua, and writing the list populator so it fills in command names and Lua function objects and the just dynamically load lumps of Lua instead of having a build/debug cycle.
This also allows objects to change their command structures depending on the world around them. If you're in a suitably magical place, 'wield' becomes an option for the wand. If you're near a river 'deploy' becomes an option for the canoe. That sort of thing.
And since just copying another game is dull, we can think of improvements...
Provide importance ordering on the commands, and now you can float different commands to the top of the display lists (so now the appearance of 'wield' is more obvious to a player).
If you allow things to return non-executable commands, the menu for 'hat' can contain a non-selectable option saying 'already wearing a hat'. And if you remove that hat, this object will change that to a 'wear' command which does work. Now the player knows why an option might become available.
Because otherwise, you will spend the rest of your life looking at job adverts for really cool jobs. Jobs that everyone else wants as well. And which hence have a "must have computer science degree" pre-filter on them.
And you can rail about how it's unfair or try endlessly to convince gatekeepers that you're just as good as someone with a degree...
Or just go and get the degree.
It's expected you get it. Google has only just stopped regarding with suspicion people who didn't stick around for the doctorate. And even those people who will interview you will ask why no degree and you'll need a good story for that. And "couldn't be bothered" won't cut it. And you'll have to tell that story every time you go job hunting until you're 60.
" it's worth mentioning that I have a full-ride scholarship to my University"
And you're thinking of not taking that up? If you don't take an opportunity like that, you're an idiot.
Other reasons to go to uni;
Everyone else you work with will have. So if you don't, you'll always be the lone one who didn't and doesn't have stories from that time to share.
You'll meet interesting people. Where do you think Sergey met Larry? FB started on a campus. I met my husband at uni. I met people who I hired a decade later, I got hired by people I've known since uni days. It's a massive networking opportunity.
You'll learn a lot more than you think you will; including the ability to study OTHER subjects. Take those opportunities because they'll make you a more rounded person.
You'll get to do random stuff. I helped run the student cinema. I failed the technical test as a projectionist, but I did learn how to manage a door team and how to do crowd control. And once again, that's building a character. And free movies for years.
You'll be at work for long enough. If you can put it off for three or four years of good times, do so.
" Like if you had an inventory, do you use a class?"
So a useful way to start thinking about this is to do what's called verb-noun analysis. Write some short sentences about things in your world. If you have a thing in your world which has a noun for a name, then it should be a class. It'll then have verbs attached to it, and hence they're methods on it. So; "I want to show the user an INVENTORY. I want the user to be able to SORT their INVENTORY. And that gives you a class Inventory with a sort() method.
Eventually you get used to this enough that you can just sort of see the classes without doing the analysis or you can switch to more sophisticated techniques, but it's a good way to get started.
I can't see anything obvious in the host portion of the code -- certainly if that stuff works on the other phones I'd say there's no problem there.
Are you sure the shader compiles/links/uses? That's a pretty common cause of renders doing nothing. (And it's a step whose functionality differs between the different phone hardwares). Can you run the shader through the Mali offline compiler? (Available from Arm's developer site)
There's also a few example programs on their website which you could compile up and try out (they should defn render).