I'm not sure what you mean so I think I might have got it wrong. That's a sample code not written by me. Mine is on the first post.
Here are some flaws with that design:
Rotation and scale are kept with yeah image in the so called scene. If I have 100.000 images in the scene (not necesarrly on screen) it adds some memory usage. Morehowever this mean that the transformation matrix is automatically calculated for each image in the scene.
From my point of view there is not "scene" it's a useless ambigous term that each game needs in a unique way. You load a image into the memory and if you want to draw it 5 times you just call DrawImage 5 times. What you are saying is some sort of persistent image which in many ways is not the right thing to do since it screws up flexibility a lot. The so called action system also kills flexibility.
What you are saying is more like a game framework that should stay on top of an engine. A great ideea but not actually for the engine itself. I will however consider something like this though.

Basically I just call SetRotation or SetScale or SetColor etc.. before drawing a image if it's needed. If 10 images are using the same transformations then why calculate it again. Just use SetRotation and SetScale once then use that transformation for each of the 10 images.

The main ideea is that it's not a sprite. It's an image. That format of mine is the container of the Sprite which is a different object. It does provide a easier control.

Hm.. Why not automate it. You might want to draw some objects in a weird way. Bundle more images on one object. If you keep creating a sprite for each one it just becomes overloaded.

Anyway I will keep in mind the thing with the framework. However first the engine then the framework.

Yes it supports even photoshop files. I use FreeImage so every format it offers my engine offers as well.

Anyway I really like this topic so please keep posting. I may deny some of your points but I still keep them in mind :)

Mostly criticism, but that's the way of evolution :)

Quote:Original post by LorinAtzberger
Basically I just call SetRotation or SetScale or SetColor etc.. before drawing a image if it's needed. ...

That reminds me of the immediate mode GUI stuff, and it'll suffer from the same disadvantages.

Quote:Original post by LorinAtzberger
... If 10 images are using the same transformations then why calculate it again. Just use SetRotation and SetScale once then use that transformation for each of the 10 images.

Why should I deal with 10 images all with the same transformation? They will overlap each other, and in the end only 1 is visible ;P

If you want to be able to change only parts of transformations while keeping others, then a kind of state memory is needed. Such a mechanism disturbs the locality of code: I cannot place an image without either having knowledge about the state or else driving the state memory useless because I set the entire transformation anyway.

Looking at the cycle of a typical game loop, I see distinct places where control and where rendering happens. That means for your example of writing transformation stuff close to the rendering stuff that those transformation invocations are to be fed by data calculated previously, compelling me to touch those things twice where otherwise one touch would have been enough (remember the mention of immediate mode GUI above).

BTW: I second jyk's comments on abbreviated function names. And how does your "immediate transformation mode" not contradict the "less typing by abbreviating function names idea"?

It's generally not the same thing as immediate mode GUI. Basically you have images here and only images. And by transformation I only mean scale and rotation leaving the position outside of this business.

Quote:And how does your "immediate transformation mode" not contradict the "less typing by abbreviating function names idea"?

I really don't see how these are related.
I forgot to mention that I used to teach game development here in my town and thus I got used to making user friendly code. At one point I was teaching BlitzMax which has a command set roughly just like mine. (actually I was inspired by it) and my "students" understood that code very easily.

Quick question: Do you guys like Radians or Degrees more? I tend to think degrees are easier to understand but I'd like some second opinions.

So basically you say that when I have a function like SetRotation(float r) it should take a radian?
Noted.
But I'd still like some more opinions on this :)

"I forgot to mention that I used to teach game development here in my town"

How many games have you personally worked on that were published ?

Just out of interest.

None that actually got published. But that's not my fault since projects were canceled about 75% of the development time. I was thinking of completing them myself and finding publishers but I'm not legaly allowed to do that.