Blitting Speed

Giuliano · Post by **Giuliano** » Wed Apr 12, 2006 9:16 am

Hello

I haven't done any dev'in in Lua since a few versions ago and I was wondering how the blitting speed has changed.

I plan on making a side-scroller engine but there might be a lot of objects on the screen and I wish for it to run at a good frame rate. I thought about pre-rendering the levels but that might mean pre-rendering probably over 40 images 512x512 and I am not sure how Lua/PSP would handle that. Anyone have any advices?

romero126 · Post by **romero126** » Wed Apr 12, 2006 9:49 am

Slow as hell, but great news!@# LUA player 0.19 is out. Check out the main page for more information

Giuliano · Post by **Giuliano** » Wed Apr 12, 2006 11:34 am

romero126 wrote:Slow as hell, but great news!@# LUA player 0.19 is out. Check out the main page for more information

err that was as helpful as a hemroid.. anyone can give some insight ? I can make it fast through trial and error but I rather get input from you guys as to the best way to do it and skip the debugging time :)

romero126 · Post by **romero126** » Wed Apr 12, 2006 11:43 am

sadly the more blits you do.. the slower the game becomes..

So i suggest.. no blitting

Use 0.19 its module based.. which means you can code in c# and have a polished engine for blitting.

The more blits per frame you do the slower your fps becomes...

For more information on this check out this sad sad demo.

Code: Select all

-----------------------------------------------------------
-- Proof of concept for real animation on the LUA PLAYER --

time = os.clock&#40;&#41;
CYCLES_PER_SEC = 0
screen&#58;clear&#40;Color.new&#40;255,255,255&#41;&#41;
screen.flip&#40;&#41;

Color_Black = Color.new&#40;0,0,0&#41;
Color_White = Color.new&#40;255,255,255&#41;
CUR_Color = Color_Black
while true do
    CYCLES_PER_SEC = CYCLES_PER_SEC + 1
    CHECK_TIME = os.clock&#40;&#41; - time
    if &#40;CHECK_TIME > .999&#41; then
        time = os.clock&#40;&#41;
        if &#40;BKG&#41; then
            CUR_Color = Color_Black
            BKG = nil;
            --print&#40;"Elapsed Time&#58; "..CHECK_TIME.."     CPS&#58; "..CYCLES_PER_SEC&#41;
        else
            CUR_Color = Color_White
            BKG = 1;
            --print&#40;"Elapsed Time&#58; "..CHECK_TIME.."     CPS&#58; "..CYCLES_PER_SEC&#41;
        end

        CYCLES_PER_SEC = 0
        screen&#58;fillRect&#40;50, 50, 5, 15, CUR_Color&#41;
        screen.waitVblankStart&#40;&#41;;
        screen.flip&#40;&#41;
        --screen.flip&#40;&#41; 
    end
end

Cycles Per second is how many times it goes arround per loop.
Its in print.. so to find it out try blitting it.. or something i dunno GL

Giuliano · Post by **Giuliano** » Wed Apr 12, 2006 11:52 am

well the slow part of blitting is the overhead not the actual blitting itself. I don't have much time to code for the PSP so I don't have time to write my own graphics engine. It is possible to do it with LUA if you do it the right way and pre-render the correct amount of graphics, etc... but I wonder how many images can you pre-render before it starts to hinder the game speed.

romero126 · Post by **romero126** » Wed Apr 12, 2006 11:57 am

no its the blitting.. trust me.. its slow

Giuliano · Post by **Giuliano** » Wed Apr 12, 2006 12:00 pm

No it's not. Do this test: blit a screen of tiles and then pre-render and blit the image. You will see that when you blit the large image, it's fast. Look at the isometric engine I posted, it's actually very fast.

If someone does make a graphics library I'd be more than happy to test it out if it's got a complete amount of functions :)

romero126 · Post by **romero126** » Wed Apr 12, 2006 12:31 pm

