Discussion: Optimising code for speed in GLBasic

[Wampus]

In two to three days I will be into Beta testing my first game in GLBasic (so will need to purchase a full license!) It easily runs at optimum speed on my PC test platforms but I suspect portable devices might struggle because of the amount of layered 2D images on screen. Having options to turn down detail seems a good idea but that also got me thinking that my code was really messy and I should optimise it.

Do you have any tips for optimising code? What kind of commands or approaches do you know to be processor expensive compared to alternatives? Let's discuss.

I also have a specific question: Are GLOBAL variables inherently faster than creating LOCAL variables in Function calls? My game currently uses a lot of LOCALs and I'm thinking creating and releasing these variables may take up extra time.

[MrTAToad]

LOCAL variable would probably incur an extremely slight speed loss every time the function is called, however that should be offset against the memory used by GLOBAL.

The main thing is to keep graphics small; avoid rotating or scaling large numbers of sprites; use a routine to calculate movement speed independent of processor (or display) speed, and most importantly : efficient code.  If need be use C/C++ INLINE, but each command needs to do as much work as possible.

[Ian Price]

It easily runs at optimum speed on my PC test platforms but I suspect portable devices might struggle because of the amount of layered 2D images on screen.

You'd be surprised, actually.

My Shadow Of The Beast demo, can run at a constant speed over 60FPS on a Wiz and GP2X. Someone here stated that they had erratic FPS on their pcs - this is odd, seeing as the handhelds were rock solid (and so was my lappy). But it also goes to show you how shit pcs really are and how much variation there is between even similar specced machines.

As for rotating and scaling, my current WIP (which Gernot has seen and played) does a fair bit of both (a lot at certain points) without slowdown on Wiz (not tried on GP2X), so they can handle a lot more than you'd expect.

I can't speak for iPhone, as from what I've seen and read, it's performance is actually worse than Wiz, despite being technically more proficient. Go figure.

So what I'm really saying is - try it on your target handheld. It might hold up a lot better than you think, and if not, find the exact areas where optimisation is required. It's always good to get the most out of your code, but if you are just making work harder for yourself with little to no payback, then really, what's the point?

[Wampus]

MrTAToad calculating movement speed regardless of processor is an idea I hadn't considered. It wouldn't be much use on the project I'm working on right now but its something I might seriously have to consider later on.

Ian, the person who reported variable frame rate on the SOTB demo was me. The PC I was running it on had an 3.2GHz Pentium 4 processor and an old onboard 82910GL graphics chip. I got a steadier frame rate after installing alternative drivers but it was still below 60 fps. It runs even slower on my 1.6GHz Atom processor netbook. These are bad systems for sure! Could I ask to see your code for the SOTB demo? I'd be interested to see if there is any way to tweak it for faster running on my ancient PC or netbook or whether its just hardware limitation.

I now think I'm going to include variable detail in all games that I write so I can scale things up or down where necessary.

[Wampus]

Hey Ian, I was thinking there is no way the Wiz and the GP2X can run your Shadow of the Beast demo at 60 fps and my Pentium 4 and Atom netbook can't do it. That's just not right and yet it really does run at about 10-15 fps on my Atom. So what's going on?

Are you by any chance loading the graphics you want to display as layered parallax using something like LOADANIM "beastbackground.png", x, 1, 480 where each line of animation is only 1 pixel wide and then displaying each line of your images by calling DRAWANIM for each line? If you are, that's a problem (for PC compiled code). DRAWANIM seems to be a relatively expensive command to call.

For an example if you wanted to cover an 800 x 600 screen with sprites I've found it would be much much faster to cover the screen completely 32 times over each frame by drawing 64 alpha-blended 800 x 300 sprites that it would be to completely cover the screen just once by using DRAWANIM to draw 800 lines as sprites that were 300 pixels in length! That's an incredible difference and shows how expensive it is to call the DRAWANIM function

If you need me to attach a zip file with some example code I'll do that. I just wanted to check the problem was what I thought it might be before I do that.

[Ian Price]

Hey Ian, I was thinking there is no way the Wiz and the GP2X can run your Shadow of the Beast demo at 60 fps and my Pentium 4 and Atom netbook can't do it.

Well, all I can say is -

http://www.youtube.com/watch?v=58O59UIP73I

Crappy no sound vid from a real old camera, but it shows ME actually playing MY SOTB demo on MY Wiz and at pretty much 60FPS (the lowest it drops to is 57FPS).

Nope, I'm not showing only one line of imagery at a time. And no, I'm not sharing the source code at this point in time. I'm using standard drawing commands for everything. No tricks. No cheats. No inline stuff. All plain vanilla GLBasic. And my vid proves that your machine should be more than capable of running it.

If a Wiz can do this, why on earth can't your pc?

[Wampus]

Well, all I can say is -

...

If a Wiz can do this, why on earth can't your pc?

Heheh. I'm not sure, but I know that through my own experiments I've found that calling DRAWANIM and DRAWSPRITE has a huge CPU cost when GLBasic compiled for PC regardless of the size of the sprite. The more times you call these routines the slower the PC code will run. How big or small the sprites are is insignificant next to the cost of using DRAWANIM in the first place. Try covering a screen with 32 x 32 sprites compared to 320 x 320 sprites and you may see the same difference on the PC that I am. I may be wrong about this - it might be something to do with my WinXP PCs here - but I've already started to adjust my routines accordingly because I was using line by line rendering in places and now they run a lot faster.

