Rick

Would be nice to have the ability to loop over files as part of the FileSystem class so that it's crossplatform and part of LE.

True Olby. A day doesn't go by that I don't have a game automatically updated on steam. Now that updates are automatic and done behind the scenes and are generally unobtrusive to the gamer devs can get away with this kind of thing.

I'm sure this wasn't intentional but I recall Josh posting an article once about MS having a moving target for their platform that developers had to deal with. The idea was that they were more doing it on purpose but I see Leadwerks (and other software) doing the same thing so I don't think these kinds of things are on purpose. I think they are just a natural part of software. You have to release a product at some point even if it's not ideal at the time of release. Then you go back and refine it and change things. So maybe Josh will take it easy on MS now that he's doing the same thing

I'm not sure I follow. If I update the model the name stays the same. Save the last incremented number in the mdl file so when you have to update it you pull that value in the original mdl file before updating it. If someone manually deletes the mdl file and then re-adds on adding check for this filename with numbers and find the largest number and give it 1 more. If you store the incrementing number in the mdl file then if it gets renamed it doesn't matter. Just pull that number and increment it.

That's what an auto incrementing number at the end of the name is for. That's a pretty universal method for giving unique names.

This fits nicely with what I've always said about all names should forced to be unique anyway to avoid issues. I like mac's idea of a dropdown. Maybe a dropdown that we can type into (I think this control is fairly common) and while you type it filters the list shown.

Nevermind. Looks like this works: surface->CopyTo(pixels, uiTex->GetWidth() * 4, 4, true, false);

Playing around with awesomium to see what it's about. I'm having issues trying to get the contents of the awecomium buffer to a leadwerks texture. The screen is just black. Just curious if anyone has done this before and has any tips on how to do this. Texture* uiTex = Texture::Create(window->GetWidth(), window->GetHeight()); unsigned char* pixels = (unsigned char*)malloc(uiTex->GetMipmapSize(0)); // copy surface to LE texture and draw that texture to screen BitmapSurface* surface = static_cast<BitmapSurface*>(view->surface()); if (surface->is_dirty()) { //surface->SaveToPNG(WSLit("C:\\Users\\Rick Piller\\Documents\\awesomium.png")); surface->CopyTo(pixels, 1024, 32, true, false); uiTex->SetPixels((char*)pixels); context->DrawImage(uiTex, 0, 0); } Saving the surface to png (commented part out) works so I know the surface from Awesomium is valid. So clearly I messed up the CopyTo() part. I just hardcoded some values for testing but I'm not 100% how this is working behind the scenes but pixels is the same value before it goes into CopyTo() as it is when it comes out so clearly something about my parameters are messing this up, but not exactly sure how they work compared to the LE texture. Here is the Awesomium CopyTo() functions header: /// /// Copy this bitmap to a certain destination. Will also set the dirty /// bit to False. /// /// @param dest_buffer A pointer to the destination pixel buffer. /// /// @param dest_row_span The number of bytes per-row of the destination. /// /// @param dest_depth The depth (number of bytes per pixel, is usually 4 /// for BGRA surfaces and 3 for BGR surfaces). /// /// @param convert_to_rgba Whether or not we should convert BGRA to RGBA. /// /// @param flip_y Whether or not we should invert the bitmap vertically. /// void CopyTo(unsigned char* dest_buffer, int dest_row_span, int dest_depth, bool convert_to_rgba, bool flip_y) const; I'm not 100% sure what dest_row_span would be from leadwerks. I'm also not sure what dest_depth or if I would need convert_to_rgba or flip_y. Those last 2 are boolean so I could figure them out I think once I get what dest_row_span and dest_depth should be as I suspect those 2 are causing me issues.

Seems misleading in description to what it does to me, but OK.

