cori5555

I was just wondering which one of these 2 codes is more efficient for deactivating all objects outside of the view?

instance_activate_all()
instance_deactivate_region(view_xview[0],view_yview[0],view_wview[0],view_hview[0],false,true)

Or...

instance_deactivate_all(true)
instance_activate_region(view_xview[0],view_yview[0],view_wview[0],view_hview[0],true)

My friend thinks its #2 but I'm not sure because #1 is the example from the help file.

Pretty simple question, which of the following does view_hview and view_wview do?

1. Show the Y/X of the bottom/right side of the view

Or...

2. Tell the height/width of the view

Alright -- What the help file says is #2

view_wview[0..7] Width of the view in the room.
view_hview[0..7] Height of the view in the room.

However while coding I've found that while putting "view_xview[0] + view_wview[0]" does not seem to give me the X of the right side of the view, the "Deactivating Instances" section of the guide seems to agree that this doesn't work. And seems to point out #1 as the proper answer...

{
  instance_activate_all();
  instance_deactivate_region(view_xview[0],view_yview[0],view_wview[0],view_hview[0],false,true);
}

Notice how that example code uses "view_wview[0]" and "view_hview[0]" instead of "view_xview[0] + view_wview[0]" and "view_yview[0] + view_hview[0]"?

So this is pretty much me wondering which one it is so once and for all I will finally know which one to use.

And if it is #1 then -- How do I then find the X/Y of the right/bottom of the view...?

Well, I will start off by saying that I am currently working on a random terrain generator -- Everything is going well with the generation part and whatnot, but due to the scale that is generated of 16x16 tiles, I have to deactivate outside the view... This is where the problem begins.

I have begun to look into adding sand to the generator, however I have hit a bit of a snag. Currently the sand physics simply checks if there is an object below it that can support it (with the parent "par_solid") OR if there is another block of sand below it (with the parent "par_nosolid") if neither of these objects are present, the sand block will continue to fall by 16 pixels every 5 steps until it comes in contact with a "par_solid".

The problem is this -- Since it needs to deactivate objects, if a "par_solid" that is supporting a sand block gets deactivated the sand it was supporting just simply falls down and deactivates, only to be reactivated usually INSIDE or BELOW the "par_solid" that was previously supporting it... So what I need to figure out is a way to keep the sand from falling when it's supporting "par_solid" is deactivated/out of view.

I've had a few idea's so far as for how to prevent them from falling, but am not quite sure if they would work or really how to implement them... Before I get to that though I will post the deactivation code.

//BEGIN STEP EVENT
if activate = true
{
   instance_activate_all();
   instance_deactivate_region(view_xview[0] - (view_wview / 4),view_yview[0] - (view_hview[0] / 4),view_wview[0] + (view_wview[0] / 4),view_hview[0] + (view_hview[0] / 4),false,true);
}

Basically what that code does is "activate" get's set to true once the map has fully generated, so that only once the map is generated will it begin to deactivate outside of the view.

So my only idea that really has much plausibility was to simply check if "par_solid" was supporting a sand block after "instance_activate_all()" and before "instance_deactivate_region()" and then re-activate those blocks after the "instance_deactivate_region()" takes place, but the problem with that is that it would probably require the ID's of ALL the "par_solid" supporting a sand block to be checked and the ones supporting a block to be returned and saved somehow.

The problem with this is well, how to save them? There could be any number of "par_solid" blocks supporting a sand block, there is little way to anticipate how many there would be, yet alone get the ID values of all the ones that are.

What I had come up with was something along the lines of taking a blank string "" and then for every "par_solid" that came back as supporting a sand block, to add it's variable to the end of the string followed by a space -- So for example "" would become "283293 ", then "283293 878243 " and so on. Then once all of the "par_solid" blocks had returned the value it would have an alarm set to run a code that would check for the ID numbers and reactivate them 1 by 1, using the spaces as a symbol showing where one ID ends and another begins.

As it reactivated the objects via their ID numbers, it would remove them from the string. The biggest problem with this idea is it would be ran every single "begin step" event, causing lots and lots of lag...

You know -- I swear I am massively over thinking this...

Any idea's of how to either do this differently or how to make my idea work right would be greatly appreciated.

