martyj

It would be nice to have access to glClipPlane in Lua for rendering UI. For example, we could use glClipPlane to make sure we didn't render outside of a Panel when rendering. I wouldn't use glClipPlane per say, as it is limiting to GL_MAX_CLIP_PLANES -1. Which I believe is 6 on most hardware setups. I would recomend the use of a Geometry Shader to have the ability to throw away verticies. For performance reasons you could even limit clipping to 2D surfaces. Which I think would be the most common use case.

Where did you get your dwarf model btw?

Do you get a better framerate when you run the app without debugging it?

It's probably a KDE, Mate, Cinnamon appearance problem. You can adjust your window color settings for your GUI interface. That should resolve your issues. There's nothing that LE can do about it as it's a problem with your theme and not the program at hand. My recommendation though is to stay away from Linux mint as there is no easy way to upgrade the OS to a later revision. Id suggest you go with ubuntu and install different desktop enviroments if you want something different.

Without having your map, I don't think we can make suggestions on how to improve shadow performance. Shadows in games can be implemented in two ways. The first way is to render the scene to a shadow buffer. The second way is to bake in that shadow buffer to each of the models. Which let's be honest, in this case of an off the shelf engine, is very unrealistic. There could be some AA done on the shadow buffer which could be lowered for improved perfomance. I'd assume there is judging by the soft outlines provided by the shadows. What hardware are you running on? You'd be surprised how cheap you can get a second hand graphics card today. Especially since the bitcoin bubble popped. Also I've noticed for the most part I have poor performance on debug builds. If I run my code for release I get a lot better frame rate.

Yea, that was the issue. I kept trying to drag it up from the bottom.

http://i.imgur.com/6QlnVjf.png I lost my debug tabs yesterday some how and I can't get them back. I've tried uninstalling and re-installing. The window missing from this screen shot can be found here: https://i.imgur.com/u4fQToh.png How can I get it back? This is really killing development.

@Drarem, I found when modifying Lua files, it's best to just create my own Lua file. So if you have an FPSPlayer Lua file you could name it like MyNamePlayer.Lua or Player.Lua and not loose your code.

I'm not even concerned about bringing back deleted files. It's a bit of a pain, but for the most part I ignore them. As far as using the "update" functionality, I honestly didn't know what it did until I had this problem. The engine always just complained that the project needs to be updated before running inside of it. Maybe what you could do for us having to delete files is not include them in the project, but allow access to them in sample projects. I think for the most part, the most common use case of the game engine is to not build off of what's included, but to "Start from scratch". I don't use anything from the original LE project in my code. Everything's been customized to fit my own use case.

I think Rick covered it best. Since I'm using the C++ version of the app. It's assuming that ANYTHING inside /Source/ should be off limits to be "updated/modified/changed" I'd even say not to change /Projects/ as well, as it's a pain to reimport everything into visual studio.

Honestly it shouldn't be needed. If there's a code change let me do it myself. Don't trash my code and force me to fix it via version control when I had a working version.

So I updated my LE project and the following source files were changed and the modifications I added to them was removed. App.h App.cpp Main.cpp Could we not have the engine modify our code? If you change these files, let us know, but don't force a change on them. Some of us don't use the built in C++ code that calls LUA scripts to do everything

This gets my vote. It would make our code a lot cleaner for NPC path walking.

Thanks for the info Rick! It's great to know this exists.

You can't just included a LUA library into the LUA version of leadwerks. You need the C++ version. Unless I am mistaken to LUA's potential with LE. What I'm talking about is having Josh provide a way to import dynamic libraries into the LUA version of the game.

I think it would be very beneficial for the LE community to be able to create and distribute C++ libraries that create additional LUA functionality. For example, the LE exe could search through a /libs/ folder, load each .dll/.so dynamically calling a "leadwerks_init" function defined in the dynamic library. The dynamic library could use to_lua++ to create additional functionality, such as playing MP3, OGG, audio file, networking, or anything else that people create. To load a library in Windows: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175%28v=vs.85%29.aspx To call a function in the library in windows use https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212%28v=vs.85%29.aspx To load a library in Linux use http://man7.org/linux/man-pages/man3/dlopen.3.html dlopen To call a function in the library in Linux use dlsym I currently use the C++ version of LE, and could distribute a game exe that would include this functionality with a library that I create, if I did. But it would be better for the LE community if the LUA version had this built in. What if Josh never had to program networking into LE because someone in the community did it first? What if Josh never had to program in a compressed audio format into LE because someone in the community did it first? Imagine the possibilities.

If you had C++, you could always code it yourself. OpenALSoundDriver.h extends SoundDriver. OpenALSoundDriver has all the OpenAL information needed to be able to create, write buffers. Create a Source. Get the SoundDriver from the source. Cast as OpenALSoundDriver (No other should exists in LE, so it should be safe). Load File, Play buffers, Cleanup Profit??

It would be nice to have a System::Print hook that would allow a user to capture data going to std::out. It should be fairly easy to implement There are a few use cases which this could be used for. 1. Used in creating a log file 2. Easy debug message drawing on screen 3. In-game console log 4. Hacking in functionality that's normally not allowed, such as animating the loading of a Map by drawing something every time a texture, shader, ect is loaded. I'm sure there's more use case.

I am pretty sure it won't work in Lua as the code that runs when you load a map is native C++ code. So overriding the Print in Lua isn't the same as overriding the print in C++. So I think in order to hack in Animated loading screens you have to use C++.

I have an idea. So when you load a map, it is making different Sytem::Print calls to print to the console on which texture, shader, ect it is loading. In a project I did a few years ago, we had a developer who left in all his debug messages. (And there was a TON!). So to get rid of them, I overwrote the built in log function with my own. This function would still log in "development" mode, but would do nothing in production. The following code is untested and is based on some Objective C code I wrote a year ago. Mind you this is only theoretical for C++ version of LE. Not Lua. I also don't know how this will work with Visual studios and C++. I know something like this will work with GCC and C. In theory C++ gets compiled to a C library using name mangling. static bool loadingMap = false; void NewSystemLog(const std::string& s) { if(loadingMap) { Context* context = Context::GetCurrent(); //Draw loading screen context->Sync(true); } } int main() { void(*logFunc)(const std::string& s); logFunc = System::Print; System::Print = NewSystemLog; } // App.cpp App::Loop() { loadingMap = true; if(!Map::Load("Maps/test.map")) { System::Print("Error loading map"); } loadingMap = false; } Since System::Print is an overloaded function what you might ahve to do is surround your code in extern "C" {} brackets and reference System::Print by the name mangled function. When I get home tonight I will test it out and update with my findings.

Wow, I can't believe I never thought of that last night. Dam. I wish LE was better at map loading for a loading screen. Although there are other priorities tbh.

How did you manage to even draw "loading..."? My map has a good 30 seconds of loading textures and shaders before it even hits the map loading hooks.

In any textbox on leadwerks, if you are in the middle of some text in the box, if you press delete it doesn't delete the character to the right of the cursor.

I really wish it came with more RAM. I've always wanted an ARM desktop.For starters, the assembly of ram is lovely. Especially when you compare it to that of Intel.

Time:GetCurrent() returns a long integer value of time in milliseconds since the program has started. There is no decimal places involved. See the documentation. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/time/timegetcurrent-r494