How to optimize for speed?

[jonza]

Hi!

I've been coding a platformer game in qbasic for the first time in something like 20 years. I used _LIMIT 60 for timing, but was suprised when commenting it out didn't speed up the game.

I have 4 800x480 32bit screens: invisible one for floor collisions, nicer looking one for the visible level and one for sprites, and one where I copy everything except the collision layer. Then there's the 1366x768 sized one where everything is shown. I use _PUTIMAGE to layer everything. After that I copy and resize a 320x180 sized rectangle from there and _PUTIMAGE it to my 1366x768 screen. I refresh the screen with _DISPLAY. I use point maybe 6-8 times a loop.

like:
if POINT (x,y)=_rgb32(0,0,0) then something=something+1

Is might just be my wasteful usage of _PUTIMAGE. Any other ideas?

Just seems weird that I made a lot faster platformers with my 386sx and QuickBasic 4.5, with some external libraries. Of course it was just 4 pages of screen 13, but anyway.... you know... my current computer is quite old, but it does run Fallout 3 on high :)

[bplus]

_LIMIT will only slow a program down if going too fast and this might be good running your code on faster machine.

You can check at what _LIMIT setting, _LIMIT does start to do something.

[SMcNeill]

POINT is pointlessly slow.  Use the _MEM commands instead.

DIM M AS _MEM
M = _MEMIMAGE(0) 'for the display screen

Then in your loop use the following instead of point:

IF _MEMGET(M, M.OFFSET + (X * 1366 + Y) * 4, _UNSIGNED LONG) = _RGB32(0,0,0) THEN something = something + 1

And to break that down for you:

M Is the memory block we want to get data from
M.OFFSET is where the screen data starts in memory.
X * 1366 + Y represents the pixel placement in memory.
*4 is because you're using 32 bit color screens.  There's one byte for each Red, Green, Blue, Alpha value.
_UNSIGNED LONG is how we tell MEMGET to return the 4 color values back to us all at once.

[bplus]

Is 1366 and this method the same for all OS?

[SMcNeill]

Is 1366 and this method the same for all OS?

PUTIMAGE it to my 1366x768...

  It's the width of the screen in question.  ;)

[Pete]

I would like to point out beside speed optimization, there could be problems that can arise with statements that are dependent on the size of the screen, especially if it's the device screen. When I change to different sized laptops, I have to redo all my _SCREENCLICK statements. I should come up with some function that detects screen size and an algorithm that can assign _SCREENCLICK values on a relative basis. Now if you are simply making a window with _NEWIMAGE  and it could be displayed on smaller screens, I suppose that is OK. I don't do graphics but this has me wondering if I did, wouldn't _NEWIMAGE set the pixels so if I put a program on a smaller display screen I would run the risk of the window being past the borders of the screen?

Maybe I'll start this a s a new topic and come back again to edit in the link...

OK, here is that new thread: https://www.qb64.org/forum/index.php?topic=823.0

Pete

[jonza]

POINT is pointlessly slow.  Use the _MEM commands instead.

DIM M AS _MEM
M = _MEMIMAGE(0) 'for the display screen

Then in your loop use the following instead of point:

IF _MEMGET(M, M.OFFSET + (X * 1366 + Y) * 4, _UNSIGNED LONG) = _RGB32(0,0,0) THEN something = something + 1

And to break that down for you:

M Is the memory block we want to get data from
M.OFFSET is where the screen data starts in memory.
X * 1366 + Y represents the pixel placement in memory.
*4 is because you're using 32 bit color screens.  There's one byte for each Red, Green, Blue, Alpha value.
_UNSIGNED LONG is how we tell MEMGET to return the 4 color values back to us all at once.

Thanks. I'll definitely do this. Actually I'm not reading anything from the screen, just displaying the game there, so the the screen hardware size should not matter. My layer count and level size is getting higher all the time(if I really implement all secondary stuff I want) so I't seems I might go 8-bit just to save ram.

It's going to be a Fallout 3 and Donald Trump inspired tragically comical post-apocalyptic sandboxed rpg platformer metroidvania game.

[Gets]

Is might just be my wasteful usage of _PUTIMAGE. Any other ideas?

Resizing images with PUTIMAGE is very slow if you're not using hardware acceleration. On a slow computer, just scaling the 320x180 image up to 1366x768 is more than enough to bring it well below 60fps. _MAPTRIANGLE is much better for that.

You should create a simple benchmark program to see what you can get away with graphically and maintain a decent framerate. Hardware graphics are much faster than software and switching to them will probably clear up any problems you have with speed. However, a lot of basic QB functions don't work with them.

[Cobalt]

Just a side note, using PUTIMAGE to resize is around 10.5x slower than just regular PUTIMAGE. you will loose a lot of speed there.
So you might think about remaking your graphics to fit the final screen size.