Josh

Lua's debug hooks are a little funny, because they don't appear to allow line-by-line calling of your own function. The description here is pretty vague: http://pgl.yoyo.org/luai/i/lua_sethook The line and count hooks look like they might be what I wanted, but the docs have one big caveat: This makes me wonder what the point of these hooks even is. The way I have it set up now, "Step" continues to either the next Debug:Stop() call, or to the next point where a Lua function is called. Not C++ functions, Lua functions only, as shown in the code below. Additionally, I found that each time the hook was actually being called twice. No idea why, but I added a flag to discard every other call. I'm not too happy with the documentation of this or it's design, but the important thing is that the Debug:Stop() function be usable to set a program breakpoint, which it can. I sent a query to the Lua mailing list, and I'll work on it some more if anyone indicates that it's supposed to be able to do line-by-line stepping. I did some additional work on the shader editor, adding a few ideas I got from the script editor. The tabs for errors and warnings will show a number indicating how many items each tab has. I also made it so the compiler output gets printed even when the shader is successfully compiled, which wasn't the case before. As you can see in the screenshot below, the shader editor can be very useful for catching problems that might occur on other cards. I have an NVidia GEForce 480 in right now, but I can see from the warnings list this shader probably would not work on other hardware! This is becoming very useful as a diagnostic tool. Well, that was my day today. What did you accomplish today?

We use the standard interface for Windows and Mac, and these don't support line numbering. You can double-click on a function in the debug tree to go to the appropriate line, and the current line number is displayed in the status bar. It's a compromise, but the native text rendering looks sooooo much better than Scintilla or something like that. That's a good point. I'll see what happens when I start actually using it.

http://www.leadwerks.com/werkspace/page/Documentation/le2/_/tutorials/

YES.

