Polyvector instead of Usescreen

Previous topic - Next topic

MrPlow

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

fuzzy70

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

"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


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...

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

fuzzy70

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
"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)

fivesprites

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


erico

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.

fuzzy70

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

"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)

erico

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)

spacefractal

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