[Leadwerks Levels Up]

The students could work on a 32-bit and 64-bit Linux port too. Make sure they work under 64-bit Debian 6.0 Linux environment, so they learn to write cross-CPU code too, and test it under ARM, PowerPC, Intel, Motorola, etc....

I'll get right on that...

[Leadwerks Levels Up]

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.

[Mounting Weapons Equipment and Armor]

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

[Leadwerks Levels Up]

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

[Mounting Weapons Equipment and Armor]

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.

[On the Naming of Things]

the old forum had a lot less stuff cluttering up the screen... Leadwerks Engine, Content Creation, and General... you'd select a forum, then you'd select a sub-forum (if there was one), and you were there... right where you wanted to be, getting info, exchanging info, interacting with those who had a common interest... now... you've got the gallery in your face at the top... the comments (updates) on the side...

That's the portal page, not the forum?

[On the Naming of Things]

so... in other words... we're pretty much right back where we started, more or less... and it only took us about two years to get here... or there... or wherever...well... lets see if i can find something now... 'cause the last couple of times i opened the page, i couldn't locate a darned thing amongst all the pop up dialogs and sub categories within categories...--Mike

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

[On the Naming of Things]

The problem is, the categories still aren't "catchy" and are still generic. If you want to go the iTunes route, you should think up a neutral catchy name for each category, such as:Lead:Code, or LeadCode.Lead:Art or LeadArt.etc.

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.

[On the Naming of Things]

Art and Sound

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.

[On the Naming of Things]

The articles section will gain tag functionality shortly.

[Design Confusion]

This could be inefficient if it's the case as you could have 20 syntax mistakes and it'll only show you the first one? Then you have to keep syntax checking over and over again? Sounds like a pain.

That's just the way Lua works. It stops on the first error. This actually annoys me about C++ because one syntax errors causes a whole cascade of errors, and you end up with 40 error messages because you forgot one semicolon.

 

Maybe F5 in Editor could be programmed to switch to the Code::Blocks IDE window, and then send a F9 keystroke. That would actually work! Then you can use your favorite language and your favorite IDE, and only the window class and F9 key would need to be configured in Editor. And you would have a debugger too for all languages.

One of my design rules is not to rely on or try to integrate third-party tools I don't have complete control of. This is slightly different, but recall all the problems that arose when I relied on the third-party Newton serialized format.

 

I personally think your Lua design is mixed mode which makes things more difficult. You seem to still want to give an "int main" type Lua file and not fully commit to the Lua model script system for total interaction of the entire game logic for games using Lua.

That's correct. I think a global script is always needed for a Lua game and attempts to abstract that away end up being more confusing.

 

The ability to debug the Lua state of a C++ program is a new idea you have not been exposed to before, but I think it will end up being very useful, especially for professional studios. Think about when your game code is done and artists are producing maps for the game. They'll want to be able to easily launch the game with the current map, and they will want to be able to inspect the Lua state to see if something goes wrong.

[Design Confusion]

I don't see any point in setting up Leadwerks3D to launch command-line compilers for C++ or other languages (though you could). It gets very complicated for so many languages and platforms, and the feedback would be inferior to just using the real IDEs for that language. I just see it as launching either the script interpreter, or your own executable that you define.

 

I've been using C++ so long, that I am used to a big wall of text whenever I hit F5, but I think the feedback when Lua loads a file is just a single error line if anything goes wrong. Therefore, there is no need to print out a bunch of compile information. If you press F5 in the script editor, the Lua file can be evaluated, and if any syntax errors exist, a message box can pop up and the line in question can be highlighted. This is simply evaluating the syntax of the script, not running anything.

 

Now when we want to launch a scripted game, I can either launch it from the script editor, using the script in the selected tab, or I can do it through a "run game" dialog where you define whether it's a scripted game or your own executable. The advantage of the "run game" dialog is you can launch script and C++ games and debug their Lua states in one interface. However, I feel like it's more natural and easier to launch a script by hitting a hot key in the script editor, which is my main point of conflict in this design.

 

Should the debugger and game printed output dialogs be built into the script editor window? That seems logical, but what about C++ applications? Am I going to make a separate script debugger and output window for those? It's a bad idea to have two versions of the same interface.

[Design Confusion]

There's no technical problems. The problem is one of workflow. What is the best way to design this to work? (The UDP socket is actually exactly what I am doing. It allows the debugger to communicate both ways for code stepping.)

[Design Confusion]

Getting the printed output of the program is not a problem. I can just create a process and read the output directly. I'm thinking more about the workflow and ease of use.

[Painting Dungeons]

I want this on my iPad!

[Viewport Navigation]

i suspect that is a reference to being able to automatically frame the entire scene into the viewport with a key press... with the ability to ignore the terrain.

Not a bad idea.

[Viewport Navigation]

The API will be very similar to LE2, unless Josh allows to use the .lib file in C++ directly, then it will cause a big rift between C++ and other languages again, as it did with BlitzMax and other languages in LE2. Using the .lib file in C++ should be possible for the speed freaks, but it should not be official, but only the DLL should be officially documented.

No, actually it's the opposite. The object-oriented commands will be the official documented API, and every language will be made to match that. BMX is an exception, but they are just calling commands from a BMX include file and that's easy.

[Viewport Navigation]

will you also incorporate a 'frame selected' (f key?) and 'frame all' (a key?)---the latter omitting the actual world terrain as an option to set in preferences?

Can you explain this more?

[Viewport Navigation]

BIG HERO NAMED JOSH! when I buy LE3 does it support my already at 50 - 80% done, game made in LE2.x? cheers

I can't answer that. The API is very similar, but it's impossible to say since I don't know anything about your game.

[Leadwerks3D as generic cross-platform 2D/3D application framework]

I'm getting a surprising amount of interest in this from engineering people.

[Moving Right Along...]

It's also one feature I was initially against, but the community successfully convinced me to do it, and I think they were right.

[In Like a Lion]

It's easier to develop for all platforms I intend to support at once. It would be much harder to go back after the fact and find out I have to change things around in a product that is already in use. Past a certain point, I can just write code and not worry about which platform it's running on.

[A Story of IT]

The only thing I'll ever bother using for communities any more is Vanilla Forums. It's the most lightweight I found.

If all you need is a forum, I recommend XenForo.

[A Story of IT]

A lot of times complex systems will run okay with small amounts of data, but if performance scales in a linear manner as the amount of data increases, you will have much worse performance than if you do something clever to change the way it scales. This is true of both 3D graphics and database applications. In 3D graphics, we do things like clustering objects in an octree so that large numbers of objects can be discarded without iterating through them all. In database applications, they do stuff like caching and who knows what else to make applications scale in a non-linear manner. I can't say exactly how database applications are designed because it's not my area of expertise, but there's a lot of work that goes into it.

[A Story of IT]

I believe you could set up a very rudimentary system in two days, but a fully-featured system that scales well would take a very long time to learn and develop.