Tiled level layouts do not mean movement has to be from tile to tile. You can still have positions stored as float, and adjust position gradually within a tile, without having to snap to up/left/right/down tiles on movement.
In a topdown (non-isometric) level, with each tile being e.g. 128x156 pixels in size, you can move around as if the level weren't tiled. You can, however, use the tile system to figure out e.g. collisions.
Using some simple math you can figure out which tile you're standing on, and only check for collisions or whatever in tiles that are adjacent (or otherwise interesting).
In this case, you could figure out the tile by using pos.x / 128 and pos.y / 156.
This also works for isometric layouts, but the math is (slightly) more involved.
You seem to be having problems with all the code in the tutorial you are following. Have you considered slowing down and going through it more thoroughly? Even if that means taking longer, or even going back a few steps, I'm fairly certain you would benefit from it in the long run.
Alternatively, supplement your reading with an additional tutorial or something similar?
That said, I agree with cavendert -- it's impossible for us to guess at what you don't understand if you don't tell us. If there is something you don't understand, state explicitly what it is. If you get errors, state what you expect to happen, and what happens instead. If there are errors listed, include them so we can help out.
That sounds like you set position to 0 somewhere in the code you haven't posted.
You're also doing some very strange things here, indicating you might want to slow down and be a bit more thorough. For example, you have a lot of gPlayer.XPos = gPlayer.XPos; which changes nothing. This to me suggests that you might want to clean up your code a bit -- it might even help you fix some bugs you have in the process.
gPlayer.CurrentFrame = 0x00000008 means gPlayer.CurrentFrame is equal to hexadecimal (hex) 8. Hex 8 is equal to 8 in our normal counting system as well. You might want to brush up on hexadecimal numbers if this is new to you. You might also have the option to turn off hex display of values in your IDE, which can make some values easier to read (although some numbers are easier to read in hex in certain contexts).
This means, as I guessed, that you're indexing into the array which has size 8 (and maximum index 7) with the invalid index 8.
The cause is also what I guessed, the appropriate "facing/idle" if checks are always executed, even when the player is moving. This causes the gPlayer.CurrentFrame value to increment (although in a strange matter, which I also touched on in the previous post), up to 8.
After the facing/idle checks, you do the movement anim checks. This part will simply explode if gPlayer.CurrentFrame is 8, and as we see above, it clearly can be.
A simple way to verify (verifying is not fixing) this would be to put the gPlayer.CurrentFrame = SDL_GetTicks() / 150 % 8 (or 9) stuff directly before the SDL_RenderCopy calls, forcing the gPlayer.CurrentFrame value to be valid before you use it.
It should no longer crash, but your code should still be fixed properly. I'd recommend trying to find a tutorial or similar for this. The way you're doing animations and drawing now doesn't really work well for a game, in my opinion.
Print the value of gPlayer.CurrentFrame (right before each RenderCopy call) so you can see in a log/output window what the last value is.
You could also hover the variable when the application crashes, to see its value. This might be IDE specific, but the ones I know about support this.
You're only posting snippets, which makes it impossible to guess the overall flow of the thing, but if the last code you posted is directly copied, I think i see the reason for it, plus some other issues:
gPlayer.CurrentFrame = SDL_GetTicks() / 150 % 8; //Also in the facing code, with the % 9
You first increment the frame by one, but this is a complete waste. The very next line you set the variable directly, overwriting the increment operation.
If I'm reading this correctly (I can't recall the operator precedence rules here), this if will never trigger.
I'm reading it as equivalent to (SDL_GetTicks() / 150) % 8, which means that the result will always be between (and including) 0 and 7. Your if check checks for 8 and higher, which is never true.
if (gPlayer.Facing == gPlayer.RIGHT)
if (gPlayer.CurrentState == gPlayer.WALK_LEFT)
//Stuff that crashes
I'm assuming you also have a facing == gPlayer.LEFT somewhere. If you actually execute the facing (idle?) drawing always, and the overwrite with the walking animation, this will result in out of bounds reading.
The % 9 in the facing/idle code will make gPlayer.CurrentFrame be between (and including) 0 and 8. If it's set to 8, and then the walking animation code is run directly after, you will be indexing into your 8 large array (with max valid index = 7) with the invalid index
I would suggest taking a look at some Unity tutorials. It's been a while since I checked personally, but I seem to remember Unity's official tutorials being fairly decent at introducing basic concepts like this.
If you found a solution that works for you, great!
However, this kind of reasoning is something you should avoid. Whether you feel, think or guess something is slow is highly irrelevant. The compiler might do all kinds of magic to make any assumptions you have invalid, or your assumptions might be wrong from the get-go.
If you think something is too slow, profile it. That'll tell you if it actually is too slow, or if your bottleneck is elsewhere. If the bottleneck is somewhere else, all your optimizations, time spent and hair loss due to tearing at your own skull scalp might be for nothing.
If the code is too slow, then profiling before and after changes will tell you if the change actually made it better or worse. In a lot of cases, "clever optimizations" from a programmer can cause the application to run slower.
Of course, this isn't to say that e.g. algorithm knowledge is bad or wasteful -- high level changes related to algorithms are probably one of the best ways of optimizing something, and knowing whether an algorithm is O(n) or O(n^n) can matter a lot.
Also, another quote which might be of relevance:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
- Donald Knuth
And, just to re-iterate: the only way to know which parts are critically in need of optimization is by using some sort of profiling tool.
If you want to get a team to join you, you'll need to bring more to the table than just an idea. Be it art skills, programming, level design abilities, etc.
While it might seem a bit harsh, you would probably benefit from reading this as well.
Making games is difficult, and will require a lot of time. If you stick to it, you can achieve quite amazing things, either on your own or as a part of a team, but the likelyhood of you basically starting from nothing and pursuing a dream project with no prior experience AND finishing it are practically zero.