images to images

BlitzMax Forums/BlitzMax Programming/images to images

boomboommax

(Posted 2005) [#1]

er so i need to draw an image onto another image (first being a dead character image for example and the second being a large screensized image that i can draw stuff onto so i just gotta show that one large image)

no setbuffer so er, i tried with pixelmaps and its just slow, is there another way?

tonyg

(Posted 2005) [#2]

You're going to have to draw both images and then grab them.

Scott Shaver

(Posted 2005) [#3]

here is a method I used to create complete card images from images containing pieces of the cards:

		image = CreateImage(iDECKWIDTH,iDECKHEIGHT,1,FILTEREDIMAGE|DYNAMICIMAGE)
		Local dest:Int=image
		Local x:Int,y:Int
		InsertImage decks,x,y,deckNumber,dest,$FF010101

	Function InsertImage(src:Int,destx:Int,desty:Int,srcFrame:Int,dest:Int,transColor:Int=$FF000000)
		dmap = LockImage(dest)
		smap = LockImage(src,srcFrame)
		For y=0 To ImageHeight(src)-1
			For x=0 To ImageWidth(src)-1
				Local color:Int = ReadPixel(smap,x,y)
				color=(color & ($FFFFFF:Int)) | $FF000000:Int
				If color<>transColor Then
					WritePixel(dmap,x+destx,y+desty,color)
				EndIf
			Next
		Next
		UnlockImage(src,srcFrame)
		UnlockImage(dest)
	End Function

Dreamora

(Posted 2005) [#4]

if you use :TPixmap after dmap and smap it will become faster ... this holds for nearly all aspects of BM by the way (if you asked yourself why banks etc are slower than in B3D)

tonyg

(Posted 2005) [#5]

Isn't it this?

Graphics 640,480,1
image1:TImage=LoadImage("i1.png")  '256*256
image2:TImage=LoadImage("i2.png")  '64*64
DrawImage image1,0,0
DrawImage image2,10,10
GrabImage image1,0,0
Cls
DrawImage image1,0,0
Flip
waitkey()

boomboommax

(Posted 2005) [#6]

thing is, that above method is slow with a larger image, the the one above above i cant use for what i need.

must be a decent way to draw ONTO an image FAST

Dreamora

(Posted 2005) [#7]

There is none. Either you use this or no way, OpenGL has no surface buffers as long as you don't use pbuffers which need around a GF4 to work.

tonyg

(Posted 2005) [#8]

I asked before and didn't get a different answer.
one
two
three, with answer from BRL
four, my attempt
I also think focus is on 3D, GUI etc so I'm not sure we'll get them soon.

Rambo_Bill

(Posted 2005) [#9]

Yep, only two options:
1. Lock the image and use writepixel then unlock.
2. User current screen buffer.

I've been trying to use the first for most things, But I couldn't figure out how to drawtext onto a tPixmap, so for that I had to use the screen.

ImaginaryHuman

(Posted 2005) [#10]

Soo.... you have your backbuffer with a background on it , and you have these things moving around in the foreground and when they die you want to stamp them in place permanently on the background so you don't have to draw them. Right? And presumably you are drawing the whole background as an image each frame.

In the old days you could keep the background image and just save off the areas underneath the moving objects which is later restored, saving having to redraw the whole background. But that's not exactly how they do things these days.

If you could use a custom flip routine which copies the backbuffer to the front buffer rather than rotate which buffer is used, you could keep your backbuffer as an image and just stamp down the permanent objects onto it, but then of course you'd need to protect it from the moving objects.

You might be surprised just how many objects you can draw per frame these days. The GPU is usually especially fast at drawing image data. You could probably try just drawing everything, all the background, all the dead objects and all the live objects every frame and not have a problem. That will also let you animate the dead objects.

tonyg

(Posted 2005) [#11]

Imagebuffers really had so many uses.
Building up composite 'sprites' is what I used it for most. A base image with multiple images pasted onto it to make unique 'composite' images.
Also damage to spaceships, bloodsplats on clothes, dame to cars etc.
Settling snow is another good use. Get your snow particles moving and, when they land, paste them into your background image.
I STILL point back to the B3D/B2D manual...

There are 1000 reasons for this command.

and

This is a powerful command!

Also from 'Learn to Program 2D games in Blitzbasic...

There are a ton of reasons for manipulating buffers directly

In one of those posts I was told that they could only be added to Bmax via OGL extensions and, until Bmax was released, this wasn't a priority.
I'm guessing the 3D and GUI modules are a priority now rather than the 2D stuff. IMO a shame.

ImaginaryHuman

(Posted 2005) [#12]

I agree. I wonder if it would be possible for BRL to add their own `image buffers` system inbetween the Blitz program and the OpenGL library, as a transparent thing that OpenGL doesn't really know about.

I agree there are lots of things that can be done when you can render to a destination which can also be used as a source. It makes sense because source and dest are two sides of the same coin.

It's also sad how much effort is needed to read one single pixel from the backbuffer, having to set up glReadPixels with several calls, etc. Very slow.

But OpenGL is good at rendering.