Speeding up Rendering
BlitzMax Forums/OpenGL Module/Speeding up Rendering
| ||
| Hi there! I've been thinking about trying to speed up displaying stuff in a fashion similar on how Flash and Actionscript works but I am not sure if such feat is possible in both OpenGL and DirectX (or only one of these). So, if I understand correctly, that's how drawing images work in Max2D: DrawImage - Creates a new square (out of two polygons) with texture being the image, draws it to the window/port/whatever and kills the object. Flip - Throws the window/port/whatever to the user screen. Cls - Clears the buffor. Unless that's not how it works, the way I think it could be sped up would be by having each object creating its "display object" when being created and removing it when being destroyed. So, let's say I create a brick for an arcanoid and instead of having to call the DrawImage() in each step I would only have to do something like image=CreateImage(pic, x, y) and then, when killing the brick all I would have to do would be RemoveImage(image). That way we wouldn't have to create a new polygon for each call of DrawImage(). So... Is something like that possible and would it make the rendering faster? I hope my explanation is understandable :). |
| ||
| Every time you do a flip you have to re-draw all geometry. |
| ||
| that's just the way the Flash/Actionscript sprite engine works as seen by you but that doesn't translate to how it works under the hood. Opengl does have display lists but this won't help you for sprite type engine performance... mostly for static geometry and or large models. batching can help many situations but not all. In any case, BlitzMax already kills Flash's performance so I don't think there is much to learn from flash for performance. but there can be a lot to learn with how their engine is presented to the programmer... |
| ||
| Flash is actually a complex beast of code.. have a look at gameswf if you'd like to see the inner workings of an attempt to mimmic it. It uses all sorts of frame caching, vector algos, and so on.. so its not really similar to how bmax runs/renders. The performance of rendering, is a messy thing to try and determine since there are a huge amount of factors involved. But these days, most rendering is generally 'batch' limited anyway. There is a certain amount of time needed for the CPU to 'setup' the data that needs to be sent to the GPU on the Gfx card. This 'setup' time is the general killer in "how many different pretty things can be shown in a single frame", however, there is of course many different rendering techniques that can mitigate this issue, and depending on your application type, sometimes you can render in quite a different way: one example would be a side scroll shooter, rather than re-rendering the whole screen, you could composite say 3 or so layers (depending on your game) and buffer scroll them to move along the world. It becomes very much up to the technical game architect how this is best implemented. Another current method around CPU setup problems is to push rendering systems to the GPU and 'do it yourself' in shaders/CUDA/OpenCL type execution. This has great advantages, but also great disadvantages. On the plus side.. you can do almost whatever you want to do with the amazing rendering power on the GPU's these days (> 1teraflop of processing most often), but this limits your audience since there is alot less people with these cards as you may think :). For example.. over 30% of all PC's have Intel GMA based Gfx systems which are less than ideal for this sort of rendering. :) Basically.. there is a tun to learn on the rendering end of the pc (both 3D and 2D).. and theres no simple way to 'improve performance' without specifically looking at the app.. target audience.. target hw.. etc :) |
   |