Jump to content

Shaping

Members
  • Posts

    68
  • Joined

  • Last visited

Everything posted by Shaping

  1. Does the updater work across all versions of the standalone version going forward? I reinstalled the standalone recently via exe download between 3.0 and 3.2. I don't know why I thought I had to do that, but I did.
  2. Is there an answer to the above question?
  3. How do I find out when the next normal version of Leadwerks is available and where can I download it?
  4. Okay, I'm not (yet) interested in Steam, but if I were, where would I download this beta? Perhaps we can be more explicit when announcing versions (for Steam or normal/C++/Lua). I'm in and out of the forum infrequently these days, and I'm not tuned to the situation as well as the rest of you.
  5. Where is the download for the new Leadwerks 3.2 beta? I see only the small shapebrush.zip attachment in the above posting. The new Leadwerks 3.2 beta download is not available in my client area. The download there is from 2013.
  6. The above updater shows "3.1" for the version in the combo box, but installs 3.2. Josh, did you intend that, or did you forget to change the 3.1 to 3.2, or is something else happening? Josh, is a new build coming soon? I still don't know how generally to obtain the latest normal (C++/Lua) build from the client area. It was not there this time. DerRidda ultimately posted the correct link above, this time, and I don't know how to find that link on my own.
  7. That seems more than a little roundabout. Why can't I as a standard license owner just find the right link for the latest version of the C++/Lua version of Leadwerks 3.2? Also, I noticed that the menu bar in Leadwerks 3.2 is looking loud and unpleasant with all-capital letters. Can we please use initial caps only, as is the convention?
  8. Above I observed that C:\Program Files (x86)\Leadwerks is the default location. Do you mean to say that C:\Leadwerks is actually the default location? If so, why does it not appear in the path box in the updater?
  9. The download for Leadwerks 3.1 should be accessed at least by the Leadwerks 3.1 link. Why would one choose to click on the root node named "Leadwerks 3 Beta" when one wants Leadwerks 3.1 or 3.2? Can someone please fix this page? I installed using the downloaded zip file from the root node (Leadwerks 3 Beta). It installed 3.0 in C:\Leadwerks, as expected, not 3.1. The link (how did you find it?) above installs 3.2 in C:\Program Files (x86)\Leadwerks. Is this the new default location?
  10. 3.0 did that. 3.1 does not. Indeed. This is what I see under my purchases: Leadwerks 3.1 Upgrade Pre-Order Purchased: 25 March 2014 - 11:39 PM Thank you for your order. Please follow the Leadwerks Company Blog for the release of Leadwerks 3.1.
  11. Yes, I understand that the hack may work, but why did the install not just work? I started from zero, and got a bad install. That means the installer is not cleaning up the old config file or making a new one to agree with the new install directory. I found the Leadwerks.cfg file, but none of the paths look wrong. Can someone tell me where to download a Leadwerks 3.1 installer that does a correct, clean, working install into a designated directory (default or other). "Working" means that the new install does not look for files where they don't exist, and so doesn't auto-create a project to fill-in for what it could not find.
  12. I just found the Leadwerks 3.1 download e-mail from 2014-04-04. Somehow, I missed it, or I've got e-mail problems again. I did a clean install, but first removed the old 3.0 install from C:\Leadwerks. The new 3.1 install was written to C:\Program Files (x86) by default. Is this the new convention? I used LeadwerksUpdater.exe dated 2014-04-05. Do I have the latest 3.1 updater? When I launched Leadwerks 3.1, it declared that it could not find a file it was looking for in C:\Leadwerks (the old location, now deleted). If this is a clean install, why is Leadwerks 3.1 looking for any files in any directory besides the new install directory? Where exactly are we supposed to look when we want to download the latest Leadwerk 3.1 installer?
  13. As mentioned, you would need to pass the object's instance variables by value into the DLL function. You would get one one or more values back from the DLL call and update your client-side object ivars. The object or in this scenario the relevant parts of it (its ivars), as needed by the current function. Yes, but I don't have C++ objects to begin with. I can get close enough, though. I have C data structures on the client's foreign heap that can function as the data part of the object, but not as the function part. That's okay, as long as all the functions are in the DLL, and as long as the shape of that data is as it would be in a C++ object, including alignment and endianness. I just need some extra client-side code to place the Smalltalk object on the foreign heap as a C object. I wasn't thinking about doing that earlier. I wanted to emulate the entire C++ object, but that isn't necessary. So in summary you can pass the parts (the ivars of the object) or pass the whole object. The second creates easier coding, but requires some preparation and will produce a speed hit, because all the St heap objects must be mirrored on the foreign heap. (I'll get back to this any day now and test the idea, but I need first to work some of the simple C++ demos and tuts to see how the rendering loop works.) Thanks for shaking me out of my fog. I thought I was missing something obvious. And to really take advantage of the SWIG, I must pass the whole object, which would be my preference. I've done this sort of thing in the past, where I've taken a set of C++ classes, converted them to matching Smalltalk classes, and then from within the Smalltalk client, at run-time dynamically externalized these objects on the client's foreign C heap, so that some DLL can use them. It works pretty well, but there are start-up and shut-down phases during which the new C objects must be created by the client and then later freed, respectively. It's expensive, and is practical only at low frequencies. Some of our C++ objects (and therefore these matching C objects) must come and go very quickly in Leadwerks 3.0. So, depending on the speed of the C-object creation/release flux, it may or may not be practical. The St foreign heap thrashing will ruin run-time efficiency. That is why I was more inclined initially toward just tail-argument DLL functions and a manual (slow and careful) conversion all needed C++ code. Are the choices and problems making more sense now?
  14. Okay, I see the pattern: SWIG uses always in its flattening functions a list of parameters with a head and a tail. The first parameter (the head) is always the object whose method is called. The remaining parameters are the parameters in that method. The name of the function on the object is the middle of the flat function name. The flat function name here is _wrap_Entity_Translate__SWIG_1. The method name is Translate. I see that the _wrap_Entity_ and SWIG_1 are added automatically by the SWIG wrapping process, and suppose that the user of SWIG can determine what these pre- and post-fixed strings will be. Because the object pointer is the first parameter and is passed-in from the client program, the Smalltalk or the C# is obviously creating and holding the object there either on the heap or transiently on the stack, as methods come in and out of scope. However, because the SWIG-created flat function calls a method on a C++ object, I don't see how to use that function. Where are these C++ objects being created? This was my question above. Where is the state created and maintained, in a C++ environment or in the client Smalltalk or C# environment. I think we both want to do this in Smalltalk/C#, not in C++. So, I don't see the utility of SWIG in this case. My Smalltalk environ has a foreign C-heap but this is not a C++ heap. The foreign heap gives no way to attach procedures to data on the C- heap, as far as I know (I'll check that...). In other words, I don't think I can emulate a C++ object in my environ's C-heap, and that does not seem productive anyway. It could probably be engineered, but the idea is a bit repulsive, because the situation is already awkward, with the head and tail of the flat-function's parameter-list being the object and arguments, respectively. This already is a shape change in function structure. Ideally, I want DLL functions with only the tail parameters (method parameters). (Note that outboarding a class method as a DLL function is not desirable unless the function is very compute-intensive--say lots of matrix math--and the time to marshal the result to and from the C function is tiny compared to the time saved doing the computation outboard with unboxed floats and doubles.) I suppose I can still use the auto-generated SWIG functions, and then just go into those and manually edit off the first parameter, but then I must provide the source code for each of those methods. If we have that in the C++ that comes with our standard license, I'm okay with doing that manually. Yes, it's a lot of work. Do we have all the code to do that? Does anyone know? Josh said that the DLL does not cover all functional areas. Does the C++ source cover all functional areas? If any of those provided C++ methods call or instantiate deeper undocumented/unprovided functions or classes, then I'll be stuck, and will not be able to finish implemented the DLL methods. See the problem? Am I missing something? Can anyone answer my question about the threading model for the graphics and physics? These two are likely running on separate threads. I'll assume also that loads of models, textures, sounds, fonts--assets--are also done on separate threads. I'm assuming that we have a synchronized shared queue that lets the rendering thread talk to the physics thread. I think I can handle three threads in the Smalltalk version of this, for starters. But for the time being, to get something working, I just want to focus on one thread for everything. Do we have a simple tutorial that can draw a finely tesselated sphere? This is where I'd like to start: One good-looking sphere, ambient light, two directed lights, and a short blurb of text rendered with a flat font parallel to and at or near the near clipping plane of the frustum, all running on one thread in a dynamic environment. I have a high-frequency, icosahedral-sphere vertex-generating method in Smalltalk. I've tested it already. I probably want to save that vertex set down as a model, and load it. (Do we have a tut on how to do that?) I'll like to see this simple scene work as a Leadworks 3.1 scene, and build up from there.
  15. Yes, briefly. But why use it? I have an ExternalLibrary building facility in my environ. I feed it a C header file and it creates the ExternalInterface subclass and its methods (one per function). This is the programming environment's model of a DLL and its entry points. That was my point. The FFI of the environment is a C-based one, not C++-based. There is no point in modeling C++ objects on the foreign heap when you can model Smalltalk objects on the native heap, and have just as much speed and better debugging. You get the speed improvements by outboarding compute-intensive methods as C-functions. Wrapping C++ won't get me speed. SWIG looks like a way to use a framework that for whatever reason is not or cannot be modeled in a flat way as functions. SWIG looks like a convenience that has value when the equivalent flat model does not exist. I thought we were working on a Leadwerks flat version, too, which I prefer. Have you benchmarked a C++ wrapping? Guards? Smalltalk does not seem to be supported directly. Are you saying that SWIG produces a description of C++ classes that can be parsed to produce equivalent flat functions? Where is object state maintained? For productive use of one's environ, this must happen in the environment's process space--on the native heap in the case of Smalltalk. If SWIG uses the foreign (C-based) heap, then are the object's instance variables unwrapped and moved to a more global scope? Or do we have no state at all and just C functions? Broadly, the question is: What do we do about maintaining state (object state) across multiple invocations of a function? If the client (the environment) is creating all the objects and hence all the state, then we must pass those variables each time we call a function.
  16. Thanks. I'm studying it now. I know that the C-DLL is not all-encompassing. What functional areas are left out? The main issue is: does it contain the functions I need to build, in my programming environ of choice, an event/rendering loop that works by calling into the DLL and/or by setting-up callbacks from the DLL? Or, is that source in the C++ we get with our standard license? Or, do I need to buy some or all of the source to get this basic functionality? Does the C++ rendering/lighting loop currently run on a single thread? That would be easiest for me to implement as a first go. Does the physics engine also run on its own thread? Is there a place in the documentation that covers these topics?
  17. I must be confused. We have a C-DLL that covers the functions of the editor, right? One could wrap those functions with classes one creates in any language that has a C-based FFI. I want to use as much of the framework I bought as possible, not write a new one. You've already done much of the hard work, and I want to leverage that as I do my own app-level work. I don't mind shadowing the existing framework. I don't want to write a new one, because my time/money budget doesn't allow for it. I asked above what additional functions are needed to implement the methods found in the basic classes for the scene, primitive geometry, lighting model, renderer-- the basic stuff that lets you create a scene either with the editor (not necessary now for me) or programmatically (necessary for me). If those functions exist, where can I find them? I need to wrap them to implement the methods of the basic classes. I don't mind doing that work, but starting over is not necessary. I need to know which C functions are missing and where to get them. In light of what you've said about this not being a supported feature, I'm having trouble understanding why klepto2 would build a C# wrapper using the C-DLL. I want to build a VW wrapper using the same C-DLL. I'm thinking that the rendering loop runs in the C# or in Smalltalk or in whatever language one chooses to shadow/implement the core classes. These would be the same classes that now exist in C++. This issue is not a matter of having or not having a supported feature. It's a basic matter of the form in which the code of the framework can be used. No one can wrap C++ classes from C#, Smalltalk, or any other language with an FFI. We can only wrap a flat C-DLL. What functions must I add to the existing DLL to implement the classes in the basic framework? I want to start this work now. I can't get any useful domain-level work done until I do, and I'm wasting time waiting for a solution from someone else. Thus, I'm willing to do what is needed to re-shape or shadow the existing C++ classes, but the basic functions needed in the framework class methods must be in the C-DLL. Such an architecture is efficient and separates framework-level and domain-level concerns somewhat. It let's me use much of what I bought but more productively. This architecture will render quickly, not as quickly as C++, but I don't care about losses under 15% of the C++ reference. The programming/debugging dynamism is more useful to me. This architecture lets me focus on using what I bought and on writing mostly my domain classes, once the basic C++ classes have been shadowed. I thought that this is what klepto2 was doing.
  18. Josh, I know that you are busy finishing Leadwerks 3.1, but is there a response to the above question? I also wrote you an e-mail concerning this. I'm twiddling my thumbs and and waiting for a basic Leadwerks framework that I can get working in a dynamic programming environment, via an FFI to a C-DLL.
  19. Josh/klepto2, which functions needed to build Leadwerks 3.1 class member functions are missing from the current, mostly editor-centric C-DLL? I'm trying to quantity and quality these missing functions, so that I can estimate how much time/effort I need to write them, and then to build what I need in Visualworks (arguably the most commercially successful and mature Smalltalk environ). At last check, the DLL contained about 600 functions. I need the ease of programming and debugging that VW offers, and I have there many years of work I don't want to port. Porting and having to continue to work in C++ are, for me, two ways of working more slowly toward my goal--an unpleasant thought. In fact, I'm doing in the VW debugger some things that I could never do in VS. I don't want to waste time trying. More up-front time is needed to get Leadwerks 3.1 working in a dynamic language, but I'll be working this project for a while, and the invested time will be worth it.
  20. Where is klepto2? Josh, is the function set in the C-DLL only complete enough to support the editor, or is it complete enough to build all member functions of all classes in Leadwerks 3.1?
  21. Thanks for the update. So how many of us want this? I'm counting klepto2, Wchris, and myself. I think we have the same thing in mind. Yes, we need correctly named formal parameters in all function or method calls. This is especially true for Smalltalk, where the keywords in the method selectors each name the formal parameter. As a contrived example we want DrawPointX: x y: y and not DrawPointX: arg1 y: arg2. You lose lots of reading speed and comprehension on long parameter lists, with the generic argument names.
  22. Hi Wchris/klepto2. Where are we sitting now in the development of a C-DLL equivalent (or basis) for Leadwerks 3.1? This is for those of us who enjoy the productivity of a dynamic language (or any language offering an FFI) and who are willing to wrap those C functions with their own new classes in the new language.
  23. These 600 "commands" are really just class member functions in the C++ framework, correct? Are you saying that you have equivalent flat versions (C functions) of some of these 600? I count about 505 non-commented-out function prototypes in the DLL header file. But I don't really expect these functions to map directly to the all of the member functions in the classes; so comparing these counts is likely not very meaningful. After reading Kepto2's posts, I see that they are two years or older, and don't relate to L3. I sent Klepto2 a PM. Is anyone else working toward a flat C-API-based version of L3 that they intend to use using directly, or wrap with their own classes? I don't need Lua if I have a flat C-API.
  24. I will be interfacing VisualWorks to the C-API DLL, because I prefer to develop with a dynamic language, and I've already done many years of work that I don't want to port. I'm trying to understand which functional areas are covered in the DLL and which are not. Josh has told me that the DLL is not a complete functional equivalent of the C++ class hierarchy, and that the DLL is currently used by the editor. Josh, can you tell us more about what is missing from the current DLL? I would like to see you support the DLL (the functional version of the framework), which is what I thought you had planned from the beginning. If you don't have resources for that, I understand, but please help us along with some suggestions for our own extensions to the DLL. I will probably be doing a lot of this, and I would be happy to contribute my additions to the product.
×
×
  • Create New...