I doubt that the if true or not mattered. You simply can't control when the knockback hits, so, if you got hit right at the end of the dash when it was already trying to change sheets, both changes try to happen together and they go ham. You actually need to use "if true" events to fix that. On every animation that can be cut by the knockback (or any other animation that you cant control when it triggers) , you need to put before any event that changes sheet/state a: "if knockback (or whatever) is true, stop script"
#SEEMLESS REAL TIME ANIMATIONSHEET CHANGE
1054 messages · Page 2 of 2 (latest)
I'm having trouble after switching from Color + Monocrome to Color only. The sprites were swapping fine between each other before, but after changing to Color mode (which splits the sprite into 2 VRAM banks), the glitch returned. The strange thing is, it happens when transitioning from "standing" to "walking", even though walking uses the standing frame.
the two spritesheets are literally 1:1
Video of before GB-Color only mode:
After:
Another problem I'm having now is with the sequences. Standing -> Crouch -> Crouch Attack. I can't go from Crouch to Crouch Attack without the first frame being standing. I'm trying different states to have a different beginning while putting the standing sprite in "Default" or something, but not having much luck
I found a solution to the first problem, the two states were on different update speeds. Setting the standing to the same as walking fixed it. Just in case someone else runs into it
Figured out the other problem too. Ill help anyone who run into those problems
Hey anyone, I can get bits of this but i cant seem to integrate what im looking for. Im struggling to understand exactly how to code this for a top down game. Does anyone have an example i could pick through.
Im trying to implement this into a "player" that can
Stand still
Walk
Stand still after rising gun
Walk With gun
The last two also lock the player direction with active (strafe mode) @vagrant gazelle gave me a fantastic solution early last week.
Heck at this point, id be willing to give a little cash for some help
top down?
if you have strafing working, just make a "with gun" version of the sprite, make sure it also has the same named states for each direction (fixed direction +movenet)
and you should be completely covered with set player sheet, strafing system will work with either sheet currently loaded.
otherwise, you could have a single sheet with and without gun, double the anim states,
extra logic to check if var $gunHeld for all directions + no direction, and more logic when switching to the gun state, since it needs to check if you're strafing...
A set sheet would be a much easier drop in change, with hopefully no major graphical issues
Im trying to aggressively crunch my sprite counts.
I essentially had everything working with your help this week, then realised i have no space for an enemy
so you want to use a different sheet for every direction +- with gun?
might need to kick your strafing system into a sprite direction system, so it can set sheets on direction change without the strafe
i'm assuming you've already tried to crunched your sheets into all directions without gun, and it's not enough, has to be one direction per sheet?
Yeah, I forced it as low as i could but when changing the sheet i got the "glitch" explosion of sheets that dont use this line up seamless trick
yep, it's a bit of a hassle, but are you first struggling with a script based animation system to change sheets per direction?
or you have that working, but terrible frame glitches.
initial post's advice is great
may also suggest setting anim frame to 0, idle, then set player sheet, so it's more likely switching from frame 0 to frame 0 of new sheet.
I think, 1 - im probably way to tired, and frustrated, perhaps need to sleep on it.
2 - Largely i really dont understand what im trying to do exactly as im deeper in then i usually can understand. So when trying to "implement" anything here, im not really thinking, just copying stuff from others. I might just need to leave it for a bit... sigh
This might be of interest, I'm developing something new regarding this problem. https://discordapp.com/channels/554713715442712616/570924885291827200/1310336924807987210
Thats amazing and I support this 100% in the end I got something im atleast ok with. But going forward i would think this is a must have
I spoke with toxa and there's a few things to be considered before someone goes forward with that format. Though I think it'll still help ppl out
Any update on the VRAM changes when changing sprite sheets?
A few things I'm in the middle of now. Changing the projectile system to support the VRAM system, which also allows an unlimited amount of projectile types on a scene (but only 5 at once still until I can figure out how to up that)
I just worry of the load maybe getting too much, but I'm still relatively safe in terms of a 4x3 sprite for GBC.
And I figure most proj will be like particles, being 8x8, which won't bump up it up too much
It's also not very user friendly, I'm only used to it because I'm the one who made the system, so I need to figure out how to manage the data better
so, how does this work?
I have changed a 3.1.0 project to 4.1.2. Now, when player change the animation state a glitch sprite appears, but in 3.1.0 It doesnt appear.
Whats happening?
basically, I switch the actors sprite sheet to allow for more hitbox stuff, but it looks odd
Yeah, I do same thing.
do you know how to fix it?
In 3.1.0 works fine but in 4.1.2 when I change the spritesheet, a sprite appears before the change
Hay
Fixed following the code snippet from this threat!!!!
😄 what is the update
I got something working with around 100 different frames for my game. Its just the process of putting it together is difficult.
It involves extracting sprites into different binary files and allocating banks to contain them. Then going through the process of cycling thru them.
Maybe I'll post my stuff here after work and see if anyone finds my architecture useful for them.
What is the max framerate you can pull?
60 FPS but starts to chug a bit when three other actors and moving on screen. Still trying to optomize things
right now the new system's taking about 8% of the processing time to do its thing. I think that can be improved
I shaved off 0.2% this morning, I feel accomplished lol
I'm trying to make this technique work for a long time, but I'm not even close to make a sprite sheet transition every time I press a button. Best I could get is this script that makes the player change the sprite sheet to walking but it doesn't get back to idle when I stop pressing left
First sprite of every sprite sheet is blank, then second is the character idle position, which is the single frame sprite I'm using for transition state in every animation sheet
Here's the spike when doing an animated sequence vs one frame
needs work for sure
I'm going to have the other actors use the traditional sprite swap method, just keep this functionality for the player.
So the main code issue here is your 'if held' check. Since it executes barely a moment after the 'On Press' event starts, it will register as held 99% of the time. Your fingers won't have had time to leave the button when the check happens.
The bigger issue is the approach. Sprite sheet switching for directional movement has a huge potential for conflicts and this causes glitches. If a person were to mash the d-pad, they would be sending a lot of conflicting instructions in a very short amount of time.
That's just the nature of this technique - it works, but you have to work pretty hard to account for all possible conflicts between state and sheet changes. My best advice is make it easy on yourself and don't do basic movement this way. Keep all your directional sprites in one sheet, and only switch sheets for attacks or special animations.
thank you soooo so much man, you're a legend
how exactly do I solve this? I thought if I stopped holding the button it would go to else and there I could make it return to the other sheet, but looks like this wouldn't be the case
as for the basic movement advice, yeah man, that's great advice and certainly would make my life a lot easier, I'd have to give up on like 3 walk cycle frames though, that's so sad cause my walk cycle was very cute and cool the way it is
Well hey, if you're super keen on 3 frames then there's always color-only mode. But I understand wanting to keep it old school.
If you want to learn more about checking if buttons are held down, that's usually done with looping checks - example here: #gbstudio-discussion message