Jump to content

Shaping

Members
  • Posts

    68
  • Joined

  • Last visited

Blog Comments posted by Shaping

  1. Congratulations on the LE 3 release, Josh.

     

    $499 for the basic Windows LE3 is okay, and I will buy at least this. I might also buy the Android component--not sure yet. Like many of the others, I do want to know what additional forthcoming features, if any, my $500-$1000 investment buys. What new features and what degree of fleshing-out of the new LE3 architecture are planned for this basic price and by what date? What features must I buy in addition, and by what dates will these be available?

     

    My values differ somewhat from those of most developers posting here. I do not plan on developing a game. That could change. I build simulations involving finely rendered, mostly primitive, programmatically generated geometry and text. I need very good-looking, carefully animated basic geometry and text. I can develop my own domain-specific language (DSL) to do this, but you've done at least some of this with your flow-control system, which I need to study carefully for its usability.

     

    Building models in an editor, importing them, applying textures, and animating them are not tasks I need to do now. Those tasks will happen in a later phase of my project, but we are still talking about mostly simulation/education and not game playing.

     

    Over the last two years, I've studied and watched development of Leadwerks 3, Shiva, S2 Engine, UDK, and Unity. The last two are no longer interesting to me. Shiva and especially S2 Engine seem in some ways promising, but Shiva's rendering quality seems not to be as good as I want, and I'm not sure it will every be. There are too some communication problems with the principals and main players in these groups.

     

    My main reasons for choosing LE3 to do my simulations are:

     

    1) The very good-looking lighting I've seen in the LE2 demos. I need excellent lighting, and need to be able to control it easily. I am hoping also that I can render geometry with the very best AA modes available on my card (AMD Fire Pro V7900). I hope you also eventually support offline, frame-by-frame rendering using ray-tracing, for the very finest and smoothest animations possible. I'd like to know your thoughts on this. I can assist in the effort if necessary.

     

    2) You are a native, competent speaker/writer of English. This matters greatly to me. The Romanians, Estonians, Italians (whom have I left out?) have their problems communicating carefully, and I don't need this added frustration, now matter how promising their engines.

     

    3) I really need that C-API we discussed earlier, for one very simple reason: If your chosen scene construction/manipulation paradigm turns out not to suit my needs, I can use the C-API as a substrate on which to build my own framework, which is what I had planned to do, anyway. (But I will certainly give you scheme a thorough testing before I take that path.)

  2. 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.

     

    Is this a mostly straightforward, possibly somewhat automated conversion process? Any idea how long after the release of the OO Leadwerks framework we will see the purely functional equivalent in a DLL?

  3. 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%.

     

    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?

  4. Josh, is the matching C API also being prepared?

     

    Specifically, do you have a .c file and .h file I can compile to a .dll file on Windows, and interface to with my favorite dynamic language? Syntactically, I am assuming that the form of each function name will be very similar, each being prefixed by an appropriate class name. I can then make my own classes and name-spaces in my dev environ, as needed to encapsulate the C API.

     

    This is exciting. I look forward to a test run with the new C API.

×
×
  • Create New...