Problems Problems
BlitzPlus Forums/BlitzPlus Programming/Problems Problems
| ||
| G'day. My, it's been a while since I posted here... I'm involved in a pretty long-term project to create a graphic adventure using Blitz 2D, and I've recently come into a few problems. I've just recently changed from Win98 to WinXP, and my previously smoothly running code now suffers major slowdown during a certain part. Mostly it's fine, but when I initiate the funcion to start a conversation with another character everything, including the cursor, slows right down. I can't think of anything that the conversation functions do that nothing else does apart from display some text... Could it be a font thing in XP maybe? Also, I downloaded the BlitzPlus demo to see if it ran my code any quicker, and it did, but it also had some problems of it's own. For one, the player-character is scaled in real time using a my own function which uses WritePixelFast - BlitzPlus displays the transparent pixels as white... The next thing is that another function which greys the screen (for an in-game menu) crashes the program. This function uses WritePixel. So... any ideas? |
| ||
| For the crashing, bounds checking? Testing for input while the buffer is locked? The transparency problem may be to do with the colour palette in 16-bit mode or some such. Not really sure how you're doing it all, but you might want to do a few checks to make sure the mask colour is what you're expecting. Can't really think of anything for the conversation problem, perhaps you should add some profiling (with Millisecs()) to try to find which part is running the slowest. Unless it's that NVidia driver problem which I would suspect most people are aware of by now. |
| ||
| Ah, a fellow Lovecraft fan :). The text problem sounds like the nVidia Detonator 43.x bug. Update to the newest drivers and your text problems should go away. If your not using a geforce then I dont know what the problem could be. |
| ||
| Ahah! I am indeed running a geforce, and using 43.45 drivers. I'll have a see if I can fix it, cheers guys. The screen-greying function is completely self-contained and is hard-coded to run through pixels 0-799 x 0-599 of my 800x600 game screen, so I don't think going out of bounds or input testing can be the problem... Thanks for the ideas, I guess I'll have to track it down the old-fashioned way. |
| ||
| Also if you're using any of the drawing commands which are set with the color command it's now buffer specific so if you set it to red on one image buffer it'll stay red when you draw to that image buffer even if you change it to green while using another imagebuffer or drawing to the backbuffer. |
   |