Is there an efficient way in Love2d to print a big (like, 800 x 600) table of color values on the screen? I've tried things like creating lots of rectangles (which is horribly slow) or creating an imageData and drawing that (which would be fine if the table-values didn't change at every frame, but they do). Thanks!
If you can compute the values without (much) extra data, you could try writing a shader and letting that compute stuff as things are being drawn.
If that doesn't work, using an ImageData can usually be made a lot faster than it is by default. First, you should ensure that you're not calling g = love.graphics.newImage( image_data ) per frame but create it once and then only call g:refresh( ).
The next thing is that :mapPixel is really slow because it's constantly calling from C into Lua (once per pixel) and that's quite a bit of overhead. It's faster to rewrite that in Lua or just use a plain loop with :setPixel (and maybe :getPixel).
If that's still too slow, the last problem is the following: LuaJIT cannot JIT-compile calls to C functions provided via the normal Lua API. But these can be replaced if you describe the data structure via the ffi and then let LuaJIT do the accesses directly. Slime has done this for love-0.9 (code on github). Just require that file and it will replace the slow functions, and everything should be a lot faster. I'm not 100% sure but I think I already used this with the current version (0.10) and it still works. (If the internal format of the ImageData ever changes, it will break, but it should be relatively easy to fix – and it's likely that someone else will update the code and post it somewhere.)
Related
I am developing on a linux system using latest (at the moment) SDL2 (2.0.8) + openGL ES 2.0 (GLSL 1.0) eventually targeting a raspberry pi 3 board. I have so far done a few things like drawing text with freetype, drawing lines, text boxes (editable), text lists, waveform boxes (all i need to pass to a function is an array of vertices) and other shapes with glDrawArrays(). Now, there are things that need to be refreshed at, let's say, 10 times per sec and others that need 1 time per second. What would be the best approach to skip re-rendering everything at the rate of 10 times per sec? Because obviously openGL works by drawing everything from scratch on every 'frame'. However i know and you know that other approaches exist that include: rendering on top of the screen you already have or taking a screenshot and rendering on top of it only the fast changing things as well as other solutions. What do you thing would be the best approach to skip re-doing everything before calling SDL_GL_SwapWindow() ? How can i take a screen shot and render it on the invisible buffer then render only the fast changing objects and then call SDL_GL_SwapWindow() ?
This is a screen shot of the app so far drawing basic things
Thanks in advance.
i eventually had to realize that i should not have posted the question in the first place but since this is a place where people learn from others i now feel somewhat nicer :) . So, the thing i had to do was to simply stop clearing the invisible buffer (i will call it that for simplicity) and render on top of it only controls that change. Those that change are updated by covering the area that they take by a rectangle and then draw new stuff on that area. I have already done it and the frame rate just 'exploded'. I do not really think that there is a better approach since the way i do it requires no action at all. All i had to do was to add a few if conditions that selectively rendered or skipped every time the execution reached the point where functions iterate through the controls that have to be drawn on screen and therefore decide what to render and what not. However a well thought set of structures is required for every control instead of declaring and defining endlessly global variables which will only makes things confusing and difficult to maintain.
Regards to all.
I cannot figure out what's wrong. I mean, the speed is way too fast, like 1 million items vs 10 million items basically have the same 0.0005 second computation on my machine. So fast, it looks like it wasn't doing anything. But the result of the data is actually correct.
It is mind boggling because if I make similar computation on sequential loop without storing the result in an array, it is not only number of cores slower, but, like 1000 times slower than ArrayFire.
So, maybe I wasn't using the timer correctly?
Do you think they didn't actually compute the data right away? Maybe it just sets up some kind of shadow marker? And when I call the myArray.host(), it will start doing all the actual computations?
From their website, it says there is some kind of JIT to bundle the computations.
ArrayFire uses Just In Time compilation to combine many light weight functions into a single kernel launch. This along with our easy-to-use API allows users to not only quickly prototype their algorithms, but also get the best out of the underlying hardware.
I start/stop my timer right before/after few ArrayFire computations. And it is just insanely fast. Maybe I test it wrong? What's the proper way to test ArrayFire performance?
Never mind, I found out what to do,
Based on the examples, I should be using af::timeit(function) instead of using the af::timer. Using af::timeit will be very slow, but, the result scale more reasonably when I increase the size 10x. It doens't actually compute right away, that's why using af::timer myself wouldn't work.
thank you
I have been tearing my hair out for a while over this. I need an OpenGL 3.2 Core (no deprecated stuff!) way to efficiently render many sprites, using batching (no instancing).
I've seen examples that do this with geometry alone, but mine also needs to send textures to it, I don't know how to do this.
I need a well done example of it working in action. And looking at how other libs like monogame and such do it isn't much help, because all I'm interested in is the GL code, and it has to have no deprecated stuff in it.
Basically I want to be able to efficiently render thousands+ of sprites, all having textures. The texture is just a spritesheet, so I just need to tell it to render a region of that spritesheet.
I'm disappointed in the amount of material available for programmable pipeline. To the point where it seems like it'd be so much easier to just say screw it and use fixed pipeline, even though I definitely don't want to do that.
So yeah, any full examples that do what I want? Or could somebody more knowledgable write one up? :)
A lot of the examples are "oh, here's how you render 1 triangle". Well that's great, except nobody needs to render only 1 triangle/quad. And they need to be textured in addition to that!
An example that uses VBOs/VAOs/EBOs
ALSO: this means the code can't use glTexPointer and that stuff, but just in raw VBOs/VAOs...
I saw this question and decided to write a little program that does some "sprite" rendering using points and gl_PointSize. I'm not quite sure what you mean by "batching" as opposed to "instancing," but my program uses the glDrawArraysInstanced() call so that I can render multiple points without needing my VBO to be variable sized. My code also doesn't texture the sprites, but that's easy enough to add in (upload the active texture index (the one that was active during your call to glTexSubImage), to a GLSL sampler2D using glUniform1i).
Anyway, here's the program I wrote: http://litherum.blogspot.com/2013/02/sprites-in-opengl-programmable-pipeline.html Hope you can learn from it!
I wonder if there is any known algorithm/strategy to add some noise to a text string (for instance, adding a random sequence of characters every now and then or something similar).
I don't want to completely destroy the text just to make it slightly unusable. Also, I'm not interested in reversing back the changes, I can just recreate the original text from the sources I used to create it in the first place if needed.
Of course, a very basic algorithm for doing this could be easyly implemented but probably somebody has already created a somewhat sophisticated algorithm for this. If a Java implementation of something like this is available even better.
If you are using .Net and you need some random bytes maybe try the GetBytes method from the rngcryptoprovider. Nice n random. You could also use it to help in selection random positions to update.
Previously, when I've built tools, I've used D3D version 9, where the call to Present() can take a target window and rectangle, and you can thus draw from a single device into many different windows. This is great when using D3D to accelerate desktop applications, and/or building tools rather than games!
I've also built a game renderer with D3D11 before, which is also great, because the state management and threading interfaces are well designed, and you can even target D3D 9 level hardware that's still pretty common in the wild (as opposed to D3D 10, which can only target 10-and-better).
However, now I want to build a tool with D3D11. Unfortunately, the IDXGISwapChain that comes back from D3D11CreateDeviceAndSwapChain() seems to "remember" its HWND, and only wants to present to that window. This is highly inconvenient, because I may have a large number of windows that each need fairly simple graphics drawn to them, and only in response to a WM_PAINT (again, this is for a tool, not a game).
What I want to do is to save back buffer RAM. Specifically, I used to be able to create a single back buffer, the size of the desktop, that I knew could cover all rendering needs, and then that would be the single copy allocated. Even if there are 10 overlapping windows, they all render through the same back buffer, so there's no waste of memory beyond the initial allocation. I can create textures that are not swap chains, and use them as "render targets," but I can't find a good way of presenting to an arbitrary rectangle of an arbitrary client window, without reading back the bitmap and copying it into a DIBSection, which would be really inefficient. Also, there is no way to create many swap chains, and having them share the same back buffer.
The best I can do is to create one swap chain per window, and resize the back buffer of each swap chain to be really small, except when I render to the swap chain, at which point I resize it to match the window. However, this seems inefficient, because resizing the targets is not a "free" operation AFAICT. So, is there a better way?
The answer I ended up with was to create one back buffer per separate display area, and not size it to the back buffer. I imagine that, in a world where desktop composition and transparency can happy to "anything" behind my back, that's probably helpful to the system.
Learn to love the VVM system, I guess :-) (VVM for Virtual Video Memory)