ID:155887
 
Hi, i'm trying to figure out how does:

1) Pixel movement works in byond?
2) How to do it with projectiles.


I'm not asking for any code but any procs that may help with this or anything similar is welcomed and i can try to figure out myself.


Basically im trying to design my own pixel movement system and the pixel projectiles librarys aren't what im really looking for.

I'll know you'll ask me to reference up pixel_x and pixel_y but are there any maths involved in making a really good pixel projectile system?
Gamemakingdude wrote:
1) Pixel movement works in byond?

Sure, and it's piss easy. Basically, you displace an atom's location every time it should move until it tries to move and it's already displaced "off" of its current tile, then you move it to the adjacent tile and readjust the displacing.

Though I don't know how fluid the results would be over a network and with multiple players nowadays, that is something to find out.

2) How to do it with projectiles.

No differently than you'd do it with another movable atom such as a mob.

I'm not asking for any code but any procs that may help with this or anything similar is welcomed and i can try to figure out myself.

Just to make it clear, there's absolutely nothing to it other than using the pixel_* vars and BYOND's regular location/movement system (Move(), loc, etc).

I'll know you'll ask me to reference up pixel_x and pixel_y but are there any maths involved in making a really good pixel projectile system?

If you want to do more in-depth collision detection than tile-based collision, you'll have to resort to some math to implement your bounding-box-based (or whatever you choose) collision, but nothing too groundbreaking. The rest is programming logic.

I believe there are many examples already on the forum and hub if you need a base or some pointers to get started from.
In response to Kaioken (#1)
Should i also be looking into erm... Shadowdarke library?
In response to Gamemakingdude (#2)
That'd be a good starting point. Just don't copy and paste code from libraries. It's bad practice for one, not to mention the hordes of problems it causes in the long run because of excess variables and what not. Remember, libraries are meant to be learned from, not used.
In response to DemonicK (#3)
DemonicK wrote:
Remember, libraries are meant to be learned from, not used.

It's the reverse, actually. They're built to solve a problem in a plug-and-play fashion. Any learning material in them is often an afterthought--or at least not their main purpose--and has often been clouded by optimization. This isn't always the case, but as a rule of thumb, if you're trying to learn by reading libraries all you're going to get is a headache.

I think you're thinking of demos.
These are decent places to start:

http://www.byond.com/members/ Forumaccount?command=view_post&post=99026

http://www.byond.com/members/ DreamMakers?command=view_post&post=77879

The Vectors article may be more advanced than you need if you just want box collisions, but it can do a lot of cool things.
In response to DarkCampainger (#5)
Thanks dark i'll check those out!
Gamemakingdude wrote:
Hi, i'm trying to figure out how does:

1) Pixel movement works in byond?
2) How to do it with projectiles.

As others have said, you can use the pixel_x and pixel_y vars to move objects a fraction of a tile at a time. Most approaches define a proc that moves an object a specified number of pixels. Generally, the proc checks if the move is valid, and if so, it performs the move (updating pixel_x, pixel_y, and loc accordingly).

Edit: I forgot to mention it initially, but another big way that approaches to pixel movement vary is collision detection. Most people use rectangles to approximate the shapes of objects. The benefit is that turfs are rectangles, so by treating mobs as rectangles too every object is the same shape. Some people use circles, but by using a different shape you then have to worry about circle-circle collisions, circle-rectangle collisions, reectangle-circle collisions, and rectangle-rectangle collisions. My libraries treat all objects as rectangles (2D rectangles in the Sidescroller library, 3D rectangular prisms in the Pixel Movement library).

There are different ways to check if a move is valid. There are some very simple methods but they have drawbacks. Depending on how you'll be using it, you might not like the drawbacks. The simplest method is to check if the move would place the object inside another one. If so, it's not valid and no move is made. This is very easy but has some drawbacks. For example:

             +---+
+---+ | B |
| A | +---+
+---+
######################
######################


If mob A moves down and right it'll place them inside the wall so the move is invalid. However, what you'd usually want to happen is that the mob slides along the wall to the right.

If the gap between mob B and the wall is 5 pixels and the mob tries to move down 10 pixels, this move would place them inside the wall and is invalid. What you'd want to happen is that the mob moves 5 pixels down instead of 10.

When making my pixel movement libraries (Forum_account.PixelMovement and Forum_account.Sidescroller) I made sure I addressed this problem by using a more complex method. Instead of just saying "oh, the move would put you inside the wall so it's invalid, you don't move at all", the library figures out how the move can be adjusted so that you still move in the desired way.

Before making my pixel movement demos and libraries I looked to see what existing approaches existed. Most of the demos I found used the simple approach I mentioned. Here is the list of what I found:

PixelMovement by Ebonshadow (110 lines / 20 lines)
* does not support "sliding" along walls when your move is oblique to the wall.
* doesn't perform partial moves, they just fail completely

Simple Pixel Movement by VcentG (430 lines for code+demo)
* very buggy
* the code doesn't seem to support variable sized bounding boxes
* doesn't check all necessary tiles for collisions

K_Pixel_Movement by Kakashi24142
* no longer available

alternate movement by Jotdaniel
* no code
* strange implementation - pushes you out of walls by moving you backwards
* this also doesn't allow for sliding along walls.

Pixel Movement by Wtrbooger
* no code
* no obstacles so there's no way to evaluate it

C Pixel Movement/Collision by Cody123100 (500 lines / 250 lines)
* overly complex code
* doesn't allow for sliding along walls

CG - Pixel Movement by Chris Gayle
* no code
* seems to mask bugginess by having a very small step size
* limited movement makes it hard to tell how robust it is

Simple Pixel Movement by IainPeregrine
* not on hub, available here: http://files.byondhome.com/DreamMakers/2008-03/ IainPeregrine-0001/simple_pixel_movement.html
* playable demo here: http://www.byond.com/members/DreamMakers/files/2008-03/ IainPeregrine-0001/PX_part1.zip
* limited code available and it's not in a .zip
* collision detection is easy, collision resolution is not. The demo resolves collisions by making you explode, which would be a rare application of pixel movement.
* it's hard to tell how useful this code would be for other applications.

Demo by Mr.Tophat
* from a forum post: http://www.byond.com/developer/forum/?id=741448
* broken link: http://www.byond.com/members/MrTophat/files/pixelsample.zip

Megaman Files Pixel Movement Demo by Fugsnarf
* from a forum post: http://www.byond.com/developer/forum/?id=736605
* broken link: http://www.byond.com/members/Fugsnarf/files/MMF2test.zip

Zelda: Link's Awakening Pixel Movement by Fugsnarf
* from a forum post: http://www.byond.com/developer/forum/?id=730563
* deleted hub entry: http://www.byond.com/games/Fugsnarf/ ZeldaLinksAwakeningPixelMovement