did that .. checked the cycles.. was getting about 14.. not including overhead.. thats also done on a multi threaded process tree..

:-) blitting is too slow GL

Shine · Post by **Shine** » Wed Apr 12, 2006 3:15 pm

romero126 wrote:sadly the more blits you do.. the slower the game becomes..

So i suggest.. no blitting

Blitting is fast enough for full 60 fps in Lua Player.

romero126 wrote:

Code: Select all

-----------------------------------------------------------
-- Proof of concept for real animation on the LUA PLAYER --

time = os.clock&#40;&#41;
CYCLES_PER_SEC = 0
screen&#58;clear&#40;Color.new&#40;255,255,255&#41;&#41;
screen.flip&#40;&#41;

Color_Black = Color.new&#40;0,0,0&#41;
Color_White = Color.new&#40;255,255,255&#41;
CUR_Color = Color_Black
while true do
    CYCLES_PER_SEC = CYCLES_PER_SEC + 1
    CHECK_TIME = os.clock&#40;&#41; - time
    if &#40;CHECK_TIME > .999&#41; then
        time = os.clock&#40;&#41;
        if &#40;BKG&#41; then
            CUR_Color = Color_Black
            BKG = nil;
            --print&#40;"Elapsed Time&#58; "..CHECK_TIME.."     CPS&#58; "..CYCLES_PER_SEC&#41;
        else
            CUR_Color = Color_White
            BKG = 1;
            --print&#40;"Elapsed Time&#58; "..CHECK_TIME.."     CPS&#58; "..CYCLES_PER_SEC&#41;
        end

        CYCLES_PER_SEC = 0
        screen&#58;fillRect&#40;50, 50, 5, 15, CUR_Color&#41;
        screen.waitVblankStart&#40;&#41;;
        screen.flip&#40;&#41;
        --screen.flip&#40;&#41; 
    end
end

When testing "blitting" speed, you should use the "blit" function :-)
fillRect is slow.

LuMo · Post by **LuMo** » Wed Apr 12, 2006 6:43 pm

i am for sure that blitting is fast enough
as i was blitting very much at my bomberman game (although it was on old luaplayer 16-bit)
so you just need to "optimize" your blitting code

means:
(1) do not blit stuff that is not on screen
(2) do not blit stuff that does not change (store your non-changing stuff in an image)
(3) blit over (2) to get a new image if possible rather than reblitting the whole stuff [better blit a small background again and blit the new item over instead of reblitting like 80 sprites and add the new one...]

this might take some tricky calculations but its worth

a guy posted once luaplayer is too slow to do a sidescrolling helicopter game...
had a look at his code, rewrote some parts and... it was smooth as hell
;)
greets and good luck from me :D

Giuliano · Post by **Giuliano** » Wed Apr 12, 2006 10:30 pm

LuMo wrote:i am for sure that blitting is fast enough
as i was blitting very much at my bomberman game (although it was on old luaplayer 16-bit)
so you just need to "optimize" your blitting code

means:
(1) do not blit stuff that is not on screen
(2) do not blit stuff that does not change (store your non-changing stuff in an image)
(3) blit over (2) to get a new image if possible rather than reblitting the whole stuff [better blit a small background again and blit the new item over instead of reblitting like 80 sprites and add the new one...]

this might take some tricky calculations but its worth

a guy posted once luaplayer is too slow to do a sidescrolling helicopter game...
had a look at his code, rewrote some parts and... it was smooth as hell
;)
greets and good luck from me :D

hey Lumo nice to see you're still here. I was here a few months ago. About how many sprites did you blit every parse? Also, what's the memory on the PSP? Will having 30-40 512x512 images pre-rendered take up too much memory?

LuMo · Post by **LuMo** » Wed Apr 12, 2006 10:35 pm

2mb vram
32mb ram
blitting 512x512 images is evil.
i blitted like 120 tiles á 8x8px to prepare the background
then about 40 images i guess (not sure) possibly more

