Pixel Perfect

I'm not sure now this was what I was trying to download. I tried to download the SetupShroud_basic.exe which is the Shroud Simulation Engine Basic Edition but that stated it was 94Mb. This was what the link in their order (no charge for the basic edition) email pointed me too.

Newton behaves like this when the bodies penetrate each other, you get a massive reaction of force. It used to hurl me sometimes completly off the level. Pauls advice sounds about right from what Josh has said in the past.

As far as I understand it the normal map texture should be applied to the same UV coordinates that the diffuse texture is mapped to, so should follow the tiling exactly if the original texture is tiled. This is done automatically by the engine. All you should need to do is create a mat file using the same name as the diffuse texture in your model and specify the diffuse in texture0 slot and the normal map in texure1 slot. So if your diffuse texture was diffuseTex.dds then name the mat file diffuseTex.mat and specify the normal map as the second texture (doesn't matter really what you name the normal texture ... dot3 is just convention): texture0="abstract::diffuseTex.dds" texture1="abstract::diffuseTexdot3.dds" shader="abstract::mesh_diffuse_bumpmap.vert","abstract::mesh_diffuse_bumpmap.frag" Just for information, if your model had two diffuse textures applied then you would create two mat files, one for each diffuse texture. Every diffuse texture used in a model must have an associated mat file.

Someone was working on integrating Leadwerks Engine 2 with Dark Basic and I believe pretty much had it working but I can't seem to find the posts (probably because we lost 6 months of the forum posts recently). I don't believe he ever got to the stage of releasing it although I might be wrong on that! As Leadwerks uses openGL and not DirectX you'd be ok using any Dark Basic Pro plugins so long as they don't depend on DirectX. The Dark Clouds plugin does use DirectX. You'd need to talk to the guy doing the integration for a better idea of what works and what doesn't. Personally, I think you'd be better off using one of the officially supported languages like BlitzMax or Lua. It really wouldn't take you long to adjust to them and they are far more powerful languages than Dark Basic. There are also lots of people using them and hence lots of helpful advice should you get stuck . Other options are C++ (a bit more daunting) or some of the user supported languages like the .net wrappers for C# etc. Dark Basic Pro is a popular starting point (I started there myself) but with no disrespect most people move on to more capable engines and more suitable languages after a while as you will be held back by both in DBPro.

Should never have been absent in the first place but better late than never I guess! Glad to see you guys back with a forum (and yes I am a C++ developer ... so please don't tar us all with the same brush )

There is a scale setting in the settings.ini file which sets the scaling for the terrain textures. The file is in the root of the 3DWS installation. Look for the Scale section: [scale] TextureMapScale=0.5

I'd suggest using dds textures in 3DWS to start with (saves converting them afterwards) as I think the latest version supports them. Then when you export all you have to do is create mat files for each of them. There are some tools about for creating default mat files from textures in a directory if you want something to speed this process up a bit.

I found when using CameraUnproject that if the returned z value was less than 0, that is the object is behind you, then I needed to inhibit the display of the label or it would display in odd places.

I updated all my muzzleFlash code last night both for the player and NPCs to cut the parenting out. It's all working fine now so many thanks MG for the pointer on this

I found my notes on this and it was b3d2gmf.exe that I previously used. The command line was as follows: b3d2gmf +mesh "filename.b3d" –nocolor +scale 0.01 and that definitely worked as I converted and scaled many models using that. So either the obj2gmf never supported the command line switches or they were indeed removed at some point.

The shader assignment and the color map facility sounds brilliant!

Well you can use the Leadwerks 2D Drawing commands to make a dialogue box and control how text appears in it. This is how I created the content scrolls in my game Kingdom Of Soul. Of course you'll need to buy the engine first!

You need to code these things yourself Mark. Artificial Intelligence is not provided as part of the engine so individual game developers need to design and code this to suit their own game ideas. Depending on what you want this can be fairly simple or incredibly complicated. There is plenty of information available on the web regarding these topics.

I've not used that convertor in a long time but I'm sure thats the syntax I used to use and it worked fine. Maybe later versions of the exe have had the command line options removed.

I always thought the smf format used in 3DWS was unique to 3DWS. So I'm guessing the .smf that AC3D exports is a non compatible format. Just export to .X and use those in 3DWS, I doubt either of the .smf files will be recognised by any game engine!

You might want to cast you eyes over this recent spec for LE3

Thanks MG, I'll look into this (I'm pretty sure I have it parented to a bone in the weapon currently). A pain in the "sitting muscle" is exactly what this is and another classic example of why I hate upgrading to any newer version of Leadwerks Engine as something like this always happens and we are forced to spend time we really can't afford reworking code that worked perfectly well beforehand for seemingly no gain at all. [EDIT]I have confirmed (as you suggested MG) that if I simply position the plane in the right position rather than have it parented to the weapon then it renders correctly. This is clearly a bug and I'll log it now.

This was working properly in 2.31 but since moving to 2.42 now appears not to be. I get the same result whether using Framewerk or Framework. The muzzleflash texture does not appear to be masked correctly against the main world although works correctly against the background world. It almost looks like the plane is getting lit although lighting is set to off in the mat file. example mat file: texture0="abstract::muzzleflash.dds" zsort=1 blend=LIGHT depthmask=0 castshadows=0 lighting=0 shader="abstract::mesh_diffuse.vert","abstract::mesh_diffuse.frag" Rendered against Background: Rendered against Foreground: Do I need to do something different in the mat file now or is this a bug?

Thanks Aggror ... your critique is always appreciated

I like that Mika

I decided to take a look at the BlitzMax framework code as I'd forgotten this was still being published (as the module can't be built because of the name being reserved or something) and found that the code which sets the hdrformat to TEXTURE_RG11B10 had been commented out confirming what I've found. An additional bonus was the fact that, as this is clearly still being maintained unlike the C++ framewerk, it contains the code for setting the Saturation/Contrast/Brightness which means I can now update the C++ framewerk to support Saturation/Contrast/Brightness too ... cool!

