Well, thanks for your suggestion of the Torque2D engine. I will give it a go but I prefer BASIC-like languages over C-like languages (which is strange because PureBASIC is more C-like than any BASIC implementation I've seen so far) and learning C# would be difficult. I've tried to get into C programming before on Linux but I didn't like it because the syntax is very complex with a lot of library inclusions, curly brackets and strict variables and functions. I like how I can just open a BASIC compiler and get started without worry about the setup. The things I like about BASIC is: it is powerful, flexible and easy to use but I'm sure C# can be all those thing, I just need a good tutorial.
Sounds like a problem with the game engine, 2d flys these days with a million sprites at once. Try a different engine, theres a really good 2d engine that goes really quick called torque 2d and it goes with a programming language that edits with torsion, to control behaviours, i learnt it in school. its made by garage games, goto www.garagegames.com that should fix all your problems. 1) something going wrong. 2) you need framerate for animation 3) ??? 4) torque is really really good for debugging 5) torque handles double buffering for you 6) youll have to learn c# to code with torque, but dont worry its pretty similar to basic anyway.
By the way I looked up the Torque2D engine and I found it was available free on github, however I'm not sure how to build it, there's no instructions included and I can't seem to find any online documentation. Can you have a look into it?
1) Thanks for your help but I am working on a 2D game and I don't think these structures can help me.
Just some potential answers below. 1. There are numerous reasons this could be happening. i) Are you CPU bound? If your CPU cannot preform logic fast enough, then your frame rates will drop. Solution? Batch polygons for rendering rather that loop through and render each individual polygon. Partition your scene and render only the pieces that are visible. Check for collision only with the pieces that are visible, and in some cases perform on AI on the monsters that are visible (or extend the visible range so AI kicks in before they show up on screen). ii) Are you GPU bound? If your GPU is struggling with fillrate, to many polygons, expensive shader effects? This could all lead to poor frame rate. Solution? Analyse your GPU code and try to optimize it where possible. Minimize your poly count and/or texture resolution (or use texture compression), avoid to many layers (fillrate issue), render front to back with opaque geometry and back to front with translucent objects. Make sure you're using vertex buffer objects for efficient rendering. 2. Use programming for animation whenever possible. Skeletal animations is widely used as is key frame animation. If you are using 2D sprite sheets (atlases), you may need to do some extra work. Some sprites may be able to use a skeletal animation system, but you would have to partition your characters into pieces so that you can apply bones to them. This has limited capability, but can work for some scenarios. 3. Why do they look terrible? 4. IMO, try to get accustomed to real-time debugging. Don't debug in fullscreen either, debug in window. Your next alternative is a good logging system. 5. You don't render twice. The backend will copy your back buffer (where you are rendering graphics) into the front buffer before being displayed. This smooths out the rendering of the front buffer, which otherwise would have rendered even if you were still working on it and would introduce that nasty frame tear/blinking effect. 6. Keep up to date on technology and programming designs and techniques. Find out how other people do things because you might learn something new that will help with your own developments and productivity.
2) I've used programming for 100% of the game so far. I've just started the game so I have a static sprite, I could make an animated on but it would be tricky.
3) I'm not sure, moving in multiple directs looks a bit jumpy with only moving in one is smooth. Perhaps I could try moving the character by less on horizontals?
4) I created a flag in my variables section to make the application windowed. That makes it more like I'm used to.
5) Yes, but I still need to keep track of where I draw my character so I can replace the background on that buffer. What else can I do?
6) I've upgraded through VisualBASIC versions in the past, but I'm hesitant to switch to completely different technologies.
Thanks, I'll look into it.
It sounds like the trouble is in your double buffering. Maybe ask someone on a Purebasic forum if there is one how best to implement it. Otherwise do some study by googling. Most hardware doesn't have a problem keeping up with 2d anymore unless you are moving very large sprites. The only other problem might be that you aren't using hardware acceleration or you are under some kind of frame lock that is too low.