Blitting

[iamaboringperson]

hi,
im trying to make an action game in C but i cant seem to get blitting to work properly

im able to load an image and stick it anywhere on a window using WriteChunkyPixels() - but its WAY to slow!
so i want to use BltBitMapRastPort(), BltMaskBitMapRastPort(), &ClipBlit()
i allocate a bitmap + a rastport, initialize them then link them, then i try to write an image to it, then blit from it to a window, but it only writes blank squares(all 0)!
does any one know what i might be doing wrong? and would anyone know of any good examples or source code for doing what i want to do?
the main thing im working on at the moment is placing tiles for a map, as a background...
im the sort of person who works best from example code, and the graphics.library/blitting pages of the ARKRM's dont contain much...

also im using cybergraphx on a SV64/3D not AGA
so to make it easier on my self im opening a window on the workbench screen

thanks for any help... :-)

[Karlos]

Technically what youre describing is no different to what I use to render into a window for Warp3D stuff.
When you allocate the bitmap, do you make a friend of the window's bitmap? In the Includes&Autodocs info for AllocBitMap you'll see that the last parameter is a pointer to an existing bitmap. It essentially clones the existing bitmap's pixel format, ensures it's in graphics RAM and has all the correct alignment for blitting and stuff. It probably helps to have a RastPort for your off screen buffer to make sure you can render to it ok.
You should then be able to render your tiles into your bitmap and blit them at will.

[iamaboringperson]

thanks, i didint see the bit about the friend bitmap
so ill try again!!
 :-)

[Karlos]

iamaboringperson wrote:
thanks, i didint see the bit about the friend bitmap
so ill try again!!
 :-)

Pleasure. Forgot to mention that there are some flags you should look at in the AllocBitMap() - specifically BMF_DISPLAYABLE - I think you need it too, though I guess using the friend bitmap may force this anyway.

What you might want to do is something like this.

1) Allocate a window.
2) Create a friend bitmap the same size as your windows visible area as an offscreen buffer.
3) Create a second friend bitmap thats some sensible multiple of your tile size.
4) Render your tiles into the second bitmap.

During gameplay, you can then draw your tiled stuff into the offscreen buffer using blits (very quick).

Then render your sprites etc. into the offscreen buffer. Maybe these are blittable bitmaps too.

Once all your rendering is done, you can blit the whole offscreen buffer into your window using a clipped blit. You can synchronise this to the display refresh cycle and eliminate any flicker.

Anyway, if your'e using cybergraphics, I definately reccomend you use the LockBitMap funcs rather than WriteChunkyPixels. You can write your own rendering code that can be much faster than WriteChunkyPixels but you have to care for the bitmap pixel format yourself.

[iamaboringperson]

thanks!! i worked out the BMF_DISPLAYABLE part out last night, after using AllocBitMap() and ataching the windows bitmap as a friend, the code worked but was very slow, BMF_DISPLAYABLE made it much faster! but still a bit too slow, so ill try the idea you just gave me of rendering on a bitmap that isnt displayed, i could imagine how that should give me the speed im after

i only found out about AllocBitMap()  after reading through my includes and autodocs i wish there were new printed ARKRMs!!! :-(



 :-)  :-)

[iamaboringperson]

ok, now rendering to the offscreen bitmaps or rastports produces the wrong image, it looks like just one or two of the planes of the image, theres somthing there but its definently the wrong color, rendering straight into the window using the exact same tecnique is fine

also how would i speed the thing up on 15/16/24 bit screen modes? its fast on 8-bit now, but is there any way at all to speed up writing the second bitmap to the window?

im using cybergraphx
 :-)

[Karlos]

Hi geezer,

Sorry about the delay, I don't have weekend internet access...

iamaboringperson wrote:
ok, now rendering to the offscreen bitmaps or rastports produces the wrong image, it looks like just one or two of the planes of the image, theres somthing there but its definently the wrong color, rendering straight into the window using the exact same tecnique is fine

also how would i speed the thing up on 15/16/24 bit screen modes? its fast on 8-bit now, but is there any way at all to speed up writing the second bitmap to the window?

im using cybergraphx
 :-)

When you create your offscreen bitmap, make sure it has a rastport of its own that has the same properties as that used by the window (things like palette etc).

I suspect the slow speed in 8-bit is because you maybe have some colour conversion between you applications' palette and the screen palette. This can be a big performance hit. Without the colour conversion you get all the wrong colours etc.

