Queue on 6/1/2011 at 16:41
Quote Posted by Uur
this forum is far too cowardly to assist you with a clandestine thief project.
I always thought of it as far too smart to not recognize a stooge.
lost_soul on 6/1/2011 at 19:09
Why not just help get Thief 1/2 working perfectly in Wine? Even with a Geforce 9800GS, we don't have to use DDFix to play Thief 1. The only problems are that videos occasionally cause the game to crash when you skip them, and after the game plays a movie, it switches back to running on multiple cores. This means the game locks up after a wile too. I've had to disable movies to get around this. Since the publisher doesn't give a crap about the customer and will never ship an official patch to fix the multicore issues, that one really isn't so much a Wine issue.
I'm not a programmer, but it should be easy to fix these bugs in Wine. It would probably be tougher to get the Wine devs to accept your patches though. I fully expect to still have unplayable Unreal engine 2 games in Wine in 2013 due to that mouse movement bug that has been there for at least *FIVE YEARS*.
Volca on 9/1/2011 at 08:26
Quote Posted by Albert
Good luck finding a time machine to travel back to the point before the first Dark Mod version was released. At least, aim for being able to play it never the less when you get a better gaming PC. :cheeky:
I somewhat understand why the project is now on ice but, you've at least been enlightened by the source, to continue on OPDE, if the source release gets the axe, right?
Sure, I didn't say I'm abandoning the project - if the original source code won't be usable for some reason (which seems unlikely), OPDE can be still worked on and finished. Although it will be difficult to avoid the temptation to use the original source code - we'd have to use some clean method.
@camperman: I wonder why you chose to write something from the ground up even though OPDE is already capable of rendering and has the object system basis written, with bindings to Python for the most parts of the engine. My plan was to write the game independent code in C++ only, the rest would be scripted via python.
If you're thinking about making it easy to yourself by ignoring many things Dark Engine is capable of you'll probably have a hard time later on, trying to convince the engine to be able to do the things original engine does. For example how are you going to render the original levels? Or are you going to rework the level design as well? (Not to sound like a jerk though, maybe you have the way to do that designed in).
camperman on 14/1/2011 at 09:02
Quote Posted by Volca
@camperman: I wonder why you chose to write something from the ground up even though OPDE is already capable of rendering and has the object system basis written, with bindings to Python for the most parts of the engine. My plan was to write the game independent code in C++ only, the rest would be scripted via python.
Right - I just figured that out after some more analysis of OPDE :) I guess it's NIH syndrome. I've always wanted to make a large game and I thought I would kill two birds with one stone. I haven't got OPDE running yet because I can't compile a bloody thing on this Mac but I will be setting up a nice Linux dev box this weekend to have a look. If it kicks ass and is just totally awesome, then who knows? I might just contribute.
Quote:
If you're thinking about making it easy to yourself by ignoring many things Dark Engine is capable of you'll probably have a hard time later on, trying to convince the engine to be able to do the things original engine does. For example how are you going to render the original levels? Or are you going to rework the level design as well? (Not to sound like a jerk though, maybe you have the way to do that designed in).
The levels as I see them are just geometry + textures. Throw them at Irrlicht's BSP renderer and you have yourselves a level. Movement means modifying the default scene node camera to do funky things like leaning and climbing ropes. Level design? Dunno. IrrEdit (also part of IrrLicht) could come in handy here. But I have a ways to go before I even get started. I want to wrap a largish C++ library in Lua first for the practice and produce a small game out of it, perhaps in Love2d. Then I will take those lessons and apply them to Thief: the Remake Project (or whatever name I decide upon).
jtr7 on 14/1/2011 at 09:08
That's really so oversimplified I have to hope you know it's much more than that. :D
Volca on 14/1/2011 at 09:24
@Camperman: Trust me I tried to render the level geometry without the need to do the portal traversal and the in WR/WRRGB BSP tree. Not too good. I dunno if irrlicht's BSP renderer is more flexible than the one in Ogre3d (which only renders Q3 BSPs and simmilar) but the problem is that there is no PVS and the whole geometry is interior based (as opposed to quakes exterior based geometry). I was able to render the level geometry somehow using the irrlicht's octree but the performance depended on level position (with a really bad performance on some places since it had to output nearly all the level's geometry - no occlusion culling was involved). I think it would be worth the try to drop the BSP and group the geometry using Room database, but I feared this would be somewhat fragile.
Then there is the problem with dependencies - for example there is an option in tweq to only animate when visible - if something depended on this tweq, then rendering differently would affect that.
camperman on 14/1/2011 at 11:23
Quote Posted by jtr7
That's really so oversimplified I have to hope you know it's much more than that. :D
Yes I do. In spades.
camperman on 14/1/2011 at 11:47
Quote Posted by Volca
@Camperman: Trust me I tried to render the level geometry without the need to do the portal traversal and the in WR/WRRGB BSP tree. Not too good. I dunno if irrlicht's BSP renderer is more flexible than the one in Ogre3d (which only renders Q3 BSPs and simmilar) but the problem is that there is no PVS and the whole geometry is interior based (as opposed to quakes exterior based geometry). I was able to render the level geometry somehow using the irrlicht's octree but the performance depended on level position (with a really bad performance on some places since it had to output nearly all the level's geometry - no occlusion culling was involved). I think it would be worth the try to drop the BSP and group the geometry using Room database, but I feared this would be somewhat fragile.
I hear you - none of these problems will have easy solutions. One option I've seriously considered is reading in geometry for the first time, re-rendering it in an optimal format for a stable framerate and saving it to disk for future playing. It might suck to throw up a screen saying "calculating PVS - please wait for 30 minutes" though...
Quote:
Then there is the problem with dependencies - for example there is an option in tweq to only animate when visible - if something depended on this tweq, then rendering differently would affect that.
Or you could cheat and animate everything within the currently visible tree of the scene graph. I don't know - I'm just throwing out ideas based on absolutely zero knowledge of what you have learned the hard way. But that will come.
Volca on 14/1/2011 at 14:10
Well the PVS is not a big win either, as it would force you to compose the IBO (at least) on a per frame basis and have the geometry in small chunks anyway - there are more HW friendly ways to calculate visibility set, for example portal based or polygon soup based - I don't know enough about them to help though. If you want to experiment a bit I'd say try to group the polygonal data per room from the room database, since it is used for sound and AI calculations is could be okay for rendering too (aside from some unforseen corner cases).
You could then compose a single atlas texture for all lightmaps in a given room or room cluster (based on room adjacency or some kind of simple PVS evaluation), which could lower the number of combinations of texture/lightmap atlas - lowering batch counts, hopefully.
Edit: That is to say if you're counting with lightmaps, anyway. But dynamic lighting will probably suck and omni shadows are still quite expensive.
