Jump to content
Ultra Engine Community

Josh

Staff
 View Profile  See their activity

  • Posts

    23,222

  • Joined

  • Last visited

 Content Type 

Blog Comments posted by Josh

    Andy Gilbert

    Posted

    But in the videos I watch of left 4 dead there's a torch being emitted and that torch lights up everything, models and geometry? What I did notice is the torch doesn't effect the shadows of the zombies, but nevertheless they do have some basic projected shadows from somewhere. And I guess this is what's missing the most, simple shadows for animated objects and maybe some dynamic lighting for csg, even if for pc/mac use only.

    That's true. I will add that in. It's pretty simple to do.

    Andy Gilbert

    Posted

    In a renderer designed to run on everything, it's useful to have a distinction between CSG and model geometry. CSG geometry forms the "background" of the scene and is very cheap to render, since no lighting information has to be calculated. If you look at Left 4 Dead 2, the dynamic lighting only affects the models as well. They put a lot of model geometry into the scene, and you don't really notice when you're getting eaten by zombies. If it's good enough for Valve, I think it's good enough for our basic renderer.

     

    It's not really worth it, IMO, to worry about physical accuracy of light when you just want something that runs everywhere. The new deferred renderer will provide very realistic lighting, and the basic renderer is intended to provide a fallback for hardware that can't handle high-end graphics. If it turns out a lot of people absolutely need dynamic lights to affect CSG brushes, it's pretty trivial to add, but I don't want to make spur-of-the-moment design decisions.

     

    Likewise, models do not self-shadow because they just use vertex lighting. I don't think it's worth putting a lot of effort into making a better "fake" lighting system when we can put that effort into writing a new deferred renderer. The basic renderer is meant to run fast on everything, not provide physically accurate lighting.

     

    Now, I can add CSG normal maps by baking the light direction into the lightmap. The challenge there is I want to store the light vector in the alpha channel of the lightmap, not in the RGB components of a second texture. It's not perfectly accurate, but it looks good. (Again, Source Engine uses this approach.)

    Josh

    Posted

    @Pancakes, the flowgraph is meant to handle interactions between objects, not become a visual scripting language. You can use logical scripts and in some cases it's necessary, but if you get too complicated the flowgraphs become just as confusing as code...look at anything done in Unreal Engine for an example of how messy it can get. IMO, if you need to read a manual, it's too complicated.

     

    @macklebee, I will look at what is standard practice in the software industry and do that for the situation you describe. Perhaps there will be some upgrade window of 3-6 months within which the upgrade is available.

     

    @YouGroove, Leadwerks is primarily for people who like programming a straightforward API with native code and Lua.

    Josh

    Posted

    I think upgrades should cost in some range between 20%-60% of a full license. I can't comment on time or price because it depends on the size of the company, how many users there are, what they can reasonably afford, what my expenses are, and so many other things.

     

    We can switch the order around if needed. I'm not really sure who the average Leadwerks user will be in three months. I'm getting inquiries from all sorts of different places.

    Josh

    Posted

    Personally I'm looking forward to Leadwerks 3 as the second coming of Blade3d

    That could be taken a number of ways, but thanks! XD

     

    Actually sir, your bugging me about flowgraphs is what led to this idea.

     

    While I can appreciate your explanations as to why you priced the way you did, I personally have been burned before by developers. I purchased the early adopters license of Torque3D and was promised so many features. They even had videos of the features implemented in the engine. Then all of a sudden, they do a 180 and those features get removed and now we have an open source engine. I swore on my life that was the last time I was going to be an early adopter.
    Yeah, I've seen that happen. Our company is low-risk. We aren't leveraged so a small decrease in sales doesn't kill us. But yeah, I have not been talking about future development because I don't always know how technical details will work out, and I don't think it's right to sell promises of features you will add in the future. We could have taken pre-orders for Leadwerks 3 a year ago, but that's not what I do. I got pretty lucky with Leadwerks 3 in that pretty much everything I set out to do was possible, even though I didn't know anything about OSX, iOS, Android, etc. when I started.
    Josh

    Posted

    I think our biggest advantages are an API design that can be developed with native code, built-in level design tools, and our Lua integration with a built-in script editor and debugger, and gameplay flowgraphs.

     

    We'll have a product roadmap for future development up this week so you can see what we're planning on next.

    BLaBZ

    Posted

    Yes, this concept is very good. They say "nail it, then scale it". In other words, spend a lot of time and effort pre-testing with a small customer base and figure out what they really respond to. This is much cheaper than having a long development cycle and then finding out after you launch that you got it wrong.

     

    In terms of game development, I think this means build a small base of players who really love your game, and focus on the gameplay and what makes it fun. Start with a free playable tech demo. Penumbra was a good example of this, and that later became a full game and then led to Amnesia: The Dark Descent. Don't get hung up on the details, because those don't need to be locked in until you have your final design.

    • Upvote 1
    Josh

    Posted

    I wrote the door script so that as the signal is continually received, it resets the door close delay. This makes it so the door doesn't close on a player if they stay inside the trigger area.

     

    Regarding "not" and other logical scripts, you can add arguments to flowgraph connections, and they will be passed to the receiving function. So yes, you can make a logical script like "not" that tests one condition as an argument, and fires and output if the result is true. You could also make logical scripts for "and" and "or" and have them receive two function arguments each, for the two conditions to test.

    • Upvote 1
    Josh

    Posted

    I need (and thought from the early discussions that you intended to provide) a lowest-level function-based and call-back-based C-API implemented as a DLL, with the corresponding .h file. I don't see how that relates to Lua. The C API should resemble the C++ class member functions with perhaps some extra prepended syntax to scope and associate concepts correctly. Will such a DLL happen? I was counting on it.

     

    Also, can you explain the "ToLua++ clean header file" , the glue code, how the two are related, and where the DLL fits into all of this? My dev eviron can link to a C API in a DLL via STDCALL, CDECL, and FASTCALL calling conventions. The dev environ also supports callbacks from the DLL. This is fairly typical of any C FFI for a dynamic programming environment.

     

    So are we talking about Lua in a DLL?

    Oh, I didn't read that closely. No, we have one object-oriented API. I've got to focus on that right now or we'll never get Leadwerks 3 out. Then we can consider a full procedural one.

    Josh

    Posted

    Josh, is the C API being developed concurrently with the C++ and Lua?

    We wrote a little tool that scans the header files and generates the ToLua++ clean header file, which gets compiled into the Lua glue code. So the Lua API always matches the C++ API 100%.

    Josh

    Posted

    Why should it even be a float? That indicates a small-minded commitment to that a variable is a number. Instead it should be 'LeadwerksDataTypeConstVariableValueRefRealNumberFloat'.

     

    But why restrict it to just Leadwerks? Let's make a data type everyone can use:

    'UniversalDataTypeSystemDataTypeConstVariableValueRefRealNumberThat HappensToUseFloatingPoints'

    • Upvote 5
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...