5SD033 Benefits of pre-loaded sprites
|
Most work this week has been in optimizing our game, with few new additions beyond another projectile. However, as the new projectile is mostly a re-thread of older projectile types and the EMP class mashed together, I instead chose to make this blog post about the benefits of loading sprites for projectiles before they are used instead of when they are created.
Crafting Bullets When we had first started making our projectile class, we created it to hold its own sprite in the constructor of the projectile, and to let other portions of our program like the enemy manager class contact that class for information on the sprite’s size and position. This made sense as we could directly influence each sprite this way when required, and and the prototype we created did not require swift loading to test our ideas.
 Making a Mold However, in the beta phase of development, when we had added more features and larger waves of enemies, slowdown was noticed on older and less efficient computers, requiring us to somehow lower the amount of memory being used at any one time. Enemies were altered, and I was assigned the job of altering how projectiles were loaded to ensure a lessened memory use. To resolve this issue, texture-loading was done inside our manager class instead of each projectile, with a referenced adress passed as an argument to the projectiles as they were created. Since the sprites of projectiles were never altered beyond animations, this meant we could now load only 3-4 (depending on final projectile count) different projectiles and use their loaded images and only assign positions to them seperately. Depending on what projectile was required, a switch was used to craft each one with the settings it required in a vector of projectiles. Working as intended, this should now lower memory requirements by almost 9/10ths, and would allow for us to modify the game to allow for many more “waves” of enemies and turrets to fire at them.
switch (type)
{
case PROJ_BULLET:
flash.setOrigin(38, 146);
muzzleFlash.push_back(flash);
projectiles.push_back(new Projectile(pos, angle, projectileTexture));
shotSFX.setPitch(rand() % 3 * 0.1f + 1);
shotSFX.play();
break;
case PROJ_MISSILE:
flash.setOrigin(38, 140);
muzzleFlash.push_back(flash);
missileSFX.setPitch(rand() % 3 * 0.1f + 1);
missileSFX.play();
projectiles.push_back(new Missile(pos, angle, enemyManager, projectileTexture));
break;
case PROJ_EMP:
EMPSFX.play();
projectiles.push_back(new EMP(pos, angle, enemyManager, projectileTexture));
break;
case PROJ_FREEZE:
projectiles.push_back(new FreezeShot(pos, angle, enemyManager,projectileTexture));
break;
case PROJ_FREEZPLOSION:
projectiles.push_back(new FreezeExplosion(pos, angle, enemyManager, projectileTexture));
default:
break;
}
Projectiles themselves now only save their collision information, type, time it has existed and their “strength”, or the variable that is subtracted by the Enemy Manager class when it notices a collision between a projectile and enemy. All other interaction is handled by their Manager class, destroying each projectile when it hits an enemy or has existed for too long (is out of bounds).
 |