game-editor.com

How can I make it so nothing is drawn outside of the view at all, but without using regions?

My method is:

Code: Select all


void
DrawInViewOnly()
{
    if(xscreen>640||xscreen<0||yscreen>480||yscreen<0)
    {
        VisibilityState("Event Actor", DONT_DRAW_ONLY);
    }
    else if(xscreen<640&&xscreen>0&&yscreen<480&&yscreen>0)
    {
        VisibilityState("Event Actor", ENABLE);
    }
}



I'm sure theres a different way though, but for now ima use this.

This is what I would do:

Code: Select all

void DrawInViewOnly()
{
    if(xscreen - width/2 < 0 || xscreen + width/2 > view.width || yscreen - height/2 < 0 || yscreen + height/2 > view.height)
    {
        VisibilityState("Event Actor", DONT_DRAW_ONLY);
    }
    else
    {
        VisibilityState("Event Actor", ENABLE);
    }
}

Notice how instead of using '640' and '480', I used view.width and view.height? Also, see how I used just else, instead of else if?

Hope that helps

SuperSonic wrote:This is what I would do:

Code: Select all

void DrawInViewOnly()
{
    if(xscreen - width/2 < 0 || xscreen + width/2 > view.width || yscreen - height/2 < 0 || yscreen + height/2 > view.height)
    {
        VisibilityState("Event Actor", DONT_DRAW_ONLY);
    }
    else
    {
        VisibilityState("Event Actor", ENABLE);
    }
}

Notice how instead of using '640' and '480', I used view.width and view.height? Also, see how I used just else, instead of else if?

Hope that helps

Thanks

Would it make more sense to just have the actor set to not receive events if out of vision? I assume you're doing this for lag and it would be a lot better to just use that. The last option in the actor control panel, set to off.

Combining them would disable both the drawing and functionality of the enemies. also, the enemies reset their positions too, making it more appealing and less cornering if you get surrounded.

Hblade wrote:Thanks

No problem

jimmynewguy wrote:Would it make more sense to just have the actor set to not receive events if out of vision?

I dunno xD

I did something similar when working with huge maps for apalia. The problem was that the maps were just too large graphically and just by the number of actors. So I set it up to print out all of the actor's positions into an array, that way if the actor was not in a specific range, I could remove it, and if one came into range I could make it reappear (of course making the range a little larger than the view). The benefit of this is not every actor had to have a draw event, which could very easily contribute to the game lagging. Also I could define the range to whatever I needed it to be, which in your case your's does as well (but that wouldn't be the case if you use out of vision).

Ahh, thats amazing sky. Since I'm guessing the maps were from a tile editor, all the tiles are actors, correct? It's genius. And yeah, out of view.. I don't know.. I'm debating a lot about what I should do. It needs to be remade anyway. I forgot to back it up so now I have an old one.

No, using a tile editor would have been far too inconvenient. Though if I had planned the maps like that I could have done it that way as well. The problem is that the levels were already created and I wasn't the one creating the levels. So, in the create actor events of the map (they were all pretty much clones) I added an event that would store their coordinates based off their cloneindex, and then wrote it all out into a file (using the proper array format) and then just loaded that into global script (and disabled the create actor event). That way I could manage everything through the one draw actor. It still wasn't as efficient as could be, but it as definitely a lot faster than just having the huge level.

Oh. Storing/Checking the location of a clone index is one of the main problems I have when it comes to that kind of need. Using your idea would make a game run twice as smooth as it would normally. How much, in the long run, did this effect the performance?

Well the game was running far too slow, around 15fps but really because of how large the graphics were. There were over 300 trees and similar if I'm not mistaken, sized from 200x200 to 900x900. It made the game run at the proper 30 fps. But it's not a system that I would say is good for every type of game. It just so happened that the levels were already created, so I needed a way of controlling it. It wasn't as efficient as it could be, since more or less I had to loop through the entire array every frame.

Yeah, I see what you mean. Looping through the arrays each frame would alone, cause more processing than it needs to. So if you made the maps, what would you have done to make it work more efficiently? This subject has taken my interest.

Forgot to respond to this. Since the game is a giant map system instead of individual rooms, and way to large for conventional tiling systems, I probably would have broken things up into zones. You could create actors that represent the zone areas, and the tree or level elements would store their information into the specific zones. And if the zones are aligned properly, you only need to have 2 zones activated at a single time. This means you only need to loop through at max two individual areas, instead of every single tree. And you can make the zones as small or large as you need them to be, and have them trigger at customizable distances.

Interesting! As you probably already know, I never thought of it that way. See, when you say stuff like that it makes me think your already working for like.. capcom, or square or something.