As far as I understand, problems like that would persist no matter what dimensions we use, because they stem from the very nature of isometric graphics.
But the dimensions in x-com are selected so that a floor tile which is 2 levels up exactly overlaps some underlying tile. So using x-com dimensions, so the problem with the difference between destroyed and normal floor is especially noticeable. Most likely this was done for implementing some performance optimization tricks. If you have some floor grid on some higher level, it exactly overlaps some tile below and we don't have to spend some precious CPU cycles drawing it (original x-com had to run on i386 cpu).
When there is no perspective distortion, and no way to rotate the camera, it can sometimes be difficult to estimate the relative distances of different objects to the camera plane. Usually these things are obvious from the way how maps are constructed, but in some freak situations little glitches like these "invisible holes" cause annoyance. Since a true 3D engine is not going to be implemented in UFO2000 anytime soon, for various reasons, one way to solve the problem would be to shade the different height levels differently depending on which one of them is focused, like Sporb suggested. Or simply just build maps in such a way that there are no identical floors on top of another, which is probably the most feasible solution.
Well, I feel that this could add some extra confusion, but actually implementing full 3D rendering of the battlescape is technically not very difficult. The code for drawing the map is a bit scattered all over the code, but is not that large and can be isolated. And we may add some kind of 3D frontend in the future if we decide it is worth it. For anyone who would like to try making 3D frontend for ufo2000, it can be started from making the game run with F_FASTSTART=1 flag in ufo2000.ini set. So the battle will start immediately after running ufo2000 executable with the setting of the previous battle and we don't have to implement all the gui and mission preparation code at first. And an interesting demo would be to just display loft data on the map using OpenGL (probably start from using allegrogl, but making an ogre based frontend should be also possible). This 3D frontend task is not that difficult as it may seem at first

Actually when I came to this forum, the idea was to work with Xenocide people on the same game. We make the battlescape, they make the geoscape. And we could merge the codebase at some point in the future. I still keep an eye on Xenocide waiting when they finally have a playable geoscape in order to estimate if it is difficult to merge it with ufo2000 engine. That's probably why the forums of our projects are both hosted at xcomufo.com
Here are some dusty old threads which have all the information about these cooperation ideas from the very beginning of the Xenocide project (they are quite long, either read them all or just search for my posts):
http://www.xcomufo.c...hp?showtopic=97http://www.xcomufo.c...p?showtopic=293Do you feel completely confused now?

OK, I'm not going to implement any 3D graphics right now. We just don't have enough resources for that and I myself do not consider 3D graphics to be better than 2D. Quite the opposite, 3D graphics adds lots of compatibility problems while 2D should work just anywhere. Also we might even port the game to mobile devices, so it is good that we still use 2D graphics:
http://www.xcomufo.c...?showtopic=8451But I would not mind if someone started making 3D frontend if he is interested, even more I will provide any help or explanations regarding current ufo2000 codebase that he might need.
I don't really have a strong opinion on whether the new graphics should be usable alongside with the graphics from X-Com, but I don't see any good reason why we should deviate from the proven and tested X-Com dimensions. Changing the camera angle too much would probably just compromise the readability of the graphics in one way or another. Perhaps halving the tile height, so that one cell is almost cubical, would give more freedom to mappers, on the other hand, one normal soldier standing upright would then take two cells vertically, and there should be an implementation of multi-celled units first before anything like that can be done.
Well, looks like we are short on man power in the programming department currently. So we should probably finish a set of free graphics using x-com dimentions, make the game use it and run without any data files from x-com and release the new stable version as soon as possible. After that we will continue the development in the next beta versions and can add support for high resolution graphics. What do you think?
Edited by Serge, 04 September 2005 - 01:54 PM.