The C++ code has some oddities in it now that the templates have merged. It still has window, context, world, & camera pointers in the App class even though they are never created in C++ anymore. The App.cpp file is looking fairly bloated. It just seems kind of weird and while a C++ person may be more experienced it may be best to have a some of this stuff cleaned up a little. Perhaps add the app class as part of the leadwerks library and the source the customer sees derives from it and the base is called that does all this stuff. If we don't want to use the Lua files then we can simply comment out those base calls to Start() and Loop() and put our own code for our games. That would look much cleaner on the C++ side of things. class MyApp : public App { public: virtual bool Start() { return App::Start(); } virtual bool Loop() { return App::Loop(); } }; Perhaps instead of MyApp you use the app name. Could even leave the App class as part of the source files if we want to see how to do some Interpreter stuff since it is a good example of how to do those things, but the above is just a nicer experience for the customer (even C++ customers).

Why would not calling window->Closed() cause the window to freeze and not respond to anything? Isn't this just when pressing the X button on a window? If it's fullscreen you shouldn't need this right? There must be some window updating going on in here which I don't think makes sense. If that's needed shouldn't we have a window->Update() or something?

Where is .type coming from? My guess is that's nil and so a nil would be not equal to 100 so it would print false. I think you mean: if v.val ~= i then

I mean you can make it any value and check you want. A common idea is that a 0 means empty and a 1 means something is already there so you can't put another there. And by having it only 2D you can't build upward/downward which I would guess you would like to do at some point.

I think you would use a 3D array (widthxheightxdepth) to store what "tile" is filled or not. Now this is all a very basic implementation of all of this. If you plan on allowing creation and destruction of these things like in a minecraft clone than this would be the best way to do any of this. Those things get more complicated on how to handle it.

I actually found a nice one that seems to be better organized. These open source ones are all a mess from what I've seen. I'm just tired of hacking things together and want a company that I can get support from. https://coherent-labs.com/buy-coherent-ui/ I contacted them to see if we could get an indie version like they do for unreal and unity. I really want the html/css/javascript stack since I think it's the best way to go for UI for the reasons I listed above.

