Pixel-Based walking with dwimmercrafty (etheldreme!)
Moderators: Bob the Hamster, marionline, SDHawk
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
- sheamkennedy
- Liquid Metal Slime
- Posts: 1110
- Joined: Mon Sep 16, 2013 9:29 pm
- Location: Tama-shi, Tokyo, Japan
- Contact:
@Bob: Ahh cool, I see now. I guess I didn't really understand the code overall.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Actually, it's more complicated than that. Map wrapping is really hard to get right.
This is a deficiency in the engine, which I do want to fix. NPC and hero slices appear over the edges of a wrapping map because the engine does some special voodoo with their positions to make it work. Other slices parented to a map don't get this, and so aren't drawn correctly. But the slice system ought to be made to just draw slices over the map edge without requiring special positioning.
That's also the only way fix wrapping maps which are as wide as the screen, in which case a slice that crossing the screen edge ought to be drawn on both sides of the screen!
Add the following script:
Then add the following line right at the end of the main loop, before the wait(1):
You can call that script on non-wrapped maps too; it does no harm.
This is a deficiency in the engine, which I do want to fix. NPC and hero slices appear over the edges of a wrapping map because the engine does some special voodoo with their positions to make it work. Other slices parented to a map don't get this, and so aren't drawn correctly. But the slice system ought to be made to just draw slices over the map edge without requiring special positioning.
That's also the only way fix wrapping maps which are as wide as the screen, in which case a slice that crossing the screen edge ought to be drawn on both sides of the screen!
Add the following script:
Code: Select all
# This script ONLY works to make a slice correctly appear over the
# edge of a wrapping map if "camera follows slice" is
# called on that slice. In other cases, the voodoo required is even worse!
script, fix slice position on wrapped map, slice, begin
variable(mapw, maph, halfw, halfh)
mapw := map width * 20
maph := map height * 20
halfw := slice width(slice) / 2
halfh := slice height(slice) / 2
put slice(slice,
(slice x(slice) + halfw + mapw), mod, mapw -- halfw,
(slice y(slice) + halfh + maph), mod, maph -- halfh)
end
Code: Select all
fix slice position on wrapped map(player)
Last edited by TMC on Sun Nov 12, 2017 12:57 pm, edited 1 time in total.
- sheamkennedy
- Liquid Metal Slime
- Posts: 1110
- Joined: Mon Sep 16, 2013 9:29 pm
- Location: Tama-shi, Tokyo, Japan
- Contact:
Interesting. This was becoming more and more clear as I started playing around with things. I would definitely be interested in a feature which allowed all slices to wrap properly.TMC wrote:Actually, it's more complicated than that...
In the meantime I am wondering if parenting each slice to an invisible NPC would work since NPC's can wrap properly or is it not that simple? Or is the "camera follows slice" necessary? I do have the camera following a slice parented to an invisible hero and this slice wraps perfectly when it hits the edge region.
I assume this also means something like walktall will have visual issues when the NPC crosses over the wrap edge?
I should point out that my maps are always going to be larger than the screen height and width so if there's a fix in the meantime for maps of this variety which handle multiple slices, I'd be interested.
Last edited by sheamkennedy on Sun Nov 12, 2017 1:58 pm, edited 1 time in total.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Sorry the code is cryptic. My next goal here is to remove the "check cardinal direction" script and just use the friction TMC implemented. That alone should condense the code pretty significantly in addition to making it read better. I'm also working on an animation handler that doesn't just alternate between two frames. There's a sprite set per direction. I'm only animating 4 directions in my sprites but will make the code account for 8 directions. I plan on making this integrate well with the new sprite editor that has customizable frame counts. I know I shouldn't be holding my breath for that, but hey, design for the future, I guess.
After those, I'm probably going to add NPCs. They'll be slice-based fake NPCs, rather than manipulating the actual NPC slices. I'm treating slices like objects, adding children to provide more data fields. Sort of like the slice based fake array scripts on the wiki.
I'll look into the wrapping issue, but if it's not simple to fix, I'll probably put it on the backburner, just because the aforementioned items are a little bit higher priority. That being said, removing bugs is also important to me. If I find the time, I'll really try to fix it.
After those, I'm probably going to add NPCs. They'll be slice-based fake NPCs, rather than manipulating the actual NPC slices. I'm treating slices like objects, adding children to provide more data fields. Sort of like the slice based fake array scripts on the wiki.
I'll look into the wrapping issue, but if it's not simple to fix, I'll probably put it on the backburner, just because the aforementioned items are a little bit higher priority. That being said, removing bugs is also important to me. If I find the time, I'll really try to fix it.
- Attachments
-
- Spent some time making 8 frame walking sprites in each direction for testing purposes.
- Screen Shot 2017-11-12 at 5.47.30 PM.png (10.95 KiB) Viewed 3026 times
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
Parenting slices to a hero or npc walkabout slice will work fine (provided your slices appear about at the same position as the hero/npc), because those slices get positioned correctly. For the same reason, walktall works fine on wrapping maps.
The script I provided to fix the wrapping isn't going to work if there are slice-based fake npcs. I'll work on getting automatic wrapping implemented.
(If you care to look how you would script it, it's done by the closestwrappedpos, framewalkabout and update_walkabout_pos functions in the OHR source)
The script I provided to fix the wrapping isn't going to work if there are slice-based fake npcs. I'll work on getting automatic wrapping implemented.
(If you care to look how you would script it, it's done by the closestwrappedpos, framewalkabout and update_walkabout_pos functions in the OHR source)
- sheamkennedy
- Liquid Metal Slime
- Posts: 1110
- Joined: Mon Sep 16, 2013 9:29 pm
- Location: Tama-shi, Tokyo, Japan
- Contact:
Okay I think I can get by doing that for now then. I'm messing around with making a space shooter game (which has a wrapping screen) and there's no walls in the game so I think I can just parent every instance of a slice to an instance of an invisible NPC, then I can manipulate the NPC's positions for things like projectiles and the projectiles should wrap properly because the slice will be stay relatively close to it's invisible NPC pair. I'll also suspend obstacles so no NPCs interfere with eachother which repositioning them.TMC wrote:Parenting slices to a hero or npc walkabout slice will work fine (provided your slices appear about at the same position as the hero/npc), because those slices get positioned correctly. For the same reason, walktall works fine on wrapping maps.
This is more just a test than anything but I think once slice wrapping is implemented a game like this would be quite feasible and really neat.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Working on cleaning everything up. Removed the "check cardinal direction" subscript and altered much of how the velocity and direction are interpreted. I added an animation handler that uses 8 sprite sets (of any type) for each direction. It cycles through each frame of that sprite set, meaning if you're using walkabout sprites, you'll have 8-frame walking animations. However, you could load the player as a weapon sprite and have 3-frame walking. Bear in mind, the sprite dimensions do not determine the hitbox. There are player width and height constants defined at the top of the scripts.
I'll post an updated version after some testing.
I'll post an updated version after some testing.
- Attachments
-
- Here's some walking in action.
- pixel-walker0000.gif (714.5 KiB) Viewed 3001 times
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
This is the script I used to quick fix the wrapping issue.
It's not perfect. It has some weirdness when crossing the wrap line, but it's usable. I think I'll need some guidance on how to make it work more smoothly.
EDIT: Uploaded the new scripts. You can take a look if you want.
Code: Select all
script, wrap player position, begin
variable(w, h)
w := map width(current map) * 20
h := map height(current map) *20
if(slice x(player) < 0) then(
put slice(player, w+slice x(player), slice y(player))
) else if(slice x(player) > w) then(
put slice(player, w--slice x(player), slice y(player))
)
if(slice y(player) < 0) then(
put slice(player, slice x(player), h+slice y(player))
) else if(slice y(player) > h) then(
put slice(player, slice x(player), h--slice y(player))
)
end
EDIT: Uploaded the new scripts. You can take a look if you want.
Last edited by kylekrack on Tue Nov 14, 2017 12:50 am, edited 1 time in total.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
That animation system is nice.
I noticed a bug before (not sure if it's still in the latest version), where if you're standing still facing one direction and tap the opposite direction key, then the hero moves backwards but doesn't change their facing direction.
I noticed a bug before (not sure if it's still in the latest version), where if you're standing still facing one direction and tap the opposite direction key, then the hero moves backwards but doesn't change their facing direction.
Err... just use the script I posted. It's largely the same as yours, but fixes the glitch when you cross the map edge.kylekrack wrote:It has some weirdness when crossing the wrap line, but it's usable. I think I'll need some guidance on how to make it work more smoothly.
Last edited by TMC on Sat Nov 18, 2017 12:18 am, edited 1 time in total.
It'd probably help if I read things, wouldn't it? I think I was in a hurry when I posted that, for some reason. Anyway, I fixed the script to what you posted earlier. The player position no longer glitches, but the sprite still goes invisible for a bit while on the edge of wrapping.TMC wrote:Err... just use the script I posted. It's largely the same as yours, but fixes the glitch when you cross the map edge.
The animation system is completely reworked. That bug doesn't happen anymore, but I remember when it did. Animations worked using a timer before, which is what I think caused the delayed update in direction. This new system runs every tick, and it's based on the sprite's extra data, which gets incremented every tick. It resets the extra data to 0 and increments the sprite's frame once the extra data reaches the animation speed, defined by a constant. It's much smoother and will be easier to transfer to other animated sprites on the screen. It'll also allow for sprites that animate at different speeds but use the same script. Timers were a bad call for animating sprites.TMC wrote:That animation system is nice.
I noticed a bug before (not sure if it's still in the latest version), where if you're standing still facing one direction and tap the opposite direction key, then the hero moves backwards but doesn't change their facing direction.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
What? I downloaded the last version you uploaded (from the 14th), simply replaced your wrapping script with mine, and it works perfectly. Maybe you made some other edits to the scripts since then.kylekrack wrote:Anyway, I fixed the script to what you posted earlier. The player position no longer glitches, but the sprite still goes invisible for a bit while on the edge of wrapping.
Oh I see, the problem with using a timer is that timer-triggered scripts will run before other scripts, but you need them to happen afterwards.The animation system is completely reworked. That bug doesn't happen anymore, but I remember when it did. Animations worked using a timer before, which is what I think caused the delayed update in direction.
Your animation scripts look clean and reasonable. You have the grisly details isolated to some utility scripts, but aside from those it's quite simple and general.
Last edited by TMC on Sat Nov 18, 2017 5:03 am, edited 1 time in total.
It was a typo. My bad. Thanks for providing that fix, though. I would never have come up with that solution on my own.TMC wrote:What? I downloaded the last version you uploaded (from the 14th), simply replaced your wrapping script with mine, and it works perfectly. Maybe you made some other edits to the scripts since then.kylekrack wrote:Anyway, I fixed the script to what you posted earlier. The player position no longer glitches, but the sprite still goes invisible for a bit while on the edge of wrapping.
I kept anything that accessed slice extra data in utility scripts because that's the part that's totally unintuitive. That way, adding changes to the scripts should be more doable, and if I want to change how data is managed, I won't have to change the main scripts. I'm happy to hear you endorse them.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
Update: NPC movement
I got slice-based NPCs to load, animate, and move properly based on various attributes. You can adjust in the scripts what sprite type your NPCs have, allowing you to load any sprite as an NPC. However, you will be limited to the frame count that sprite type provides. NPCs can animate in 8, 4, or 1 (no sprite change based on direction) directions. In order to give an NPC more animated directions, you'll have to add sprite sets. For example, if you want an NPC to have 4 different directional sprites, you'll create the original as facing right, then the 3 sets directly below that original will be down, right, and up, respectively.
There are currently two functional move types: Wander, and not. Standing still counts as a move type, at least that's what I tell myself. Because the built-in move types are grid-based and I'm not using actual NPCs, I have to script all of the different types of movement. This means James's new pathfinding probably won't make its way into these scripts.
Drawbacks and major hurdles for NPCs are collisions with the player and between NPCs, and zone behavior for NPC movement. Because I am using move slice with wallchecking() to move NPCs, they ignore zones, and adding in that check to bypass the command will be challenging. I'll figure something out. For now, this is what I've got. I still need to clean up the scripts a lot. They're expanding at an unfortunate rate, and getting quite convoluted. I plan on splitting the scripts into multiple files so that the massive list of utility scripts doesn't become overwhelming.
I got slice-based NPCs to load, animate, and move properly based on various attributes. You can adjust in the scripts what sprite type your NPCs have, allowing you to load any sprite as an NPC. However, you will be limited to the frame count that sprite type provides. NPCs can animate in 8, 4, or 1 (no sprite change based on direction) directions. In order to give an NPC more animated directions, you'll have to add sprite sets. For example, if you want an NPC to have 4 different directional sprites, you'll create the original as facing right, then the 3 sets directly below that original will be down, right, and up, respectively.
There are currently two functional move types: Wander, and not. Standing still counts as a move type, at least that's what I tell myself. Because the built-in move types are grid-based and I'm not using actual NPCs, I have to script all of the different types of movement. This means James's new pathfinding probably won't make its way into these scripts.
Drawbacks and major hurdles for NPCs are collisions with the player and between NPCs, and zone behavior for NPC movement. Because I am using move slice with wallchecking() to move NPCs, they ignore zones, and adding in that check to bypass the command will be challenging. I'll figure something out. For now, this is what I've got. I still need to clean up the scripts a lot. They're expanding at an unfortunate rate, and getting quite convoluted. I plan on splitting the scripts into multiple files so that the massive list of utility scripts doesn't become overwhelming.
- Attachments
-
- A 4-directional NPC's sprite sets
- Screen Shot 2017-11-28 at 3.48.46 PM.png (66.34 KiB) Viewed 2887 times
-
- Here's some NPCs wanderin around
- pixel-walker0003.gif (314.2 KiB) Viewed 2889 times
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
Cool, is this getting somewhere! Lack of NPC-NPC collision doesn't look terrible; the biggest thing missing is NPC activation.
Aside from a command to do zone checking, I guess it might make sense to have one for moving with collision checking too... put probably it should just be a script anyone can use, because which slices should obstruct each other, or whether anything special should happen when they collide is game-specific.
Amusing use of the default graphics... when I saw an earlier .gif you posted, it never dawned on me that two NPC graphics might be a single NPC.
Aside from a command to do zone checking, I guess it might make sense to have one for moving with collision checking too... put probably it should just be a script anyone can use, because which slices should obstruct each other, or whether anything special should happen when they collide is game-specific.
Amusing use of the default graphics... when I saw an earlier .gif you posted, it never dawned on me that two NPC graphics might be a single NPC.