next »

[nikki]

I've been playing with PIXI.js for a few months, now I am looking to build some stuff specifically for the raspberry pi, so I started looking for a native fast 2d rendering library, I've tried SDL2 but it might be hardware accelerated it is slow as %$# compared to pixi.js, as ane xample this is a test app in pixi http://www.goodboydigital.com/pixijs/bunnymark/ what native lib out there has similar speed results?

[Krux]

Try out allegro.

[Sik]

Note that you *can* force SDL2 into making a software renderer (i.e. not using the GPU). Honestly I wouldn't say it's the fastest though... There used to be Allegro around but since version 5 it's also GPU-oriented and its software renderer is beyond slow (it literally tries to emulate a GPU).

I think you're probably better off writing your own renderer. Look up what kind of code compilers are better at optimizing and you should be mostly OK. (first try forcing SDL2 to use software rendering though, it may be good enough for your needs)

[nikki]

No I don't want to use software rendering, that can never be the fastest. (edit: I'll give it a try though)
SDL2 is using the hardware, its just not very fast, it reminds me a little of Blitzmax, I wouldn't be surprised if it actually just does immediate mode behind the scenes honestly.

I think I'll give love2d and allegro and haxe a look. (the raspberry pi requirement (ARM proc.) might be a show stopper for any of them though)
and off course my hands start itching to just port the pixi code, but you know reinventing the wheel and everything.

[eclectocrat]

You might try and check with pi experts to find the lowest level graphics access and run a few simple tests (like the bunnies) just so you can know what to expect as your upper limit. PIXI running textures on a modern card designed for games will beat the shit out of software rendering any day though.

The org has a forum devoted to graphics on pi: http://www.raspberrypi.org/forums/viewforum.php?f=67

Good luck!

[nikki]

good idea!

[kamac]

Fastest would be a custom rendering lib that would be suited just to the thing you want to make.

Other than that, I'd give SFML2 a look.

I wouldn't do haxe / love2D, unless you can't do C++. Haxe is flash after all ( = slow as hell, unless it has a proper compiler that outputs .exe/.o, which I doubt ) (figured it can output c++), LUA is bytecode, which does reduce it's performance (would probably be especially visible on raspberry), unless you use LuaJIT.

You can't beat a well coded, C++ app with those, though.

Viable options that aren't C++ (slower, but I guess they're fine):
- lua + love2D
- blitzmax

[Geti]

SDL is commonly used to grab an opengl context and do your rendering from there, with sdl handling sound and input and giving you a cross platform way to actually grab that opengl context. Allegro is also good (and much less hands-on), some people seem to love SFML but it's always turned me off, haha; I should mention it though.

SDL2's rendering isn't particularly slow though fwiw (at least as fast as any lib I've seen with a more or less "immediate mode" interface, got a feeling pixi might be optimising there by batching render calls as I dont think this integrated card would break 12k bunnies at 50fps otherwise, but I could be mistaken ), make sure you're rendering in (a) very tight loop(s) and doing an optimised build if you're seeing slowness.

SDL has been used for a bunch of mobile games and is generally a very sane starting point, though it doesn't give you much out of the box other than platform independence, and the C interface turns off a lot of C++ devs (less power to them).



What exactly are you trying to accomplish?

If you just want sprites and tiles and particles at console-ish res and 60fps, you should be able to without a hitch using any of the libs mentioned above; if you're really trying to crank out performance, rolling a custom solution tuned and trimmed down to your specific needs (in this case, custom opengl solution) will just about always rock anything pre-packaged.

[nikki]

Fastest would be a custom rendering lib that would be suited just to the thing you want to make.

rolling a custom solution tuned and trimmed down to your specific needs (in this case, custom opengl solution) will just about always rock anything pre-packaged.

yes offcourse, I think I have almost decided on trying that, it's just I can't believe all these 2d rendering libs NOT trying their best to best as fast as possible.. 

got a feeling pixi might be optimising there by batching render calls

that's exactly what they do https://github.com/GoodBoyDigital/pixi.js/blob/master/src/pixi/renderers/webgl/utils/WebGLSpriteBatch.js actually the code is adapted from libGDX which might suit my need, sadly though my main laptop has a too crappy card to use lbGDX and I actually don't really want to go java.

What exactly are you trying to accomplish?

Sprites and tiles and particles at console-ish res HD resolution and 60fps,

I am experimenting to see if I can do my presentations (as an 'digital' artist) running from an embedded system (like the pi or maybe some clone with a better graphics chip) that I can build in my artworks as opposed to the bric-a-brac of whizzing PC's and cables I use and have to hide at the moment.

edit:I've tried SFML a few weeks ago, I am also learning D (which I intend to use on the pi since I can and it's just as fast a C (they say)) and the way SFML is wrapped for D is very unpleasant compared to SDL, actually @geti: it's good you mention the way it's commonly in use, I am very new to it and didn't know that, I imagined slightly diff. so thanks.

