| View previous topic :: View next topic |
| Author |
Message |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Wed Apr 12, 2006 9:16 am Post subject: Blitting Speed |
|
|
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? |
|
| Back to top |
|
 |
romero126
Joined: 24 Dec 2005 Posts: 200
|
Posted: Wed Apr 12, 2006 9:49 am Post subject: |
|
|
| Slow as hell, but great news!@# LUA player 0.19 is out. Check out the main page for more information |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Wed Apr 12, 2006 11:34 am Post subject: |
|
|
| 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 :) |
|
| Back to top |
|
 |
romero126
Joined: 24 Dec 2005 Posts: 200
|
Posted: Wed Apr 12, 2006 11:43 am Post subject: |
|
|
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: | -----------------------------------------------------------
-- Proof of concept for real animation on the LUA PLAYER --
time = os.clock()
CYCLES_PER_SEC = 0
screen:clear(Color.new(255,255,255))
screen.flip()
Color_Black = Color.new(0,0,0)
Color_White = Color.new(255,255,255)
CUR_Color = Color_Black
while true do
CYCLES_PER_SEC = CYCLES_PER_SEC + 1
CHECK_TIME = os.clock() - time
if (CHECK_TIME > .999) then
time = os.clock()
if (BKG) then
CUR_Color = Color_Black
BKG = nil;
--print("Elapsed Time: "..CHECK_TIME.." CPS: "..CYCLES_PER_SEC)
else
CUR_Color = Color_White
BKG = 1;
--print("Elapsed Time: "..CHECK_TIME.." CPS: "..CYCLES_PER_SEC)
end
CYCLES_PER_SEC = 0
screen:fillRect(50, 50, 5, 15, CUR_Color)
screen.waitVblankStart();
screen.flip()
--screen.flip()
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 |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Wed Apr 12, 2006 11:52 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
romero126
Joined: 24 Dec 2005 Posts: 200
|
Posted: Wed Apr 12, 2006 11:57 am Post subject: |
|
|
| no its the blitting.. trust me.. its slow |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Wed Apr 12, 2006 12:00 pm Post subject: |
|
|
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 :) |
|
| Back to top |
|
 |
romero126
Joined: 24 Dec 2005 Posts: 200
|
Posted: Wed Apr 12, 2006 12:31 pm Post subject: |
|
|
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 |
|
| Back to top |
|
 |
Shine
Joined: 03 Dec 2004 Posts: 728 Location: Germany
|
Posted: Wed Apr 12, 2006 3:15 pm Post subject: |
|
|
| 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: | -----------------------------------------------------------
-- Proof of concept for real animation on the LUA PLAYER --
time = os.clock()
CYCLES_PER_SEC = 0
screen:clear(Color.new(255,255,255))
screen.flip()
Color_Black = Color.new(0,0,0)
Color_White = Color.new(255,255,255)
CUR_Color = Color_Black
while true do
CYCLES_PER_SEC = CYCLES_PER_SEC + 1
CHECK_TIME = os.clock() - time
if (CHECK_TIME > .999) then
time = os.clock()
if (BKG) then
CUR_Color = Color_Black
BKG = nil;
--print("Elapsed Time: "..CHECK_TIME.." CPS: "..CYCLES_PER_SEC)
else
CUR_Color = Color_White
BKG = 1;
--print("Elapsed Time: "..CHECK_TIME.." CPS: "..CYCLES_PER_SEC)
end
CYCLES_PER_SEC = 0
screen:fillRect(50, 50, 5, 15, CUR_Color)
screen.waitVblankStart();
screen.flip()
--screen.flip()
end
end |
|
When testing "blitting" speed, you should use the "blit" function :-)
fillRect is slow. |
|
| Back to top |
|
 |
LuMo
Joined: 21 Aug 2005 Posts: 410 Location: Austria
|
Posted: Wed Apr 12, 2006 6:43 pm Post subject: |
|
|
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 _________________ "Good artists copy, great artists steal."
Pablo Picasso
go2lumo.com |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Wed Apr 12, 2006 10:30 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
 |
LuMo
Joined: 21 Aug 2005 Posts: 410 Location: Austria
|
Posted: Wed Apr 12, 2006 10:35 pm Post subject: |
|
|
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 _________________ "Good artists copy, great artists steal."
Pablo Picasso
go2lumo.com |
|
| Back to top |
|
 |
daurnimator

Joined: 11 Dec 2005 Posts: 38 Location: melbourne, australia
|
Posted: Wed Apr 12, 2006 11:06 pm Post subject: |
|
|
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 |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Wed Apr 12, 2006 11:18 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
LuMo
Joined: 21 Aug 2005 Posts: 410 Location: Austria
|
Posted: Wed Apr 12, 2006 11:24 pm Post subject: |
|
|
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) _________________ "Good artists copy, great artists steal."
Pablo Picasso
go2lumo.com |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Thu Apr 13, 2006 12:06 am Post subject: |
|
|
| 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 ? |
|
| Back to top |
|
 |
LuMo
Joined: 21 Aug 2005 Posts: 410 Location: Austria
|
Posted: Thu Apr 13, 2006 12:13 am Post subject: |
|
|
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 _________________ "Good artists copy, great artists steal."
Pablo Picasso
go2lumo.com |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Thu Apr 13, 2006 4:52 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
 |
LuMo
Joined: 21 Aug 2005 Posts: 410 Location: Austria
|
Posted: Thu Apr 13, 2006 7:09 am Post subject: |
|
|
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 _________________ "Good artists copy, great artists steal."
Pablo Picasso
go2lumo.com |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Thu Apr 13, 2006 7:58 am Post subject: |
|
|
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 |
|
| Back to top |
|
 |
LuMo
Joined: 21 Aug 2005 Posts: 410 Location: Austria
|
Posted: Thu Apr 13, 2006 8:03 am Post subject: |
|
|
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 _________________ "Good artists copy, great artists steal."
Pablo Picasso
go2lumo.com |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Thu Apr 13, 2006 10:32 am Post subject: |
|
|
| 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!
Last edited by Giuliano on Thu Apr 13, 2006 11:59 am; edited 1 time in total |
|
| Back to top |
|
 |
DiabloTerrorGF
Joined: 15 Jul 2005 Posts: 64
|
Posted: Thu Apr 13, 2006 11:24 am Post subject: |
|
|
| Why are you loading so many big images? |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Thu Apr 13, 2006 11:26 am Post subject: |
|
|
| 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 ? |
|
| Back to top |
|
 |
DiabloTerrorGF
Joined: 15 Jul 2005 Posts: 64
|
Posted: Thu Apr 13, 2006 12:04 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Thu Apr 13, 2006 12:09 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
 |
DiabloTerrorGF
Joined: 15 Jul 2005 Posts: 64
|
Posted: Thu Apr 13, 2006 12:26 pm Post subject: |
|
|
| Is blitting to the screen slow or to an image? I always blit to am image then to the screen... seems faster to me... |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Thu Apr 13, 2006 12:28 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
 |
DiabloTerrorGF
Joined: 15 Jul 2005 Posts: 64
|
Posted: Thu Apr 13, 2006 12:40 pm Post subject: |
|
|
| Dont you flip before you vblank? I guess it doesn't really matter though. |
|
| Back to top |
|
 |
Giuliano
Joined: 13 Sep 2005 Posts: 78
|
Posted: Thu Apr 13, 2006 12:49 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
 |
|