Glad to hear, and for anyone else using framewerk hopefully. I've decided to stick with framewerk as I've never liked the fact that framework is enbedded in the DLL with no way of altering it or extending it. I'm going to test this out with several other nVidea cards and also an ATI and if the effect (bug) is consistent then I'll see if I can make this effect switchable by adding my own procedure in renderer.cpp. Of course this means goodbye yet again to Leadwerks implementation of Lua as I'll need to implement my own Lua (or other scripting language). But that was always on the cards as I need to expose my C++ Classes to the scripting language which the current implementation of Lua doesn't support. Looks like I might be porting Klepto2's daynight system to C++ after all.

Having done a lot more comparisons between C++ and framework and C++ and framewerk I now understand why I am seeing the differences. Quite simply framewerk has a bug where turning on HDR causes the DOF to be applied accross all ranges seemingly ignoring the DOF Range setting. As I had the DOF strength setting fairly low it was not initially obvious what was happening. So framework works correctly, framewerk does not and the effect I like is effectivly an artifact of a bug, not exactly what I wanted to find but at least I now know. The issue appears to be in the following bit of code: void Renderer::SetHDR( bool mode ) { if( GetShaderModel()>=4 ) // SM4 is required! if( hdrenabled!=mode ) { hdrenabled=mode; if( 0==hdrformat ) { // Create a test texture to see if format is supported TTexture tex = CreateTexture(64,64,TEXTURE_RG11B10); if( tex ) { hdrformat=TEXTURE_RG11B10; FreeTexture( tex ); } else hdrformat=TEXTURE_RGBA16; } FreeBuffers(); } } The TTexture tex is created successfully and as a result the hdrformat is set to RG11B10. If I hard code this to RGBA16 then the hdr and DOF works correctly. Maybe you could comment on this Josh as I'm not sure what you were intending here.

I had to use the background command when I loaded it manually in my code or I too got a black sky, but as Mack suggests, if you have the atmosphere object in your level then the Lua script should take care of that.

Wow! That test render looks great.