Josh

Brucey on the BlitzMax forum would be the best person to talk to. I think compiling in BMX would be best because then I could add this functionality into the editor. I don't know enough about how it works yet, so your experimentations are really helpful.

Use a third-party lib.

Oh, I am very impressed with what you have done so far.

Yes.

When I think about the single state with renamed entity functions, it makes sense when I consider the resulting combined source with the main program, and all the included model scripts. The source code the engine makes by doing different script files would look something like this: Graphics(800,600) while KeyHit()==0 do update() render() flip() end function light_directional_Spawn(model) --do some stuff end function light_directional_Kill(model) --do stuff end function vehicle_truck_Spawn(model) --do some stuff end function weapon_gun_Spawn(model) --do stuff end It looks a lot like a C program, like the Quake 3 source for example. It makes sense and seems like a good approach.

Lua inheritance seems extremely workaroundish to me: http://lua-users.org/wiki/InheritanceTutorial

If that's the model I think it is, I did not pay to have it made, I only asked him if I could use it with Character Shop.

There are other ways of doing inheritance, but my function renaming approach seemed the simplest to understand. One consideration was that if I was having trouble understanding table inheritance, many of my users would too, and that would have a negative impact on their experience and my sales.

The function calls for an object, so an integer would not work. Lua is a little different because integers, strings, objects, and tables can all be used in the same parameter. This function has to work with C++ and every other language, so the flexibility of Lua is not something it can support.

SendMessage() is an engine command, so it handles data native to the engine, which doesn't include Lua tables. I mean, does Lua consume an amount of memory significant enough to worry about? It seems we want some data to be shared, but we don't want other data to be. Entities should be able to communicate and call each others' special functions, but we also want model scripts to be simple to write. There are two ways this can be solved with only small modifications: 1. Rename all model script functions with a prefix of the model file name. Instead of Update() you would write light_directional_Update(). 2. Make the engine automatically rename these function names by running a short source code after the script file is run: light_directional_Update=Update Update=nil I am leaning towards option 1. It's more explicit and there are no issues of trying to call a special function later only to find it has been set to nil automatically. The entire combined source code of the state can be printed out, and it is clear where everything occurs. I don't like ambiguity as a general thing. Option 1 is not as cool as just writing "Update()" in each script, but it seems like the most explicit and understandable approach.

This is the biggest advantage. This is not a concern, since no game engine can call random commands on separate threads without locking everything. Is memory use by Lua even an issue? Is it more expensive to run multiple GCs with a small amount of data, or one GC with a lot of data? I have not seen any definitive data on this. I've demonstrated that almost every interaction can be done, but it is awkward, and I do think it will cause problems further down the road. This is the single best argument for a single state. I don't think this is a big issue unless you are trying to store complex sets of data. I could see it coming up during advanced AI implementations. Can't comment on this. True. Are you sure? Where is the proof of this? I have seen the opposite asserted. Is memory consumption of Lua even an issue? The biggest con is duplicate function names and garbage collection. Right now cleanup is simple because when all instances of a model are freed, the lua state for that reference is freed. Cleanup becomes more important when a single-state is used, especially as individuals scripts are saved and re-run by the state in the editor. (When you are real-time coding a model). Not a concern. So the big issues are memory leak prevention, especially when a script is being re-run over and over as it is edited and saved, and sharing data between scripts.

The speed of drawing a line is not a bottleneck. The command you wrote is the same thing the engine does internally.

I assume you are working with the visual geometry, not the physics geometry. This must make the raycasting and other algorithms an order of magnitude slower than if you had the physics data?

Agreed. What have you been hiding?

More force does not mean greater speed. More force is exerted, but because the heavier object has more mass, more force is required to move it. Barring air resistance, a heavy object and a light object fall at the exact same speed. When you consider air resistance, the shape and mass of an object become factors. For example, a person wearing a parachute is much heavier than a brick, but the brick will fall faster.

I'm not sure I understand this. Maybe you should consider logic entities, where you are basic dragging an If statement into the scene.

It's the same in 2.28.

Nilium does know a lot more about Lua than I do. I'm not sure if Lua can pass a pointer to a table back to the main program. Everything I have searched for and read indicates otherwise. Maybe there is a way, but I couldn't figure it out. In the end, the way I ended up associating a table with a BMX object was to put them both into a Lua table. That's why every function starts with a lookup in the entitytable to retrieve the table associated with a model.

http://leadwerks.com/wiki/index.php?title=Vehicles

This game?: Sorry, couldn't resist. This looks really interesting. Maybe I can integrate it into the engine.

Default gravity in the engine is -9.8 units/s^2.0. Gravity on Earth at sea level is -9.8 meters/s^2.0. Since you can change the gravity value, it's all relative, but I recommend using 1 unit = 1 meter. However, you should understand there is no such thing as real units in a computer program. One spatial unit could be an inch, a meter, a mile, or a light year. One weight unit could be a gram, a pound, or a ton. It's all relative. Gravity affects all objects the same regardless of their mass. A piano and a feather will fall at the same speed in a vacuum.

Good point.

The jury has spoken.

That's why you have the source. Lua is just another language to access all the same commands with as you do in C++, C#, or any of the other supported languages. However, it is a free easy to use popular language, so supporting it gains me a lot of new fans. It can also be used with other languages on a per-entity basis. If you're comfortable with C, you've got everything you need already to make a game. A problem we found is that people can get through the tutorials and understand everything, but still don't know how to structure a game. And my response has always been that I can't write their game for them. With Lua, yeah, to a degree I am writing your game for you. But everyone is writing functionality, and it's easy to mix and match components. So it depends on your skill level. Some people use C++ and make games. Some people use BlitzMax and make games. Some people say they want to use C++, but they have trouble making anything with it, and are better off with Lua. Some people just like Lua because it is fun. My personal preference is BlitzMax, but I am finding Lua to be a lot of fun.

Framewerk handles all the effects. You can implement them yourself one at a time, but it is difficult, even for me, to get all of them working together. So most people just use Framewerk instead of struggling with basic rendering effects. It handles DOF, water, bloom, HDR, god rays, SSAO, and a bunch of other stuff, with simple on/off behavior. Lua is quite new, and the integration with C++ is something we have to explore further. This will evolve, but I would not start writing a large amount of code in Lua just yet. I think it is possible to expose all your own C++ classes to Lua and call engine and C++ functions from the script, but we still need to work it out.