Animated Sprites for the Chili framework?

The Partridge Family were neither partridges nor a family. Discuss.
User avatar
Zedtho
Posts: 189
Joined: February 14th, 2017, 7:32 pm

Re: Animated Sprites for the Chili framework?

Post by Zedtho » August 4th, 2017, 5:30 pm

Oh, I completely forgot about that! I thought I was fine because I couldn't recall having copied anything, but calling functions with out & obviously copies stuff :P. Thanks for figuring that out!

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Animated Sprites for the Chili framework?

Post by albinopapa » August 9th, 2017, 12:46 am

You know, sometimes the simplest solutions are the best.

Just spent the last couple days on the particle stuff ( since the 4th ) and have gone through about 4-5 rewrites and the final solution was much cleaner, easier to understand and easier to work with.

Just because it's easier, doesn't mean there isn't some work to be had to get the results you expect.

I have uploaded what I have so far. The demo this time is Fireworks. It's all in the master branch. I have two out of four particle emitters made. The first is a single emitter, it fires a single particle or single stream of particles depending on the delay, if any, between launches. The second is a radial emitter. It emits particles in a radius and random speeds. I played with this one the most. I probably need to make that a ranged variable, but for now you just enter a speed and it randomly chooses a value between 0 and speed.

The other two I haven't done yet, are going to be single stream and conical. The first I'm planning will hopefully be something like fire and the second would be water from a faucet or afterburners from a jet or ship. Just have to throw something together and see what comes out.

At present, and hopefully there won't be many changes, the way you create an emitter is:

Code: Select all

// SingleEmitter
m_baseEmitter =
	SingleEmitter( StartPosition, NumParticlesToLaunch, MaxParticlesToStore, DirectionEmitterIsFacing );

// RadialEmitter
m_burstEmitter = 
	RadialEmitter( StartPosition, NumParticlesToLaunch, MaxParticlesToStore );

RadialEmitter fires in all directions, so no need to pass a direction. The direction should be normalized btw. If not, it will throw off the velocity of the particles.
and to create/spawn particles:

Code: Select all

	const float speed = 5.f;
	const float minRadius = 5.f;
	const float maxRadius = 5.f;
	const float minTTL = .016f * 40.f;
	const float maxTTL = .016f * 70.f;
	const Color color = Colors::Orange;

	m_emitter.SetPosition( position );

	m_emitter.SpawnParticles( ParticleSetupDesc{
		speed, minRadius, maxRadius, minTTL, maxTTL, color
	} );
For the Fireworks demo, I have the radial emitters spawn particles at the locations of the dead particles that were fired from the single emitter. Each group of particles that gets spawn from the radial emitter gets their own color. Those colors are stored in an array and randomly selected.

Right now, particles are dynamically allocated both using std::unique_ptr and std::vector, or more precisely, a std::vector<std::unique_ptr<Particle>>. My original idea was to pass around the dead particles in a messaging system, but that got complicated and messy. I think I will try having a vector for each emitter that is sized for what the user passes in, and just reuse those slots, moving the dead ones to the end or just finding a dead one and replacing it with a new one. This should cut down on dynamic allocations/reallocations and deallocations. Hopefully, this won't affect the interface too much.

Right now in Release I only use about 8% cpu and 6.3 MB of memory when spawning in 500 particles. I didn't setup a fps text on screen so I'm not sure if there was any frame rate issues, probably not with only 8% usage. In debug mode, you will notice a performance hit and is to be expected. I'll share results when I change from using vector of unique_ptrs to vector of Particles. Also, I'll put up a fps counter before and after.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Animated Sprites for the Chili framework?

Post by albinopapa » August 9th, 2017, 5:53 am

Using a vector of smart pointers
Image

Using a vector of objects
Image

Well, after changing some things, CPU usage went up to 30%, but I still got a pretty descent framerate with vsync disabled...still gets 60 enabled.

Even though the fps is higher in the vector of smart pointers, it's not that big a difference and honestly after awhile of sitting there, they both reach about the same fps. The allocations are only 32 bytes per particle. At max, there are about 500 * 32 = 16,000 bytes being allocated/reallocated/deallocated so memory isn't the bottleneck. If there was one, it'd be all the alpha blending calculations done on the particles.

I think I'll keep the vector of objects though. Later if I decide to use SSE/AVX and or GPU, I'll want a vector of object. The GPU can't handle pointers and SIMD likes solid data as well.

Just did some more runs, increasing the particle counts. I can get between 3500 and 4000 particles on screen before I drop below 60 fps with vsync on. That should be plenty for most 2D games. That doesn't mean you'll get that if you start adding physics calculations and collision, not to mention all the other stuff that make up a game.

Now all I need to do is finish the other particle classes and I still want to have the particles use sprites to draw as well, instead of my colored balls.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

User avatar
Zedtho
Posts: 189
Joined: February 14th, 2017, 7:32 pm

Re: Animated Sprites for the Chili framework?

Post by Zedtho » August 9th, 2017, 7:52 am

