Jump to content

Josh

Staff
  • Posts

    22,901
  • Joined

  • Last visited

Everything posted by Josh

  1. Loading a model, loading a mesh, or copying either will all result in the minimum number of vertex and indice buffers used. Every instance in the engine will use the same data and be rendered in a single draw call.
  2. The C++ object debugger for Lua is working now. It was a little tricky, but I implemented a method to view all members of C++ objects. The debugger does handle dynamic object fetching, so if you expand a node in the debug tree representing a C++ object, the contents of that object will be loaded and displayed. Let's say you have an entity parented to another entity. This allows you to expand the parent member of the child, then find the child in the parent's child list, and so on, ad infinitum. If you're interested in how this works internally, every class in LE3 is derived from a base class called "Object". The Object class has a virtual function called Debug() which returns a string in a format like the following: entity={position={x=0,y=0,z=0},rotation={x=0,y=0,z=0},scale={x=1,y=1,z=1},parent=0x00fh7fC} This is read by the debugger and used to create more readable nodes in the debug tree. The hex address listed for all pointers can be compared to values in C++ or another language, if needed. Classes that are used as direct objects, like math classes, and, well,. nothing else, simply output their data like this: v={0.0,0.0,0.0} Hard to explain, but easy to understand when you just look at the debugger.
  3. I actually could cast it back, since I am using pointers and they'll be fine as long as they aren't deleted, but I don't think I will be doing that. Anyways, it works. See my blog for details about the Lua debugger.
  4. Here's the proper way to convert to an integer and hex string, and back: int pointer = (int)(int*)o; std::string hex; stringstream ss; ss << hex << pointer; hex = ss.str(); int l=hex.length(); for (int h=0; h<8-l; h++) { hex = "0"+hex; } o = (Object*)pointer; return "0x"+hex;
  5. I'm actually storing the object in a map, looked up by the hex address, but I like to display the hex address because it can be verified in any programming language. I always found it weird how C++ programmers are so scared of this idea. It's just a block of RAM.
  6. I don't see why it wouldn't work. It's just a memory pointer.
  7. In theory, this works: Object* o= (Object*)&pointer; But the program says the second pointer is not the same as the original.
  8. My example above is not the actual code I am using. The object pointer is pointing to a valid object.
  9. I'm actually getting the same hex address from each object, but only the original pointer seems to be recognized.
  10. I can convert an object to an integer as follows: Object* o; int pointer = *(int*)o; What is the reverse operation to get an object from an integer?
  11. Yes. Object slicing with ToLua isn't an issue as long as you keep the object in Lua memory somehow, so I just add all relevant object to a global table.
  12. Josh

    Tools and Stuff

    Yeah, that is in the design spec.
  13. Josh

    Tools and Stuff

    The script editor and Lua implementation is very close to being a usable programming environment. You can actually see the pointers to the C++ objects you create, and step through code. It's still missing features, but the parts I was worried about are working. I am adding Lua commands like crazy, and it's easy to keep track of them because they all reside in one header file. The function overloading is great, as you can see in my example here, where I use a single float value to set the ambient light color. There's also a new Camera::SetFOV command. I also fired up the editor for the first time in a couple weeks, and it immediately struck me that there should be single texture, shader, model, etc. editors, instead of creating a new one in a window every time an asset is opened. That and I want to make the interface more like 3D World Studio are the two things I will be working on in the editor. I'm nearly ready to start writing the scene editor. That's not an area of new research, so it will go a lot faster. It's just a lot of work and careful planning, but no more crazy unknown parts that I'm not sure will actually work. All in all, the tools I am using now give me complete control to give you the best experience possible, and I am really happy with Leadwerks Engine 3 so far!
  14. I've got a GEForce 480, and I'm not sure what it wouldn't be able to run. It's monstrous.
  15. Josh

    Too Cool

    Something like that. There's a few ways I can do it. I'm a little worried about the potential for a crash to occur during the pack save operation, but it writes to a temporary file, then renames it when finished, so it seems like the probability of corrupting a package is no worse than the risk of saving a zip file.
  16. What country are you in? We probably have someone around who speaks your native language.
  17. Josh

    Too Cool

    While working with zlib, I implemented the package system, and it turned out really cool. Here's some stuff you can do First, let's load the package and register it in the file system: Package* pak = ReadPackage("mystuff.pak"); //Read the package RegisterPackage(pak); //Register package into file system Read a file from a package, just as if it were on the hard drive: Stream* stream = ReadFile("mystuff/new document.txt"); //Read a file straight out of the package! Write a file to a package, just as if it were on the hard drive: Stream* stream = WriteFile("mystuff/new document.txt"); //Write a file straight into the package! To save your changes permanently in the package, make sure you close it before the program ends: pak->Close(); //Close the package when finished to save the changes This should work in the editor, too, so you can store all your files in packages and the editor will automatically save any packages that change. When a file exists both on the hard drive and in a package, the engine will preferentially read from the file on the hard drive. When a file is written, the engine will preferentially write to a package file, if one is available with the directory the file is being written to. Zip folders and file hierarchy are kept intact. The idea is you can register all your packages, probably with a recursive function, and then read files from and write them to the packages, without knowing or caring whether you are dealing with a file on the hard drive or a file in a package. This is different from the abstract file system, because each file has a precise file path. The only ambiguity is when you have a file on the hard drive and in a package file with the same name, in the same directory. The package file names are considered folders. So if I had a model "teapot.mdl" in a package file "Models.pak" I would load it by calling LoadModel("Models\teapot.mdl"). If you want, you can leave all your files on the hard drive during development, and then let Leadwerks automatically package them up for publishing, and you won't have to change any code to load your files. Once a package is registered, all the file system commands will include them in the file hierarchy, and there is no need to worry about packages at all. If you do write to any, you should close them before ending the program so your changes are saved. My idea I mentioned last time about putting shaders in zip packages and calling the .shd files won't work, because that involves packages within packages, and I don't want to do that. So the shaders are simply going to be left as collections of associated .vert, .frag, .geom, .ctrl, and .tess files, which will be easier to keep track of when editing anyways.
  18. That sounds reasonable. Terrain isn't going to be in the initial release, because it's something I want to devote about two months to.
  19. That should work if you attach the texture to a buffer, enable the buffer, then call that command.
  20. Quadros are for rendering old CAD programs. They might work with Leadwerks, but they aren't designed for games. The GEForce series is designed for modern graphics.
  21. Josh

    Small Victories

    Ah, I'm so used to using macros in glsl I didn't even think about it.
  22. The vehicle itself is a joint. The chassis is the body, and you should be able to retrieve the velocity with no problem. You can retrieve the velocity in local space to make your job easier.
  23. Josh

    Strange Error

    There was a bug report filed on this that got resolved.
×
×
  • Create New...