Hi internetfreak

I'm not sure I follow exactly what you are looking to do but here's a couple of thoughts on what you've said:



Previously Entities were not added to the EntitySystem by default and now they are - this is because probably 95%+ of the time someone creates an Entity they actually want to make use of it straightaway. However, it's still possible to add and remove Entities from the EntitySystem on demand (including at creation) by simply changing the IsActive flag:

var sprite = new Sprite(...) { IsActive = false }; // Creating a sprite that does not render


var sprite = new Sprite(...); // This sprite is rendering
...
sprite.IsActive = false; // We stop this sprite rendering


You should not be seeing any framerate drop over time so long as you are inactivating sprites that are no longer wanted.

---

On a side-note, though it isn't really applicable here, if you wanted the Sprite to stay active in the EntitySystem but not render - let's say it had some internal values it was updating - eg. the Sprite is an enemy creep that has health that is regen'ing - instead of setting it to inactive you could just remove the Render EntityHandler:

sprite.Remove<Sprite.Render>(); // Stops this sprite rendering but all other handlers keep on processing
...
sprite.Add<Sprite.Render>(); // Restarts rendering of this sprite

(Looking at this, I think I might like to change the names of those methods; I think the following reads more natually:

sprite.Stop<Sprite.Render>(); // Stops this sprite rendering but all other handlers keep on processing
...
sprite.Start<Sprite.Render>(); // Restarts rendering of this sprite

Maybe expect to see that changed in the next couple of releases!)

---



I don't entirely follow but let me attempt to answer:

To start with, changing the image on an existing Sprite is possible and easy, it's just:

sprite.Image = content.Load<Image>("New Image");

Yes, you can't add the same entity more than once, but you wouldn't want to. A Sprite can only be in one place at a time; You can't render one Sprite in multiple places in a single frame.

What I think you're getting at is you're worried about having lots of Sprites all using the same Image, worrying that it'll be inefficient - but don't worry, Images are cached; If two Sprites have the same Image they share it; the Image hasn't been loaded twice or stored twice internally or anything. And if two Sprites start with the same Image you can make one have a different Image without affecting the other.

Using two Sprites with the same Image is very much like making two Material2D draw calls with the same Material2D. So just go ahead and create as many Sprites as you need.


Hope this helps clear a couple of things up :)

Edited by user Wednesday, May 29, 2013 3:31:54 AM(UTC)  | Reason: (Code tags were acting weird so had to change to italics!)

Sure, if you want to do it this way, it's a little bit messier than before but you still can.

If you look at what Sprite.Render does, it's not very complicated and you can imitate it. Basically, instead of calling Material2D.Draw you call Drawing.DrawQuad. You will also need to copy the method logic to convert the quadratic coordinates to screen coordinates (actually vertices). (And then you've basically cloned Sprite.Render because that's all it does...)



I get what you're saying. Sprites are persistent things: You tell it once to draw an image in a particular place, and it will do it forever more until you tell it to stop. Your way of working is to start from scratch every frame.

Well, the persistence can actually make things simpler. After all, how often does the contents of a Cell/Sprite change? Only if the state of the Cell changes (eg. a tree grows) or if the map scrolls. It could cut down your code from having to do processing every frame to becoming purely events-driven/reactive, which is obviously more efficient as a rule.

Also, by using Sprites, you can leverage the fact the engine will automatically batch draw calls by Image within a RenderLayer (it doesn't do this yet, but it soon will - perhaps even this week). By doing the draw calls yourself, if you had a naive loop that just looped across all cells swapping from one image to the next and back again, that would introduce a far bigger slowdown than anything we're discussing here. The code needs to loop by layer, then by image, then by cell (but you probably knew that :))



The memory usage is really trivial either way. I mean, even when you did Material2D draw calls, it stored data internally roughly equivalent in size to 20*15*3=900 sprites anyway. Really, you should just code it in whatever way makes your code simplest and cleanest; 900 objects, even done highly inefficiently - which they won't be whatever way you choose - is not going to be any kind of bottleneck :)



Well, you shouldn't have to compute visible cells every frame. There are basically two ways you could pair up Sprites with Cells:
- A Sprite could represent a fixed area of the screen: When the map scrolls, you update the Image of each Sprite (you don't change anything else about a Sprite like DrawArea/IsActive).
- A Sprite could represent a fixed area of the world: When the map scrolls, you don't update any Sprite Image, you just change which Sprites are Active and Inactive. (If you have no Camera class you also need to update their DrawAreas, but with a suitable Camera class this part isn't necessary.)

(Personally I'd choose the first of those: Having Sprites for each subsection of the screen, and just update the Sprites' Images when the map scrolls or something changes. That way even if the logical map is, like, 1000x1000 tiles you still only have 900 Sprites.)

Basically, by coding reactively/events-based instead of starting from scratch every time, you should find your code becoming simpler and doing less each frame - because, after all, most frames nothing will change.


---

Feel free to throw me a PM or just continue to post in this thread if you wish to discuss things further; I'll be around on and off for the next couple of hours at least :)

- Phil

Edited by user Wednesday, May 29, 2013 1:31:29 PM(UTC)  | Reason: Not specified