Antialiasing - what is the best way to achieve?
BlitzPlus Forums/BlitzPlus Programming/Antialiasing - what is the best way to achieve?
| ||
| I know that alpha channels do not work in blitzplus, well at least they are not used when blitting images to the screen. However, correct me if I'm wrong, it seems that readpixelfast does not read the alpha channel from a loaded RGBA image (32 bit) so that even if we store alpha information in an image, by reading it by first loading the image and then readpixelfasting every pixel in the image we still don't have access to the alpha information. If that is correct then I will have to write my own image loading routines - which is fine as in my current engine I simply poke images direct to the backbuffer pixel by pixel - which is fast in blitzplus, fast enough for me anyway. I've done a little reading on anti aliasing and am interested to find out what a simple algorithm would be that performs the operation. |
| ||
| With my Xmas and Easter bonus games I had the graphic image and a separate greyscale alpha image that I loaded in. This contained values from 0 to 255 (transparent to solid) and when I drew my main images pixel by pixel I simply multiplied the color values by the greyscale value. In fact all the code to do this is in that Blitz Plus code I gave away for free that you looked at a while back. Things is, it's best done on menus and stuff that you can precalc as you really won't have enough CPU to anti-alias large areas I'm afriad, trust me on this, I tested it and it's why my next game is in BMax. |
| ||
| Thanks Grey, I'll take another look at your code, although I thought it may have been as simple as that - loading a separate grey scale image). I don't need to anti alias huge areas - just the borders of some sprites so hopefully it won't incur too much of a performance hit. Thanks again. |
| ||
| I antialiased all my menu items and page headers but it's fairly slow even though the code is well optimised. Try it on the sprites. It might be OK for a few, but too many and it won't be very good... I think some paint packages can export the alpha layer as a greyscale bitmap which should save some hassle, cos then you can use that with your "manual" antialias code. |
| ||
| Matty - it is sloooooooooooow i don't know what the problem was - reading or writing of pixels... but one of this was to slow... |
| ||
| For what I need it to do I don't think it is going to be all that slow. Currently all my sprites are drawn pixel by pixel and I did a small test where I drew them all 'alphaed' with the scene which is basically the same procedure ie get background pixel, get image pixel, use a particular transparency value and draw the pixel at the appropriate color. The only difference between what I tested and what will happen when I get the greyscale alpha image is that the actual level of transparency will vary from pixel to pixel. In the test I managed to have around 50 'creatures' running around with alpha (each about 80x50 pixels in size (actual 'creature' dimensions not the 'frame' size) at a decent frame rate - and this is in a game environment with all the other game features running. Anyway, I'll find out soon enough if it is fast enough, although I am pretty confident it will be. |
| ||
| My sprite system supports alpha. I found during testing that if you're gonna have a lot of alpha, then you can improve your framerate by drawing to a scratch image I think it was... One which is not in the video buffer, and then blitting that to the screen when you're done. You should only use this if you have lots of alpha though and your framerate is already less than say, 60fps, cause this will drop the framrate to around 60fps immeidately, but not drop nearly as much from there when you add all the alpha stuff. That's because it is costly to blit a big fullscreen image to the video card from ram, but it's even more costly to read pixels from the video card to do the blending. Reading them from the image in memory is much faster. You will also get a speed boost if you make sure only the edges of your objects have alpha less than 1, and you do not read pixels from the background when the alpha is 1, or write pixels when it is 0. But honestly, if you want to make a game with antialiasing, I would seriously consider BlitzMax. Btw, check out my BOB system demo (I meant BOB system not sprite system... BOS are BlutzPlus, Sprites are BlitzMax) if you want to see how fast it is possible to get antialiasing. There is even an option to toggle that triple buffer trick I mentioned above. You'll see the improvement kick in with lots of sprites onscreen at once. |
| ||
| yeah I originally got the idea of using a greyscale bitmap from sswifts bob demo (I found the greyscale image in a folder) and then coded it myself. I to did all the calcs in memory (not video memory) for speed and didn't blend when 0 or 1, just when a value in between as the blending code needs a lot of multiplications. |
| ||
| Thanks both Grey & SSwift - this is all useful. I can't use BlitzMax for a number of reasons which are: a)I don't know the language and have spent a lot of time developing what I have done so far in blitzplus, and am very comfortable with blitzplus. b)I don't think BlitzMax has as fast individual pixel plotting functions as BlitzPlus - which I really need for my isometric game which uses pre rendered scenes and a pre rendered z-buffer to test each pixel against as to whether it should be visible or not. |
| ||
| Here is a link to a small demo showing anti aliasing in action in something I am working on. Note that everything here is just for testing purposes, it has very little to do with the game being developed. http://home.swiftdsl.com.au/~Matthew.Lloyd/lloyd/AntiAliasing_2.zip (1.6MB download) Cursor/Arrow keys to move around, Space (held down) to turn antialiasing off/release to switch back on, escape to quit. |
| ||
| @Matty, I don't think BlitzMax has as fast individual pixel plotting functions as BlitzPlus - which I really need for my isometric game which uses pre rendered scenes and a pre rendered z-buffer to test each pixel against as to whether it should be visible or not. How much overdraw are you getting to make a z buffer worthwhile for a 2d game? |
| ||
| i remember... reading from vram is slow but i need it for AA. i wrote a program that export all alpha-pixels (x,y,alpha) to a separate file and read it... i also modify the image so that it have no alpha (all pixels with alpha are masked!) so i dra this image and then draw few alpha-pixels around this image - but it was extreme slow - i had 20 fps or so... when i desabled reading from vram - it was fast again... |
| ||
| neilo - I get no overdraw as I draw in the order 'front to back' and only draw pixels which have not already been drawn. |
   |