ID:118266
 
http://www.byond.com/developer/Forum_account/PixelMovement

I posted an update which includes support for BYOND's new pixel movement feature. You can use the library's API to access the new feature. All demos that come with the library and any project you had that used the library will automatically work with BYOND's new feature.

The library defines a compiler flag that you can use to switch between the native pixel movement and legacy support. The legacy mode is needed for features not supported by the native feature.

I don't have any large projects of my own that use the pixel movement library so it's hard for me to really test this. I have projects that use the sidescroller library so I can be fairly sure that once Tiny Heroes runs the same way in both modes that the library is correct. For the pixel movement library, I'll just post the version and see what doesn't work.
Glad you didn't just scrap your library because it's native now. You handled this well.
There was never a doubt about keeping the library because there's still plenty that the library does for you. Handling the actual movement and collision detection was always just a small part of it.
Damn, I just got bored and converted Eternia over to native pixel movement. Hopefully, I'll get really bored and convert it to your library.
Some of the demos are giving errors.
Tensa Soul wrote:
Some of the demos are giving errors.

Which ones and what errors? Some always give errors depending on what flags are defined in _flags.dm.
we made a game Bleach Online Adventure using pixel movement libary nd at 1st I didn't lag but ass we added on more stuff it lagged now we cnt use da pixel movement libary anymore...is there anyway to fix it.?
We use a 64x64 base and a fullscreen game(40x45)
Anime HQ wrote:
we made a game Bleach Online Adventure using pixel movement libary nd at 1st I didn't lag but ass we added on more stuff it lagged now we cnt use da pixel movement libary anymore...is there anyway to fix it.?
We use a 64x64 base and a fullscreen game(40x45)

Even with built-in pixel movement it's easy for lag to be an issue because games will now run at 30 or 40 frames per second. To fix it you need to figure out what's broken first. Profile the world to see what procs are taking up the most CPU time.
Ok how do we profile the game.?
What should we do.?
Anime HQ wrote:
Ok how do we profile the game.?
What should we do.?

You need to enable debugging (put #define DEBUG) in your code then run the game, click on the icon in the top-left corner of the window, go to "Server", then select "Profile...". That'll bring up a display which you can refresh that'll show you CPU time spent in each proc and it has a tab to show network traffic. This should help you figure out what procs are bogging your game down.
O yeaa true thanks...
Well what if I do that with dreammakers prefences instead of coding it.?
and after I profile what should I do with the procs.? Recode them or delete them or what.?
It depends on what the issue is. The profile just helps you find what's causing the slowdown.

If you have a fireball attack that spawns 40 fire objects, maybe 40 is just too many and you should make it 12 instead. Maybe a proc is just coded poorly and is doing something inefficiently (ex: doing for(var/mob/m in world) to find a mob instead of storing a reference to it).
Ok thanks...
Do you think you could take a look at the source for us.? Mayb make a few tweaks to the pixel movement for us.?

Or is it possible to make a jumping system without pixel movement.?
Ok thanks...
Do you think you could take a look at the source for us.? Mayb make a few tweaks to the pixel movement for us.?

Or is it possible to make a jumping system without pixel movement.?
Nice update!

Looks like I will start using your library due to the release of native pixel movement!
Calus CoRPS wrote:
Nice update!

Looks like I will start using your library due to the release of native pixel movement!

Thanks! I'm glad to hear that even though the library has always been solid. You could have been using it right along and automatically had your project use the native feature =)

I'm still working some kinks out, but it looks like the BYOND staff is too. The library has a legacy mode which uses the same soft-coded movement it's had right along, so you're able to use that while problems with native support are worked out.
Forum_account do you have a msn or email I can talk to you with or a Instant Messaging or somethinq.?
Anime HQ wrote:
Forum_account do you have a msn or email I can talk to you with or a Instant Messaging or somethinq.?

Nope, but you can ask questions here or post them on my forum.
Forum_account wrote:
Tensa Soul wrote:
Some of the demos are giving errors.

Which ones and what errors?

loading pixel-movement.dme
top-down-demo\demo.dm:48:error: pdepth: undefined var
top-down-demo\demo.dm:52:error: pdepth: undefined var
top-down-demo\demo.dm:56:error: pdepth: undefined var
top-down-demo\demo.dm:56:error: pz: undefined var
top-down-demo\demo.dm:62:error: pdepth: undefined var
top-down-demo\demo.dm:81:error: pdepth: undefined var

loading pixel-movement.dme
isometric-demo\demo.dm:22:error: pdepth: undefined var
isometric-demo\demo.dm:45:error: pdepth: undefined var
isometric-demo\demo.dm:49:error: ramp: undefined var
isometric-demo\demo.dm:50:error: ramp_dir: undefined var
isometric-demo\demo.dm:54:error: ramp: undefined var
isometric-demo\demo.dm:55:error: ramp_dir: undefined var
isometric-demo\demo.dm:56:error: pdepth: undefined var
isometric-demo\demo.dm:60:error: ramp: undefined var
isometric-demo\demo.dm:61:error: ramp_dir: undefined var
isometric-demo\demo.dm:66:error: pdepth: undefined var
isometric-demo\demo.dm:71:error: pdepth: undefined var
isometric-demo\demo.dm:76:error: pdepth: undefined var
isometric-demo\demo.dm:83:error: pdepth: undefined var
isometric-demo\demo.dm:89:error: pdepth: undefined var
isometric-demo\demo.dm:92:error: ramp_dir: undefined var
isometric-demo\demo.dm:93:error: ramp: undefined var

loading pixel-movement.dme
icon-size-demo\demo.dm:21:error: gravity: undefined proc
icon-size-demo\demo.dm:22:error: jump: undefined proc

etc
By default the library uses BYOND's native pixel movement feature, but this also means that it doesn't support ramps or 3D movement (which all of those errors appear to be about). When you're using native pixel movement the library won't even define the pz, pdepth, ramp, ramp_dir vars or the jump and gravity procs, so you'll get compiler errors when trying to run demos that use those features.

To get those to work you need to go into _flags.dm and switch to soft-coded mode by doing this:

// make sure this line is commented out:
// #define METHOD NATIVE

// make sure this line is NOT commented out:
#define METHOD LIBRARY


I'll add a note in each of those demos to explain this.
Page: 1 2