Quote: "Unless you have written some kind of per-pixel zsorting shader (which would be completely impractical with current hardware), there are definitely situations where you will get zsorting trouble, at least as far as I know.
"
Yeah, the example you have given would probably give even my game a run for it's money, and I didn't think of that example per se.
The alpha issue I was mainly having with in DBP, was that objects with alpha transparency on them could not be seen behind other objects with alpha transparency on them also. As you say, these issues are fixed, and aren't terribly serious, but being a perfectionist, this problem caused me enough grief (last year) to 'jump ship' to C++.
The real killer with DBP (for me at least) is definitely the CD player bug. It isn't a bug per se, but a lack of functionality. Lee stated that it is caused by ancient MCI technology, but really, for a DX9 based product on XP, is should be using something much beyond that - so the function doesn't really do 'what it says on the tin' and that was effectively the last straw for me.
The bug is here by the way:
http://forum.thegamecreators.com/?m=forum_view&t=59702&b=15
Quote: "Also, how are you managing your objects in the memory? Because it is pretty hard to keep memory in order and fast when dumping stuff in and out of it (deleting/loading objects). I mean, even very experienced engine leads have trouble with that. Are you using some free indie game dev engine?
"
For 3d I'm using Irrlicht. Irrlicht is definitely pretty speedy at allocations/deletion, but I have written a pretty simple memory manager for my game as a whole (mainly to take care of each OOP object which owns a 3d node). The memory manager has definitely helped in terms of speed of allocations etc, since the CRT is really not up to the pace of new's and delete's in most games.
Quote: "On a side note, what kind of game are you making? Screenies?"
My current game is pretty simple (in terms of design) - its an arcade-style space game, where you pretty much just shoot stuff. But the levels will be much 'deeper' as such, and I hope to really push out the boat in terms of visuals, now that I'm apt enough to start using shaders etc. It's also using real time physics with Newton (which is a first time for me altogether, since I've never bothered with physics before).
As for screen-shots, there aren't many. I'm definitely not an artist, and recently I also 'restarted' the entire project from scratch: before I was coding a very 'This game only-centric' approach, which meant that practically everything was glued to the game. This taught me a lesson when it came to coding the level editor though, so I've started a new 'framework', separate from the actual game, called "Tuono" (Italian for Thunder).
Lots of my time has been spent coding the underlying stuff so far, namely the physics. I've also been coding the level editor - in which I'm using the main engine C++ code, with a managed C++ front end (so I can use .NET's pretty UI + designer).
But yeah, actual screen shots. They're pretty crud at the moment, as I haven't really done anything besides test objects. This project was started pretty recently, so most of the work is on the low levels rather than the high (visible) level.
(Old) Pre-rewrite in-game editor (with crummy 'tube' test object)
Current (WIP) level editor, with Irrlicht rendering into the main GUI.
So yeah, quite lacklustre in terms of screenies unfortunately, as the editor is the only thing worth looking at, at the moment. Once the level editor can put segments together, then content creation can begin, and I can start doing pretty in-game stuff. Not as pretty (yet) or as easy as DBP, no. But far more rewarding, and I've learnt tons more
"History shall be kind to me, for I intend to write it" - Winston Churchill
