next »

[GZ]

It looks fine for me. That problem usually happens when surfaces aren't supported and the graphics card renders funny like that. If it bugs you, you can try setting the view to .1 or .5 more on both the X and Y plane because it can trick the graphics card into rendering properly. I had this problem on one of my old PCs and setting it +.5 more after all of my view stuff would align it right (although you will want a variable to toggle this, since when you release the game you will want that off).

[caiys]

Ah thanks a bunch GZ, as you said, temporarily increasing the wview and hview by .5 fixed it right up on my comp. 

[sandcrab]

New questions on viewports and activating and deactivating objects! :D

I am deactivating objects outside a certain range of my viewport, but others are supposed to destroy themselves outside the viewport.  So I set the Deactivate range to be four tiles outside the viewport, to allow objects ample space to get there, and I set the ones that destroy themselves to be destroyed 16 pixels (one tile) outside the viewport, otherwise they disappear while partially on screen.

The problem is that with some objects, they don't destroy themselves on the right side of the screen, but they do on the left.  Also, if I change my numbers to destroy still within the screen (or right at the border) it does work, but I don't want it to happen on screen.  I'm sure I'm doing something wrong that's really basic.

The "all-objects-deactivate" code:

Code:

instance_deactivate_region(view_xview[0]-64, -240, view_wview[0]+64, room_height+240, false, true);
instance_activate_region(view_xview[0]-64, -240, view_wview[0]+64, room_height+240, true);

And this code works, but it destroys the instance while on screen.  If I change the values to -16 and +16, then the left border works but the right border doesn't.  Enemies deactivate on the right and then I catch up to them all in one big lump:

Code:

if (x < view_xview[0]+16) || (x > view_xview[0]+view_wview[0]-16)
    {
    if (spawnWolf)
        instance_destroy();
    }

I don't understand why I needed to add view_xview and view_wview in order to make this work, either.  In the deactive script (taken from the tutorials here) the right side of the screen is referenced with view_wview alone, but when I tried it in the enemy code, it didn't work right.

My other question is how can I have some objects that never deactivate, or more specifically, never deactivate again once activated?  I looked up the instance_deactivate commands in the help files and it says that the feature is "mainly left in for backward compatibility," but doesn't suggest anything to use as an alternative.

Thanks!

[GZ]

Nothing is jumping out at me, so I think it might have to do with other systems in the game. For instance, the deactivate code works based on the collision box of the object, while the code you use to destroy things uses the X coordinate which is not equal to that. Meaning, the origin and collision boxes may be set up in such a way that would cause odd behavior like this.

The answer may be obvious, but I can't see it. So I'd recommend uploading a stripped down GMK so all of the game systems can be checked.

[sandcrab]

That's probably very likely!  Because there are other objects that do work correctly, but they're smaller, and of the objects that do deactivate, they don't all seem to be doing it at the same distance out from the viewport.  Is it possible for me to base the destroy code on the collision boxes so it matches? 

Anyway, here is a new version with a level that demonstrates the problems.
http://www.starquail.com/michael/tinyblog/tinybarbarian-stripped.gmk

I didn't strip it down much because a lot of the systems are tied in together pretty closely with parent-systems, and you should be able to find the relevant code pretty easily.  Here's an explanation of what you're seeing:

The howler wolf (oWolf) above the player summons wolves (oWolf.spawnWolf = true) that run across the screen.  They're supposed to be destroyed when they go off the screen (this code is right at the top of the step event in oWolf), but it only works on the left side of the screen.  The zombie archer above the wolf fires shots (oArrow, same location as oWolf) to the left and right, and these do seem to destroy themselves, but use the same code.  If you go to the higher platform to the far right, you'll find an enemy (oNymph) who is supposed to follow the player at all times once encountered, but deactivates when she goes off the screen, I have no idea how to tackle that (besides making her the object that controls deactivation).

The enemy-deactivating code is the only code in the object oGame.

[sandcrab]

Not a bump, but I didn't hear back on that last one, if anyone is still willing to help out. :>  I have another new bug!

This here is an enemy who jumps up off the screen (staying within the vertical limits for deactivation, though!) and then drops back down.  While off-screen, he sets his X to the player's X, so he'll try to land on you when he comes down.  After enough damage is done to him, he starts homing in on the player as he falls (after appearing on the screen).  Everything works well enough, but if I dodge to the left, his pixels get all blocky and distorted, but if I run to the right, everything's fine.  His pixels will remain blocky until he jumps off the screen or the player gets on the other side of him (every step he checks the player's position and adjusts to face the player).  Here's a picture:



The one on the right is the desired effect, however I notice his left thumb is distorted a bit for some reason too, but that's so slight it doesn't bother me.  I have no idea where to even start looking for this!

[GZ]

Hey, I haven't got around to checking out your original problem because I've been busy, but this second error seems like it might be a simple rounding issue. Basically, when you draw that character, make sure you use round() on the x and y values, otherwise you can get an effect like that. Using round() (floor() and ceil() also work) will make sure the position values are integers and ensure they are drawn on the canvas correctly. Typically you would do this in the draw event for that sprite, if you use it in something like the step event and alter the movement values themselves you will encounter problems with your movement code most likely.

[sandcrab]

Thanks!  I had a feeling it was going to be something really basic like that, and I use a custom drawing script in nearly all my draw events so I only had to change that one script to effect nearly every object, yay scripts!  Now I can also make the character move at a speed that isn't a whole pixel increment without making the screen jitter. :D

Glad you're still willing to look over that code from before, too.  I'm in no hurry!

[sandcrab]

Here's another one that is hopefully easy and basic.

