TylerH

Ah, ok. That start script idea is great, thank you .

How do most games get around this then? It isn't impossible, because you can see it has been done in games: - Windows - Water - Rain - Emitters - Other Glass We will stumble upon a way to do it eventually, and it isn't anything super important. I am happy with the fact we have robust particles at all.

We can not make use of LuaBind without a Lua State. By using your Lua State (granted it was indeed usable from C/C++ properly), we wouldn't even be using another instance, we would be using the same instance of Lua, since it is already in memory from when you created yours. The state is just a pointer to the core memory utilized by Lua and some other variables it needed for garbage collection and such.

Ah, that makes sense then. The first thing that came to mind when this reared its head was more than one transparency world, but probably not.

Why exactly?

Well, I am not rendering refraction on top of refraction. I am rendering refracting particles on top of normal fog / smoke particles. Refraction on Normal Particles should work...

Add a SetBlend(0) to line 39 to remove the artifact that occurs when opening/closing the console.

Specifically for Vex, we store our assets as an external on our SVN, and keeping the Editor in the bin folder with the game executable. Like this: SVN Root/Assets SVN Root/Bin/Editor.exe For that reason, it would be great if we could add abstract paths to the Editor for loading resources from different places. Cheers, Tyler

I had/still have this issue with the heathaze. I also would like to note that any of the particle shaders that use refraction will not be visible if there are other particles being rendered behind them. It seems that particles don't play nicely with each other.

abstract::ssrt.frag not found.

You can modify the hdr.frag shader to allow a greater range of pixel brightness, though it seems too bright already. It isn't really using a proper tonemapping algorithm, which is why it appears odd.

@Niosop: The only thing that has to be the same in a VBO is vertex data, normal data, and texture coordinate data. If you are using primary/secondary colors or other indices for the array pointers in the VBO, those must also be the same, but since the textures are passed as samplers to the shader per-mesh, they could be different. From what I remember, this instancing behavior is something Leadwerks implemented in its own way using some kind of reference system vs. instances.

Yes, we are experiencing this EXACT same problem with Jeklynn Heights at Vex. Our environment_atmosphere, light, etc. entities do not load their saved properties from the SBX file and run in the LUA script properly, so things like intensity, brightness, saturation, contrast, etc. do NOT work. If you find a solution, please let me know. Maybe we can find out the specific area of cause, or worst case, motivate Josh to get this fixed.

Well, I know nothing is borked outside of LoadScene here, because even though I call it in a seperate thread, I use WaitForSingleObject( hThread, INFINITE ); So the main thread is basically sleeping until the LoadScene thread is done, which should give the same effect as calling LoadScene in the same thread, except for the cosmetics and such of the structure. The idea here is that running non-mutable code in a secondary thread shouldn't cause problems. Now, I could see the issue of say, calling PositionEntity, RotateEntity, etc. in a secondary thread, or whatever. Actually, if you use semaphores and mutexes correctly, you wouldn't need to worry, threading would basically take care of itself...

Sure, there are ways to hack around it, and we already have such ways implemented, or are working on them. I really am not comfortable with custom parsing the SBX file, because half of the stuff in there isn't doable with the procedural command set, i.e. Multiple vegetation layers, Some of the script stuff I am sure, etc. It would be great if we could get the source code to LoadScene, and be able to customize it in our own language, then I could make it thread safe.