We are looking at NoesisGUI because of the lack of GUI with LE. It's probably the most frustrating thing about LE honestly. Having to pay for a GUI that costs basically the same as the engine itself. GUI's are actually very complicated things to get right (to make sure things scale and position correctly and supporting enough controls, while being easy to work with). I first made my own very basic one with LE commands but it was only for 1 resolution/ratio and no real controls but exactly what was needed but it turned out very hacky (as expected for a quick thing). I then went on a search for web technologies that could be used since there are so many libraries out there to give so many different kinds of functionality for the web. However, all options sucked and were hacky. I still think the ideal world of UI is through html/css/javascript and functionality that can easily hook javascript to C++ or Lua. html/css/javascript is very powerful in representing UI and there are already so many libraries out there as I said before. Sadly it comes with a lot of baggage as people try to force your game into a webpage vs just displaying the webpage over your game and/or some solutions require an entire browser to be added to your game. Ideally there would be a thin html/css/javascript layer in a C++ library built into an engine. Now we are looking at NoesisGUI. The goods being that it uses a common language to describe the layout "wpf" and it comes with all of wpf's controls and easy ability to nest controls together (since wpf is basically xml). You can also use MS's freely available editor Blend or VS to visually make your UI. The bad is that it's pretty complex if you don't know wpf and wpf takes some time to get to know. Especially when you are doing a game UI which is far more complex than a normal business app (inventory drag/drop and such). One great thing is that a lot of ppl in the world know WPF so if you wanted to hire a professional to help it's very doable. This would also be a huge benefit for html/css/javascript UI libraries. Most game engines are propriety in their UI's which means the amount of people that you could have help or hire drops significantly or learning it does very little for you in other areas of technology. What I've found is that this is a space that is really lacking in the game industry. If I were rich and didn't have to work I honestly would be working on making an html/css/javascript UI library for desktop games that easily integrates into OpenGL and interaction easily maps from javascript to C++/Lua, without all the huge overhead that it currently has (which is mostly security features which aren't needed in game UI's for desktop apps. html/css/javascript probably has the most people available who know it in the world compared to other options and there are so many free libraries existing for it. Not to mention MS is also embracing it for their UI's for metro apps (they haven't gone away from wpf but they really aren't doing much with it either but the writing is on the walls if you ask me). This is why html/css/javascript is ideal. It's not going anywhere anytime soon. I'm pretty sure it's the biggest (most users) and longest lasting library to represent UI with and there is no sign of that slowing down.

function Script:UpdateWorld() --обновляет камеру каждый фрейм self.UpdateCamera() end should be self:UpdateCamera() not self.UpdateCamera() (colon vs period)

Just note that you may run into performance issues if you have a ton of entities. LE doesn't like a ton of entities so you may have to lower the view distance to be fairly low to help out the performance pending on how many entities you end up with. I know we ran into this when we were trying to do something similar with our game and making houses in a very modular way.

In Lua it's a string

You need to call DrawImage() after world->Render() and before context->Sync(). You see world->Render() draws the 3D world to the buffer and context->Sync() draws that buffer to the screen. The place you have DrawImage() gets overwritten by the 3D world being draw to the buffer. That's why you don't see it.

This seems fine, but the trend we are seeing is Lua getting a ton of focus and C++ sort of being pushed aside. Now I'm fine with that as long as you don't drop allowing us to code in C++. Your pattern generally becomes removing features when you deem something else is best to focus on (instead of just leaving it there) and I just want to make sure you aren't thinking of removing us from having the C++ library to code in and just giving us a pre-built exe and force us to only use Lua.

I may be weird but I actually prefer learning random bits here and there since when I come to a new engine my goal is not to learn the engine it's to get what I wanted to do with the engine done. I think we'll find the people who ask a lot of the questions are the ones who are like me and don't go through step by step structured learning. They often are artists who just want to get x working and are only interested in trying to get x going and not going through hours of other stuff that isn't directly related to x and therefore is meaningless to them at that time when all they have in their head is x. An example to this wold be "How do I make a HUD?". The question we hear very often. Well, a person could go step by step through all the tutorials that don't directly talk about how to make a HUD and if that person isn't already a programmer, they may not be able to directly translate what they have learned into how to make a HUD. Reading the large "here's a game" sections also talk about so many different things and if a HUD is in there somewhere then it's hard to remember where you found that information a few weeks or months after the fact because it's blended in with all this other information. I personally think the gameplay sections shouldn't be full games (or still have those but in other areas). The gameplay section, I think, should have a bunch of smaller examples of gameplay elements that aren't fit together in anyway to an overall game. The HUD example is a good one. Just show how to make a HUD that has some basic stuff to it and ideas on how to expand on it. But don't put controller, AI, other stuff in there. Inventory system(s) would be another. Basic AI could be another, etc. Putting them all together in an actual game can be nice but it also makes it harder to pull just those sections that you care about out. Those are my thoughts on this anyway. I prefer to learn while doing the specific thing I want to do vs just generally learning the engine itself because there is so much information to an engine that learning all the basics and then trying to translate all of that to my specific needs I find to be difficult. I would have learned so much that I will just forget in about a day because it wasn't related to my specific needs. Specific needs are often general enough though to make tutorials on. There are only so many game elements out there and if someone is trying to go outside those game elements then it's more acceptable that it'll be harder to figure that out.

I think the idea was to get procedural levels which comes with the benefits of having unlimited level designs since it's put together in code with some randomness, making replayability much higher and more interesting.

Using booleans like this is just setting states on and off. States being the state your game is currently in, or do when to run certain code. The above is a poor mans state machine. It's good for learning the idea but becomes horrible to maintain in bigger projects. Then one starts thinking of code separation to make it easier to read and maintain and one can come up with all sorts of interesting designs to do this. The switch statement would be the next step after booleans and then entire classes! Designing is fun

It really sucks having all these subsets of OpenGL. I mean everyone can see the end result is 1 version of OpenGL able to run on basically everything. Wish we could just get there already. OpenGL, OpenGL ES, & WebGL come on hardware let's get this done