Most Efficient Sprites Question

[NakedApe]

As I continue to have fun writing 2D games with lots of action, Asteroid-esque space stuff, I'm wondering:

What's the most efficient / fastest approach to moving arrays of objects around the screen in QB64PE?

A. Programatically generated images on the fly for fairly simple things?
B. Manipulating strings with DRAW commands, VARPTR$...?
C. Using small images, say 40x40, with _PUTIMAGE commands, _ROTATEIMAGE ()...?


Thanks, and have a great weekend, everybody.

[NakedApe]

As I continue to have fun writing 2D games with lots of action, Asteroid-esque space stuff, I'm wondering:

What's the most efficient / fastest approach to moving arrays of objects around the screen in QB64PE?

A. Programatically generated images on the fly for fairly simple things?
B. Manipulating strings with DRAW commands, VARPTR$...?
C. Using small images, say 40x40, with _PUTIMAGE commands, _ROTATEIMAGE ()...?


Thanks, and have a great weekend, everybody.

Now that I think about it, we already discussed this a few months ago. Turning objects into hardware images is fastest of all, sharing the graphic load with the GPU, but what's the next fastest?

[TerryRitchie]

As I continue to have fun writing 2D games with lots of action, Asteroid-esque space stuff, I'm wondering:

What's the most efficient / fastest approach to moving arrays of objects around the screen in QB64PE?

A. Programatically generated images on the fly for fairly simple things?
B. Manipulating strings with DRAW commands, VARPTR$...?
C. Using small images, say 40x40, with _PUTIMAGE commands, _ROTATEIMAGE ()...?


Thanks, and have a great weekend, everybody.

Using _PUTIMAGE with a pre-made sprite sheet is the way to go.

If your image(s) need to rotate then having them pre-rotated on the sprite sheet will help too. Remember that by using _PUTIMAGE you only need to draw your sprites facing in one quadrant on the sprite sheet. You can then use _PUTIMAGE to flip each sprite vertically, horizontally, or both to cover the other three quadrants.

A rotozoom function is handy but is very costly when dealing with many moving sprites on the screen.

[bplus]

The advantage of drawing each asteroid or chunk of one is that every one can virtually be unique (and no Rotozoom needed but remember the trick to randomize with a seed number) whereas you are a little more limited with images. This is why I chose drawing asteroids as opposed to rotozooming images.
https://qb64phoenix.com/forum/showthread.php?tid=508

[NakedApe]

The advantage of drawing each asteroid or chunk of one is that every one can virtually be unique (and no Rotozoom needed but remember the trick to randomize with a seed number) whereas you are a little more limited with images. This is why I chose drawing asteroids as opposed to rotozooming images.
https://qb64phoenix.com/forum/showthread.php?tid=508

Your game runs on my Mac, but I can't get the ship to move, b+. Much of the code is commented out too. It looks like the UP arrow or K key should make the ship move, but no luck for me. The splash screen instructions also don't mention the thrust key fyi. 

Thanks for the feedback, guys!

[bplus]

Arrows are way, way, way too slow its basically ALL mouse moving, use left mouse button to shoot left and right mouse button to shoot right. More points (and color) when you get ships or bombs. Yeah opening screen is all wrong for that version, sorry.

There is or was a space warp jump when desparate to get out of dodge forgot which... nope that doesn't work either, for me more fun just moving mouse, playing dodge ball with rocks.

I can post earlier versions with all keys working but this was most fun for me. I didn't like having to look away to find a key.

[NakedApe]

Ahh, I see. I like your version a lot. Thanks for the insights!

[Cobalt]

One thing to keep in mind if you need to flip or change the size of your sprites it will really start to slow down your program doing it with _PUTIMAGE. IF possible you should have them already at the size and rotation you need or use _PUTIMAGE to do all that work to a _NEWIMAGE when your game first starts up to avoid any possible slow down while running.

[SMcNeill]

It's all just a matter of doing the least possible amount of work inside a loop.

Put this sprite here.  One command, rather simple.
Put this sprite here, but make it 10% taller.   A little more complex and slower.
Put it here, 10% taller, 22% wider.  Even more junk to do.
Put it here, 10% taller, 22% wider, at 212 degrees rotation.   Now the CPU is starting to sweat a little...

Oh, and do this for all 60000 parts which I have on the screen -- even if 90% of them haven't changed shape or position at all!!

....  and this, my friends, is how you make your computer imitate an airplane with the fans inside it's enclosure.   VVVVVVVRRRRRRRRRRRRRRRRRRRRRRRRRRRUUUUHHHHHHHRRRRRRRRRRRRRRRR!!!!!!!!!!!

[bplus]

ME: "Yeah opening screen is all wrong for that version, sorry."

No it's not, it's correct. The arrow keys will spin shooter left and right according to arrow.
p will pause action, p again restarts
left mouse shoots left, right mouse shoots right, moving mouse moves ship

   

PS if the app doesn't immediately open in Full Screen comment out the _ScreenMove line because it delays FULL SCREEN in my QB64pe v 3.10 sometimes.

Yes the code has most or all the keypress stuff commented out. I think you could revive all that and find out the action is too fast to keep up with key presses. You can't look away for a fraction of second. The first thing to go was the spacebar for shooting, you'd wear it out in one game!