SwiftBOBS now available! (2D sprite system)
Community Forums/Showcase/SwiftBOBS now available! (2D sprite system)
| ||
| The Swift Blitter Object System is now ready for public consumption! Grab the demo here... and as a bonus, you'll get a sneak peek at some of the graphics for a puzzle game I've been working on... [update] I've uploaded a new demo of my BOB system here: http://sky.prohosting.com/scswift/swiftbobs-demo-021.zip This version has a few added options to play with as well as triple buffering, which is on by default. Triple buffering dramatically improves the performance of the system in Blitzplus when using blending operations. It has no effect on Blitz3D. I've included one demo for each version of Blitz so you can see the performance in each. The BlitzPlus version is the faster one by far, especially with triple buffering enabled. [/update] SwiftBOBS is a system designed for handling 2D sprites, reffered to in the system as BOBS, which is an homage to the term used for sprites on the Amiga. With SwiftBOBs, creating 2D moving objcts is very easy. Just load your image, call CreateBOB(), and off you go. A single flag enables masking, if you use the default masking color. And if you want, you can change the mask color for each BOB individually, or for a whole group of BOBS that use the same image, at once. And this is just the tip of the iceberg. Not only does the system make it simple to create sprites, but it supports every blending mode you get with 3D graphics in Blitz3D. Add, Multiply, Multiply x2... You can even do alpha blending if you specify an image to use as an alpha map. Blending does come at a price however. It incurs a pretty significant performance hit. But it's there if you need it. Just don't expect to draw a hundred antialiased things at once. You can also change the base color that the BOB's image is multiplied with, just like on an entity in Blitz 3D, and you can change the overall alpha of the BOB. When not using the special blending modes, or the color shifting, or the alpha transparency, the system is lightning fast, as you can see in the demo. On my system I had 2000 24bit color 30x30 masked sprites moving around at 60fps. So when blitting normally you get no less than you have come to expect from Blitz. To achieve maximum performance, the system has FOURTEEN seperate blitting functions, each one optimized for a specific task. A normal blit uses the standard image blitting functions which are super fast, while the special blending modes use highly optimized functions specifically designed for each combination of blending operations. Here is a list of all the functions included in the system: (minus the internal blending functions) InitializeBOBS() CreateBOB.BOB(Image, Flags=1) FreeBOB(ThisBOB.BOB) BOBBlend(ThisBOB.BOB, BlendingMode) BOBAlpha(ThisBOB.BOB, Alpha#) BOBAlphaMap(ThisBOB.BOB, AlphaMap) BOBColor(ThisBOB.BOB, Color_R, Color_G, Color_B) BOBMask(ThisBOB.BOB, Mask_R, Mask_G, Mask_B) MaskBOBS(Image, Mask_R, Mask_G, Mask_B) BOBOrder(ThisBOB.BOB, Order) BOBFrame(ThisBOB.BOB, Frame) BOBFlags(ThisBOB.BOB, Flags) ShowBOB(ThisBOB.BOB) HideBOB(ThisBOB.BOB) PositionBOB(ThisBOB.BOB, Position_X#, Position_Y#) TranslateBOB(ThisBOB.BOB, Offset_X#, Offset_Y#) SetViewport(X1, Y1, Width, Height) UpdateBOBS() BOBS_Overlap(FirstBOB.BOB, SecondBOB.BOB) BOBS_Collide(FirstBOB.BOB, SecondBOB.BOB) BOB_RectOverlap(ThisBOB.BOB, Rect_X, Rext_Y, Rect_Width, Rect_Height) BOB_RectCollide(ThisBOB.BOB, Rect_X, Rext_Y, Rect_Width, Rect_Height) BOBX#(ThisBOB.BOB) BOBY#(ThisBOB.BOB) Now that you've read about it, try the demo, and see for yourself. Most functionality is represented in the demo, and there's lots of options to play with. I have included one demo compiled in Blitz3D, and one compiled in BlitzPlus, so that you can see the perfromance differences between the two. I highly reccomend you use BlitzPlus if you're going to make a 2D game that uses any special blending modes, but both BlitzPlus and Blitz3D are extremely fast with regular masked blitting. And finally, if you're interested in purchasing a license for the system, the terms are the same as for all my other systems. $15 for shareware/freeware, $100 for commercial use. Payment is accepted through paypal to scswift@..., Western Union, or via bank transfer. See my worklog for additonal details. But wait... there's more! If you are familiar with my FLUX and Anibrush systems, then you'll like this... I plan to port both to a single system for animating BOBS in much the same way that they now work on 3D objects. With just a few simple commands you'll be able to have BOBS weaving back and forth in sine wave patterns, becoming more and less transparent, while animating their image, in looped, one shot, or ping-pong animation modes. This will be a FREE addition to the BOB system when completed. |
| ||
| Save your worklog entry, because it will be lost when the site's finally moved to the new server. |
| ||
| Oh there's no worklog entry, I just meant that the worklog discusses what the licenses are like. And I have saved this message. |
| ||
| Link doesn't work for me. |
| ||
| Hmm It is not really that fast tbh. I got 20-30 at 20-40fps on a radeon 9700 pro using alpha/blend modes. Aside from that.. well I guess for some newbie/lazy blitzers, it would be nice to have a pre-built sprite layering system. (not exactly hard) |
| ||
| I think those fps are good, about as good as your going to get with 2d alpha images in Blitz. |
| ||
| Odd. I'm getting 80fps on a 2ghz P4 with a craptastic Intel onboard graphics thingy at home. I'll test with the beast when I get home. (Just upgraded from the 9600XT radeon to the 9800XT radeon so we'll see what happens) :) |
| ||
| "I got 20-30 at 20-40fps on a radeon 9700 pro using alpha/blend modes." That's odd. If I run the BlizPlus verison of the demo on my Radeon 7200, I can draw 80 alpha blended bobs at 60fps. The other blending modes are slower though. |
| ||
| Link doesn't work here either... |
| ||
| Supposedly I get 1000 frames per second on my parents' PC, which is 2ghz with a Radeon 9800. I have the vaguest idea that it isn't the real speed. |
| ||
| probably is without alpha turned on. Turn alpha on and try again (2 on the keyboard I think). Kanati |
| ||
| I have added another link for the demo above if the original doesn't work. |
| ||
| "Supposedly I get 1000 frames per second on my parents' PC, which is 2ghz with a Radeon 9800. I have the vaguest idea that it isn't the real speed." If you haven't enabled any blending modes, then you certainly can get that. How many BOBS did you have? If it was just the 10 that it starts with, then it's quite easy to get 1000 fps. I can display 2000 bobs at 60fps on my Radeon 7200, with masked blending only. You won't get near those rates with the special blending modes though. But I can get 80 alpha blended bobs at 60fps in Blitzplus. |
| ||
| I have come up with a method that allows one to render 280 add or multiply bobs at 20fps in Blitzplus. Normally, that many would render at 4 fps. Alpha sees no similar major increase in speed, but I suspect that is merely because only the edges of the BOBS are antialiased. Has no apparent effect on the speed of Blitz3D. One unfortunate side effect appears to be that you won't get more than 30fps with this method even if you render normal bobs. Another strnage side effect is that rendeing masked bobs with the standard image drawing commands is incredibly slow compared to rendering a mask manually. I am using the demo version of BP, so perhaps the full version will behave differently. I have to assume that that second side effect is a bug in the demo version of Blitzplus which has since been fixed. |
| ||
| Okay I decided to purchse Blitzplus instead of using the buggy demo, and I can now report that the method I described above now works much better! What method is that? Triple buffering! Rendering normal BOBS using triple buffering, you get a performance decrease when rendering normal bobs, but a huge performance increase when rendering any blended bobs. Here are some numbers: Rendering 500 BOBS at once: Without triple buffering: Normal - 200 Alpha - 11 Multiply - 2 Add - 2 Multiply x2 - 2 With triple buffering: Normal - 58 Alpha - 20 Multiply - 16 Add - 19 Multiply x2 - 16 And that's rendering 500 30x30 sprites. So, you're pushing around 450,000 pixels per frame with those numbers. And that doesn't count redrawing the background. Triple buffering is easy to implement in your game and does not require any special programming to handle your other graphics. To do triple buffering, all you need do is create an image the same size as your screen, and Setbuffer ImageBuffer(Triplebuffer) at the start of your program. All draw operations will then go to the triple buffer. Then just before you flip, you set the back buffer to be the draw buffer, copy the triplebuffer to the back buffer with drawblock(), reset the triple buffer to the draw buffer, and the flip. That's all there is to it! The reason this works is because it is much faster in BlitzPlus to read pixels from an image, than it is to read them from the screen. And blending operations need to read a lot of pixels. This method will NOT improve the performance of the system with Blitz 3D however. |
| ||
| Woulda thought there'd be more interest in this given how many users are doign 2D stuff and have been asking about blending stuff lately... |
| ||
| On "the beast" I get 3000 bobs at 75fps (you wouldn't let me go higher dagblastit!) with option 1. But with B3D I only get 9fps with about 50 (don't remember exactly but it wasn't many). With blitz+ I got 15fps with 500 of them with alpha. The other options are really too slow to use any number of sprites with. Good stuff sswift and would probably be pretty nice in limited use. But I'd have to say it's too slow with anything other than normal or alpha for any real use. |
| ||
| Sswift, when I start another 2D project i will be in touch, i think its great. |
| ||
| Kanati: Try the new demo which I posted the link to in another thread on this forum. "But with B3D I only get 9fps with about 50" I presume you meant "with alpha I only get 9fps". |
| ||
| Are you aware of andreas_blixt's excellent image buffer DLL stuff? Might help speed things up. Interestingly before Blitz3D existed I made a sprite library that did what (I think) yours does: only alpha the soft edges (and transparent areas) of the sprite. Yours is much better I'm sure, and your marketing is better. :D |
| ||
| "Are you aware of andreas_blixt's excellent image buffer DLL stuff? Might help speed things up." It migth speed thngs up in Blitz3D, but it would not speed things up in BlitPlus, and I'm more concerend with BlitzPlus. Besides, I did a test and I know how much of a speed advantage I'd get by doing that, and it's only in the range of 5-10fps or so. And that's only if you use triple buffering. And that 5-10fps presumes one can find a way to do one poke per pixel rather than 3 when reading/writing 24bit color data... getitng it down to 2 would be easy, but getting it down to 1 would require major effort. In addition, one would need to support every pixel format. Given that I have fourteen functions now, if I were to support every pixel format I would need 42 functions. And trying to write each pixel in one poke would double the size of each function because I'd need to write pixels in two seperate loops. And lastly, as far as I know, that DLL is likely to break in any new update of Blitz... I've been following some imagebank stuff people have been talking about lately, and it relies on the ability to get the data from Blitz' internal structures in an unsupported manner. ONE CHANGE to that structure in Blitz, and the whole thing will blow up. All in all, it would be a huge headache, and given the lack of interest in these functions so far, completely not worth the headaches. Besides, it would make making changes to it down the road a nightmare. |
| ||
| Oh and... "Interestingly before Blitz3D existed I made a sprite library that did what (I think) yours does: only alpha the soft edges (and transparent areas) of the sprite." You are correct. My system determines for all blending modes which pixels are opaque or transparent and blits them fast, and only does blending on those that remain. So an alpha blended sprite which only has edge antialiasing will go much faster than a semi transparent square of cloud. |
| ||
| sswift- what are you using to draw the gfx? |
| ||
| Using to draw the graphics? Writepixelfast, if a blending mode is enabled or a color or alpah change is in effect. Drawimage, DrawBlock, if drawing normal masked or unmasked stuff. I've tested with the poke commands available in Blitzplus, and determined that at this time, it is not worthwhile to support them. Maybe if the system were geared towards 16bit color, but 24 bit color is not significantly faster. Of course I might change my tune if there is signficant interest in the system, but with the current lack of interest, the added complexity of having to support three different pixel formats, and the fact that the system is more than fast enough for most needs as it is... well, there's not currently incentive to go that direction. |
| ||
| Btw, I have optimized the system a little more, so multiply blending in the demo will render as fast as the add blending... it was not before because I was not checking for black pixels in the multiply map, because there aren't likely to be many of them. However in the demo because I'm just using the pshere graphics, all those black pixels around the edge really slowed multiply down compared to add which only had to draw the center of the sphere. This optimization would be handy if one were to draw pure black shadows behind things, with some fading at the edges. I also just tested a new rendering method I call a difference buffer, but it turned out to be a dead end, and did not improve performance. The difference buffer used a two layer array that stored the current front and back buffer. This was compared to the triple buffer I was writing to, and if any pixel differed, they were updated in the array, and then plotted to the screen. This optimization worked under the presumption that writing to the screen buffer would be slower than reading from the image buffer. But it turned out not to be. Besides which, this method of rendering would only have accelerated situations where the background remains largely static. In that way, it was similar to a dirty rectange type of system, which I also have not implemented, because that would force one to render only bobs and stuff overlaid over bobs, and would not accelerate any kind of game which requires a scrolling background, which I imagine a lot of people want to have. |
| ||
| Hm... odd... I just did a test. It appears that image buffers, whether created in in a 24 bit graphics mode mode, or in 16 bit graphics mode, will have a 24 bit color depth. 3 pixels per color, BGR color order. I discovered this when testing 16 bit mode with triple buffering enabled. If one could count on this always being the case, this would make optimizing for Blitzplus easier in some ways and more difficult in others. |
| ||
| The imagebufer / DLL stuff isn't actualy a DLL, it's a method I found of pointing a Bank to the memory area of an imagebuffer. Andreas wrote some tidy functions to wrap it all up. There's been no side effects that I know of, and I can't guarantee it, but I strongly doubt the method will break unless Mark does something drastic with image/texture buffers (like upgrade to DX9? hehe). Don't judge it before at least trying it!, it may or may not benefit your system :) Tom |
| ||
| "Don't judge it before at least trying it!" I have judged it before trying it, but I did not judge it before evaluating it. I know what you are doing, and how you are doing it essentially. And I know that it cannot be faster than BlitzPlus's specialized commands. Knowing that, I know that using it will only provide moderate performance increases. If it made it 10x faster I'd consider using it, but it will at most increase the speed by 2x. And I know that the method relies on the internal strucutres of Blitz remaining the same so you can get the format of the image and the width of the buffer. One change to those and the whole thing blows up. And I'm pretty sure that it only works in B3D, so I'd have to code a seperate system for BlitzPlus. So it's just not worth it. Anyhow, only like one person has shown any real interest in the system at all. As far as I'm concerned, it's as optimized as I want it. |
   |