SFML 2.0 a portable Toolkit
BlitzMax Forums/BlitzMax Programming/SFML 2.0 a portable Toolkit
| ||
| Does some of you already try SFML 2.0 RC ? http://www.sfml-dev.org/features.php It's a quite popular portable C++ toolkit similar to SDL. I think it could be an incredible companion for BlitzMax ! It's more or less everything you could hack or add into BlitzMax and by the package system would allow us to keep the best part of both world. I think about it cause I somewhat reached a rendering speed bottleneck with Max2D and can only dream about trying some more advanced things like Shaders, sprite batching, render to texture, etc. I've read that SFML 2.0 is incredibly faster than SDL, don't know against Max2D but by the look of it, it's certainly one of the best update BlitzMax could get. Plus it's actively supported and pretty solid. What do you think of it ? |
| ||
| I think it's pretty great and a well know standard. And I am pleased the 2.0 version is coming near. But how will it be a companion to Blitzmax ? and can't you "just" do those things in OpenGL in bmax? but I think I am happy all these great things are around. |
| ||
| Hi Armitage I've held off replying since you posted this because I'm trying not to miss the point, but as nitti says, why not write some specialised opengl or dx9 code for your own needs? Any general purpose system (ala Max2D and even SFML) won't be optimal for most purposes. The more 'optimising' routes the API's provide, the more complex they become, and they still might miss the case you're looking for. Ultimately there's only so many polygons/particles/texture swaps/shader effects etc you can have in your scene before your target audience becomes people only with extreme gaming rigs, and unless you're making the next farcrysyshalflifecod they won't be interested. If SFML are providing the speed you need it'll only be down to a few hardware vertex buffers - after that you can decide how to optimise your scenes to make best use of them. There was a 'batching' (DX9?) driver under construction but I don't think you need it. The last 2d stuff I did away from blitz used a lot of custom hardware vertex buffer management code, and it was lightening fast -- I could draw an entire GUI system in one render call simply because I laid out the GUI to use one texture. That's an example of understanding your scene and knowing what you can (and should be) getting away with. For dynamic buffers (where 2d objects were moving around individually) I had a system memory copy of the buffer and a tracker to maintain which parts of the buffer had to be updated (ie uploaded to the video card.) Once your data resides there, drawing it (within reason) is not an issue. Based on my limited knowledge of the Max2d driver source, I think that building on those drivers will open up a whole new world of performance. It's not an area I'm working in at the moment, but anything we can do to help we will. I'll drop my C++, DX8.1 engine source (with the VB management) somewhere too. |
| ||
| Hi Matt & Nitti Thanks for replying ;) In fact I already write a few specialized OpenGL functions, some that can coexist with Max2D and do the job. I know the next step would be dropping Max2D and write my own set of optimized drawing commands, but I know where my limits are. Using them is not a problem, writing them is another thing. As for DX Driver I can't really count on it since I'm also working with Mac & Linux. About the GUI I'm exclusively using CEgui under BlitzMax, it's better than anything I could write from scratch and in the making since so many years that they addressed most problems and reach the best rendering speed possible (included single texture rendering). I don't target any audience, I'm just making games that I want based on things I want to experiment. And if libraries already exist to achieve this then I see no reason not to lay down my ideas directly into a pre-made engine rather than writing one. SFML could be one of the best companion available out there cause : - BlitzMax development ended - Using C++ Libs is one of the main feature - The current rendering toolkit (aka Max2D) is easy to use but not fast/practical enough on some situation (for Particles system or R2T for example). - It would allow Max users unable to code some features to use them ultimately (it's not because you can't code a sound driver that you can't play sounds). - It's portable like BlitzMax - Because SFML was made to be integrable But you right, such thing probably never gonna happen and for many reasons unfortunately... |
| ||
| This is what I meant about not wanting to miss the point... As far as I can see, if you want to use SFML, switch languages. If you want more performance from Max2d, recode some stuff. All SFML's current bindings are for languages that don't natively support SFML's features (Sounds/Gfx/Networking/etc), which makes perfect sense. Adding a binding for a language that does those things already (albeit in a broken or limited performance kind of way) seems like a pointless approach. Unless I'm missing something here? I'm not even sure existing Blitzmax games would benefit from simply plugging into SFML's rendering pipeline - if games continue to use DrawImage, Drawrect, drawline etc (ie non-batched operations) the performance will be the same, or any minor gain could be matched by tweaking Max2d. I hope the tone of my message comes across -- I'm trying to understand and be helpful :) |
| ||
| I'll drop my C++, DX8.1 engine source (with the VB management) somewhere too. If Armitage isn't interested in this, there are others of us that would be. |
| ||
| Hi Gary, This takes me back. I recently found it on a demo reel CD from '06 :) http://www.matibee.co.uk/mengine/index.html There's not a lot of relevance these days I fear. It was using DX8.1 and D3D fixed-function pipeline (before shaders.) |
| ||
| It's true that I could switch to C# since SFML support it (except I'm mostly limited to Windows this way). The idea for BlitzMax was just to infuse a bit of fresh air while keeping the simplicity of the language. Anyway ! Hope this link will awake a bit of curiosity for some of us. |
| ||
| matibee: Thank you, I will download it later this week. I look forward to learning from it. |
| ||
| It's true that I could switch to C# since SFML support it (except I'm mostly limited to Windows this way). Well, what about a brand new Monkey target? GLFW still makes use of Mojo, but it's pure C++, 64bit inside. An SFML native target could be outstanding! |
| ||
| Yeah. I own Monkey. It's a pure gem. I don't use it. Wrapping/Porting & supporting libraries is hard, often dropped and not documented. It's not officially planned. Most here are satisfied with BlitzMax / Monkey. |
   |