Pixel Perfect

Many thanks tjheldna, yes that definitely helps. I had considered just saving the data rather than the actual objects which can always be reconstructed and re-populated with the data. That's a fine example of doing just that, and nicely implemented. I like the header (key) type method of ensuring backwards compatability. Use it or ignore it and presumably cope with anything not supplied if loading old save files. Avoids dependancy on external libs too which is an advantage and less likely to cause cross platform porting issues in the future.

Just wondering what mechanisms others are using to implement game saves and loads. C++ doesn't inherently support serialisation so I've been looking at some of the options out there from the Boost Libs to jsonCpp and Google Protocol buffers. Straight serialisation seems like a nice option but there are some immediate considerations to take into account such as: How do you cope with changes to design of class objects and patched games with respect to backwards compatibility of save files. Is any given solution able to span multiple platforms (not required by me personally at the moment but always worth consideration from the outset). Any other issues I may not be currently aware of. Any heads up/advice would be gratefully received at this point.

Fragmotion allows you to do this but you will have limited success unless the skeletons are fairly matched.

One thing you need to understand about LE2 is there is no game framework, so you can pretty much do whatever you want so long as it's viable; as you will be writing your own framework. So there is no existing convention for bone names in weapons as far as Leadwerks is concerned.

Will be changing my own stance on this and I'm sure my scenes will look all the better for it. Wish I'd realised this earlier on ... a lot of textures to re-work!

No, there is no known converter for this game model format available

From what I've been reading I don't believe that is the case. The drop in quality is purely down to the fact that the compression is lossy, not that they are used without decompression. The articles I've referenced do support the belief that the DDS files are decompressed using hardware on the GPU. They do remain compressed in memory though and hence occupy less space than formats that cannot be decompressed using the hardware, so you can pack more onto the graphics card using direct draw surface formats with block compression.

That's what I've been today using. Matches the quality of the png textures used in the 'other' engine. The loss of quality using DTX5 was unacceptable

Just a quick question first, have you bought the engine or tried it yet? It's just that I wouldn't even contemplate exporting 2000+ assets until I was absolutely sure I wanted to use the engine!

Thanks Flexman, it's always good to hear other peoples opinions too. I'd kind of come to the same conclusion whilst doing some more conversion, that for things that don't matter so much/are not seen close up I'd probably retain the compression but leave detailed/close inspection surfaces uncompressed. I'm converting some very high quality assets (probably the best I've managed to get my hands on so far) and they really do benefit from not compressing the textures. In answer to your question Roland, it was my understanding that Josh recommended DTX compression for the very reason that it does remain compressed on the graphic card memory; being expanded as required on the fly by hardware acceleration. However, don't quote me on that as I'm just going by what I'd previously heard

Having converted some assets I own from the engine 'I dare not mention' I noticed that the visual quality seemed far worse in Leadwerks and was somewhat taken a back. Having experimented a bit I've come to realise for the first time just what an impact compression and the DTX5 format has on both grain in the diffuse and also the quality of the bump mapping. Once you see it without compression it's hard to go back. Whilst there are I believe some obvious advantages to using compression, namely the ability to fit more textures in the graphics card memory and the fact that DTX expansion is supported in hardware making it fast, I'm not sure I like the side effects. So basically, what are peoples thoughts/experiences on this and what do you use?

Better get one of the Immortals to stop battling and write a converter then

Except that when you tell people it is thread safe they assume you don't have to use mutexes. Avoid misinformation please, it's not helpful to people.

Fair comment, but that's not the same as saying that LE2 commands are thread safe ... they are not!

Well I have seen examples where mutli-threaded calls to basic Entity functions caused crashes. The general concensus as I understand it has always been that Leadwerks is NOT thread safe! What mechanisms are in place to ensure, for example, that only one thread reads or writes shared data at any time?

From all that I've seen in the past from people that have tried it, most of the commands are not thread safe and can cause crashes if run asynchronously, what makes you believe the others are all 'thread safe'?

In C you can do either really depending on what it is you are wanting to do: For instance, if you want to store the value for some later point then you can assign a variable the value returned from EntityDistance as follows: float dist = EntityDistance(Entity1,Entity2); But if you just wanted to test the value with an if statement for example then there is no need for the variable, the return value is simply used in the comparision: if(EntityDistance(Entity1,Entity2) <= 2.0) { ... do something } With regard to re-use of the same variable, then yes, this is possible depending on the scope (life) of the variable, but not always desirable. It is generally better practice to scope your variables locally.

Nice work ParaToxic, that's about as much as you can do really given that LE2's commands are not thread safe.

I'm not being funny but most newcomers could do with reading through the following document before starting with the engine and tools: Leadwerks User Guide Most of your questions will probably be answered and you will learn so much more too!

That's a couple of nice editors Michael, thanks for the shout on these

lol ... I know that feeling well

If you have already used PointEntity to point the knight towards the player then Daimour's suggestion should work, so the whole line becomes: UpdateController(knight.control,EntityRotation(knight.model,1).Y, knight.speed * 2,0, 0, 500,1,0); rotation.y is a BlitzMax property and these are not directly exposed in the C DLL

Cry Engine uses voxel terrain construction too in conjunction with normal heightmap terrain for detailed outcrop sections etc, its a pretty neat feature.

Very nice again Andy and I still think the terrain you used in your last paraglider video you showcased was the most realistic textured landscape I've seen in Leadwerk's bar none! Did that use a terrain model rather than Leadwerks terrain? For anyone that's not seen Andy's project Parafly take a look here: Parafly videos

Penumbra Overture was produced by a core team of four people who also used additional resource for some of the music, artwork and programming. They were working full time on the project and it took nearly 10 months. Maybe you are thinking of the original tech demo that Josh referred to which was simply called Penumbra! Besides, these guys had already written an engine together and were used to working as a team before they even embarked on Penumbra.