cori5555

not sure how much this will help but:
x < view_xview[0] + view_wview[0]
states that 'if the x-origin of the sprite is less then the right edge of the view'

If you say have a square sprite, and the origins are 0,0 (top right of the square. The code will
test if the left edge of the sprite is less that the right edge of the window.
In this case x+sprite_width would be the right edge of the sprite assuming the above conditions are true.

However, its late and I'm having trouble visualizing the problem, so I'll try yo get back to it when I'm
more refreshed if someone hasn't solved it by then.

edit: also, i need a wider wide-screen monitor, that line of code is looong xD

And I thank you, sir/madam!

Who knew something as small as 24 pixels could make that much of a difference -- You were right about it needing to measure from the right edge instead of the left edge of the block -- I have been working on trying to fix this problem for about 5 hours -- Thankyou so much!

I just changed "x < view_xview[0] + view_wview[0]" to "x < view_xview[0] + view_wview[0] - sprite_width" and sure enough! It fixed it!

*cheers*

Honestly they both look about the same, you could try bench marking it but it might be a little difficult.

To benchmark you could do the following:

ct=current_time;
repeat(100000){

//code A

}
show_debug_message("code A:"+string(current_time-ct)+"ms");

ct=current_time;
repeat(100000){

//code B

}
show_debug_message("code B:"+string(current_time-ct)+"ms");

Actually, rather than posting another question today I'm going to see if I can sneak another question into this thread -- The main reason I'm looking for which is more efficient is because I am trying to solve a problem with my "project" -- So since so far I can't find the problem I'm going to ask away.

Currently I am working on a Random Terrain Generator -- And I have recently gotten to water physics. When I was working on sand falling physics previously I learned that deactivating outside the view would sometimes make the sand fall if the block under it was deactivated. So to fix it I would simply make the sand's physics not work outside the view and extended the activated region to 1.5x the view size in all 4 directions. Now -- Working with water physics -- I am doing the same thing, it works perfectly if I move the view to the right side of the water (Making the water go off the left side of the screen) -- But when I move the view to the left side of the water (Making the water go off the right side of the screen) the water will act as if the blocks to the right of it are missing and when I move the view back to the spot I'll have water blocks and dirt blocks overlapping and whatnot. So I'm currently trying to figure out how to solve this.

Here is the code I am using for deactivating outside of the view.

if activate = true // If the variable that deactivates all instances outside the view is ON
{
    instance_deactivate_all(true); // Deactivates all instances
    instance_activate_region(view_xview[0] - (view_wview / 2),view_yview[0] - (view_hview[0] / 4),view_wview[0] + (view_wview[0] / 2),view_hview[0] + (view_hview[0] / 2),true); // Activates all instances inside the view
}

First thing's first -- Yes "activate" is "true" -- I would know if it wasn't because there would be horrible fps drop.

Here's the next bit.

if place_meeting(self.x,self.y + sprite_height,par_solid) or place_meeting(self.x,self.y + sprite_height,par_nosolid) or place_meeting(self.x,self.y + sprite_height,par_liquid) && !place_meeting(self.x + sprite_width,self.y,par_solid) && !place_meeting(self.x + sprite_width,self.y,par_nosolid) && x < view_xview[0] + view_wview[0] && x < room_width - sprite_width
        {
            if place_meeting(self.x + sprite_width,self.y,par_liquid)
            {
                with(instance_position(self.x + sprite_width,self.y,par_liquid))
                {
                    if level < other.level
                    {
                        other.level -= 1
                        level += 1
                    }
                }
            }   
            else
            {
                level -= 1
                if level > 0
                {
                    with(instance_create(self.x + sprite_width,self.y,obj_water))
                    {
                        level = 2
                    }
                }
                else
                {
                    instance_destroy()
                }
            }
        }

Now -- This is what makes makes the water equalize/shift to the right -- Which is what it seems to do when I move the view away from it to the left. The code "&& x < view_xview[0] + view_wview[0]" is supposed to prevent the physics from functioning off the right side of the view, however it doesn't seem to be working all that well -- Any idea's?

EDIT: If you need more info on the problem -- Just ask.

#2 doesn't seem to have enough arguments:

instance_deactivate_region(left,top,width,height,inside,notme) Deactivates all instances in the indicated region (that is, those whose bounding box lies partially inside the region). If inside is false the instances completely outside the region are deactivated. If notme is true the calling instance is not deactivated (which is normally what you want).

If however you include all the arguments, you'll probably wind up with the same amount of efficiency. I could be wrong, but they don't seem all that different.

#2 is using this.

instance_activate_region(left,top,width,height,inside) Activates all instances in the indicated region. If inside is false the instances completely outside the region are activated.

The project I'm currently working on has lots of blocks on the screen at once, some running physics checks, others not -- But if I run the whole room at once it will drop to 6 - 10 / 60 fps -- Limiting it to the view using method #2 Brings it to 55 - 60 / 60 fps -- Depending on how many blocks are running physics checks. I was just wondering which one would be more efficient for this.

I probably should of initially mentioned that part.

Thankyou everybody for such a quick response, the reason I was questioning it was because I thought it was #2 but it didn't seem to be working with what I was doing and #1 I didn't actually test... But either way it turned out the reason it wasn't working was because I had accidentally used method #1 while being confused about what those 2 codes actually did...

if keyboard_check(vk_left)
{
direction+=3
}

if keyboard_check(vk_right)
{
direction-=3
}

That is a strange way of doing gravity o.0 I am interested on what you are doing. It would make you "fly" as that if you have any speed, you going to move in the direction of the variable direction. So if direction is greater than 0 but less than 180 you will always move vertically in some way.

That is not how i am doing gravity. I use that code to make my guy turn while he's in the water... Like rotation -- Its from a side view. But Anyways, it works very well combined with gravity because it allows slight control while even in the air and gravity is taking effect. Since my guy rotates with gravity so that the more gravity takes hold the more downwards he faces using a low enough number in this code usually does not allow flight to take place.

Gravity is not taking place at all when my guy is in the water -- It only takes place when jumping out of the water.