Hi,
Is the polyvector method for screen scaling difficult ?
Can be used to simply replace the stretchsprite / usescreen method?
thks
Yes, its a little difficult but its worth it.
It takes some work to accustomed to and is more complicated than the super-easy sprite commands in GLB. However, once you get used to it you'll probably do everything using polyvectors. If you're drawing a lot of sprites it can be faster than sprite commands in GLB because you will tend to use the same texture to draw multiple sprites in the same draw call.
It can be used to replace the stretchsprite / usescreen method. I'm not sure how much faster or slower it is without making a test program but it looks better.
There are examples of how people have made screen scaling here on the forum, like Z-Project (http://www.glbasic.com/forum/index.php?topic=7145.0).
You may want to get your hands on a texture packer and write your own importing routine to speed things along. I use a commercial texture packer and wrote a little proggy to import the sprites into GLB by generating code to name the sprites I can paste straight into my apps. Its very quick that way.
Thanks Wampus...that all sounds very good!
Might need to look at polyvector soon
Be aware - you still need to use a screen as a base to create the scaled POLYVECTOR. Switching between virtual screens and the main screen can reduce the efficiency of using POLYVECTORs (or stretched sprites) and have a negative effect on the speed of the game. It's not always a WIN-WIN with polyvectors. The more devices you can test on the better the estimation of speed benefits. Try using stretched sprites as well (on the same machine) to give more accurate results between the two.
I had it in my head that the solution was simple and I could use setscreen to change the android device down to lower res - but i was wrong...it only takes up the portion as defined.
My nexus is a big sluggish with the high res defaults..but for my game to flow with smooth movement at FPS 60 I would ideally like to change the nexus display to use less pixels - like the way setscreen works on PC...
Thats not possible i suppose?
Maybe I will look into pre-stretching the sprites and working with the devices res without scaling with Usescreen...
I think I have ran out of optimising alternatives...although the game will prob run better on the older gen nexus due to lower res usage...doesnt make sense really....higher res - slower perf...and they call that an improvement...my eyes cant tell the diff at such sharp densities.
60 FPS is not always required in some ways.
For example films at the cinema are 24 FPS as are nearly all bluerays (just slightly under @ 23.976) & they are smooth.
I have played games at 30FPS & tbh can't really tell the difference if done right, in fact the human eye/brain processes images at around 15 FPS. If there is a lot going on & your looking at the whole image & not focused on say 1 small object moving about you wouldn't notice any difference between 30 & 60 FPS.
60 is common in PC circles because vast majority of flat panels refresh at 60hz so 1 frame is done per refresh hence smooth movement. 30 FPS is exactly half & just means it skips every other frame, pick an odd one like 45 FPS & it has to skip every 3rd frame which is noticeable.
What the refresh rates are for mobiles/tablets I have no idea :D
Create a screen with quite a few moving objects at 30 FPS & I'll be surprised if it's jerky looking.
Lee
note. I deliberately skipped analogue TV rates of 50/60 as they are interlaced & a whole different ball game :D
Movies uses motion blur to hide the lower framerate, most games does not. There is highly different between 30 and 60fps on games. Not just on graphics, but also fells smoother due shorter input lately, the reaction time to accept input is shortere.
Howover when that is said my games was designed so it's can run in 30fps as well 60fps with various graphics settings.
Ps. On some amiga games enemies often ran 25fps, but main scrolling and speed was 50fps. Nice compromise.
Motion blur (other than an effect used in CGI parts to make it blend into footage) is technically a combination of shutter/filmspeed used in movies & something way beyond the scope of this post. You can create a 30FPS animation with software like Blender for example with no blur & its still smooth.
What I was implying with my post, & tbh I could have made it clearer, was just try updating the screen at 30FPS if it is lagging or unable to cope with 60FPS.
As stated by the author the Nexus with it's higher resolution was a bit sluggish which is common. Higher resolutions will always be slower than lower resolutions due to the extra amount of data being piped through the system.
Also mobile devices with inbuilt screens, be it a mobile/tablet or even consoles like PSP's & Gameboys etc tend to have their resolution tied to their respective screens unlike PC's where the users screen can be anything from 640x480 upwards. This problem used to affect old laptops (as well as old LCD monitors) as well in that if you set a 640x480 & your display was say 1024x768 native you would get a basically a 640x480 window at the screens native resolution in the middle of the screen surrounded by a black border.
Most laptops since then have something called "Zoomed Video" which basically stretches the screen to fill the display, which if I recall correctly is part of the display hardware & not the gfx chip (especially in the case of monitors).
If your program is running sluggish on the Nexus it could be down to numerous things like you are trying to draw to many things at once, or there is a bottleneck in your code somewhere & others.
Android is a PITA due to so many combinations of screen resolutions along with cpu's/gfx chips. Try what Ian suggested as in using stretched sprites & see if that makes an improvement. Also like Ian mentioned what works well on one device may not work as great on another. Other than that you could write a test that draws & moves a sprite then adds another one every loop & see how many it manages before the FPS drops below 60. Do the same with stretched sprites, polyvectors & even a combination of normal sprites then stretched by a single polyvector.
The above is flawed in that it obviously doesn't take into account your game code or logic but it will give you an idea of what works best on that system. Also if it manages say 800+ objects before the FPS drops & your game only draws 50-60 objects then you may need to have a look at your game logic as that may be the bottleneck & not the drawing.
Lee
Thanks for all the input on this...
I had been toying with the 30 FPS but reverted back due to other issues that appeared in the game logic (less iterations meant i needed to change a lot of values in the system - enemies reduced their attacks and such...)
I may go back to 30 FPS but think i might have a go with the stretched sprites option...
The 30 FPS still requires a modifier in the movement values to look as nifty as the 60 FPS verison...so not sure if its the ideal method yet.
You should code your gamelogic in such a way, that its independent from the FPS. Imagine you code it that it only works on 60 FPS but your users device is so slow that it runs at 30 FPS for him - and its no fun if your enemies move at half speed only etc. So your logic needs to be independent from FPS and should be able to handle both, lower and higher FPS then your preferred ones.
As kanonet said, game logic should be independent. FPS should be what the display updates at hence it's name, your game logic should move an object the same amount of distance in the same amount of time.
Try not to think of it as frames but rather distance/time. For example a ball has to move 100 pixels in 1 second & not 100 pixels in 60 frames.
Out of interest what type of game is it?
Lee
Its my Galaxians clone/variant...
The speed of movement is all fine and working okay...just I have some randomisation going on that seemed to be affected by number of gameloops...more game loops more chance something happening...dont see how to avoid that other than to customise based on loops / frames per second..
I'm a bit confused over the gameloops part & randomisation.
From what I can see from the last version of the game you posted the only randomisation I noticed is possibly the following
- The swooping aliens changing their path
- The speed which the main body of aliens move left or right
- If an alien swoops down or not
- If an alien shoots
The 1st one there is only 4-5 of them doing that at one time, so to me that's a simple boolean true/false in that "Do I change direction or not". If false carry on the same path else if true create a new path.
The 2nd one I thought there was some randomness in that the block seemed to change speed (stop/jump) while moving across screen but after having another look that only happens when you are firing, If you are stationary & not shooting then they move at a consistent speed.
The 3rd one is a boolean like the 1st in that swoop/don't swoop. I presume you are using something like MAXSWOOPINGALIENS=5 & possibly a random timer so the maximum number don't all swoop down at the same time.
The 4th is the same along the lines of shoot/don't shoot & might have a random timer on that as well.
So to me there is not a great number of randomness that could seriously effect game speed but that's just a quick observation & you may have more in your game code.
By game loops I presume you are talking about the different parts i.e
//Mainloop:
REPEAT
get_input()
update_positions()
check_collisions()
draw_screen()
// etc etc
UNTIL dead
One thing that can seriously effect performance on occasion is collision detection. When the player shoots are you calling a SPRCOLL() against every alien that's still active?. If so that's a lot of wasted time being used up.
Lee
My collision detection might do with some optimisation alright...but that is another story ;-)
The alien movement is the arcade "alien dodge" effect that was present in Galaxians - if your don't have a direct hit the aliens hesitate so you don't hit a back-rank one...(at least not easily)
And yes I have some random events like you said...I used the profiler and after so many secs I stopped the program ...
LIMITFPS 30
Gameloop ran 300 times (need to include a modifier for my randomness)
LIMITFPS 60
Gameloop ran 600 times...and in this case doesn't your randomness have a higher chance of executing?
I think my logic is correct?!
I'm still confused :D
Quote from: MrPlow on 2013-Dec-10
LIMITFPS 30
Gameloop ran 300 times (need to include a modifier for my randomness)
LIMITFPS 60
Gameloop ran 600 times...and in this case doesn't your randomness have a higher chance of executing?
If you had LIMITFPS at 30 or 60 then the gameloop will run at 30 or 60 times, I cant see where you have got the 10x from
Lee
I think we are confusing visual speed differences with CPU cycles....
Think of the 300 and 600 values as CPU run cycles (not FPS/loops)
LIMITFPS 30 can run the loop 300 times in 10 secs (as example...)
LIMITFPS 60 can run the loop 600 times in 10 secs
So my RND(x) = y will occur more frequently in the LIMITFPS 60 unless I modify to allow for the extra cycles/loops.
So FPS 60 doubles the run rate in this case...no?
Try it urself with profiler ...
Well that's obvious, but there was no mention on 10 seconds before so you can see why I was confused lol.
Running your loops more frequently than drawing is a simple case of drawing every other loop, but I think your loops are the issue as basically you are drawing 40ish aliens, 1 player & a handful of bullets which is seriously very little.
My old pocketpc with a 400Mhz Xscale cpu & crappy gfx can draw more sprites than that & it's less powerful than any nexus, so to me that points to something wrong in the game logic.
Exactly how many random numbers are you generating per frame?
Lee
Sent from my C6603 using Tapatalk
No probs Fuzzy, sorry for the confusion...
Not a lot of randoms in code and i think (or hope!) my game loop is sorta okay ... but think my perf issue is down to stretchsprite and usescreen... plus I am doing a scanline effect on top of that
So looks like I have to stretch my sprites before running or live the current perf....Its not bad now and 30FPS not slick as PC but still good for nexus ... and hopefully for other devices too...
;-)
Prestretching the sprites at startup could be a good solution for machines that are not that powerful & shouldn't take a lot of time do.
Having not really played with Android stuff before it may be possible to save the stretched sprites on the device on the 1st run so they are available every time the game is run. However you will have to ask a someone who knows more about file storage on Android about that & it definitely ain't me :D
Lee
Thought I'd just add a little of my experience with Polyvectors...
I'd originally ignored them - completely - and opted for the standard sprite functions within GLB. I also used CREATESCREEN/USESCREEN to draw to a fixed resolution and scale to the target device resolution.
The problem here is that create/use is SLOW on mobile devices. Big time slow. So, I calculated a scaling function and scaled sprites accordingly. Still very slow on some devices.
I then decided to invest some time into polyvectors, and oh my - was it worth it!
I now have a single startpoly and endpoly with everything plucked from a single texture atlas - including particles and fonts. The difference was incredible - from 20fps on a nexus 7 to a solid 60fps. Even on a lowly Galaxy Europa I was getting 50fps+ (from less than 5fps). Same code on OUYA is running 60fps too with bags of room to spare.
Granted, this is a tile based game with a single 2048x2048 texture atlas and sprites that don't need loads of detail, but there is a lot going on. Even having multiple texture atlases and a few start/endpoly routines will see a massive improvement.
It really is worth spending time investigating them and building up your own library of polyvector routines.
//Andy
In my case, a 428x240 core game scaled to whatever size and using the legacy commands (draw/anim/setscreen), full of random calls and objects, I get 60fps on the few devices I tried, including the caanoo. I learned transparencies can give a hit on performance here and there.
If your game has a core screen in low res, it should not slow down.
Polivectors still scapes me a little, a bit too complicated yet for me to handle.
polyvectors ran very bad on my pocket pc, I think Ian said they weren't to smart on the cannoo or Pandora (Can't remember which as know little about them).
Have heard good reports from other devices though & I use them quite a bit.
Lee
Sent from my C6603 using Tapatalk
Yep, I also believe Gernot said that drawsprite is extremely optimized for caanoo (maybe to pandora too?)
Within my tests, caanoo can´t handle much of transparencies or polyvectors unless you are an average to good coder(which is not me).
I wonder about older android or ios devices...maybe they work similar?
Mr.Plow, there must be something hogging your code, could it be the scanline fx? ...or maybe maps out of the 2x scale? (512/1024/2048)
Offscreen hogging too. On some iOS Devices im often see issues with colored polyvectors. So in my games it's a mixed bag what I uses (in karma Miwa all moving sprites is normal commands while files is polyvector example.
Howover polyvectors can't been used for html5 yet. So property it's more depend on the game what it's best.
In my games 30fps is the goal for ouya.