ps: i do not think all images will fit, think about memory management -> load when needed

daurnimator · Post by **daurnimator** » Wed Apr 12, 2006 11:06 pm

xtecticx (with his rpg) was finding that after about 19 images, you ran out of ram.

gotta keep it optimized.

just code smartly, and your code will work

Giuliano · Post by **Giuliano** » Wed Apr 12, 2006 11:18 pm

well I wanted to pre-render the static sprites of a level (ie: floors, walls, etc..) but since a side scroller has a lengthy level it would end up being about 20-30 images.. I have barely started on the project so I will do some tests and do a pre-render on the fly as you move through the levels so it only keeps x amount of images in the buffer.

LuMo · Post by **LuMo** » Wed Apr 12, 2006 11:24 pm

well i tried with 3 images whereat only two were blitted (code can be found on my page) i optimized it to blit only the area shown on screen...
loading took about 3 seconds
if you try loading the images in background you might have solved your probs ;)

not sure if it will be smooth (while loading next pic)

Giuliano · Post by **Giuliano** » Thu Apr 13, 2006 12:06 am

LuMo wrote:well i tried with 3 images whereat only two were blitted (code can be found on my page) i optimized it to blit only the area shown on screen...
loading took about 3 seconds
if you try loading the images in background you might have solved your probs ;)

not sure if it will be smooth (while loading next pic)

well this is where the advantage and disadvantage comes in ..
the game will have basically 2 layers of sprites.. the background, which is a fixed image and does not need to be rendered. I simply load it when the level loads.

And then we have the layer with the walls, blocks, floors, etc... now I plan on having some animated blocks (like the ? blocks in mario)

so my idea is during Loading time
1) load in BG, sprites (will probably be contained in one image), and tileset
2) pre-render X amt of the layer with walls, blocks, etc... animated sprites such as the ? blocks and enemies will be drawn everytime it is necessary, hopefully I will be able to draw them at every frame and not have a problem

Then while the player is in the game.. as he moves through the level it will discard far away pre-render images and pre-render new ones.. if I do this correctly, it should work .. if there is lag during pre-render then I can split it up (ie: draw only X amt of blocks per cycle when pre-rendering a new image)

ONE more thing.. does sound take up a lot of CPU ?

LuMo · Post by **LuMo** » Thu Apr 13, 2006 12:13 am

i would split the game up into more layers (as i did it in bomberman)
which reduces some blits

layers:
player (saves some blits for fixing backgrounds)
background
non-animated level
animations in level (-> small animated areas)

when you blited all those layers merge em (4 large blits)

this speeded up my game a lot

greets
lumo

Giuliano · Post by **Giuliano** » Thu Apr 13, 2006 4:52 am

LuMo wrote:i would split the game up into more layers (as i did it in bomberman)
which reduces some blits

layers:
player (saves some blits for fixing backgrounds)
background
non-animated level
animations in level (-> small animated areas)

when you blited all those layers merge em (4 large blits)

this speeded up my game a lot

greets
lumo

Yes that's one of my plans but the bomberman game map is not nearly as large as a side-scroller is it ? That is why I was wondering about pre-rendering a lot of images

LuMo · Post by **LuMo** » Thu Apr 13, 2006 7:09 am

actually there is no difference
as you always render an image of 480x272
and if you remember the screenshot... i also had quite a lot of sprites

greets

Giuliano · Post by **Giuliano** » Thu Apr 13, 2006 7:58 am

Im actually thinking of not even using the entire PSP's screen because the sprites are all 16x16 and since I can not find an easy way to "zoom" or change the resolution I will just use a smaller section of the screen

Wouldnt it be faster to implement GL functions for 2d rendering though? seems better than blitting

LuMo · Post by **LuMo** » Thu Apr 13, 2006 8:03 am

