Polyvector instead of Usescreen

Previous topic - Next topic

MrPlow

Hi,

Is the polyvector method for screen scaling difficult ?
Can be used to simply replace the stretchsprite / usescreen method?

thks
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

Wampus

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.

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.

MrPlow

Thanks Wampus...that all sounds very good!

Might need to look at polyvector soon
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

Ian Price

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 came. I saw. I played.

MrPlow

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.
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

fuzzy70

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
"Why don't you just make ten louder and make ten be the top number and make that a little louder?"
- "These go to eleven."

This Is Spinal Tap (1984)

spacefractal

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.
Genius.Greedy Mouse - Karma Miwa - Spot Race - CatchOut - PowerUp Elevation - The beagle Jam - Cave Heroes 2023 - https://spacefractal.itch.io/

fuzzy70

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
"Why don't you just make ten louder and make ten be the top number and make that a little louder?"
- "These go to eleven."

This Is Spinal Tap (1984)

MrPlow

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.

Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

kanonet

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.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

fuzzy70

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
"Why don't you just make ten louder and make ten be the top number and make that a little louder?"
- "These go to eleven."

This Is Spinal Tap (1984)

MrPlow

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..
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

fuzzy70

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
Code (glbasic) Select

//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
"Why don't you just make ten louder and make ten be the top number and make that a little louder?"
- "These go to eleven."

This Is Spinal Tap (1984)

MrPlow

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?!
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

fuzzy70

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
"Why don't you just make ten louder and make ten be the top number and make that a little louder?"
- "These go to eleven."

This Is Spinal Tap (1984)