The player moves using keyboard_check, so as long as the defined button is held down, he moves.  Now I have him moving from room to room as a persistent object, but when he transitions from one room to the next the keyboard state seems to be lost and he won't move again until I release the button and press it again.  I've tried io_clear and/or keyboard_clear in a few different parts of my code and it seems to work sometimes, but not consistently and never smoothly (ie, there's a pause before movement starts again).  I'm sure there's a real specific way to do it.

[GZ]

Here's another one that is hopefully easy and basic.

The player moves using keyboard_check, so as long as the defined button is held down, he moves.  Now I have him moving from room to room as a persistent object, but when he transitions from one room to the next the keyboard state seems to be lost and he won't move again until I release the button and press it again.  I've tried io_clear and/or keyboard_clear in a few different parts of my code and it seems to work sometimes, but not consistently and never smoothly (ie, there's a pause before movement starts again).  I'm sure there's a real specific way to do it.

Use keyboard_check_direct(). It's another method for checking keys, but you need to change the way you use keyboard checks when using this method. Normally when you press a key, you probably use keyboard_clear to unset the key, however, keyboard_check_direct returns if the key is pressed on a hardware level so cannot be unset using that function, instead you need to write your own code to only execute the key code once and set some variable the prevents another execution until the player releases the key.

[jwk5]

I generally use the following code (or similar) to handle the directional keys in my games. Rather than using keyboard_check(vk_whatever) for events I use two variables I named xKey and yKey to get which keys are being pressed (and to allow two opposing directionals to override each other rather than just making the player stick in the middle). I imagine that in your situation you could store the values as the rooms are transitioning and then reload the values as the next room starts so that the events using them would still trigger even if the actual key presses are not yet being detected (and then the key presses could then take over and properly set the variables once the keyboard has been cleared and reacquired).

rKey,lKey,uKey, and dKey are just variables storing the directional keys (for the sake of custom controls). xKey -1 is left, xKey 1 is right, and xKey 0 is when no keys are pressed. yKey is basically the same thing (1 up, -1 down, 0 is neither).

Code:

//RIGHT / LEFT OVERRIDE
if (keyboard_check_pressed(rKey)
    or keyboard_check(rKey))
{   
    if (keyboard_check_pressed(lKey))
    {
        keyboard_clear(rKey);
        xKey = -1;
    }
    else { xKey = 1; }   
}

//LEFT / RIGHT OVERRIDE
if (keyboard_check_pressed(lKey)
    or keyboard_check(lKey))
{   
    if (keyboard_check_pressed(rKey))
    {
        keyboard_clear(lKey);
        xKey = 1;
    }
    else { xKey = -1; }
}

//NO X DIRECTION PRESSED
if (not keyboard_check(rKey) and
    not keyboard_check(lKey))
        then xKey = 0;
   
//UP / DOWN OVERRIDE
if (keyboard_check_pressed(uKey)
    or keyboard_check(uKey))
{   
    if (keyboard_check_pressed(dKey))
    {
        keyboard_clear(uKey);
        yKey = 1;
    }
    else { yKey = -1; }   
}

//DOWN / UP OVERRIDE
if (keyboard_check_pressed(dKey)
    or keyboard_check(dKey))
{   
    if (keyboard_check_pressed(uKey))
    {
        keyboard_clear(dKey);
        yKey = -1;
    }
    else { yKey = 1; }
}

//NO Y DIRECTION PRESSED
if (not keyboard_check(uKey) and
    not keyboard_check(dKey))
        then yKey = 0;

[sandcrab]

Cool and thanks, keyboard_check_direct worked fine just replacing my existing checks for left and right movement.  But:

Normally when you press a key, you probably use keyboard_clear to unset the key, however, keyboard_check_direct returns if the key is pressed on a hardware level so cannot be unset using that function, instead you need to write your own code to only execute the key code once and set some variable the prevents another execution until the player releases the key.

I've never unset a key before, so I don't understand what this is for.  I mentioned using it here because I was thinking it would reset the current input and let it accept a new one, thus solving my problem of key presses not carrying over between rooms.  It seems like the direct method works perfectly well with no problems that I can see, so what would I need to unset for?

[GZ]

I've never unset a key before, so I don't understand what this is for.  I mentioned using it here because I was thinking it would reset the current input and let it accept a new one, thus solving my problem of key presses not carrying over between rooms.  It seems like the direct method works perfectly well with no problems that I can see, so what would I need to unset for?

If you don't use it in your game, then you can ignore it. Typically keyboard_clear is used for interfaces and sometimes gameplay as a shortcut to allow only one key press, then clearing the key input even though the player still has the key held down. So for instance, say I had an interface where you could use up and down to change the current selection. Using this code:

if (keyboard_check(vk_up)) {
    //move selection
}

Would not be ideal because it would move the selection up every frame (30 times a second at 30 fps). So by doing this:

if (keyboard_check(vk_up)) {
    keyboard_clear(vk_up);
    //move selection
}

It clears the input for the up arrow, even though the player still has it held down. It works much the same way multiple keystrokes on a keyboard works. To test for yourself, simply go to a text editor and hold any key down. Notice how it does one key press, then repeats the key press after 1 second. keyboard_clear() does this behavior.

[GZ]

Also, for the time being you may just want to simply disable the activating and deactivating functions until your bug is ironed out (I still haven't got a chance to check it out thoroughly), usually that function is only necessary for optimizing and given how few objects you have in the game right now you will not see much of a performance benefit from it right now. I'm pretty sure disabling it for the time being will solve some of the issues you are having.

[sandcrab]

I went ahead with your advice there.  The bugs as they were weren't too serious anyway, except for losing control over the one object that I wanted to never have deactivate (probably something with activate_object might have worked, but this is cleaner).  Setting up my own function for that was probably the way to go, as long as optimization isn't a concern, like you said.  Thanks!