BlitzMaxier 2D?
BlitzMax Forums/BlitzMax Programming/BlitzMaxier 2D?
| ||
| Would anybody be interested in creating a 'package' for BlitzMax which extends the existing 2D command set and collects useful modules and code archives. (a bit like the B2D Extended DLL did). Maybe have a thread where people can request features which are found if existing or written if possible? I am not talking so much about new engines and wrappers but more new functions : blend modes, multitexturing, drawimagerect etc Might even go as far as Particle and Sprite systems and, perhaps, TileMap editors. Anyway, what do people think? <edit> From the requests : Line Antialias Unfilled/filled shapes BBstyle DrawImageRect Scaled pixmaps Once these threads have had enough (?) input I'll add comments and tidy the variable names. Maybe edit them into a module here? |
| ||
| how about these: - anti-aliased line and open oval - open rect (yeah, simple, to do, but nice to have natively) - resurrection of ye olde DrawImageRect, but then one that doesn't bug on various videocards -including my Geforce4MX-. I'm not sure about particle, sprite and tilemap stuff, this is all so terribly custom to one's needs that it's nearly impossible to make a one-stop solution. I'd focus on the smallest elements only. Take particles.. drawing something is not really a biggie, the biggest part of such a particle system would be the math and the programmability of that math. Technically speaking such a particle system can serve anything, gfx just being one of many examples. Sprites idem.. there's quite some overlap with particles I think, in any case it's perhaps a bit too high-end if you ask me. Tilemaps, same again.. there're so many things one might want to have in a maptile class. Rather than having to investigate how a lib works, I rather make my own tile class in 5 minutes.. :P So, all nice, but I'd focus on low-level/basic functionality. That said, don't let me stop you if you want to do particles/sprites/tiles anyway. :P |
| ||
| Take a look at the grey alien framework... PLS |
| ||
| It would be nice too, if one could control when glstart/end are used... Surely it can't be very efficient to call them *every* time you draw a line ? The programmer should be big enough to know when to end it himself.. Unless it doesn't matter that they are called all the time, of course? I had to write my own set of "open" drawing functions for the graphviz module - rectangle, ellipse, etc. Bit of a pain, as it is something you would have expected to be available in the package already... |
| ||
| For every line, no. But whenever you switch texture you must have it within a begin end ... so the "regular BM" programmer wouldn't be capable of doing it correctly. Although I like this idea ... a BeginDraw(textureHandle) ..... EndDraw() would surely be something usefull :) |
| ||
| Take a look at the grey alien framework... I have GA's framework which does have some extended functions but I am thinking more community driven requests rather than a framework. In fact GAs framework includes some of the functions from the Code Archives and/or supplied in posts so could also benefit. @CS_TBL, yep I agree with the Particle, Sprite and Map Editor remarks. However, if somebody was to say "You can package my Particle System" and it's a good one then it won't hurt to add it. Your requests are very much the sort of thing I envisaged. The extra benefit is having a few more people available to stress test any solutions. @Brucey, The glstart/glend query is another good one. Does it matter? I don't know but maybe others *do* know and/or are willing to test it. Finally, there are open drawing functions in the Code Archives. I haven't used (they might even be yours Brucey) but, if somebody has a problem with them, it could be looked at further. Anyway, thanks for the interest. As always I guess it's who is willing to help and how it can be controlled. Many times I see the comment : Can this be added to the official modules? which gets no response. I would prefer an official update but, maybe, the next best is Can this be added to the unofficial modules? <EDIT> From DX point of view 'SetFillStyle' should allow filled/non-filled rects, circles, elipses etc. I'll have a look. I can see how to anti-alias a line in DX but OGL seems OK. I also think some graphics cards don't allow anti-alias which was the problem with B3D. GetCaps shows the cards DX capabilities with this If mycaps.dwRasterCaps_LINE & D3DPRASTERCAPS_ANTIALIASEDGES Print "The device can antialias lines forming the convex outline of objects." Else Print "The device can NOT antialias lines forming the convex outline of objects." EndIf showing if it can do it or not (I think : It was a long time ago I wrote GetCaps and didn't really know what I was doing : still don't). |
| ||
| Sounds like a good idea (except for future framework sales ;-) but I don't mind). I was thinking about this just yesterday. Basically the code archives are all spread out and have lots of less useful stuff, and many other cool bits of code are in general posts, not the archives. So to collate it all (perhaps standardising some names) and make it into a single downloadable file (or several files based on category) would be pretty cool. Who's gonna do it though? |
| ||
| You know what I'd like? I dunno whether it's possible.., to draw a TPixmap... scaled, with SetScale! |
| ||
| @GA, Yep I agree about collating the useful code. Not that they're not all useful in some way just some are more niche than others. As for who is going to do it : Not my strong point although I would be willing to help to some degree. Maybe somebody who has a syncmods server. If we have guidelines for the code it could be as easy as a cut/paste into a module. @CS_TBL, might be worth adding it as a normal post then, if/when it is answered, it can be stuck in Code Archives and then be a candidate. |
| ||
| How about something like GoogleCode ? I'm using it for wxMax, and it's very good, and has a simple interface. Give a few chosen developers write access to the repository, who can apply fixes, add new functionality. Work out a release strategy, which doesn't have to be very involved, and is simply a case of upload a new release into the downloads area. You might have a source-only build, and maybe one pre-built for each platform. And of course, there's direct subversion access for those that want the latest and greatest... (I find googlecode easier to navigate than the sourceforge monster, but they all do the same thing at the end of the day). |
| ||
| Never worked with GoogleCode, nor with SourceForge ... Use Origo and our university SVN service normally :) |
| ||
| Not easy to find (english) words for what I want to say, but I'll try: Before contributing any clever stuff (particles, effects etc..) we need a basic but solid framework to handle the lowlevel stuff. E.g. a particle engine that calls glBegin..glEnd for each particle is a bad idea, so it wouldn't be good to rely on default Max2D commands for contributed functions. Ok, no problem, let's use vertexbuffers, there are plenty examples in the code archives. With using vertexbuffers the next problem comes up: texture management. Everything inside a VB must use the same texture, so the way to code with VB's is total different than with Max2D commands....if we solve all problems that come along with VBs (and other enhanced topics like shaders, additional backbuffers) we end up creating an engine. Don't get me wrong, to have a enhanced graphics engine that's based on BlitzMax and works together with Max2D is a very good thing! I would love to contribute all my engine's code to build a community engine, but if we really want to do that we need a clear and clever plan how we do it! How to handle extensions (VB,Shaders) ? How to do texture management? How to do fallback/error handling for the whole stuff etc... Without an modular and flexible engine that drives everything most contributed functions will be isolated solutions that hack Max2D to achieve a single effect. Then there's nothing more to do as the code archives are still up and running. Jake |
| ||
| For what you need, you can use miniB3D or miniB3D extended from klepto which does that and a few other things. From what I get, this is meant as a similar thing as Blitz3D extended. This means extend Max2D, not replace max 2D. Although the beginDraw endDraw part might actually be something that BRL even could consider to integrate into BM if it was developped carefully. |
| ||
| @Jake L, I think what you're talking about is slightly beyond the scope I had in mind. I was looking for more of a 'best of the forums' module which collates good basic function code on-top of Max2D. |
| ||
| This sounds like a good project in general. I think Max2D definitely would benefit from being extended in a number of ways. It seems Mark was working on Max3D which I always presumed would let you do most of the things that we wanted Max2D to do but in an integrated way, but now that's turned into a whole new higher-level editor-driven system so now Max2D is still left with its diapers on. I think Max2D needs to at the very least have a comprehensive set of drawing functions. I don't know why there weren't hollow rectangles and ovals right from the start, this was a major oversight. DrawPixmap unfortunately uses glDrawPixels which in Max2D code does not set the scale factor. It is actually possible to define a scaling operation which occurs during the drawing, if you write it on your own OpenGL code. I think we also need to see splines and we also need access to the points along the spline to use them not just as drawing primitives but as paths for animation etc. As far as new draw modes go, there aren't a whole lot of blend modes that are supported in the base level OpenGL. We already do Add and Multiply. It's possible to do Inverse and it's possible to copy the alpha value into the RGB components during rendering, but that's about it. More blend modes were added in newer versions of GL. Maybe it would be helpful though to do composite things like drawing shadows beneath sprites. It's hard to do a subtract mode, though. We should also have use of the stencil buffer - BlitzBasic on the Amiga had stencils! I also agree about the glBegin glEnd - I implemented this into some drawing functions that I made for myself and called them MultiBegin and MultiEnd. I as the programmer then calls MultiBegin when I'm starting to draw primitives of the same kind e.g quads, and then so long as I know when I'm done I can do MultiEnd, rather than having new begins and ends around every quad drawn. It does help with the speed and removes a lot of overhead, but then this would only apply to OpenGL and you'd have to write all your own GL drawing operations to replace the standard Max2D stuff otherwise normal Max2D calls would interrupt it. |
| ||
| I implemented my BeginDraw EndDraw today ... Easy on GL, but hard to do in DX as someone tried to make those two as incosinstent against each other as possible *grml* Anyway: The speed difference can be forgotten ... Used hitoros breakout to test it with batching all the bricks ... No difference on my 8800GTS and 3 frames more (on 150) on my P-M tablet with Intel GMA900 onboard ... So the point is really not there. Seems like the current driver do quite some of this stuff internally. |
| ||
| I've taken parts in something like this in the past, it starts out nice and ends up a mess of spaghetti, especially if the main players get bored and move on or jump ship to another platform. I personally think a much better community project would be coding a stable DX8 or DX9 enhanced Max2D module. Using the D3DXSPrite Object for all 2D rendering would provide a good speed increase and give you the Start and End batching improvements similar to the OGL equivilent. (Especially with the DX9 version.) Coding a community engine would take forever, too many ideas, you wouldn't make everyone happy, etc. Coding a community collection of self contained routines that perform a certain task would be ideal. :) |
| ||
| Hehe it isn't like the Blitz community wouldn't have any experience with Community projects ... Even thinking of the most current one, the online multi user world editor, shows that :) As this one here seems to be more of a collection of functionality (and someone who has to standardize them to get them together) I think it is much more doable than CPs :) |
| ||
| @CS_TBL, Can you check if the links to code I have added in the initial post are OK with you? |
| ||
| Why link or post in other threads? Have all the goodies in this thread. ;) |
| ||
| Then the thread will get huge with any discussion on particular bits of code getting mixed up with others. |
| ||
| Heres the functions I use. I think this functionality should be built in but I'm biased because I use these. |
| ||
| I would really like to see a way of storing textures with a custom format - for example 10 bit where you have say 5 bits using a lookup table for colour and 5 bits for an alpha channel (the use of this for me is shifting around lots of smooth, large, cell-shaded sprites.) Don't know if it's possible, but I believe it must be! |
| ||
| @sonic, I am sure it is possible but is too niche for this suggested project. Create a new post with all the details and requirements as I am sure somebody can help. |
| ||
| Curtastic: Thanks! I posted some of my drawing ones here: http://www.blitzbasic.com/Community/posts.php?topic=73196 |
| ||
| A couple of suggestions: - textured polygon - texture splatting -AF |
| ||
| Texture splatting? You mean multi texturing? |
| ||
| Yes, multi texturing so that you can use alpha from a separate texture (or certain channel of a separate texture). Like this: 
Strict
SetGraphicsDriver D3D7Max2DDriver()
Graphics 800,600
Global gDriver:TD3D7Max2DDriver = TD3D7Max2DDriver(_max2dDriver)
Local imgGrass:TImage = LoadImage("grass.png")
Local imgDirt:TImage = LoadImage("dirt.jpg")
Local imgMask:TImage = LoadImage("blend.png")
SetBlend ALPHABLEND
SetClsColor 200,200,200
While Not KeyHit(KEY_ESCAPE)
Cls
DrawImage imgGrass,0,0
DrawText "imgGrass",0,0
DrawImage imgDirt,256,0
DrawText "imgDirt",256,0
DrawImage imgMask,512,0
DrawText "imgMask",512,0
DrawImage imgGrass,0,256
DrawImage imgDirt,256,256
If MouseDown(1) Then
Splat(imgDirt, imgMask)
DrawImage imgDirt, 0 ,256
gDriver.device.SetTexture 1 , Null
DrawText "imgDirt splat",0,256
Splat(imgGrass, imgMask)
DrawImage imgGrass, 256 ,256
gDriver.device.SetTexture 1 , Null
DrawText "imgGrass splat",256,256
Else
EndIf
Flip
Wend
End
Function Splat(r_image1:TImage , r_image2:TImage)
Local frame1:TD3D7ImageFrame=TD3D7ImageFrame(r_image1.frame(0))
Local frame2:TD3D7ImageFrame=TD3D7ImageFrame(r_image2.frame(0))
gDriver.device.SetTexture 0,frame1.surface
gDriver.device.SetTextureStageState( 0, D3DTSS_COLORARG1, D3DTA_TEXTURE );
gDriver.device.SetTextureStageState( 0, D3DTSS_COLOROP, D3DTOP_SELECTARG1);
gDriver.device.SetTextureStageState( 0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE);
gDriver.device.SetTextureStageState( 0, D3DTSS_ALPHAOP, D3DTOP_SELECTARG1 );
gDriver.device.SetTexture 1 , frame2.surface
gDriver.device.SetTextureStageState( 1, D3DTSS_COLORARG1, D3DTA_TEXTURE);
gDriver.device.SetTextureStageState( 1, D3DTSS_COLOROP, D3DTOP_SELECTARG2);
gDriver.device.SetTextureStageState( 1, D3DTSS_COLORARG2, D3DTA_CURRENT);
gDriver.device.SetTextureStageState( 1, D3DTSS_ALPHAOP, D3DTOP_SELECTARG1 );
gDriver.device.SetTextureStageState( 1 , D3DTSS_ALPHAARG1 , D3DTA_TEXTURE ) ;
End Function
-AF |
| ||
| @arctic-fox, is that definately the code you got those results with? I have been looking at multitexturing for a little while and have managed to 'merge' the blend and texture1. This gives me results as per your code (but *not* in the image) where there is no gradual move from one texture to the other. When I try to alpha the images together it blends nicely but darkens the picture. Here is the code which shows the problem I have : I keep coming back to multitexturing and, some day, was hoping for a DX/OGL module where an array of images and texturestates was passed to the function and the results returned. |
| ||
| Yes, the image is produced with the code I posted. And yes, the code does not work fully. Scaling brakes it just like alpha. I just posted it as an example of what I meant with texture splatting. -AF |
| ||
| OK, I seem to get different results with your code and the images than you have posted. In my case the textures simply switch places. What do you mean by scaling breaking it? I understand it being an example but, from the images posted, it seems to work for you and not for me. |
| ||
You can't take blend.png from that screenshot, because it doesn't include alpha channel. I uploaded the original blend.png here:  -AF |
| ||
| thanks, I get it now. |
| ||
| Anyone knows how to port this code to OpenGL and/or DX9??? |
   |