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().