Pixel Movement?

[Sealbreaker]

> The timers won't be objects. They will be using the GetTickCount method most likely.
> There's no need for too slow/fast checks. Once the key is let go, a packet is sent to halt it immediately.

yeah, but i meant that a timer/the gettickcount-method checks if the user has released the key/pressed the key to fast in a row… that would spam packages and lag the server, right? May be that i didnt understand your answer right... sorry if so :P (I'm german.. that's always my excuse for that ^^ )

-seal

[Robin]

Just drop that idea completely. The only reason it's even been brought up is because Miguu misunderstood what I was saying about interpolation.

[viciousdead]

Q: Would you guys like to have Eclipse utilize pixel-movement?
A: God yes, I would love to have it! Only problem I could see would be mapping…

Q: How would you make mapping work through this pixel-movement system?  :sad:

[Robin]

@ShawnyBoy:

> Q: How would you make mapping work through this pixel-movement system?  :sad:

The exact same way it always has…

[Chakkra]

This is an awesome idea. I've always hated tile movement. **Especially** in PV because it was so choppy looking.
In top-down mmorpgs this is a great idea too. Tile movement is too outdated for Eclipse and I think that it should definitely get pixel movement.

[ddunit]

@Robin:

> @ShawnyBoy:
>
> > Q: How would you make mapping work through this pixel-movement system?  :sad:
>
> The exact same way it always has…

I think he means to ask if we'd still have tile based block tiles.

[mrmiguu]

@ShawnyBoy:

> Q: Would you guys like to have Eclipse utilize pixel-movement?
> A: God yes, I would love to have it! Only problem I could see would be mapping…
>
> Q: How would you make mapping work through this pixel-movement system?  :sad:

Tiles work the exact same way. The player's collision tile isn't 32x32 anymore so they can walk around inside one empty tile block fully. When they cross over, that's when collisions are checked. I also have a system (since movements of 4 causes the player to slip outside the tile by one pixel) to where it adjusts how far you move if there is an object in the way or you're trying to go out of bounds. It's called PixAdj. Instead of moving 4, you can move 3, 2, or 1 depending on how many you need to move in order to be at the very edge of the tile you're moving in.

[Robin]

@MrMiguu:

> (since movements of 4 causes the player to slip outside the tile by one pixel)

32 / 4 = 8.

You're doing something horribly wrong if your player movements need to be clamped.

[mrmiguu]

@Robin:

> @MrMiguu:
>
> > (since movements of 4 causes the player to slip outside the tile by one pixel)
>
> 32 / 4 = 8.
>
> You're doing something horribly wrong if your player movements need to be clamped.

No. I actually debugged it. You do move over. If you're moving in even patterns, you can't walk to the very right edge without crossing over into the next tile. I aldeady did this. I knew what I was doing. I'm not that stupid. If I didn't need to do it, I wouldn't have. Plus, I wanted to make the system work for all variables of PIXEL_STEP, depending on what the player put in for the value (if it was 3, that'd cross over for sure).

[Jeff]

this will be put into EO final, correct?

[mrmiguu]

@ Robin:

@Jeff:

> this will be put into EO final, correct?

In my version, I'm assuming. Robin wants nothing to do with my code and I don't blame him.

[Robin]

Movement should start at 0, not 1.

[Kusy]

Is it possible / good idea to make pixel blocks by adding a mask file for the tileset? Everything that is black is a block - everything that is transparent is not and make the engine overlap the graphics tileset with the mask tileset placing blocked pixels on their graphical equivalent… I have absolutely no idea if that even sounds reasonable but whatever ;D

[Robin]

Graphics are client-side. Collision detection is server-side.

[mrmiguu]

@Robin:

> Movement should start at 0, not 1.

It does. You obviously don't understand. I showed an inversely colored pixel at 0 to demonstrate where it started. Count it out. I know what I'm talking about. Try to find some reasoning behind my madness.

[Robin]

0 + 4 = 4
4 + 4 = 8
8 + 4 = 12
12 + 4 = 16
16 + 4 = 20
20 + 4 = 24
24 + 4 = 28
28 + 4 = 32

Players cannot drift over the edge of the tile without breaking the laws of the Universe.

I'm going to take a stab in the dark here and tell you that your movement code is wrong.

If moving 4 pixels at a time took you off the tile, you'd be constantly triggering the gliding bug in Stable, as not clamping the player's movement is what causes that.

[Mikekan13]

Robin are you saying pixel movement should be handled with udp?

[Robin]

I'm saying you should buffer it the movement packets if you're serious about sending so many. What system you use is up to you.

[Mikekan13]

what do you mean by bufffer? I am currently sending a packet every 2 seconds or so that tells the server I am currently moving and in what direction. The server then actually moves the players x and y after checking for collisions and then tells the client the new x and y for the player.

[mrmiguu]

@Robin:

> 0 + 4 = 4
> 4 + 4 = 8
> 8 + 4 = 12
> 12 + 4 = 16
> 16 + 4 = 20
> 20 + 4 = 24
> 24 + 4 = 28
> 28 + 4 = 32
> Players cannot drift over the edge of the tile without breaking the laws of the Universe.
>
> I'm going to take a stab in the dark here and tell you that your movement code is wrong.
>
> If moving 4 pixels at a time took you off the tile, you'd be constantly triggering the gliding bug in Stable, as not clamping the player's movement is what causes that.

32 is in the next tile. A tile's pixel range is 0 to 31, making a total of 32 pixels. The 32nd pixel is the next tile over. So, you're wrong.

[Robin]

32 = 0 = Not moving. This is how the collision detection works.

[mrmiguu]

@Robin:

> 32 = 0 = Not moving. This is how the collision detection works.

What does that even mean? I see nothing wrong with how my system works. It's dynamic. It works for all set values to PIXEL_STEP (if a developer wants players to move in intervals of 3, 2, or 7 pixels). The way I did it is clean and perfectly acceptable. I wouldn't have done what I did if I didn't have to.

[Robin]

I'm not arguing that fact. Hell, the exact same system is used in Origins.

What I am doing is pointing out how the collision detection currently works. You said moving 4 pixels at a time (the default speed in old versions of Eclipse) takes you off the tile. That isn't the case.

[mrmiguu]

@Robin:

> I'm not arguing that fact. Hell, the exact same system is used in Origins.
>
> What I am doing is pointing out how the collision detection currently works. You said moving 4 pixels at a time (the default speed in old versions of Eclipse) takes you off the tile. That isn't the case.

Yes it is. If you're at 0, you move 4 and end up on pixel #4\. Then 4 again moves you to 8\. After a while, you end up on pixel #32, which breaks the boundary limit of that tile. I've done tons of pixel art and measuring. I am very anal about things being perfect and symetrical. It works and I was forced to make a system like this. It's obvious that you're never going to understand my view point since you've already created your own. What's the point in arguing? Nothing.

[ddunit]

In all the years I've known Miggu, I can certainly say that he's one hell of a fucking perfectionist.