Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[Siquo]

Argument gp, or "the player".

[Rose]

but is't your complain that is isn't centering on it?

* Japa is confused.

[Siquo]

Oh that's what you mean

Well, if I move around, the window moves, too, but at a higher/slower rate than the player. Then it suddenly starts jumping all over the place...

This is what I use to get the location from grid to screen, and from screen to grid: ty and tx are graphic-offsets and zero for this purpose, 32 is tile width.

Code: [Select]

    public Vec3 getScreenLoc(float x, float y, float z, float tx, float ty){
    return (new Vec3((int)(tx-viewPortX +(32*(x-y)/2)), (int)(ty-viewPortY +(32*((x+y)/2))/2), 0));
    }
    public Vec3 getRealLoc(float u, float v) {
   
    float x = -(2*viewPortY+viewPortX-2*v-u)/32;
    float y = -(2*viewPortY-viewPortX-2*v+u)/32;
    return (new Vec3(x,y,0));
    }
See: http://nam.siquo.net/webgames/lets-dev/, controls are WESD.
Hold D for long enough and the viewport should catch up to the actual playerperson.

[eerr]

I think you need to make hordes and hordes of constants so you, and us have to deal with less highly-complicated math.

[Siquo]

BUT THIS IS THE SIMPLE PART and my brain is getting more stupid by the day. 10 yrs ago this would've been easy.

[eerr]

Then make a diagram to help with the map.

needs a tilted iso map.

box defining camera.

labeled axis.

some points for reference.

[Siquo]

I got nothing, I slam my head against the keyboard until it works. But that might just be a good idea

[TolyK]

Alright.
http://www.bay12forums.com/smf/index.php?topic=64473.0
Wanting to get this to work with the lastest DF.
How should I go about this?
(Related note: where to get the older version for it? )

[Thendash]

You're passing a GamePhysical object to getScreenLoc, but then in the code you posted it accepts 5 floats. I'm assuming you overloaded the function, can you post the code that only takes gp? I think eerr is right, it's probably a mistake somewhere in the math.

[Virex]

I got nothing, I slam my head against the keyboard until it works. But that might just be a good idea

Whenever I hit a roadblock, it often helps me to write (or in your case rewrite) the solution not as what you want the computer to do, but more like an explanation to a person (as far as the syntax allows it of course). So instead of  (warning, Lost In Superfluous Parenthesis-syndrom possible)

Code: [Select]

(case (get-button)
  (1 (setf (x player) (1+ (x player))) ;Could've used incf and decf here, but this is probably easier to understand for you
  (2 (setf (x player) (1- (x player))))I'd write

Code: [Select]

(on-button-press
  (right (move player right))
  (left (move player left)))Or even

Code: [Select]

(on-key-press
  ((direction-key-p key) (move player (direction key)))) ;Using the -p suffix for a predicate function, which is a function that checks a property and returns a booleanand then worry about the exact implementation of in this case on-button-press and move (note that the last one may not be translatable into a language that lacks macros). This way, you build yourself a set of operations that can be used to write code in a much more legible way, which then helps with debugging and makes it easier to write new code. In your example, a line like (2*viewPortY+viewPortX-2*v-u)/32; makes me shudder, because it's error-prone and hard to read. If you'd split off those math operations into seperate functions and rigorously test them you'd probably find the bug rather quick.

[eerr]

It should be noted I made something similar for my brother, to align pictures in his iphone game.


If the camera's edge would travel beyond the corner of the iso map,
It must be forced back,(hard limit.)


If camera's left side.x<corner of isomap.left.x,  Camera center.x= camerawidth/2 +corner of isomap.leftside.x

Four of these to make sure the camera doesn't  scroll off the side.

The pluses and minuses change haphhazardly.

"corner of isomap.leftside.x" because the x location or y location of the corner of a tile is not the same as it's raw coordinate. But you could get away with just the raw position because nobody cares.




As the player moves about, the camera otherwise centers on the player.
(this is the simple part.)

Though for whatever reason, In your math, the camera Accelerates toward the player.
Odd, but it works(and allows you to actually get something done with terrible camera alignments!).

[Siquo]

My way of doing math is Darwinistic:

1. Make shit up.
2. Test it against the situation I want it to work for. Not quite done? Goto 3.
3. Randomly add/remove actions (add, multiply, etc) and constants.
4. Goto 2.
5. Profit.

This yields me results that nobody understands but work for the current parameters, but as soon as I want to use it for something it hasn't been tested for, it fails and I need to restart the process, taking the new situation into account. I also never get profit.


Damnit, this means I actually have to think about this.

[Virex]

hmm, that would explain why I've got a hard time following your code...
Also, you sound like an anthropomorphic version of eureqa, eureqa-san so to say

[Siquo]

Yeah something like that. Genetic algorithms have that tendency. There was once this self-reconfiguring lego-block-assembly thing that assembled into something that performed, but the creators didn't know how it did it, as it wasn't supposed to (they found out much much later there was a short circuit in one of the blocks that is was using as a feature instead of a bug).

Okay, redoing the math on paper this time.
Grid-to-Screen:
X = x-y (and some constants)
Y = (x+y)/2  (and some constants)

Screen-to-Grid:
x = (2Y+X)/2
y = (2Y-X)/2
(and some constants)

This is about what I have. Hmm, I think that's correct. So it must be the viewport code. I'll try something tonight.

[SolarShado]

One odd bit that I noticed:
You seem to include the current viewport location in the calculations for the new position. This means where the viewport ends up is relative to where it started, which I doubt you want.