ButchDean, on 11 July 2012 - 09:14 AM, said:

Good advice, I only knew of Github, but I haven't fallen into the habit of regularly using it for getting some input, except google somehow manages to direct me there

Ah that clears things up a bit.
Though I think it's funny to have a basic function like the edit button as a reward for a certain amount of posts.
Thanks for your input!

Have a look at this channel:
http://www.youtube.c.../CodingMadeEasy

Daaang, I'm tooo slow, every friggin time.
Anyway, now that I started this I will post it anyway, maybe it gets you some new ideas anyway, if not, who cares.


First of all, I think you should rather use a switch instead of all the different if-statements from line 69 on:

switch(tdarray[j][i]){
  case "g":
    //draw statement
    break;
  case "d":
    //draw statement
    break;
// etc ...
}

Then, I think what jon.kiparsky just described is called a viewport.
A viewport describes which part of the map or level you are currently on should actually be drawn on the screen.
As he already said, basically it is just 2 values which tell you how many pixels more to the right and hoch many more down your are starting drawing the map.
If I understand your code correctly, your map is tile-based, and every tile is represented by an image which is then drawn to its position within your 2D-array. (I have only worked with complete background images so far)
It would help to know if the movement is also tile-based, because with your approach, scrolling gets more complicated if it is pixel based movement.
So if you can move one tile at a time, you have to think about when you actually want to scroll. Do you scroll when you are at the edge of the screen, or do you scroll most of the time while staying in the middle of the screen, and only actually move when the viewport is already at the boundaries of your map?

In any case, to scrool you would theoretically just to do something like this:

y = j*size;
x = i*size;

// lets assume you have a viewport class
vx = viewport.getX()
vy = viewport.getY()
// this means the viewport is currently scrolled 2 tiles to the right and 2 tiles down


if(tdarray[j+vy][i+vx].equals("g")){       
  g.drawImage(grass, x, y, size, size, this);

By adding the scroll positions of the viewport to the tdarray's j and i, you start drawing the tiles at [2][2] instead of [0][0], which should equal a scroll position of 2 tiles to the right, and 2 tiles down.
Of course it's still up to you to decide what the conditions are to change the viewport.

Of course, all that is assuming I actually understood your code, havn't done any Java in a while and don't know what that game is about so, yeah.

Damn it, where the hell is the edit button?
Anyway I have to add, this comment

// this means the viewport is currently scrolled 2 tiles to the right and 2 tiles down

makes no sense, please ignore it!
I had some fixed values there initially and realised that was bullshit.

Gazuu, on 27 June 2012 - 10:33 AM, said:

Still more bullshit (seriously, edit button where are you?)
there is the 2/2 again, of yourse it has to be [0+vy][0+vx]

Kilorn, on 26 June 2012 - 12:00 PM, said:

So, you couldn't you also just set the size of the array to that of the overlapping area, since you only need those pixels?

I've actually never worked with XNA, but collision detection will be the next big concern for me after I'm done with the networking part so far in my little Ruby project, that's why I was participating here because it's more about logic than syntax. Also, I'm kinda glad that size of arrays is no concern for me with Ruby
I always hated not being able to change array size in Java without some copy-paste-method.