reepblue

The only functions you'll need the Leadwerks namespace in front of the call is Time and Window. Make a precompiled/shared header and define the following. #ifndef STDAFX_H #define STDAFX_H #if defined( _WIN32 ) #pragma once #endif #include "Leadwerks.h" #ifdef GetFileType #undef GetFileType #endif using namespace Leadwerks; #define Timing Leadwerks::Time #define EngineWindow Leadwerks::Window #endif // STDAFX_H Then whenever you want to use the Time or Window function you'll just call something like this: #include "pch.h" int main() { auto w = EngineWindow::Create(); while (true) { Timing::Update(); } } This ensures that your code will be cross compatible and you don't have to ever worry about using the namespace.

Yeah. There is a Leadwerks::Print(), but there is no such thing as Print() unless you make your own function.

Why is there a ; after include? Remove that and it should work. Also, you need to define the Leadwerks namespace calling "using namespace" above your function.

Ok, that's a start. I'll see what I can do with that information. I might need more help as I'm not 100% confident in shader code. I'll take a look this weekend, thanks.

When importing your models, the front should always be Z positive. Then you can use The point function of the entity to point to it's target like: self.enitity:Point(self.target,2,1,0) Only concern I have is that the joint locks the rotation of the entity so you might need to disable the mass of the train before you can manipulate the rotation. Then re-apply the mass. Never did this, but that would be my first attempt.

Yeah, figured much. Issue is that it may not be possible or ideal to collapse all your models into one for a real game. I guess when it comes to detailing, you need to find out what chunks you're allowed to combine. Again, the new engine makes this issue go away, but I really wish that a group feature was implemented to auto merge your models for you so you didn't have to do each combination yourself.

My concern is the collision mesh and how many buildings you want. If every building was its own model with it's own shape, you'll most likely get the same performance as The Zone. (40fps on my system)

System::Set/GetProperty() automatically does this by reading your <GameName>.cfg file located in AppData. If your game is using the stock lua app, you should be set. But if you want to make your own system, then I recommend you create a module class that for each line it reads it will extract the key and value from the string based on the location from the equal sign.

Test screenshots on my system: Intel i5 7600k and a AMD RX 480. 1000 sphere brushes (400-500fps!) Here's the app drawing 1000 boxes that are models. (108 polys per model; 250 - 280fps) It should be noted that the sphere example took really long to load, but the end result is basically free geometry. We are told in other engines that brushes are expensive and should be replaced with models before you ship. However, in Leadwerks 4, the opposite is true - Models are more of a cost than brushes. The issue is that we have no vertex tool so we are limited with building things with simple shapes. There is also a nasty rotation issue with faces in which the editor will auto apply the rotation of 0 upon loading a map. I've reported this, but it's not something Josh can't really track without knowing what's causing it. So in-conclusion, I see that you should be using collapsed brushes (brushes without scripts) for buildings. Just disable vsync to prevent the walls popping in/out and you should be set. With the upcoming engine, this shouldn't be an issue, and hopefully there will be a vertex tool for brushes in the new editor.

It should be noted that 1000 collapsed brushes will run much faster than 1000 models.

Hey all, Is it possible by shader alone to create a shader for a decal/model that'll tile the texture like a brush when the scale has been changed? One way I'm thinking of is doing the math in the shader and then tie it to an actor that'll tell the shader the models size. Is there a way to get the face size within the shader itself?

Can we manipulate the terrain in real time? If so, that reminds me of a feature of the Source engine that was removed sometime after HL2: Episode 1. Not sure how efficient it would be though.

Using the direction of the surface is fine for right now and the bouncing implementation seems more work than for what it's worth. I'm probably gonna come back to this if I decide to add reflection lasers, and I think that'll be easier to implement.

I think this is due to a physics hack not being applied for the top of the ledge. There is a "walkable" bool for brushes, but I think that's not being called as the normal of the face is not (0,0,1). What happens if you try a model like this?

The AlignToVector bit was due to success of the ball bouncing off with the normal of the surface as it's new direction. Thanks. I'll try again with Transform::Vector().

Hi All, I'm hoping somebody who's a bit better at math may be able to help with this. I'm trying to get math down for reflections off a surface based on the direction of the entity. My current code which pretty much does the same thing as aligning the entity to the surfaces normal. auto contactnorm = tr.vNorm; auto rot = GetEntity()->GetRotation().Normalize(); auto newDir = Vec3(contactnorm).Reflect(rot); GetEntity()->AlignToVector(newDir, 2); I would appreciate the help.

If you export a model with it's collision mesh as a child, you'll run into issues if you give the model mass. Plus the final result like looks sloppy to me. I personally like to collapse all my static models upon importing. This might also help performance, but I'm not 100% on that.

With my method though, you get the exact results you want. It's only really good for concave stuff. (pipes, frames, etc)

Your physics mesh will be very high poly as it does 2 triangles per rectangle face. I would guess this would be expensive, but I'm interested in how it works out. The correct way to do this would be to make the gameplay walls/floors out of brushes and do the roof, railings and such as models. But with vsync enabled/low frame rate, brushes will pop in upon spinning the camera. If your plan doesn't work out, I suggest you make your building layout with brushes, and force disable vsync. Forcing a frame rate via the graphics driver (like what you have to do with Nivdia Linux drivers) produces better results anyway.

The small footprint is one of the many reasons why I really like Leadwerks. Really happy to see you still going forward with this approach, while making it more flexible.

I'll look more into that, thanks. I used 7zip for years, but never touched the command line.

I know, I plan on doing this for my project when the time comes. However, I'd need to create a way to do this automatically. Closest I got was I compiled an app that makes zip files, but I couldn't get password encryption to work. If you know of a good command line app for zip files, let me know.

VPKs allow for splicing packages. Your 8GB game can be cut into chunks. This allows for smaller updates down the road. This can be done using the -M parameter. https://developer.valvesoftware.com/wiki/VPK This isn't perfect, but much better than the current Leadwerks packaging system.

Source Engine models have a lot of information in them so I don't know how easy/hard it would be. But also, this means we can use vpks to store our game data?

This is because EOF is conflicting with stream->EOF. What are you trying to do that the engine's stream class can't?