Personally I find windowed 8-bit such a pain in the arse that I always go fullscreen. In fullscreen you can use V40 double buffering and draw to the invisible bitmap. Simply swapping screenbuffers is even faster than blitting. You may want to test this out.

As for highcolour, the blitting technique should still work since both the offscreen and tile bitmaps have the same pixel format as the display. Furthermore you don't worry about palette conversion As long as your tiles are rendered correctly into the bitmap,
they'll appear correctly in the window.

If all else fails, email me the basic rendering code and I'll see if I can fix it up..

[iamaboringperson]

YYYYYYYYYYYEEEEEEEEEEEEESSSSSSSSSSS!!!!!!
i finaly have it working!!!! thanks all!!! it wasnt the actual blitting part of the code after all,

it was actually further up!

here is what i had when it wasnt working:

bitMap2 = AllocBitMap(640,480,8,BMF_DISPLAYABLE|BMF_MINPLANES|BMB_SPECIALFMT|PIXFMT_LUT8,bitMap);
InitBitMap(bitMap2,8,640,480);
InitRastPort(&rastPort2);
rastPort2.BitMap = bitMap2;


after using AllocBitMap() i used InitBitMap() which mustof messed up some of the BitMap structure!

but i was getting so frustrated that i was prepared to experiment & decided to remove the InitBitMap line!!
and now it works!
not only that but its fast on 15/16 bit screens now too
or at least, about as fast as 8 bit,
its still fairly slow, but thats ok for now
i probably will go fullscreen with V40 style double buffering from now, but i still want to give the user the option of having the window on a public screen, like alt-enter under windows when using a dos window
i think ill just have two slightly different routines used when changing frames, depending on weather its fullscreen or small window

but you couldnt image how happy i was when it finally worked, and it was much faster aswell
so, to all you programers out there remember what i said about the code above!
 :-D

[Karlos]

...i probably will go fullscreen with V40 style double buffering from now, but i still want to give the user the option of having the window on a public screen, like alt-enter under windows when using a dos window
i think ill just have two slightly different routines used when changing frames, depending on weather its fullscreen or small window

but you couldnt image how happy i was when it finally worked, and it was much faster aswell
so, to all you programers out there remember what i said about the code above!
 :-D

I bet I can imagine ;-) I dimly remember getting my first gfx card drawing routines up and running...Ahh, the speed.

Incidentally, I'm working on an high end 2D library that actually uses Warp3D to do rendering so you get hardware accelerated transparency, shading etc. in 2D. It buffers your drawing requests and strips out all those that would make no differences before passing the list to the rasterizer layer.

Certianly does the buisness on my machine ;-)

As for windowing, don't do something just because you can. Think about what people want and what's really required. In my experience most people prefer fullscreen gaming and only use windowed mode if they can't use fullscreen for some reason.

Of course, the above is just my humble opionion. Good luck with the development!

[Glaucus]

Incidentally, I'm working on an high end 2D library that actually uses Warp3D to do rendering so you get hardware accelerated transparency, shading etc. in 2D. It buffers your drawing requests and strips out all those that would make no differences before passing the list to the rasterizer layer.

Hey that's cool!  let me know when you're done with, I might like to use it!  :-)  Say, is it possible to use Warp3D if you have no hardware acceleration?  Does it work with WinUAE?  let me know, thanks.

  - Mike

[Karlos]

Glaucus wrote:

Hey that's cool!  let me know when you're done with, I might like to use it!  :-)  Say, is it possible to use Warp3D if you have no hardware acceleration?  Does it work with WinUAE?  let me know, thanks.

  - Mike

Regarding Warp3D, there is a software rasterizer but AFAIK its for PowerPC only. There's no 68K version. However, a software driver defeats the very purpose of the drawing library which is supposed to open the power of 3D hardware for 2D.

As for my 2D library, theres' a working version already. It's kinda in continuous development if you catch my drift ;-)

It does lines, triangles, rectangles, circles, ellipses, and antialiased text (you have to provide the font bitmap yourself), all with various effects, textures etc. applied and so on. It also handles the low level locking stuff.

I was thinking to make the rasterising process a sub thread and have a double buffered drawlist, though this is some time away.

I should point out that its a link library, not a shared library. Also, its C++, not C and is part of a much larger set of system abstraction classes that are designed to be multiplatform.

However, if you ask me nicely, I can create a cut down C-only version of just the drawlist engine and mail it to you. Just mention me in your application credits if you use it and I'll be a happy man.

Karl