Image vs Graphics

[MaskedRetreiver]

Am I missing something in terms of the "smart" use paradigm for the Image and Graphics packages? A lot of the time I'll want to do things to an image that can only be done with it as a graphics object, and other things which can only be done with it as an image object, so I end up swapping it back and forth a lot. (For example in LuaTroid (link below) I have both a graphics and an image of the same .png file so I can sometimes paste parts of it up, and others show the whole thing.)

Any ideas on how to more wisely manage the different graphics contexts?


LinkBTW: http://github.com/MaskedRetriever/LuaTroid

[Robin]

I'm not sure what exactly your question is, could you please rephrase?

[MaskedRetreiver]

It's something of a "general use" question so I'll try to cite something more specific.

Okay, so suppose I want to throw a graphic up on the screen. Easy:

I = love.graphics.newImage("pic.png")
love.graphics.draw(I)

Easy. But if I want to use the :paste method, I can't, because love.graphics.Image objects don't have that method. So I make an imageData object:

ID = love.image.newImageData("pic.png")

Now I can use the paste method, but I can't type:

love.graphics.draw(ID)

because imagedata can't be put on the screen that way. So far what I've been doing is actually keeping two copies of certain images, one as graphics.image and one as image.imagedata. I'm thinking there must be a better way I'm missing...

[Robin]

You do know you can convert between the two?

See http://love2d.org/wiki/love.graphics.ne ... Function_3 and http://love2d.org/wiki/love.image.newIm ... Function_4

[MaskedRetreiver]

...huh. I somehow missed that completely. So for onscreen graphics that one wants to paste into, the procedure is convert, paste, convert? Still a little idiosyncratic but definitely nicer than the rigmarole to which I've been subjecting myself...

[Robin]

The thing is, Images are drawn and not manipulated, while ImageData is the raw data that can be manipulated, but can't be drawn.

[MaskedRetreiver]

Ah, which brings us to the whole "screen memory vs main memory" question, answered in different ways by different systems.

In Processing for example there's a whole Double Secret Screen Memory where you draw when you think you're drawing to the screen, and then Processing quietly flips the data in when you're not looking. Love (I'm guessing) has memory that is "prepped" for this kind of swappery in the graphics library and memory associated with pure datachunking in the image library.

So really the information in a file should stay as imageData, except when you need to draw it, at which point you convert and paste. I think I get it now.

[Robin]

I'm not sure what you mean by that, all I know is that in practice you normally won't use ImageData very much.

[MaskedRetreiver]

Huh. In my case I'm using imageData so I can use the :paste method to slice up tile files into their own graphical contexts... perhaps there's something in graphics I'm missing?

For example, all these have to be imageData:

Code: Select all

	
--a 640x480 graphic is 20x15 tiles
for j=0,14 do
	for i=0,19 do
		tileImagepile[i+j*15]= love.image.newImageData(32,32)
		tileImagepile[i+j*15]:paste(TilesImageData,0,0,32*i,32*j,32,32)
	end
end

[nevon]

Huh. In my case I'm using imageData so I can use the :paste method to slice up tile files into their own graphical contexts... perhaps there's something in graphics I'm missing?

For example, all these have to be imageData:

Code: Select all

	
--a 640x480 graphic is 20x15 tiles
for j=0,14 do
	for i=0,19 do
		tileImagepile[i+j*15]= love.image.newImageData(32,32)
		tileImagepile[i+j*15]:paste(TilesImageData,0,0,32*i,32*j,32,32)
	end
end

I think you should be using quads for that.