Jump to content

Shaping

Members
  • Content Count

    68
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Shaping

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  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.
×
×
  • Create New...