Josh
-
Posts
23,328 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Josh
-
-
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.
It is as far as I'm concerned. He asked for my opinion, after all, and I gave mine - if memory use isn't a concern of yours, then that's fine.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.
-
Pros of multi-state:
- Everything is definitely separate
This is the biggest advantage.
- The different states can run in parallel
This is not a concern, since no game engine can call random commands on separate threads without locking everything.
Cons:- Memory use sky-rockets
Is memory use by Lua even an issue?
- You're going to be running as many garbage collectors as you have states (this is expensive)
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.
- Communication between states is incredibly difficult
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.
- Accordingly, everything you share is duplicated between states, and keeping those objects in sync can be a nightmare
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.
Pros of single-state:- You can have separate execution contexts, as with the multi-state setup, by using Lua threads
Can't comment on this.
- Sharing data between threads is easy, keeping things in sync is easy.
True.
- One garbage collector handling it all, less expensive overall than 30 to 100 or more garbage collectors running every X frames.
Are you sure? Where is the proof of this? I have seen the opposite asserted.
- Memory consumption is significantly less.
Is memory consumption of Lua even an issue?
Cons:- You can't entirely guarantee there's zero communication between threads/execution contexts (it's not really an issue, but I suppose in a secure environment, such as in a server, you would want them 100% separate).
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).
- Lua threads do not run in parallel
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.
-
Agreed. What have you been hiding?
-
But to be a little off-top, I keep seeing the misconception that hammers and feathers fall at the same rate in a vacuum. Which would be true if the objects didn't have mass. But a Hammer or Piano has a substantially greater gravitational field than a feather. They would actually fall faster, just not on a scale you would notice. But it's important if you plan on throwing large objects at nearby planets.
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.
-
-
Sorry for the delay, I didn't have access to the this forum. Recast is NOT my work, I've intergrated the library with Leadwerks. Recast is the work of chap who did the AI for crysis, so fairly good pedagree.
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.
-
Aye I did see that in the Wiki. Though I worries me a bit that there is in fact just an on/off switch. How does one modify the features? For example, bloom/HDR appear to be a little too over-bright by default. I understand the idea is to simplify the whole process, but I do think I'll require at least a little customization.
That's why you have the source.
How do you see things evolving though Josh? Do you have a 'perfect world' design paradigm or have you included LUA primarily as another language to use such as BlitzMax or C++?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.
-
This is presently not supported, but rest assured it will be soon.
-
Hooks
in Programming
It just means you can turn functionality on and off with a single include file.
-
I think you will find the results are not as good when you try to apply a texture to fade them along the length, when a cylinder is used.
-
Hooks
in Programming
You can add update loops to the main loop while keeping all the code contained in one file.
Let's say you include a script that has to update something every frame. Instead of adding extra code in the main loop, you can add a hook in the included script, and that way you only have to include a single file. It just makes it easier to mix and match components.
-
Hooks
in Programming
What do you think?:
AddHook(hookname,function)
RunHooks(hookname)
Example:
AddHook("UpdateHook", UpdateBullets() )
AddHook("UpdateHook", UpdatePlayers() )
Then somewhere in the main Lua loop:
RunHooks("UpdateHook")
This can be coded entirely in Lua. Does gmod do anything fancier than this?
-
I would. Load it from a file so it is instanced. Or you could create a mesh manually and copy it for each tracer. I don't think you will ever have more than 10-20 onscreen at a time, so performance isn't a concern.
In the final version, I would have a cache of tracer mesh instances you just hide and show as they are needed, instead of creating things dynamically, but there's no need to worry about that until the basic version is working. Oh hey, here's one example where a single lua state helps, because the tracer cache can be shared across multiple guns.
I think your hook suggestion from gmod is a good one, too.
-
Why would you want the particles facing up? If you looked at the particle from the side it would become invisible. You want it to face the camera, and be aligned in the direction of travel.
Is there any particular reason you want to use a particle emitter for tracers? It seems like an individual mesh would be easier to control.
STRANDED - The Game (WIP)
in Showcase
Posted
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.