The Rectangle you give when creating the sprite is already your DrawArea. DeltaEngine uses the so called QuadraticScreenSpace to ensure a resolution independant drawing of your sprites. If you want to change the DrawArea before drawing, you can always use the DrawArea-Property of your sprite. For having a 1:1 drawing, you can use the ScreenSpace class. Simply add a Property of the ScreenSpace class to your gameclass (similar to the Renderer) and you will have it. Then you can use the FromPixelSpace method and fill in the necessary params, Delta will then convert it to a QuadraticScreenSpace value and you're done but remember that this value is resolution dependant so if you change the resolution (i.e the size of the game window), you have to recalculate the value so the rendering is ok again.
Maybe the delta staff can do it so we only specify the pixel size, then it will be rendered in correct proportions and if the resolution changes, it will automatically recalculated?
Anyway, you can read more about the ScreenSpace in the old wiki, this is one of the useful infos which are still ok to read :)

About your second question: The sprite is only one class which simplyfies the process of drawing an image. Internal there are other mechanism which will do the other stuff for you. In general, you don't have to worry about performance, Delta will do as much as possible to optimize the rendering and all other stuff (but that doesn't mean that you don't have to look at performance, even Delta cannot avoid framedrops if you write bad code but it helps you a bit to achieve good performance :) )

Very good answer Internetfreak. My code snippet fits good below it :)

Benjamin, what does that mean? Does the Renderer not exist in that form anymore like it is now with the next release? Back in the earlier days, where 0.9.5 was still good, we could use Material2D.Draw to draw the image. Does this return or what it going on? I need to know because then I will suspend working on my project a little bit more (I'm currently at the very beginning of the project so I can change almost everything and I don't want to use code which is not useful anymore if I can have the new code in a few days :) )


@codesmith
Afaik Delta uses already sorting so use Renderer.Add for now to add your sprite to the list. The Sprite should have a property called "RenderLayer" or something like that where you can control the order of the sprites but without that, delta automatically sorts the sprites so it doesn't have to switch textures as often as unsorted (changing textures is very expensive regarding performance so delta will optimize it as much as possible. Just wait 1-2 weeks, you will see more and more how delta works because when the content server is ready, it will also optimize your textures and other stuff)

Well, there is just no more thing like the Renderer, Renderables or even Sprites. Everthing is just an Entity now and you can dynamically extend its features and handling at any point in the code or editor.

It is still possible to use a "Sprite" class (which is just an Entity that has all common features like the old Sprite class) and don't care about how the underlying system works, but the recommended way is to use entities yourself in your game and share entity handlers between libraries and games. Even in our few sample games we notices many overlaps and by sharing some code, tons of code could be removed and simplified. This is obviously an ongoing process and the Game Jam in a week will be the first time people are going to use the new system.



True, Renderer.Add will put them in a list and you can control the render order via the DrawLayer property of each Renderable (e.g. a Sprite). This is similar with the new entity system, but some steps are not longer needed.

The point Internetfreak is making is very important because we want to encourage writing code as simple, quick and clean as possible and don't having to worry about performance impact so much. Instead we will try to optimize away many things you as a game programmer might not be aware of (e.g. how on iOS draw calls need to be reduced to an absolute minimum, while on Android other things are more important).