Can you share a cap file for us to look into that for you? Dropbox is a good method of hosting it.

Hi work3, I'll try to explain these:

1. The per pixel collision relies on the "collision mask" to determine where to collide, so any non-invisible pixel in the collision mask is treated as the "solid" part of the sprite. The other type I think is Point, which collides at the single point of the hotspot of the sprite.

2. Point still works as long as your bullets aren't "instant hit" or moving too fast, in which case you can use the step checks to see if an overlap would occur.

Hope that helps

IMO, the tendency of most C2 users is to adopt a WET approach by merely copy/pasting events to replicate logic in different contexts. It's a lot faster than modularizing into a function, and it's acceptable for a prototype, but breaks down for projects exceeding a few hundred events.

However, you can often fend off this kind of design with a good use of families and functions. My rule is this: never copy/paste logic if you are using it it more than one place; it will always come back and bite you later on. Turns out this has been codified into a rule of thumb as well:

http://en.wikipedia.org/wiki/Rule_of_th ... ramming%29

One of the places where I still run into trouble, though, is in cases where I want to pick objects of different types in one go. For example: we can't go "pick all objects where X > foo" if some of those objects are sprites, some are spritefonts, some are TiledBG, etc. Even if we just want to pick all sprites where X > foo, we still have to add every sprite in the game to a family, then refer to that.

It would be great to be able to have a pick function that could cross object type lines and pick thru every object that shared the same kind of parameter (X, Y, Opacity, etc).

BTW, that example you link to: what, exactly, is the advantage of such an approach to multiple objects added to a family? The problem I see, in a real world scenario, is that every animation frame for every troop would be loaded with that object, which would take up a lot of unnecessary memory on layouts where you would only be spawning certain types. And...what if you had multiple animations for a given troop?

Here's a version implemented with families; if anything, I think this approach is more elegant, as adding new enemy types only requires adding a couple new actions, and all stats can be set in one go thru the enemies family:

https://www.dropbox.com/s/jychw2ppib7en ... .capx?dl=0

Completely agree with this! However, there are many cases I've run into where copying and pasting events was the only bug-free way to make things happen (else statements, or statements, and for loops all seem to get buggy in sub-events and sub-groups, etc).

So, it's a lose-lose situation where relying on things that *should* work but *don't* is bad, and you also do still get bit by the copy paste method later on. It's hard to isolate individual examples of this though, as our game was already a huge number of events (many types of enemies, different playable characters with different movement types, etc). The general experience is that anything deeper than one layer of subevents breaks.

Anytime! Hope it helps

Anytime

I wanted to see first hand how that suggestion would work out and it seems to actually make it a bit more jerky than even default scrolling, but I added another mode of scrolling to this cap for you to try: https://dl.dropboxusercontent.com/u/471 ... olling.cap

Keyboard 1 = Default (system) scrolling to Sprite.X and Sprite.Y

Keyboard 2 = Rounded (scrolling to Round(Sprite.X) and Round(Sprite.Y))

Keyboard 3 = Lerp

Lerp is a command where you use Lerp(Start, End, Percent) to get a value that is a percentage between the start and end.

Eg: Moving an object to 10% between an X position of 0 and 100, which is 10px, would be done by Sprite.X = Lerp(0, 10, 0.1) as 0.1 is 10%

For the scrolling, we use Lerp(Scroll, Sprite, 0.1) in general to always scroll to 10% of the difference between the current Scroll (X or Y) and Sprite (X or Y). When the sprite slows down I sped up the % to make it less jerky. I would definitely recommend experimenting more with an accelerated camera though if you find directly following the object is laggy, maybe even one where the camera only follows the player after they are a certain number of pixels away from the center.

Hope that helps!

Hmm, try doing this check instead:

+Bullet IsOverlappingAtOffset (Bullet.X, Bullet.Y + scrollY) with EnemyFamily

->Subtract Bullet.Value('Damage') from EnemyFamily.Value('HP')

The Bullet.X might need to have "+ scrollX", but it sounds like only the Y axis is locked on your layer. Overall I haven't tested this, but it sounds like it's having a problem getting the "world Y" that the bullet is supposed to be in, so this might be one way to convert it.

Maybe make a launcher that forces the screen resolution instead and then launches the game (eg: if widescreen scale down to a set 16:9 size, otherwise 4:3 1024x768) then when the game is closed it resets the screen size to default. Would this be a possible "Option 5" ? I've seen a few games that work this way, but it is pretty rare.

Sorry for a late reply work3, been pretty busy this past week. I might be able to make an example over the weekend though!

I'm mostly just guessing but odds are center view on me will scroll to your object position (which can be less than a whole pixel) even when in point filtering, so your option instead is the System action "Scroll To Position" and use System rounding of the positions for X and Y to scroll to.

You can try to round your scrolling to integer values if you are using events to scroll (don't use the "Center view on me" attribute).

Maybe a good method of blocking future spam is to automatically prevent (or delete) a comment/topic/post which uses non-English characters, as we do not support other languages of discussion on this site anyway. The users probably shouldn't get banned for that though since sometimes it might be an accident, banning would be a step later after analyzing the post they had made for spam.