Fastest way to draw pixel based images, user resizing frame.

[Technicolour]

Hi Folks, I'm new here but have been tinkering with Love for a while now and so far I Love it

Anyway, I have a couple of questions that I hope you don't mind answering:

First off what would be the most efficient method of rendering an image from arbitrary pixel data on the fly while maintaining it persistently over frames. Would it be a frame-buffer and rendering points to it or making ImageData, that said how is ImageData stored? Are there any other methods I've missed?

Secondly is it possible to allow the user to resize the love window via things like maximise and rescaling via dragging the edge? If not is this a planned feature?

Thank you

[Taehl]

A framebuffer is probably what you want. Whatever you draw to it isn't cleared each frame, so you can just add the pixel changes to it and they'll stick.

You can't resize the window by dragging or with the maximize button, and I don't believe it's a planned feature (I think SDL and/or OpenGL aren't made to do that?). You can change the window to any size you want at any time with love.graphics.setMode. The following code should determine the maximum resolution the current monitor can support:

Code: Select all

local modes = love.graphics.getModes()
maxWidth, maxHeight = modes[1].width, modes[1].height

[knarF.se]

Just to add some minior value to the Subject, libSDL handles window resizing just fine -- it had problems toggling to/from fullscreen-mode before, but I believe that is very likely to be solved by now (Else, it is just a matter of shutting down the video thingie and start it up again at at different resolution and setting the fullscreen flag).

I'm quite new to Lua and LÖVE myself, but I've used libSDL since i stopped using Allegro (It is like the bare-bones versus everything under the sky, Allegro even has built-in GUI which is really simple to use. But I believe that it is just libSDL that provides threads of them both [which means that a dialouge-box in Allegro freezes the entire game, except for that darn box :-])

And now I hijack the tread with a closely related question, naughty me

I'm wondering myself what one can expect from the engine, I'd like to draw ~250 images each frame that are scaled, rotated, blurred and transparent, this would not change from frame to frame so it could possible be cached. But is that feasible? I mean the game I'm going to make is going to be quite fast-paced, and I'm not currently expecting that I'd design the levels in a such way so that the player would return to a view anytime soon (I'm not really used to design levels that way at all!). And all the ‘rotated-tiles’ would have their very own rotation-, scaling-, blurring- and alpha-factors (Oh, and yes - there should be dynamic lightning on some levels as well to enhance the player engagement and to get them into the mood I want them to be in for that particular level).

Also the game is expected to run on ~3-4yrs old laptops (Mine is about that age, and I have locked it @800Mhz for both cores due to stupid HP-related-heating-problems-that-fries-the-mother-board , GFX-card is running at full-speed however, no problems after BIOS-upgrade).

I'd probably gotten further by now if I'd not taken a detour to learn Lua and LÖVE, but I'm higly confident that the ROI for this is quite high!

[Taehl]

I'm wondering myself what one can expect from the engine, I'd like to draw ~250 images each frame that are scaled, rotated, blurred and transparent, this would not change from frame to frame so it could possible be cached. But is that feasible?

Sure. I'd recommend drawing all that to a framebuffer once when you load the level or something. Note that Love2D doesn't have any built-in way to blur images, so you'll probably need to make blurred versions of your graphics with a graphics editor.

[slime]

I'm wondering myself what one can expect from the engine, I'd like to draw ~250 images each frame that are scaled, rotated, blurred and transparent, this would not change from frame to frame so it could possible be cached. But is that feasible?

Sure. I'd recommend drawing all that to a framebuffer once when you load the level or something. Note that Love2D doesn't have any built-in way to blur images, so you'll probably need to make blurred versions of your graphics with a graphics editor.

I recommend a spritebatch over a framebuffer in this case.
When LÖVE 0.8.0 is released you'll be able to make a pixeleffect (shader) to do realtime blur on your stuff, if you want.

[knarF.se]

Sure. I'd recommend drawing all that to a framebuffer once when you load the level or something. Note that Love2D doesn't have any built-in way to blur images, so you'll probably need to make blurred versions of your graphics with a graphics editor.

Framebuffers sounds like a good Idea, but I'll probably need a few, as the levels are probably going to be a multitude times wider than the monitor. Pre-bluring in a graphics editor ain't really an option, as the particular blur level kinda needs to be set in the level editor. I was thinking of testing if my quite less technical skilled 11yr little sister could design levels that are playable by our 7yr little sister. If not, she failed . What I'm out to build is something like the level-editor in this video: Design Tour - Aquaria

I recommend a spritebatch over a framebuffer in this case.
When LÖVE 0.8.0 is released you'll be able to make a pixeleffect (shader) to do realtime blur on your stuff, if you want.

Wohoo, I löve shaders!

Okay,I know the words ‘sprite’ and ‘batch’ (.BAT / COMMAND.COM is Microsofts lame version of /usr/bin/sh )

So I can kinda guess what you mean, draw sprites in a batch onto a framebuffer, Am I correct?

[kraftman]

I cant quote you cos I'm not on my laptop, but just a few notes on different points.
as far as I am aware, you cannot redraw to a framebuffer in 0.72 without it being cleared first, using renderTo or setRenderTarget will clear the framebuffer.

if you're having heat issues with your laptop, removing the thermal pads used and replacing them with thermal paste can solve a lot of issues (I halved my temps by removing dust, switching to thermal paste and using a copper shim to bridge the gap between the gpu/CPU dies and heatsink.)

with a sprite batch, frequently drawn texture locations are stored on the gpu, which makes the draw operations much quicker.

getmodes doesn't return the resolutions in any order, so you would need to sort the list before assuming the first entry is the highest resolution.