Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AxleMC131]

Can we please make it a standard that projectiles have their size as set in their .proj file match the dimensions of the base sprite? It's a pretty weird inconsistency, and detracts from the "retro" pixel-artness of the game in my opinion.

(Apologies for the meme-ness, this wasn't originally intended for the forum, but I think it gets the point across quite well...)

Spoiler

[close]

The Annihilator is a really weird outlier right now, and it seems it's causing a couple of modders to generate some pretty strange bad habits (and using "but Vanilla does it!" as an excuse).

[AxleMC131]

... and it seems it's causing a couple of modders to generate some pretty strange bad habits (and using "but Vanilla does it!" as an excuse).

And while we're at it:

DAVID!
Fix your damned backwards large turrets on your damned Remnant ships!!!  It's having the same effect!

[Megas]

Does the game use hitboxes for collision detection?  If so, the hitbox should be a bit smaller than the attacking (non-transparent part of the) sprite to avoid transparent parts of the boxes registering as a hit, at least if the goal is not a ridiculously hard game on purpose.  I know I felt cheated (in older games) when my character got hit by shots or enemies that appear to clearly miss my character, but got hit anyway (for the kill) because the hitboxes clipped.

[David]

And while we're at it:

DAVID!
Fix your damned backwards large turrets on your damned Remnant ships!!!  It's having the same effect!

.... huh, I didn't realize I did that. (Oh those wily AIs! Who knows what else they'll cook up next just to drive us batty?)

[xenoargh]

This isn't desirable for a variety of reasons.

1.  What if you want to change the pixel size of the sprite during the development process?  What if you release and want to re-size later?  If it's pixel-perfect, you're hosed.  It's best to use sizes that aren't actually pixel-perfect to stay flexible.

2.  All sprites, whether you want them to be or not, get resized to power-of-two textures in OpenGL.  It's not sensible to use anything that isn't a power-of-two size.

So that means that sizes should be 2X2, 4X4, 8X8, 16X16, 32X32, 64X64 and so forth, not some arbitrary dimensions, and not odd numbers.

3.  The sprites use the center of the image, not the "forward edge", to determine where their hitbox center is.  This is unfortunate; they really ought to use the "forward edge" minus radius of the collision circle, so that hit-detection cooresponds with the visuals, but 99.9% of players won't ever notice.

Using this as the "standard" means that a lot of projectiles with small hitboxes actually appear to hit after they hit and do some weird fading stuff.  It's best to have the hitbox be a little smaller than the outer X dimensions of the sprite (not the image file, but the sprite you'll see), but have the sprite offset so the the "front" of the sprite is hitting the front of the collision circle.

So, for example, this is a sprite where it's basically just a square representation and the hitbox is slightly smaller than the sprite's visuals.



This works OK, but only for small blobs that are basically squares. 

For projectiles that have a long tail built into the art, however, that looks really bad, so I'm using a technique like this:



The center of the projectile is roughly near the center of the art, but a little forward; this means that, visually, it appears to hit about when the code says it actually hit.

4.  99.9% of the time, players aren't at 1:1 zoom, unless they're utter noobs and haven't figured out the middle-mouse-wheel zoom function.  So the sprite's getting aliased no matter what.

5.  There really aren't significant performance penalties for using fairly large images on modern GPUs.  They eat a bit more memory and will require a little more processing, but frankly, it's of zero concern on a game where the CPU's the chokepoint for 99% of end-users.


So, basically, there just aren't very many good reasons to use this "standard", frankly.  It doesn't make technical sense and its irrelevant to the aesthetic that people actually see.  If you want the "pixel-art" of SS to be more prominent, then I'd suggest that you work with Dark.Revenant to develop a screen shader that does a "pixelizing" pass on the main render pass, rebuilding sharpness, etc.- this is something that can probably done with a post-processing technique to some degree.

[xenoargh]

How things oughtta work, imo:

1.  Collision detection should use the sprite's forward edge, not the centroid, by either offsetting the sprite or the collision circle, whichever is cheaper computationally (it's cheaper to offset the sprite, probably, because it already has to do all the math for offset).

So, let's consider a square sprite with a centered hitbox vs. an offset.

First, we've got a sprite like this:



Right now, the collision circle's the centroid, so to get something like reasonable forward coverage, it needs to be wider than is ideal:



Ideally, what we want is to do something like this:




There are other things I'd like:

1.  I would strongly prefer to be able to turn off the OpenGL stuff that draws the funky faded diamonds on projectiles.  I'd honestly rather just see the sprite.  

The only way to turn that off, however, is less than ideal; we can just make it invisible, via:

Code

"fringeColor":[0,0,0,0],

2.  Sprites should immediately fade upon impact, without changing in scales- again, this is funky OpenGL stuff that's happening that I'd honestly rather just see become legacy or have the option to shut off entirely.

3.  Whether we want it to or not, a dead projectile creates a HitGlow.  I'd love to be able to set the hitGlowRadius to zero and have it not bother at all.

4.  It'd be nice to make projectiles that weren't additive.

5.  IDK why a projectile needs textureScrollSpeed or pixelsPerTexel.  In fact, I'm not sure why pixelsPerTexel is a thing.

6.  glowRadius uses the centroid and can't be offset.  It'd be nice to be able to specify an offset on the Y axis.

[xenoargh]

Also...

1.  A manual setting for fade-in would be nice.  The current system essentially tries to fade-in projectiles based on the distance from center to +Y.  This is awkward when I correct the projectiles to have their collision be at the position of the front of the projectile (where we're expecting it, visually).

2.  Fadeout should probably have a second value, fadeOutOnHit; 0.25 seconds is visually great for standard fadeout at the edge of range, but it's too long for projectile deaths.

3.  Projectiles shouldn't keep moving forward after a hit gets registered.  When #2's affecting things, we can see projectiles continuing to be moved forward through the ship, which looks super-awkward.  Maybe they need to move a little to feel right, but not at speeds where they're obviously getting drawn past their explosion?

For example, here's my current prototype for the Autopulse:



You can see two shots have already hit the shield, but overlap it by a huge amount, even though they're offset with the centroid, etc., simply because of the huge fadeout time and they keep moving.  This isn't as visible with little pew-pew but it's glaringly obvious with the big stuff.