2D - low framerate - what's the issue?
Blitz3D Forums/Blitz3D Programming/2D - low framerate - what's the issue?
| ||
| Hi, I tested my latest build on a mate's computer last night. The program works perfectly fine on my machine, but he is getting a framerate of roughly 1 frame per second. The program is a data editor for a football game, with a Graphical User Interface I've designed myself. Over time I've been tweaking the code to try and rectify the problem. At first, I assumed it was because I was using the Text command a lot for all text. I replaced this with bitmap fonts, which saw a little improvement. I then noticed I was using StringWidth to help me centre text on the x-axis, so I rewrote that to use pre-stored character widths. These two changes increased the frame rate five-fold, which was good (there's no difference on machine, which I believe is because it can handle the Text command properly). Spec-wise, my machine is Pentium IV 2.2GHz one with 356MB of RAM. His is 1.1GHz with 256MB. Both run XP. He's adamant that he's not running anything in the background. It's also worth pointing out that due to the size of the game data the editor works with, it uses up 100MB of RAM when running. In trying to find out the problem I wrote a section of code that produced a log file when he viewed a certain screen. This gave me the clock times for all actions when updating a "canvas" (which is an Image, used so that I can redraw sections that need redrawing and keep other things constant), and the screen (which consists of drawing all the necessary canvasses to the screen). The results of my log file were great - a few milliseconds it took to update an entire canvas, and less to update the screen. Ideal speeds. His were not so great. When updating the screen it first draws a background - which I'm going to ditch now as it's a bit of a waste, but where my machine takes less than a millisecond, his took 367. The background is an 800x600 bitmap - problem? Most canvases (five were drawn) took less than a millisecond, although one did manage to take 158. One of the quicker canvases is roughly 550x450, the canvas that took the longest is much larger - perhaps closer to the 800x600 of the background (and resolution). It certainly seems like image size is an issue here - could that be the case? Are there limits when using 2D drawing commands that are hardware related? Creating a canvas took roughly half a second - this consists of a lot of draw commands to create buttons, text, icons and so forth. Sadly, without the code beside me I can't see what elements are taking longest, but for certain they're taking longer than they should do. When creating a canvas, the program cycles through all the existing Obj (objects such as button, text, item list, graphics etc.) I have created, drawing the necessary ones. There are perhaps 1,000 of these objects, and they are cycled through many times in the loop, checking their "id" field to see if it's the correct one and then skipping on if not. It exits the loop when the correct one is found and dealt with, ignoring the remaining in the loop. I don't see this creating a problem - it's negligible on my machine. Easily tested on his though so I may give that a whirl. Finally, I'm upgrading to BlitzMax soon and want to port my code. I understand that BlitzMax's 2D capability is better, allowing for alpha, scaling, rotation and so forth in real time (hope I'm not wrong). Would it also be faster? And if so, is it worth my time trying to fix my mate's problem in the meantime or could a simple port be the solution? I think that unlikely, but I can hope. Sorry for the longwinded nature of the post and the lack of code - I don't have that to hand (I'm in work now) and it's a problem that's been bugging me for weeks, and I hope to eventually find the answer. His machine lies within my target specs so I do want to get it solved. |
| ||
| simple port be the solution *Chokes* I doubt that one to be honest Your UI.. is it 2d-in-3d? If not, turn it 3D. I found my editor killing the framerate so I made a 2d-in-3d UI and then wrote functions to wrap the current UI to it. the result is a constant 60fps rather than often 20-30fps :) |
| ||
| The UI is in 2D. I experimented with a 2D-in-3D UI but was getting awkward results when displaying text (using quads, similar to a bitmap font) as they were always poor looking, missing pixels and being difficult to read without getting a headache. It's still something to consider, I do still have my engine to drive that and a weekend's work would make the change. If the problem at the moment is definitely to do with the DrawImage command, the change will solve it. I do, however, wonder. |
| ||
| Its not difficult to get pixel perfect 2d-in-3d, but if you cant hack it, there are quite a few 2d-in-3d UI libshanging around here and blitzcoder.com. It will sort your problem. |
| ||
| Fingers crossed on that one. My 2D-in-3D is pixel perfect for everything except text, although some text sizes work perfectly. It's confusing me... |
| ||
| Good luck; With text; use bold if its not quite perfect. :) |
| ||
| check out jeppe nielsens 3d gui at blitzcoder.com |
| ||
| WHAT? I think you have the answer in your third paragraph - 256MB RAM? Tell your mate to get 256MB more of RAM - that WILL help. This will be especially true as your game uses 100 MB data! Lol! 256MB in an XP machine is ludicrous if you want to do anything else except look at the pretty desktop. Working with 256MB was only just acceptable in a Win '98 PC... With the price of RAM as low as it is, this shouldn't be too much trouble. The question I want to ask you guys is where on Earth is XP gonna sit if you have almost halve the available RAM used up in your game data? Blitz in not slow in the 2d department - don't let anyone tell you otherwise, let me tell you. I have a WIndow's '98 based Pentium II 350Mhz with a GeForce 2 GTS card (32MB RAM on board)with 256+128MB sticks of RAM and it loves Blitz stuff. If you were to compare it to other languages written specifically for only 2d stuff or C++ then ok, but relatively BlitzBasic and BlitzPlus and Blitz3d are fast, especially where data processing is involved. Looking at Cygnus's replies should also point the way a little. I also have a question - if this is strictly 2d why are you using Blitz3d when BlitzPlus is probably a better option and the gui is built in. IPete2. |
| ||
| Actually my original PC with winXP had 128mb and i had no issues with memory. Since SP1, it started crunching, and sp2 kills it... 512mb is a minimum these days...... XP can sit in the trash. i dont care :P |
| ||
| Cygnus, I'm surprised the PC came with only 128MB, but did you ever really work the pc in question graphically? 128MB is just about do able with XP but I'm surprised if you could actually do anything with the PC like load a program or a game for example - meaning the machine is pretty much useless for anything but the most mundane, simple tasks. 128MB on an XP PC is definately NOT recommended! - whoever sold it you wants 'shooting'. (not really I do not condone shooting! lol!) You may also have found that the more you filled the hard drive the more work the PC had to do to find programmes, move stuff from memory to empty hard drive space and back again etc., so the slower they get. A clean install is great to erradicate old registry obesity but extra RAM will always greatly improve the performance of the PC, especially if you are starting at 128/256 MB, believe me. And as I said in my previous post, if Fry Crayola is using just under half of the RAM on the PC (100MB) for just data, what room does XP have to manouvre - it will have to use the swapdisk continuously - very slow???? IPete2. |
| ||
| That could also be the problem. I was about to test it by lowering the amount of memory the editor set aside for itself (change a few numbers in the code, takes about a minute) but set it aside after I decided to produce logs. I can't just tell my mate to get more RAM though. It's a bit, you know, rude. :) What I do know is that it's unlikely now that I'll need (or manage to fill) what makes the game use 100MB. 50MB should be sufficient, and may see better results but I'm not completely sure. Got to be worth a test. In response to your final question - I'm using the 2D at the moment because it's easier to work with for what I'm doing, but I plan to include transparency and scaling which would require a 2D-in-3D engine anyhow. That, and I'm not au fait with how BlitzPlus does GUIs - is it possible to create a look other than the standard Windows one? If not, it's next to useless for the game itself. |
| ||
| If you have images bigger than the screen (or in some cases same size as the screen) you should chop them up. 2D-in-3D will only be slower than native 2D (on normal/most machines). Graphics memory could be a problem. Its not likely to be system memory that is the problem. |
| ||
| "Its not likely to be system memory that is the problem." @Beaker - it is if he's using 100MB and there's only 256 MB on board and he's using XP. @ Fry, Lol! Sorry man! :) I wasn't really suggesting he gets more ram in a serious way, I was just surprised you expected it to work well under those conditions. Don't test it on his machine and expect it to be as good as yours. GUI - Don't go the BlitzPlus way in that case, you could invest time or money in one of the available guis (Shawn Swifts is ace and very controllable but not free). BlitzMax will allow rotation and transparency natively so you may be best to wait for that, but I don't know what the minimum PC spec is for it. On the other hand you can do Mac and Linux versions of your proggie so that has to be a plus. Fry, you could extract some of your RAM and see how it works on your reduced RAM PC, don't do this if it's something you are not familiar with or don't feel safe doing...you could damage your PC. Definately don't do it it your PC is under any kind of warranty. IPete2. |
| ||
| Can i ask why your need 50 Mb of system memory? Just incase we can help ya chop that down :o) |
| ||
| IPete2: I guess I expected it to work half as slow because his computer is half as slow. Theoretically. Despite using computers all my life I know next to nothing about them besides programming. An oddity, that. BlitzMax is what I intend to use for the project, I'll be porting code over when the Windows version comes out, and I'll be tweaking my minimum specs to suit. I want to make a great game, but I have to expect that sales-wise I'm going to have to make concessions in some places. Then again, Mac compatibility opens up a whole new market. I can't extract RAM, it's a laptop and I daren't even try to open it up. Kinda stuck with it how it is. Ross C: The game's a football management title, the database for it contains 12,500 teams and 500,000 players (the 100MB version has twice those, naturally). I'm storing these by using Banks of memory, and accessing the bytes directly. Very compact. I need all those teams and players because the world's like that. Big. I'm going to get that 50MB version tested on his PC, I might get lucky. |
| ||
| You might like to look at some form of compression or indexing system for your teams and players to cut down on memory requirements. The BBC game Elite built whole universes by using a seed for random solar system/galaxy generation... fitted in 32kB from what I remember. e.g. if 1000 of your teams are called 'United' you could use a single character for that part of the name and save ~6000 bytes for a small trade off in time to decompress the name Manchester@ --> Manchester United = 11 bytes = 17 bytes Newcastle@ --> Newcastle United etc. You will need some space for your lookup tables, but apply this to player name's, etc. and there could be a tidy saving in RAM required |
| ||
| It would be useful to apply to teams, but given the varied names on offer there wouldn't be any significant saving. I've already applied it to names though, part of my original design. Without it, the 50MB size (which I think is impressive, given its contents) would be around 20MB larger. |
| ||
| I agree with Beaker. System memory is not likely to be the issue. If it were your mate's hard drive would be going bananas paging data in and out of ram, and you would get a slowish frame rate, but I don't believe you would get 1 FPS. Pure 2d is just hellish slow on a lot of modern driver versions. It seems to change with every driver release. Sometimes it's slow, sometimes not. Give one of the 3d gui's a try to see if it makes the difference. I'm betting it will because I found Filax's otherwise excellent BBGUI was slow as all heck ( it's all 2d ) while F-UI is lovely and speedy. |
| ||
| I'm starting to get a whole other problem with the code now - enough to seriously pee me off. Then, it is half past midnight here. A whole other thread is required for that, it's not really connected. |
| ||
| Don't want to hijack this thread but I have a quick, related question: My 2D game runs in 800x600 and uses an image of the same size. Will this really run dog slow on some machines? I don't see how chopping up the image will help things. I'm really quite worried to hear all 2D stuff runs really slowly on some machines. :/ |
| ||
| I think the idea behind it is that a large image takes up a lot of graphics memory at once and is a lot to deal with. Smaller sections don't. |
| ||
| I think i remember that blitz's 2d commands use GDI, the really old windows 2d stuff, so, yes, with modern drivers that dont really care about fast GDI support it'll be super slow. |
| ||
| OK, I'm getting more confused. :P I think the idea behind it is that a large image takes up a lot of graphics memory at once and is a lot to deal with. Smaller sections don't. But 2D images aren't stored in VRAM, are they? I think i remember that blitz's 2d commands use GDI, the really old windows 2d stuff, so, yes, with modern drivers that dont really care about fast GDI support it'll be super slow. GDI? I thought blitz does everything via DX. |
| ||
| I guess I really don't know how the 2D works, but that's the only logical explanation I can see for why some large images of mine work fast, and some slightly larger ones are dog slow. |
| ||
| Indeed, it would be nice to hear from someone in the know at BRL what the deal is with 2D (why's it sometimes so slow?), and why images of a certain size cause problems on some machines. |
   |