New answers tagged sprites
0
I think you should stay at bitmaps, since they are much easier to handle, especially for a beginner. For example, storing pixels are easier: it takes only 24 bits, or maybe 32 bits sometimes - but it means that it can display millions of colours.
0
I found out how to do it by updating the enemy sprite in my games update method by adding a fraction of the distance between the enemy sprite and player sprite to the enemy sprites position.
for (CCSprite enemySprite : _enemySprites) {
CGPoint enemySpritePosition = enemySprite.getPosition();
CGRect enemySpriteRect = ...
0
I assume you're using C#. Even if you're using Java your problem lies here:
public static Sprite[] grass = new Sprite[7];
for(int i=0; i<grass.length;i++){
grass[i] = new Sprite(16,0,i,SpriteSheet.tiles);
}
This for() loop is outside any function, and as such not acceptable.
You can't initialize array members that way for static members (or any ...
2
In the overload of SpriteBatch.Draw that you are using, which you call like so:
SpriteRect = new Rectangle((int)Position.X, (int)Position.Y,
mSpriteTexture.Width, mSpriteTexture.Height);
theSpriteBatch.Draw(mSpriteTexture, Position,SpriteRect, Color.White, 0.0f,
Vector2.UnitX, 1f, SpriteEffects.None, 0);
You are passing SpriteRect into the method ...
1
You actually are getting a performance increase, which is most significant around the N = 3000 mark (in the alpha blending off case). The solid 60fps for lower counts is, of course, being caused by vsync which means that your figures actually aren't valid. You'd probably do better with something like:
glFinish ();
startTime = GetTime (); // substitute ...
4
Here's some guesses for you to experiment with:
Batch count is mainly a CPU load optimization, and not a GPU one. Try measuring CPU performance instead, for example by adjusting the positions so everything get clipped off screen.
I wouldn't be surprised if the driver realizes that each batch is actually pointing into a contiguous array and merges them all ...
4
The concept of a surface in this situation is simply describing a texture. To understand this better, you should also understand the rendering process. When rendering anything using modern graphics API's, the end result is always going to be the same, a buffer (texture) of color data that is presented to the screen. How you get to that buffer can vary quite ...
0
If you developed the demo in the video on your own you should be able to understand what is needed for the movement animations. You need to post examples of attempts at coding the movement.
In simple terms;
You need to capture the movement event(s), you then need to specify which animation(s) to use in those events.
2
I'm assuming your setup is similar to the following(however if it is not, you should be able to follow the following explanation)
If you want to display place-holder sprites (the faded-out sprites you were talking about) then you need either a list or an array to store the sprites positions, and draw them with the alpha value of your choice.
Add some ...
0
The projectile is added to projectileSheet, but being removed from current layer or scene, rather than removing from projectileSheet. The last line of spriteMoveFinished should be
projectileSheet.removeChild(sprite, true);
or better use
sprite.removeFromParentAndCleanup(true);
4
Pixel art is a complex field. Many people start with tiles and then expand to animated sprites.
A good tutorial I can recommend is "So you want to be a Pixel Artist" by Tsugumo.
You don't need any special software. Any raster-based image manipulation program will do - for a beginner even MSPaint.
0
You can test the distance between self and target to determine what sprite to use. If the distance is greater than a set MAX, then it looking to left/right otherwise it is just looking down. For example,
let self = (sx, sy) target = (tx, ty)
if (sy < ty)
distx = abs(sx - tx);
if (distx <= MAX_X OR sx == tx)
return "down"
else
...
4
You are essentially creating 3 coordinate systems when you only need 2.
The coordinate system for your grid is 0 to 800.
Your "real" space is a normalized position from 0 to 1.0.
And your "screen" space is measured from 0 to whatever your pixel width is.
You will always need to convert between some kind of world coordinate system and screen space in order ...
1
i think there is no way to make spriteparticle clickable as i am facing the same problem
have you got the answer
0
I'm not sure if this is your problem, but you don't seem to be checking for !loop if the direction is negative, and the currentFrame is less than 0.
Should it be:
if (currentFrame > totalFrames - 1) {
currentFrame = 0;
//if not looping for ever than stop
if(!loop)
{
stopped = true;
...
0
This is just speculation:
Maybe you forgot to call act() on your Stage that has all the Actors.
Actions are updated per frame through the act() method on each Actor which is called by Stage's act().
public void render () {
Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
stage.act(Gdx.graphics.getDeltaTime());
stage.draw();
}
From ...
1
To answer my own question, here's what I got working:
The scaling in the GLSL vertex shader is:
gl_PointSize = (heightOfNearPlane * pointSize) / gl_Position.w;
Where you compute your heightOfNearPlane using the viewport height and the field-of-view angle you constructed the perspective matrix with:
float fovy = 60; // degrees
int viewport[4];
...
8
There are many reasons why you may be getting those lines. I wrote a more detailed answer in here, but the bottom line is:
Do not do atlasing and mipmapping at the same time.
For 2D, in general, you don't want/need to do mipmapping. That's useful mostly in 3D where you don't know the size at which your textures will be rendered, but that's usually ...
1
Here's a different algorithm; instead of stepping the player forward and moving him back if he's colliding, check where the next collision will occur:
Get the position of a corner of the object.
Shoot a line down (or up, or to the right/left, depending on your movement direction) from that position.
Figure out the first place that line intersects a ...
-1
There isn't enough information to solve this - we have no idea what any of those functions do. Is this custom software? Is it technology from someone else?
I don't understand why one even needs a "scale center". It all seems like an overly complicated piece of tech for something so simple.
Try setting the rotation centre with the unscaled width/height. ...
1
You can have the attached sprite be an entirely separate entity, and just have this entity be moved beneath the original entity each time this entity updates. If you were using scene2d actors, you could have the bottom sprite just be an actor that continuously executes the MoveToAction with a duration of 0, instantly moving beneath the upper sprite (actor).
...
2
Demonstration:
Crude but functional collision detection and response
Video:
https://vimeo.com/64923588
The idea is that the player controlled sprite (actually a 32x32 pixels red box) can raise the speed of its next move, but it cannot go back to original speed except if it collide with something. Also if speed is enough the green wall can be "damaged" ...
Top 50 recent answers are included