[Zaphos]

There used to be Allegro around but since version 5 it's also GPU-oriented and its software renderer is beyond slow (it literally tries to emulate a GPU).

Allegro 4 is still available: https://www.allegro.cc/files/?v=4.4

(Disclaimer: I don't know anything about 4 vs 5, as I haven't used allegro for a long while.  But 4 should still be a stable, solid lib; I used it a lot back in the day.)

[Sik]

The problem is that Allegro 4 is pretty much dead by now.

Also now that I remember, SDL2 has some configuration problems with the Raspberry Pi that effectively means it can't use its hardware efficiently, so I guess that may be the root of the issue here...

[InfiniteStateMachine]

If you are planning to specifically target the raspberry pi then I think the fastest way would be to just write your own 2d renderer in opengles. Then you don't have to worry about any odd stuff a intermediate library might be doing.

[Geti]

Re: batching/why - you can't really have that "for free" in a rendering lib due to the way graphics APIs work.
- You can create (in OOP parlance) "spritebatch" objects that create separate "sprites" (basically a quad mapped to that texture) that're all rendered at once when you render the sprite batch. This is similar to how d3d "Sprites" work with subsequent render calls to the same sprite.
- The other option is to detect batchable conditions and construct a draw call to be dispatched whenever - I believe SDL handles this on some platforms if you continue rendering from the same texture, though you still have "immediate mode" type function call overhead for all the SDL_RenderCopy calls, and overhead for detecting these conditions too)

If you just want an API that lets you render whatever, wherever (ie a "nice" api for new programmers that just want pixels on the screen) you can't really have as much speed as when you're exposing the optimisations to the user. I hope that makes sense. Either way, getting a OGL ES context from SDL and rendering from there would be a good option.

Haven't heard about hardware issues with SDL and the raspi, but haven't tinkered much with HD rendering there as I'm mostly rendering something for a tiny TFT screen I'd expect you should be able to get 60FPS at HD res even in plain SDL if you keep the amount of stuff on screen down; if it's just for presentations and not big games burning time on physics, AI, etc etc.

Run a quick benchmark of rendering as many tiles as you need on the screen, plus say 30 "actors" and "items", maybe a simple particle system and see if it's feasible using just SDL_RenderCopy/Ex; if not then move to OGL


Re: D is just as fast as C - I've always been skeptical here, C compilers have had decades of time spent improving their optimisation. Unfortunately benchmarks game doesn't have a D entry for quick reference

[Sik]

- The other option is to detect batchable conditions and construct a draw call to be dispatched whenever - I believe SDL handles this on some platforms if you continue rendering from the same texture, though you still have "immediate mode" type function call overhead for all the SDL_RenderCopy calls, and overhead for detecting these conditions too)

SDL doesn't handle it at all anywhere, period. There has been many talks about it in the mailing list (and even proposed patches), but nothing came out of it yet. Also there was the suggestion of having an equivalent of SDL_RenderCopy that blits a texture multiple times instead of just once (essentially leaving batching up to the program instead of SDL).

I wouldn't be surprised though if the driver just ignores an attempt to reassign the same texture (at least in OpenGL, where the driver is meant to take control over the resources).

[Geti]

That could explain why batching "seems" to work I guess. If they're using the sprite interface in the directx renderer that could also maybe handle it on windows. I'll admit I haven't bothered looking at the source cause I get 60fps with a few thousand particles, a tilemap and some actors running around and thats fast enough for me.

An equivalent of the SDL_RenderLines/Points/Rects for RenderCopy(Ex) would be nice for sure though.