In my last development blog, I wrote about some design problems I faced, and why I wasn't sure how to proceed. I've resolved these issues by building the debugger and game output display close to where they will be most likely to be used, the Script Editor. I was pleased to find that my Lua debugger code I wrote about a year ago works perfectly. This allows breakpoints, code stepping, and the display of variable values in your game. It works with any Leadwerks3D executable, so you can even examine and debug the Lua state in your C++ executables. (This does not debug C++ code or other languages, as there are already appropriate tools for that.) I like to combine the callstack and variable display into one tree view, so you can quickly navigate the program. I decided it made sense to build the game output and debugger into the script editor, because that is where you are most likely to use it. Even if you are debugging Lua in a C++ application, you still want to be able to double-click on the call stack and display a script in the editor. The only situation where this design doesn't really make sense is if you launch a C++ application and just want to look at the program's output. In that situation, it is a little strange to need to open the script editor to do that. The actual executable to be launched will be controlled in the project settings. The default for a Lua program will be a copy of the interpreter executable that gets added the project folder. You can specify the script in a command line field, like this: +script $scriptfile Where "$scriptfile" gets replaced with the file name of the currently selected script file in the script editor. For a C++ application, the project will simply be set to call the executable the C++ template sets up a project for. If any of that sounded confusing, take a look at how maps are launched in 3D World Studio (or even Valve's Hammer Editor, for that matter). The bottom line is it's set up automatically when a project is created, and you probably will never need to change it, but the capability is there if you need to. Previously I wrote that it's better to name a thing with a specific name that describes most of what it does, rather than to broaden the description to become fully encompassing but vague. The same holds true for program and workflow design. The debugger and game output display are built into the script editor, where they will be the most useful overall. It's not "correct" in a hyper-analytical way, but it makes sense and is convenient.

For leadwerks engine, c++ is probably best. For leadwerks3d, Lua will have better debugging support, and be easier to use than installing all the different SDKs for mobile platforms.

If it's not a right angle, it's a wrong angle.

I'll get right on that...

Aria is kind of off and on when needed, but the Android stuff is done. I'd like to get a couple of students to help write the command declarations in the docs, and whatever else they can do. We'll see.

Ah, that is a little more complicated then. I just thought they were supposed to be completely stiff.

As you can see, the bloom effects are fantastic, but the chair looks a little fake.

I think your boots deforming means they use the skinning shader and have animation data, which is definitely not what you want. If you change that and still have any problems, I would like to see.

That's the portal page, not the forum?

The position and normal are in global space. There is no way to reposition a physics body without losing one frame of physics interactions, but you are unlikely to run into trouble. I would just get the velocity and angular velocity, then reposition the body, then set the velocities to what they just were. I would probably not do this in the collision callback, just set a value and then reposition the body after UpdatePhysics is finished, back in the main program body.

What if the iPad 3 has a 1080p display? What if Apple includes a standard gamepad controller with it? The game industry would instantly **** their pants. I wouldn't be surprised if one of the big consoles goes with mobile processor and graphics technology for the next round, since the cost, heat, and graphics quality are so favorable. This stuff is evolving very quickly.

It is not clear to me what you are referring to.

I wasn't referring to the "i" prefix, I meant to point out that iTunes is named for music, but does a lot more. However, the more specific name that captures most of what the program does is actually better than calling it "iMedia" or "iContent" or something more nebulous.

Your friends are likely to be gamers who like playing games. There are enormous numbers of people who are not gamers, who do not really like games, who bought consoles last round because it was popular, Wii and kinect in particular. The console industry has become dependent on this larger market of non-gamers, thus all the focus they are putting on motion controllers and gimmicks. According to this, console hardware and software sales are down 40% since last year. That is decimation: http://www.vgchartz....es-still-dying/ My thesis is that a new round of consoles will not fix this. Improved graphics alone will not provide enough benefit because we've already established that people are perfectly happy playing with vastly inferior visuals. Improved graphics wasn't even enough with the last round of consoles, which is why Wii and Kinect were the big winners, and the improvements will be less this time around. I expect to see lots of gimmicks like the Wii-U. There's a rumor the new XBox will have a touchscreen built into the controller. If this turns out to be true, it will be a clear signal they are desperate and have no idea what to do. Read this article, it's one of the smartest things I have read: http://www.cracked.c...om-e3-2010.html

That's interesting you would say that, because I used to catch myself giving things plural names a lot. I am strongly opposed to giving a thing two names. I used to do this in the Asset Store categories, like "Materials and Textures", "Barriers and Fences", etc. and I purposely made a decision to reduce these to one word.

The articles section will gain tag functionality shortly.

A world does have to be created before any entities, but I would like to see your entire script so I can run it myself.

If your body is parented to the camera, you will need to transform its position from local space to world space to get the correct position for the call to TerrainElevation(). See TFormPoint().

The design of the Leadwerks website involves organizing a lot of different kinds of data that are continually growing, including forum posts, blog entries, gallery images, videos, and downloadable files. All this information was organized in categories, and sub-categories, and in some cases, sub-sub-categories. The depth of categorization made it impossible to follow all the information that was flowing through the site, and users frequently posted in the wrong place. We recently underwent a restructuring of this information in an attempt to make all categorization only one level deep and streamline the viewer's experience. In this article, I will share with you some ideas I learned from this process that were not immediately evident to me. Programming Forums Originally, we had one main "Programming" forum for general programming discussion with several sub-forums which were meant to be used only for discussion of issues specific to each language, like compiling or editor problems. It didn't work out that way, and the community was fragmenting along programming language. Each group tended to participate in only the sub-forum of their language of choice, and I found myself answering the same questions repeatedly, for different languages. I don't know if this was related, but there was also a lot of territorialism among the various factions, with many arguments over which language should "win". Arguments occurred over which languages warranted their own forums. I also felt like the forum had grown beyond my ability to absorb, and had stopped reading the programming forums some time ago. With the arrival of the tagging feature in our community software, I felt it was time to merge all the programming forums into one, using tags as a 'light' way to sub-categorize posts. I chose to leave the Lua "Script" forum separate for two reasons: If we do an "indie" script-only version of Leadwerks3D in the future I want separate permissions for that forum. To protect beginners from intimidating low-level programming discussions. Which isn't to say anyone using Lua is a beginner, but beginners tend to prefer script. Although there was initial protest against this plan, I went ahead and closed the programming sub-forums for new discussion, without losing them just yet. I also made the Lua sub-forum a top-level forum and renamed it to "Script". My job is not about promoting other technology's brand names, and the user doesn't care much about the underlying technology, so I felt this was more appropriate than "Lua". Other Forum Categories We also had forum categories for sound, materials, modeling, and shaders. All of these sub-forums were merged into a single forum called "3D Artwork". Calling game sounds "3D artwork" may not be terribly accurate, but I'll get to that later. Gallery and Videos At the same time, I was working to simplify the entire contents of the Leadwerks website. Previously, we had gallery images and videos divided up by product. The gallery had four sections for Leadwerks Engine, 3D World Studio, our upcoming game development software Leadwerks3D, and a fourth category for miscellaneous pictures and photos. The videos section was also divided into three categories, by product. I decided to merge all videos into a single category, and replaced the gallery with a custom implementation that simply displays all images in chronological order, with no attempt to categorize them. Asset Store The Leadwerks Asset Store too was broken up into many sub-categories. The code section was subdivided by programming language, and we had similar issues as we experienced with the programming forums. Although Java was not an officially supported language, there was a lot of material available for the language, so a sub-category was created for it. I felt odd having all these "brand names" scattered across the Leadwerks website. We moved everything into a single "Code" category, using tags to specify what language a file was for. Portal Additionally, I implemented a community portal page which shows all recent forum posts, images, videos, status updates, blog entries, and asset store files. Items are displayed in chronological order, with no sub-categories. The new face of the Leadwerks community. The Result The reorganization of the programming forums was the most drastic change, and I think the community has generally agreed the change was for the better. I am once again active in the programming forums, and it's easy to keep up with current discussions. I made the final change and merged all posts from the programming sub-forums into the main programming forum, then deleted the sub-forums. The site overall is much easier to follow, especially the videos and gallery images. A chronological stream of recent items trumps sub-categorization, any day. Because there are fewer sub-sections to check on, it's much easier for me to keep up with the flow of content. Although I don't have any statistics to back this up, I feel like the community is more active now than before the change. Choosing Titles I have learned that slightly inaccurate and specific titles are better than encompassing but vague titles. For example, I removed the "Sound" forum and moved all posts into the "3D Artwork" forum. Is it accurate to include posts talking about video game sound and music in a forum that is mostly devoted to discussion of 3DS Max and Photoshop? Probably not exactly. Would it be better to call the forum "Game Assets"? You might be inclined to go with this suggestion, if you are an analytical type, but consider the following: iTunes is Apple's online music store. It was originally built as a program to purchase and sync music for iOS devices. Movies were added to the program's features, and the title "iTunes" was no longer exactly accurate. Would it have been better for Apple to rename the application to "iMedia" like "Windows Media Player"? It would be more accurate, but no one would have any idea what it did. When apps were added to iOS, iTunes gained the ability to manage applications as well. Should the program be renamed to "iContent"? It's a more accurate description, but it's so vague it loses meaning. iStuff? The name "iTunes" is catchy, and it describes the main point of the program, even if it doesn't encompass all functionality of the program. This is a weird idea to me, because as a programmer, my inclination is always use a broader and broader term until I reach one that encompasses all characteristics of the thing it describes. However, I am certain that a catchy title that describes the main point of the thing it describes is superior. With this idea in mind, it makes perfect sense to include game sounds and music in a forum about 3D game artwork. It is exciting to me to learn something that is illogical but self-evident. Conclusion When you categorize things, choose fewer categories with descriptions that encompass most of what they contain. Never get too analytical about the categorization and naming of things. Instead, just go with what feels more natural and catchy, even if your nomenclature is slightly inaccurate. We still have one big contradiction of this idea on our site, the use of the term "Asset Store". Leadwerks3D actually uses a class called "Asset" as a base class for textures, materials, shaders, and other objects, but about 40% of total files, and 100% of paid files in the store are 3D models. Additionally, the term "Asset" still isn't broad enough, because code files and games are not an extension of the Asset class. It would not be out of the question to rename the Leadwerks Asset Store to the "Leadwerks Model Store". The analytical (and much worse) extreme would be to call it the "Leadwerks Digital Goods Store". Keep your names short and catchy, and don't try to broaden them to encompass every aspect of the thing that they describe.

I agree it will not have as good of visibility, but we can't have all these Doc, Powerpoint, PDF, etc. files. What's wrong with the built-in text editor?

I decided to make articles/tutorials all one section. Previously I have been guilty of micro-sorting things on this site, and I got better results with broader categorization, which is another idea I want to blog about soon...