Well, after changing some things, CPU usage went up to 30%, but I still got a pretty descent framerate with vsync disabled...still gets 60 enabled.
VSync locks the monitor to 60 fps, so that's expected :D.

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Animated Sprites for the Chili framework?

Post by albinopapa » August 9th, 2017, 2:09 pm

Yeah, just pointing out that even with the added CPU usage, I'm getting a full 60 instead of lower.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

User avatar
Zedtho
Posts: 189
Joined: February 14th, 2017, 7:32 pm

Re: Animated Sprites for the Chili framework?

Post by Zedtho » August 10th, 2017, 1:01 pm

Oh, I must've not gotten that that was supposed to be positive :P, I guess it was the ... that made me think it was negative, sorry 'bout that!

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Animated Sprites for the Chili framework?

Post by albinopapa » August 10th, 2017, 5:10 pm

Ok, understandable, my bad.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Animated Sprites for the Chili framework?

Post by albinopapa » August 11th, 2017, 4:51 am

Fun with particles:


Image

Used an image to create a mask of just the top of her head, white pixels were spawn points for the particles.

I pretty much have the StreamEmitter finished. On to the Conical emitter. Changes not uploaded to GitHub as of yet. When I do, I'll go over the changes then, cause there are quite a few I think. The biggest reason for not uploading yet is the extra code for using std::async and the irrisponsible addition of some SIMD alpha blending code. I say irresponsible because I don't handle cases where the particles are less than 4 pixels wide...check out SSE if you want to know what that's about.

I've copied over a SIMD library that I've created on another project. I want to clean it up before really implementing it.

Cheers.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Animated Sprites for the Chili framework?

Post by albinopapa » August 11th, 2017, 4:33 pm

Memory leaks using nothing but smart pointers and vectors? What?

Code: Select all

Detected memory leaks!
Dumping objects ->
{354} normal block at 0x0000014FE3C4F610, 360 bytes long.
 Data: <         n  O   > 00 00 00 00 00 00 00 00 00 6E C6 DC 4F 01 00 00 
{304} normal block at 0x0000014FE3C93E30, 16 bytes long.
 Data: <    O           > 20 F7 C7 E3 4F 01 00 00 00 00 00 00 00 00 00 00 
{299} normal block at 0x0000014FE3C7F610, 304 bytes long.
 Data: <        PI      > 08 EC FC 82 F7 7F 00 00 50 49 FD 82 F7 7F 00 00 
{266} normal block at 0x0000014FDCC9C890, 8 bytes long.
 Data: <`   O   > 60 DC B3 DE 4F 01 00 00 
{173} normal block at 0x0000014FE3C4F860, 160 bytes long.
 Data: <            O   > 00 00 00 00 00 00 00 00 00 F0 D0 DC 4F 01 00 00 
{165} normal block at 0x0000014FDCC9C660, 16 bytes long.
 Data: <         U  O   > 00 00 00 00 CD CD CD CD 00 55 B3 DE 4F 01 00 00 
{137} normal block at 0x0000014FDCC9CAC0, 16 bytes long.
 Data: <0   O           > 30 F0 C4 E3 4F 01 00 00 00 00 00 00 00 00 00 00 
{97} normal block at 0x0000014FE3C4EF20, 304 bytes long.
 Data: <        PI      > B0 BC FC 82 F7 7F 00 00 50 49 FD 82 F7 7F 00 00 
Object dump complete.
How should I debug this?
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Animated Sprites for the Chili framework?

Post by albinopapa » August 11th, 2017, 5:44 pm

Step 1: Made all Base class destructors virtual and = default; Still have the same leaks

Code: Select all

Detected memory leaks!
Dumping objects ->
{354} normal block at 0x000001C8B8D76E60, 360 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 06 FD B1 C8 01 00 00 
{304} normal block at 0x000001C8B208C710, 16 bytes long.
 Data: < n              > 00 6E D7 B8 C8 01 00 00 00 00 00 00 00 00 00 00 
{299} normal block at 0x000001C8B8D76CF0, 304 bytes long.
 Data: <        PI      > 08 EC B3 C8 F7 7F 00 00 50 49 B4 C8 F7 7F 00 00 
{266} normal block at 0x000001C8B2007C20, 8 bytes long.
 Data: <`       > 60 DC D4 B3 C8 01 00 00 
{173} normal block at 0x000001C8B8CFF6C0, 160 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 AE 07 B2 C8 01 00 00 
{165} normal block at 0x000001C8B2008670, 16 bytes long.
 Data: <         V      > 00 00 00 00 CD CD CD CD 20 56 D4 B3 C8 01 00 00 
{137} normal block at 0x000001C8B2008120, 16 bytes long.
 Data: <0               > 30 F0 CF B8 C8 01 00 00 00 00 00 00 00 00 00 00 
{97} normal block at 0x000001C8B8CFEF20, 304 bytes long.
 Data: <        PI      > B0 BC B3 C8 F7 7F 00 00 50 49 B4 C8 F7 7F 00 00 
Object dump complete.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

Post Reply