Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Josh

  1. Josh

    [4.6 Beta] Crash when using Joint:Ball()

    Thanks for reporting! This is a big help.
  2. In Seattle. This is where this whole VR thing began.

  3. One suggestion would be to pack all those different enemies into one single message. There's no reason that would be any slower than just one.
  4. Josh

    Problem with screen resolution

    It does not yet exist. In development.
  5. We might in the future. The number of people making a multiplayer game is a niche and the number of people who want to do that outside of Steam is a smaller group.
  6. Josh

    Problem with screen resolution

    I doubt it. What is the display scaling factor in Windows display properties? Please upload an example we can run.
  7. Josh

    Problem with screen resolution

    You can install the 4.6 beta, update your project, and see if that fixes the issue. If not I suggest uploading an example here so we can all try it.
  8. Josh

    Problem with screen resolution

    Run your game without the editor.
  9. Josh

    Problem with screen resolution

    Your max resolution will be 1920x1080.
  10. Josh

    Problem with screen resolution

    It's dependent on your monitor resolution and DPI. What is your monitor resolution, and is it a high DPI monitor?
  11. Josh

    Problem with screen resolution

    Leadwerks 4 does not support high DPI resolutions because it would make the GUI tiny.
  12. Josh

    Problem with screen resolution

    Here is the code that creates the window: local gfxmode = System:GetGraphicsMode(System:CountGraphicsModes()-1) if System:GetProperty("devmode")=="1" then gfxmode.x = math.min(1280,gfxmode.x) gfxmode.y = Math:Round(gfxmode.x * 9 / 16) windowstyle = Window.Titlebar else gfxmode.x = System:GetProperty("screenwidth",gfxmode.x) gfxmode.y = System:GetProperty("screenheight",gfxmode.y) windowstyle = Window.Fullscreen end window = Window:Create(title,0,0,gfxmode.x,gfxmode.y,windowstyle) It is set up so that when launched from the editor, it creates a smaller window. If launched alone, it creates a fullscreen window at maximum resolution. This is because you often need to go back and forth with the editor when you are working on a project.
  13. The Origin Space Telescope VR exhibition at the American Astronomical Society conference is powered by Leadwerks: https://aas.org/meetings/aas233

    1. Show previous comments  1 more
    2. reepblue


      Take pics and videos. Will any demos be public online?

    3. Josh


      It depends on what they want to do with it. It might go on Steam in the future.

    4. Josh


      I'm heading up there today. I will post pictures if photography is allowed.

  14. Josh

    Emission Map Casting Light?

    It only works with spotlights.
  15. Yes, and it is using Steam's system.
  16. Yes, but not if the other computer is behind a router: https://www.leadwerks.com/learn?page=API-Reference_Object_Client https://www.leadwerks.com/learn?page=API-Reference_Object_Server
  17. Josh

    Good genre to start with?

    3D-in-2D shootemup.
  18. Ok I will definitely look into this. Thanks for reporting!
  19. I’ll be in Seattle at the end of next week.

  20. Josh

    The usage of the technical forum

    Nope, don’t know what that is.
  21. Josh

    Loading GLTF Files

    With an understanding of JSON for Modern C++ (an excellent library) I was able to dive into the new GLTF 2.0 file format and create a model loader. Here's what I've got so far: Although the file format is JSON-based, vertex and indice data is loaded from either a binary .bin file, or packed away at the end of the ASCII file. You can open GLTF files in NotePad and edit them, but GLB files are a mix of ASCII and binary. The model above loads in about 16 milliseconds. I did find some big shortcomings in the file format, however, and I am going to list them here. 1. It's needlessly complicated The way data is stored is ridiculously complex. Accessors, bufferviews, and buffers? Why not just provide an array of values. The designers of this spec must have been on some serious drugs when they came up with this. I understand why they did this, they are trying to make resource reuse as efficient as possible, and allow the file format to dictate how data is stored internally, because they are writing this from the perspective of a graphics API designer. Guess what? NO ONE is going to use it like that. Everyone is just going to load the data into their own mesh structures and send it to the GPU however they want. Allowing the file format to control how data is stored internally in the engine is a level of stupid I can barely conceive of. Why does this matter? Well, if you are trying to get people to adopt your file format you make it as simple as possible. Collada was a disaster, and I personally know one programmer who nope'd out of there after taking one look at the GLTF specification due to bad experiences with Collada. 2. It's not a model file format GLTF is a scenes (plural, we'll get to that later) file format and it's being shoehorned into something else. There is no guarantee of a single top-level node, so my loader has to create a root model to parent multiple nodes to if they are encountered. 3. It's not meant for games GLTF stands for "GL Transmission Format" which sounds like an STD but is meant for serving up 3D scenes in a web browser. Thus, it uses JPEG and PNG files for textures and does not support the most common texture format for games, DDS. It doesn't even support Khronos' own KTX texture format that no one uses. Why does this matter? Widespread support for GLTF is one of the compelling reasons to use it. When you select a GLTF file in Windows 10 Explorer, it shows the model in a 3D preview window. Really nice! But if the model stores a DDS texture, it will fail to load! (It still loads successfully in Microsoft's 3D object viewer included in Windows 10.) I plan on using DDS textures in the new engine, but if all our 3D models won't display in Explorer, why use the format? There's also no support for or concept of material files stored in external files. All materials are packed into the model file. I'm not sure how we are going to handle this. 4. It even sucks at what it's supposed to be The design of the GLTF format is a giant catch-22. Check this out: All model and material data is stored in the file format, and there is no loading of models from external files (like other GLTF files). But it's a scene file format, right? Most games have more than one setting. You don't want to have all your models copied to all your different scene files redundantly. GLTF solves this by including multiple scenes in the file, with a value to indicate the first "map" to load. So all your models, textures, and scenes are getting packed into a single file! Here's the kicker: There is no support for model compression, and this is supposed to be a file format for sending to web browsers. No problem, let's just use some ZIP compression to compress the whole file, right? Ha! Now you have to decompress ONE GIANT FILE containing EVERY MODEL AND SCENE used in your ENTIRE GAME just to load one scene! The concept of having editable asset files and a separate file format for the published game is straight out of 1994. We're not going back to WAD files and we're not going to pack all our game content into one giant uncompressed file. I actually have a soft spot for WAD files. Leadwerks 6? But Waitaminute... Okay, so those criticisms aside, it's still pretty good. We have a fast-loading open-source 3D model format with widespread support. It's designed with the concept of PBR materials built-in. And with extensions, this file format that was not designed for game models is being shoehorned into a standard that is already ahead of FBX. So in the new engine we are going to try to use GLTF as the main model format, not just as an intermediate format we convert models from. There are still some unanswered questions that will be challenging to resolve, but I think this is going to give us the best workflow in the future. Oh, and GLTF destroys OpenGEX based on one simple factor: binary data. You do not want to load vertex arrays from text as it will cause very slow load times. The whole concept of an "exchange format" is pretty dumb. It never works and it isn't what people want. People want an editable game-ready format, and GLTF while not perfect is pretty close to that.
  22. Josh

    Driving car experience with 4.6

    No, not yet.
  23. Josh

    MSVCR100.dll is missing in windows 10

    What did you do?
  24. Should the Technical Assistance forum posts be moved to General Discussion? Is the technical assistance forum, with the ability to mark an answer, a useful tool or do these posts belong in the General Discussion forum? (without the "mark answer" feature)