i do not think its implemented in GL (pspgl or tinygl)
if it would be that simple, gl would be fully supported (and its 'only' basic)

if you want to use sprites i might help out with the sourcecode of my loader
possibly we find some bugs in it ;)
would save you a lot of time for sure

Giuliano · Post by **Giuliano** » Thu Apr 13, 2006 10:32 am

LuMo wrote:i do not think its implemented in GL (pspgl or tinygl)
if it would be that simple, gl would be fully supported (and its 'only' basic)

if you want to use sprites i might help out with the sourcecode of my loader
possibly we find some bugs in it ;)
would save you a lot of time for sure

What's the loader that you are making exactly for ?

Also I'm going to make custom objects for sprites.. I have barely started to work on the engine and the sprites will probably come last.. It will be more flexible if the player is it's own object and then each monster has it's own object class with their defined behaviors

(EDIT) Okay, small problem. I just did a small test and after loading about 10 512x512 images it crashes the PSP. That seems a bit too small to even do too much pre-rendering, considering that I will have to load in the tileset, characters, and bg, that only leaves about 7 more full images to pre-render. Eek!

DiabloTerrorGF · Post by **DiabloTerrorGF** » Thu Apr 13, 2006 11:24 am

Why are you loading so many big images?

Giuliano · Post by **Giuliano** » Thu Apr 13, 2006 11:26 am

DiabloTerrorGF wrote:Why are you loading so many big images?

Testing ram .. and I wanted to pre-render as much as I could since blitting is quite slow.. the level is going to be over 4k pixels wide though .. I'm not going to preload the whole thing of course but 10 512x512 are really not that much .. the psp screen is not too far from that size

I did a blitting test and after 23 or so blits (not very big ones either) there was a significant decrease in FPS. It's definitely possible to do a nice side scroller with LUA but these limits are a huge set back as far as blitting goes. There are faster libraries out there would it really be that difficult to implement it into LUA ?

DiabloTerrorGF · Post by **DiabloTerrorGF** » Thu Apr 13, 2006 12:04 pm

MMmmm, how about only storing 5 backgrounds at once and then loading 2 or 3 ahead? You will get a FPS drop while it's loading but better than no RAM or constant FPS slowness...

Giuliano · Post by **Giuliano** » Thu Apr 13, 2006 12:09 pm

DiabloTerrorGF wrote:MMmmm, how about only storing 5 backgrounds at once and then loading 2 or 3 ahead? You will get a FPS drop while it's loading but better than no RAM or constant FPS slowness...

that's what I had planned but I get FPS drop after 20 something blits.. that means that if I blit a few backgrounds + player I can only blit a few animated tiles + enemies.. that will really decrease the fun of the game

DiabloTerrorGF · Post by **DiabloTerrorGF** » Thu Apr 13, 2006 12:26 pm

Is blitting to the screen slow or to an image? I always blit to am image then to the screen... seems faster to me...

Giuliano · Post by **Giuliano** » Thu Apr 13, 2006 12:28 pm

DiabloTerrorGF wrote:Is blitting to the screen slow or to an image? I always blit to am image then to the screen... seems faster to me...

Blit to screen, waitforvblank, flip .. I think it may be something with my PSP or the latest LUA version .. I tested LuMo's Bomberman (the version on his website) and the intro + game ran very slowly when only blitting a few images

DiabloTerrorGF · Post by **DiabloTerrorGF** » Thu Apr 13, 2006 12:40 pm

Dont you flip before you vblank? I guess it doesn't really matter though.

Giuliano · Post by **Giuliano** » Thu Apr 13, 2006 12:49 pm

DiabloTerrorGF wrote:Dont you flip before you vblank? I guess it doesn't really matter though.

I flip after.. the vblank is what you wait for to know it's okay to flip w/o flicker.. but that shouldnt make a speed diff.. I can show my code if anyone is interested but all I really did for my blit test was a basic blit to the screen X amt of times