Can't talk now. Moving

Just finished moving hence there's a distinct lack of updates or programming of any kind going on right now. Hopefully get some work done tomorrow, will update ASAP.

OpenGL is here

Finally got round to porting across to OpenGL. It's so much faster. With the same number of objects (78) and no optimisation (i.e all objects redrawn every frame) I'm getting 1300 frames per second in windowed mode, compared to 50fps when using Windows GDI. That's a nice healthy number since my target is 60fps. Still got some bits to do and my textout function seems to take a huge chunk out of the framerate so it runs a lot slower when in debug mode with all sorts of data on screen. Although 1800 won't be the final framerate since I'm expecting to have hundreds of objects on screen at the same time so this will obviously slow things down but it does mean I've got a lot of room to play. Once I've got it running properly with that many objects I'll start adding the selective redraw stuff and maybe double linked lists to speed up the sorting algorithm. My friendly host JDarling from EonClash has given me some pointers on linked lists so I'll be reading up on that soon enough. I'll post some screens and a new download very soon.

Nearly done

After much messing about trying to calculate the correct section of image to cut out I finally managed to get it working on one specific object and best of all I can have objects overlapping as much as they like and it still looks correct. Next is to make it so only objects that have changed are redrawn and I can carry on and look to porting it to OpenGL. As I said before, I can hopefully do away with the expensive sorting algorithm with costs N*N-1 (N=Number of objects) checks to correctly sort everything without the danger of overdraw. I was going to use a double linked list instead of the dynamic array that I've got at the minute but it was taking a long time to get right and kept throwing up bugs when it came to swapping objects around. I guess that's the danger of linked lists, you either get them right or leave well alone. Trouble with the new method is it's fine for the one object I've been testing but if I make all objects use the same method it slows stuff down way too much which is why it's so important only certain objects get a redraw. Guess I'll do the "dirty" object stuff next then make all objects use the same method.

Getting there

Finally got the chance to squash this bug and so far it's looking hopeful. In fact, the redesign has meant that I may be able to speed the draw code up. The reason for this is that I was forced to find a way of preventing objects competing for the front of the queue. It only happens in certain circumstances but is a major problem if I'm to retain the freedom offered by unusual dimensions and locations for any object. If for example only 3 objects are on screen but object1 should appear in front of object 2 and object 2 should appear in front of object 3 and object 3 should appear in front of object 1 it causes one of the objects to pop out from behind an object that is supposedly obscuring it Scroll down to "Big Mistake" post to see a screenshot of the bug in action. The solution which means hopefully faster redraw is as follows:

• Loop through the list of objects onscreen.
• At each object quickly loop through all other objects and check for overlaps (2D overlap with actual sprite, not a 3D collision) with surrounding objects.
• If there is an overlap with an object then check to see if this object is in front of current object about to be drawn.
• If overlapping object is in front then cut out section of overlapping objects sprite that actually overlaps our object's sprite and draw it over the top.
• Repeat for all overlapping objects and when finished move onto next object.

This means that anywhere on screen we can draw an object and it will automatically be drawn correctly. Effectively I only have to draw objects that have moved or changed frame and anything not changed does not need redraw. This of course is much faster than redrawing everything onscreen every frame. It also means I haven't got to run sorting algorithm for any objects really since the order that objects get drawn isn't important. All I need to do is check what's onscreen and redraw stuff that's changed. That's the theory anyway. Might be more difficult in practice especially when I come to putting this into OpenGL.

Possible solution

After spending yesterday thinking of the best solution to my sorting problem I have decided the best way of solving the problem would be to perform sectional redraws of objects that have objects in front of them. This would mean that certain objects would be partly redrawn multiple times which seems a waste of graphical grunt but i'm hoping that once i've converted to OpenGL it'll offer enough spare juice on the majority of computers not to be too much of an issue. My only other solution would mean a complete redesign of the code from the ground up and the possibility of not working at all. I'll implement the new method today so watch this space I guess.

Big mistake

After squashing the collision detection bug I thought I'd be able to start making a usable engine using OpenGL but I've discovered a show stopping bug and am now comtemplating how to proceed. Here's a screenshot of what's gone wrong.As you may have noticed, the draw order is all buggered. There's a very good reason for this and it isn't really something I saw coming. I did ponder very briefly if it was possible for this to occur but figured if it could happen I'd deal with it when it did, and it has. In essence: Each object is at the bottom of the list (nearest the screen) but is also behind the object at the top (furthest from the screen) of the list and so things poping out from behind other things when they shouldn't. No object is decisively in front so the sorter orders them incorrectly. Back to the old drawing board.

New screenshot

Here's a new screenshot with a couple of new objects I added. I drew them a few weeks back for a mockup but have now encoded them as objects and dumped them into the program. Remember, each item on screen is a separate object. That means every floor tile and both the TV cabinet and the tv. Though I realise I could speed things up a whole lot by compositing the floor into one image at startup and redrawing that before placing all other objects on top.