profexorgeek / glade2d Goto Github PK

I need to document what Layers are and how to use them. Raw notes from chat w/ @KallDrexx:

Layer

• Composite sprite.
• Drawn once to a buffer.
• Can be "scrolled" which will wrap pixels in X and Y dimensions.
• Can track a camera offset for when camera is implemented
  • Don't really understand this yet
• Layers can support transparency but are faster if it doesn't.
• Layers have their own transparency color setting
  • TransparentColor: the color to consider transparent when drawing sprites TO this layer
  • BackgroundColor: the color to fill the layer background with. This should be the same as the transparent color if you want transparency
• Call "Shift" on layers to shift by a certain velocity to get parallax scrolling effect. This is usually done in the tick/update/activity method
• Sprite rendering happens over the top of layers just like simple rendering

LayerManager

• Add layers to the LayerManager to have them show up in the screen
• Cannot set layer index to 0 because this is the sprite layer
• Sprites can only be drawn at layer index 0 and be sandwiched betweeen layers
• Layer manager controls rendering.
• Currently must unload layers when unloading screen

TextureManager

• Split out loading/unloading and dealing with texture manager
• TextureManager was created to make this code more reusable
• May eventually become a broader ContentManager

Screens currently have no unloading process to dispose of textures, sprites, layers, etc.

• Glade should be updated so that screens have an unloading process.
• The base Screen class should have a virtual unload method
• Sprites should be recursively unloaded and destroyed on unload
• As part of unloading the LayerManager should clear any layers

Hi, I was wondering if any of the XNA code was useful as a reference. This was Microsoft's indie game platform, 10 + years ago. .net based. I see the archive is on GitHub https://github.com/SimonDarksideJ/XNAGameStudio

That also points to monogame https://github.com/MonoGame/MonoGame and a number of ports, such as fna.

P.s. Add the #meadow tag to the repository, and check out some of my meadow demos, like expressivepixels, fontdemo, meadowlife, digitalrain, and meadow invaders

Today in Glade, each sprite has to be manually managed by the developer. When sprites are related to each other, and should have the same physics, collision detection, and positioning rules applied to them

A concrete example of this is space invaders. In the game you have X rows and Y columns of enemies that all move in the same direction and at the same speed. They change animation frames at the exact same time. They change direction whenever the outer ones hit the screen boundary, only one enemy on the bottom row fires at a time, and generally it's impossible for a player's shot to collide with an inside enemy before hitting an outside enemy.

Many NES games had larger bosses that were made up of multiple sprites combined together as well (though I don't have good examples offhand).

It seems like this can be made easier on developers with the concept of sprite groups, akin to entities in FRB. This provides a central type that developers can inherit from to provide functionality to a group of sprites. The developer can then just add the whole sprite group to the screen to add it to the screen graph.

Sprite groups can be optionally rendered to a custom render target, which allows special cases where the whole group of sprites only has to be rendered once instead of every frame.

This is a container to hold a conversation that started on slack in a more public and discoverable place.

Problem: Rendering transparency is expensive and slow.

Concept: We should have a background layer that's flattened and fast, and a foreground layer that has transparency. This keeps calls that don't need transparency quick.

• Use 565 buffers throughout (device native)
• Scale textures on load because buffer copies will be faster than the final scale
• Figure out how to accommodate a lower bit buffer (1bpp?) without rewriting an interim buffer for every display depth