Fixing after the update
-
@vinicity I haven’t heard of that before. Do you mean like detecting where the player’s analog is and setting that as default?
-
I can recommend a "threshold" value for c.lx, c.ly, etc.
For example,
If abs(c.lx)>threshold then
// do action associated with c.lx -
@DaddyJDM said in Fixing after the update:
I can recommend a "threshold" value for c.lx, c.ly, etc.
For example,
If abs(c.lx)>threshold then
// do action associated with c.lxThat’s what I meant when talking about adding a deadzone.
The "joystick deadzone" is the area around the center of a joystick that does not respond to movement.
-
I've now come to fix my Dizzy game and I'm hoping it's another simple fix! The overlay and text are all showing, but the game area is blank. Can anyone please help?
-
Have you went through putting all your refs in?
-
@AndyG1985 Are you using setDrawTarget because you now need to make sure it is set back to the frameBuffer explicitly after drawing to an image (before update() did it automatically)
-
No, I did try adding "setdrawtarget ( framebuffer )" after update as per the forum post but this didn't help. @toxibunny - sorry, I'm not sure what you mean by this.
(Btw, I'm looking to fix the much-smaller "Dizzy 4 Fuze" program since it's the same problem affecting both, and I can copy once it's figured out.) -
@AndyG1985 Previously some arguments had been passed to functions by reference. That is a pointer to the actual object was passed. This meant that if you changed the contents in the function the change was reflected outside as well. The patch changed this so that some things are now passed by value. This means that a copy is made that is local to the function. To make it behave as before you need to add the ref keyword in front of the argument definition.
function AFunction( arg1) becomes function AFunction(ref arg1)
-
Oh sorry, yes, as Dave already explained :). Well I've added "ref" to every function with arguments and added "setdrawtarget (framebuffer)" once each after "update()", "updatemap()" and "updatesprites()", and I'm afraid it's still the same.
-
@AndyG1985 Do you want me to take a look?
-
@pianofire That would be excellent :D
The code is 5G261NNDXH.
(You’ll notice the dialogue also starts when the game does - this will be an issue with the collision areas so I can sort that!) -
I have managed to get stuff to display by moving all of the drawing stuff to the end of the main loop:
loop clear() setspritecamera (camerax, cameray) setcolliders() screen() sleep(delay) game() coins() inventory() movement() updatesprites() drawsprites() updatemap() drawmap() update() repeat
Not sure why this is now an issue. Also there seem to be some transparency problems
-
Wow that’s messed up! Thanks for trying.. it’s always something of a guessing game for me working out the order the main loop commands go in, and I’ve had a bit more of a play, but I guess the problems run deeper.
-
@AndyG1985 Yes we need to get to the bottom of this because if there are more issues with moving to the new patch they need to be documented. Unfortunately I don't know what is is supposed to look like. I will downgrade my edev to the old version and have a look
-
What a hero! Thanks for that. You may or may not need to put the main loop back in the order it was already in..
-
@AndyG1985 No it still works with that order. I see what you mean now!
-
@AndyG1985 We've narrowed down the cause of why you're not seeing anything to line 162 of the shared program.
At the end of the printText function, change it to read
setBlend(BLEND_MIX)
instead ofsetBlend(0)
and it should start displaying stuff. -
That is certainly an improvement!
-
Fantastic, thanks both for your help
-
Andy, I must come clean here. I had spent a while on your Dizzy trying to get it sorted for patch 2.15.0. Unfortunately things got on top of me and I had put it aside and meant to contact you to go through it. The blend issue will get you back on screen but there are more serious problems that will take far more effort.
You use sleep() in a few major loops. Not normally a problem! (although it is not generally recommended but that's not for here). In one of the updates in the new patch changes were made to the sleep() function.
I think this explanation is correct but I might have things the wrong way around. It doesn't matter as the end result is the same..
Early on sleep() did not perform an update internally. At some point, for one reason or another, an internal update() was added. I think it was due to keypresses not registering during sleep() or something, so it was impossible to break out of a program with the + button during a sleep(). This problem was fixed elsewhere and during the patch's development the internal update was removed.
This doesn't sound so bad - In your case however, your sleep times and your animation times are, I think, linked, and as such the animation is far too quick. I tried many things including adjusting the sleep times and had some success.
I got to the stage where it was looking pretty good but was unable to fix an issue with Dizzy jumping out of water, which due to my changes he no longer could. It was at this point I stopped and meant to pursue it with you.
In truth I think with a lot of tinkering with the animation timings it could be fixed but I don't feel it would be the right or best way.
Ideally you would refactor the animation engine and remove sleep() entirely or at the very least only use sleep() at the end of a frame to sleep for any spare time between frames to keep it consistent.
I would be very happy to arrange a video call with you to look and talk about this, or if anyone else wants to help out on sprite animation timings then great.
My apologies Andy, I hope you have not been too inconvenienced by all this.
Jonboy