I have a class Image and another one ImageStore. The Image it's just a value object containing the package name and the image name. The ImageStore does all the actual work: calculates the real path of the image (based on the package and image name) and loads it from the server.

Now I have a quite big (and deep) hierarchy of nodes (this is a render engine for a game) so for example now I am in a group and I want to insert a new Image. I do:

var image = new Image("packageName", "imageName");

At this moment the Image doesn't have any size yet, as I don't want to hard code the image size (in this case this can be a tile, which is not always 64*32 for example) in my game view.

  • when the Image is added to the Group (I suppose the group is already attached to the Renderer) then the Group will be invalidated
  • the Renderer will request a new frame render.
  • it will parse the hierarchy tree of node and when it finds the Image I've added before
  • it will ask the ImageStore (or TileImageStore, this one not only stores the width and height but also the bottom center point of the tile. This only when the bottom center of the tile doesn't match the bottom center point of the real image.) for the ImageData;
  • the ImageStore now loads the package, which also has the info about the width and height;
  • it will apply the new width and height to the image and will set a flag as loaded.

I would like to have somehow the ImageStore detached from the render. To be able to use only the Image and ImageStore without the need of the renderer.

Edit: I want to do this because I would like to know the size of a image even when the image is not rendered. In order to get the image it has to ask the ImageStore for the size, anchor and imageData. The packages are like this:

package = {image01: {base64: "very very long string", width: 10, height: 20, anchorX: 1, anchorY: 10}}

Only after the ImageStore loads this big file is able to know the image width/height;

  • This is probably better suited for Software Engineering – Hugo Dozois Mar 5 '13 at 22:20
  • Should I copy paste or can be somehow migrated? – Totty.js Mar 5 '13 at 22:21
  • Hum flag it saying it should be migrated! Read the progs faq before to be sure though – Hugo Dozois Mar 5 '13 at 22:23
  • So where is a singleton in that? Apparently I am missing something everybody else understands given how many upvotes the question has, but I don't see mentioned what you have as singleton, because I don't see anything that would have to be and I don't see it stated explicitly. – Jan Hudec Mar 7 '13 at 13:24
  • Is the ImageStore. Normally there is only one place to load and cache images and therefore is assumed it's a singleton. – Totty.js Mar 7 '13 at 14:19

You just make an ImageStore and pass it into a Renderer you make. There is no reason for singletons here.

  • 2
    Really? Downvote? Do I really need to elaborate on such an obvious answer? – Telastyn Mar 6 '13 at 14:06
  • At the moment I'm thinking of doing this way but I don't want to do this way: "I would like to have somehow the ImageStore detached from the render. To be able to use only the Image and ImageStore without the need of the renderer." (it was not me to downvote you*) – Totty.js Mar 6 '13 at 14:14
  • And having ImageStore as a composed part of the Renderer provides that. The Renderer is coupled to it then, but if that's a concern, make ImageStore an interface and supply some concrete implementation when you spin up the Renderer... – Telastyn Mar 6 '13 at 14:28
  • but then how the image alone can get it's size or pixel data? I need somehow to have the ImageStore to talk to the Image from the context I am (deep into the node hierarchy) – Totty.js Mar 6 '13 at 21:25
  • @totty - eh? Either the image is given that by the ImageStore factory on creation, or it is just a texture, which the Renderer can then map appropriately. – Telastyn Mar 7 '13 at 2:03

Without really knowing any further details:

Suggest you rename your existing Image struct, to ImageInfo And create a new object called SelfLoadingImage, which has an 'Image' interface that the Renderer can use to get actual pixel data or whatever.

Then under the hood, how this pixel data is retrieved is a different problem that the Renderer doesn't care about. You can now, for instance, have a HardcodedImage for testing purposes.

In the case of a SelfLoadingImage, it has a constructor that takes an ImageInfo, and an ImageStore and uses these when needed. But these instances of SelfLoadingImage get added as 'Image' objects to your rendering system.

  • 1) I would like to keep the Image class with this name as this is what the "end user" of the framework will use, doesn't need to know about the internal classes of the renderer. 2) I don't understand very well what you explained but: where the SelfLoadingImage is instanced and how it gets the ImageStore reference? – Totty.js Mar 6 '13 at 21:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.