EDIT: I should probably add that at the moment I have added the ability to add/remove blocks for the sake of the engine at some point being used in a game, this is why the sand has physics, so it can react accordingly to destroyed blocks.

UPDATE: I am embarrassed by how much I was over thinking this... All of my initial thoughts were based off of "How to keep the block below sand from deactivating, when the real solution was "How do I deactivate sand physics when outside the view" -- And with no doubt the second question was easier to solve. For others that may also encounter this problem, I will tell everybody my solution...

The solution was simple, I simply made all instances half the view height below the view deactivate, and then made all physics not apply to blocks that were below the view. The half of view leeway is enough to prevent any glitches/bugs from occurring. It doesn't even have to be half the view, simply make physics not apply outside of the view and then a bit further down deactivate blocks, this ensures that any blocks below the sand don't deactivate before the sand's physics are turned off.

THIS QUESTION HAS BEEN SOLVED

I recently converted a game of mine from 640x480 to 1600x900, and now gravity is messing up. I have been trying to find the right number for gravity. But it seems that either its too high and you can bearly leave the water or its too low and your still as heavy as a rock but if you leave the water at a shallow enough angle you can fly... There seems to be no meeting point where the gravity is just right... So my question is... How do i fix the gravity to work right? I know its a fairly vague question so if you need more details feel free to ask.

Megalodon 2 is in the works! This game is fairly unknown as it was made over one year ago. But I have decided to come back to the idea and make it much -- Much better than the original.

Megalodon is a 2D side scroller inspired by Deathworm, but instead of a Worm it is an extinct species of shark known as "Megalodon" that lived between 25 to 1.5million years ago during the Cenozoic Era. These mighty beasts could grow to lengths of up to 67 feet and are the largest shark species to have ever lived.

The original game was more of a rushed project in my earlier game maker days when i was still in the "Yay! I can program games!" phase. You are a Megalodon shark that is roaming the waters and thought to be extinct, you have swam up from the ocean depths and found your way to an area off the coast of civilization, and you are hungry -- Very hungry... As you play you are tasked with eating whatever you can and growing as large as possible, the menu includes a variety of boats, divers, and even seagulls! But it is not all safe for you as a Megalodon, in the beginning you will have to avoid things such as fishing trawlers and their nets, or even officers in boats that will shoot at you on sight.

As you progress your presence will become more known, and bigger threats will arrive to attempt to destroy you before you cause any more danger to the public, these new threats include bombers, battleships, submarines and even more! -- Your task has now become much harder, not only do you have to eat and grow... You have to survive.

Megalodon includes achievements which you can use to unlock news modes such as night mode, wire frame mode, and even a time trial mode. Through time trial you can get special achievements which will allow you to unlock modifications to your shark, the sea, and even the sun and moon!

This is the link to the original game: Megalodon

After roughly one and a half years i have come back to this project, it has the potential i am looking for in a great game, and my plans include a new sea with a whole new batch of enemies, many new features including new playable modes such as multiplayer or vs. AI, new and improved achievements, a new engine with smoother and faster gameplay as well as many new functions, new high resolution graphics, multi resolution, multi framerate, and xbox 360 controller support, and even more!

So now i come to the request, currently i have a Lead Designer, Co-Designer, Lead Programmer, and Technical Developer/Programmer, and am in need of a Graphics Designer, Sound Effects Artist, and Composer, THIS IS NOT A PAID JOB. I have listed the requirements below for the positions.

Graphics Designer: Must have experience with creating high resolution sprites and animations, animations will include -- Swimming sharks and fish, explosions, exploding vessels, sinking vessels, flying seagulls, swimming divers, seaweed, etc.

Sound Effects Artist: Must be able to create multiple kinds of sound effects.

Composer: Must be experienced with creating meduium - fast paced background music that will make the player feel that they need to survive.

For details on any of these positions please either leave a post in this topic or PM me, i will likely ask for a few examples of your work and we will go from there.

Please note that this project is expected to take atleast a month if not longer, it is preffered that your timezone be anywhere from Pacific Standard Time (PST) to Eastern Standard Time (EST), please be willing to put work into this project when it is needed -- I will likely be asking for different things at different times.