Well, with the current Vex Studios project, we were throwing ideas around and wanted to have a real progress bar on our loading screen, instead of a "Loading..." text while the Leadwerks LoadScene function halted the main thread. In an attempt to suit that idea, and test how many, if any, of the Leadwerks functions will run in a seperate thread, we went ahead and changed up our Level Manager to call LoadScene in its own little thread. Here is some slight source code: unsigned __stdcall LoadLevelFunc( void* pArguments ) { printf( "In second thread...\n" ); Game::Globals:_LevelManager::getInstance()->m_eScene = LoadScene(Game::Globals:_LevelManager::getInstance()->m_sLevel); _endthreadex( 0 ); return 0; } bool CLevelManager::Load() { if(m_sLevel == "") return false; //m_eScene = LoadScene(m_sLevel); m_eScene = NULL; HANDLE hThread; unsigned threadID; printf( "Creating second thread...\n" ); // Create the second thread. hThread = (HANDLE)_beginthreadex( NULL, 0, &LoadLevelFunc, NULL, 0, &threadID ); WaitForSingleObject( hThread, INFINITE ); Collisions(3,2,1); Collisions(2,3,1); Collisions(1,1,1); Collisions(3,1,1); Collisions(2,1,1); Collisions(3,3,1); Collisions(2,2,1); if(m_eScene!=NULL) { std::cout << "Scene Children: " << CountChildren(m_eScene) << "\n"; for(int i = 1; i<=CountChildren(m_eScene); i++) { ProcessEntity(GetChild(m_eScene, i)); } } return m_eScene!=NULL; } The Level Manager was coded by Jeremy, and I added in the threaded function a short bit ago. Now here is the COOL part. LoadScene didn't crash immediately. Leadwerks ran it. it loaded the first model...the first mesh for that model...the material file. No problems. It failed to load every single texture for the model. It loaded the shader in the material file fine. Shader compilation failed because the textures were all null and not loaded... Printed full mesh.frag source with proper defines to the console, then the program terminated (which Leadwerks seems to do when a Shader fails to compile). So, threading failed, but these are some good signs. Maybe this will spearhead Leadwerks Corporation to look into atleast making the functions of the engine thread safe, for reasons like this. Even things like networking Leadwerks entities, Loading like in this case, or doing some kind of data streaming in the background. This doesn't require the Leadwerks Engine to be threaded at all. It simply requires that the engine commands be thread safe, and capable of being run asynchronously. Or it could be simply something wrong in the texture loading code . Hoping this gets us somewhere! Cheers, Tyler

The use of OR in lua seems the same as using || in C++. Lua supports both logical OR and bitwise OR, but using the same 'or' keyword. No confusion at all there

Then why can't we say TEntity for that? Or maybe an internal entity, or scenegraph entity.

No, he really needs an AND in there. No matter what his GetGlobalString("quit") == "false" comparison is, the KeyHit(KEY_ESCAPE) == 0 is always true, so the or never goes any further. Hence why it works without the KeyHit test. Use an and and all will be fine.

Not sure what is going on with your Pick.Structure property there? You need to use an attribute tag on your declaration of Pick: I assume you have a using System.Runtime.InteropServices; at the top of your file, which you should always have if dealing with stuff between the managed <-> unmanaged boundary, which you are. [MarshalAs(UnmanagedType.Struct),StructLayout(LayoutKind.Sequential] public class Pick { ... } That *should* be what you need to do, though I am not 100% sure. It seems most likely like you are dealing with an issue with the packing of your structure's members in memory. Since these are private forums, I hope I don't get in trouble with posting this little bit of engine.dll source: Function CameraPick_:Int(pick:Byte Ptr,camera:TCamera,p:Float Ptr,radius:Float=0.0,collisionType:Int,pickfilter:Byte Ptr=Null) "win32" GCEnter() UserPickFilter=pickfilter Local pick1:TPick pick1=CameraPick(camera,Vec3(p[0],p[1],p[2]),radius,collisionType,dllpickfilter) If pick1 MemCopy pick,pick1,4*9 Return 1 EndIf EndFunction If you notice the call to MemCopy, it is copying 4 bytes per element * 9 elements. EDIT: Ah, I see Structure is the core TPick thing, in that case, put the attribute tag on the declaration of the Core.TPick class, not the Pick class.

I think the term Nodes is also good? There are many words we are using the mean the same thing, and some creative multi-word ones: Entity Object Node Element Type Item Thing ScriptedEntity ScriptedObject ScriptedElement Scripted... SceneNode SceneEntity Scene... ModelScript For all intensive purposes I think they (they=objects created from a class archetype in Lua) should be called Scripted Entities, the model they are associated with is a Model, the combined Model/Script Entity File should be called an Entity.

Alpha test just discards pixels if the alpha of the diffuse map is < 0.3. I was coming from the approach if you wanted to store your alpha map in an entirely separate file (i.e. the definition of opacity map).

That was to Josh. The command to look at is lua_dobuffer

Internally, if you load the contents of the file using the Leadwerks file system into a stream, you should be able to run the stream via the lua_doblock or some similar method. Google the net for ways of "running lua scripts from memory" or "running lua scripts from a stream" or something of that thing. That means you can then use your abstract::, cache::, zip::, http:: protocols

This is wonderful, but there is a MAJOR issue. I initialize the Jeklynn Heights scripting system currently using lua_open(). It returns a native type of lua_State*. I tried replacing lua_open() with: State = reinterpret_cast<lua_State*>(GetLuaState()); but it causes a major load of run-time errors and exceptions. Basically, your byte pointer to the Lua State used in Blitzmax will not transfer easily to C/C++, and will be incompatible with any direct usage of Lua, LuaBind, tolua++, etc. libraries that require a lua_State* pointer. Maybe there is a way to get this working? Because, honestly, there is much more versatility in using Lua native in C/C++ along with third party libraries instead of the overhead of Lua in C -> BMX -> Re-exposed in engine.h/.cpp. Anyways, this is working great otherwise. Cheers, Tyler