I've got to go to work now but when I get in a few hours I'll write a Shadow of the Beast parallax scrolling demo using minimum DRAWSPRITE calls. I'm sure I can up the framerate to 60fps and far beyond even with many more layers of parallax. We'll see. I'll upload the demo and the code even if it doesn't work out.

[Ian Price]

The SOTB demo on my pc runs at hundreds of FPS, not just 60.

In other tests I've had hundreds of sprites (larger than 32xz32) on screen using the drawimage command (and Z ordering and scrolling at the same time) without a slowdown as significant as you are stating (<>15FPS). Maybe it's just down the graphics card, as my older WinXP pc isn't as powerful in CPU as your machine, but gives significantly better results.

But my case still stands - if a machine as underpowered as a Wiz can do this, your pc should have zero difficulty.

[Wampus]

Ian, your SOTB demo runs on my girlfriend's old Celeron laptop just fine - full fps as expected. She has the same standard Intel onboard graphics to me. However, I got the same fps drop on another Win XP computer I tested this morning. Weird.

What I am certain of is that calling DRAWSPRITE is very cpu expensive on my PCs regardless of how large the sprite is. I know this because if I use my girlfriend's laptop calling DRAWSPRITE is not at all expensive for small sprites - I can call it 800 times per frame without any slowdown whatsoever. On my PCs doing the same thing destroys my refresh rate with a vengeance. I don't know why this is happening because they don't behave oddly with other programs, just GLBasic compiled programs.

Anyway, there is definitely something about my PCs that means your demo runs very slowly. If it isn't the DRAWSPRITE problem then it is some other problem. I can't even make a guess what it would be without seeing your code but I have made a SOTB thingy myself to demonstrate that its possible to get something like you did working very fast on my underpowered Eee netbook. My SOTB thingy works with a great deal of cpu power to spare. I've included the code in the attached zip file so if you want you could take a look and see if there is anything obvious that points to why my demo works OK on my PCs and yours doesn't.

Edit: Sorry for not posting anything until today. I got carried away last night and ended up writing a little rehash of a SOTB song in Fruity Loops for my demo 



[attachment deleted by admin]

[Wampus]

That's a good tip Ocean. In this case my girlfriend's laptop has half the video memory, just 64mb, but now I've had a chance to look at my girlfriend's laptop in person it turns out it has a different chipset! She didn't actually check, she just assumed it was the same.

Incidentally, I've just discovered if I run any full screen GLBasic app on my girlfriend's laptop there is another problem. After the app closes the desktop icons and some menu/system/window icons are corrupted. Repairing or deleting the icon cache doesn't help (but a restart fixes it). I've updated the drivers but the problem remains.

This is a summary of what I've discovered:-

• Computers I've tested so far with Intel chipsets 82845G, 82915G and 945GSE are slow with DRAWSPRITE and can't run Ian's SOTB demo with full frame-rate (for whatever reason).
• A laptop with Intel chipset 82852/82855 doesn't have the same problem as above but corrupt icons occur after full-screen GLBasic apps have been run.

Could be OpenGL driver bug for Intel chipsets or could be something with GLBasic. I just don't know.

Ian, I know you don't want to release your demo code but if you could email it to me privately I promise not to let anyone have it. I just desperately want to discover what it is that makes it run slow on my Eee 901 netbook (and others). The DRAWSPRITE slowness by itself doesn't seem enough to explain what's happening.

[Moru]

Just a stupid question, did you actually update the Opengl drivers on your computers?

[Wampus]

OpenGL drivers come as part of the standard Intel graphics drivers for the chipsets I've been looking at, so yes. I've also made sure OpenGL settings are matched on each computer.

GF's laptop chipset is the Intel Extreme Graphics 2 variety.

I guess if anyone needs someone to test their apps work ok on old or under-powered PCs, I'm your man. 

[Ian Price]

TBH the only thing I'm doing really differently in my code is using scaling - the reason for this is that it was created with the WIZ in mind and showing a 320x240 screen on my laptop makes the image timy, so I scale it up. Maybe it's the scaling that is slowing things down for you, which would explain why it work on the WIZ. Dunno.

I've used two types of scaling for this at different points - grabbing the wole screen and using separate screens. Both are pretty much similar in performance on my laptop, where I've had well over 300FPS.

Of course I've got other things going on too - FPS counting, interaction with the beast and scoring (which strangely isn't displaying on the WIZ).

However, this was only every intended as a quick test and probably not going to take it further anytime soon, but there's something else I want to use similar code on at some point (for a completely different and original game).

[bigsofty]

Unfortunately as I sure you are aware of, Intel GFX chipsets are not great at OpenGL. An option would be to rescale all the graphics when the game is loading them in, then use a multiplier for all x,y co-ords. This would avoid the realtime re-scaling of such a large bitmap every frame.

[Ian Price]

TBH It wasn't intended for PC at all, so that's not going to happen with this, but something to think about for any future pc apps. I pretty much stick to handhelds now.