gamecreator

Jorn is doing something more advanced with splines which I think he said he'll be selling at some point.

I don't know what this looks like in Lua but this does it in C window = Leadwerks::Window::Create("Leadwerks", 0, 0, 1280, 720, Leadwerks::Window::Titlebar | Leadwerks::Window::Center); I wish the documentation mentioned the option. You could probably also use SetLayout after creating the window but you'd need to get the desktop resolution somehow.

You need to set the blend mode to alpha. See the example here on how: https://www.leadwerks.com/learn?page=API-Reference_Object_Context_DrawText

Does that USB drive logo look a little off-center to anyone else?

I had a similar problem. It feels like Josh is in the middle of transitioning Leadwerks over from using using bool App::Loop() to int main(int argc, const char *argv[]). When I created a new project, I couldn't get a loaded map to show (it had a skybox so I should have seen at least that). But if you remove main.cpp and App.h from your project and copy sample code from the documentation, like https://www.leadwerks.com/learn?page=API-Reference_Object_Asset_Shape_Sphere, it should work.

That's a good idea. I gave it a shot just out of curiosity but either SetElevation / SetHeight don't work on terrain or I used it incorrectly.

I don't think there's much more to it than that developers try to meet and anticipate customer demands and also what they feel will make their engine more useful. Sometimes this fails. Making something like terrain creation more complex could be any one of those. It's kind of like having your engine support C/C++ or C# or Lua or your own custom script or no coding at all. Neither is better than the other necessarily; they can each create great games if the engine is good, as long as there are customers with those demands to create them.

test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test It looks like he might be putting it into a code tag of some sort. Sounds good. It should be a good place to start from.

I don't use it but you're absolutely welcome to. No need to credit me in any way. If your terrain is flat/flattened, you won't need this tool. But if you have roads going up and down hills, I think it may be easier to just snap the road to it instead of trying to adjust the terrain spot by spot. But I think a combination of the two may be best. Yes. There are no adjustments after you snap the terrain. Vertices are saved as they are. Edit: correction/clarity: the road is actually lowered uniformly to 0 height so that it's at the origin and that it's not way up in the air when you import it into your modeling program. However, the vertices will match terrain height exactly. All you need to do is drag it back up once you import it into the editor. If you prefer to keep the road at the terrain height during export, you can remove +lowestpoint from the below code. // "Subtract" lowestpoint from all vetex heights to put road closer to origin fprintf(f, "v %f %f %f\n", vpos.x, -vpos.z+lowestpoint, vpos.y);

Leadwerks Road To Terrain Snapper (with source code) I decided to write this tool after seeing a few members inquiring about roads in Leadwerks. I thought it might be easy to code and a good way to stretch my coding muscles as a break from game coding. The tool uses the information you provide in settings.txt to locate a map file and a road file and allows you to move and rotate the road on the terrain until you find a place you like. You can then snap the road to it so that every vertex of the road snaps to the terrain below it. When you quit the program, the program exports an OBJ file you can import into your 3D modeling program. Unfortunately the program doesn't keep your texturing information but since the source is included, you're welcome to add that in. The program also keeps track of the position of the road so that when you import it back into Leadwerks, you can type it in to the position boxes to put the road right where you snapped it (you'll probably need to multiply by 100 to match the editor format). You may be wondering why the road looks bad and the terrain is sticking through it. This is a combination of two things: 1. I didn't include any space between the road and the terrain. You can place the road as high off the ground as you feel is right once you put it back into the editor or your code. 2. The road in the screenshot is only 180 triangles. I suggest using more depending on your scene. The entire project with source code: http://www.mediafire.com/file/y1743umgg0q75x9/Road_To_Terrain_Snapper_project_and_source.zip Just the program: http://www.mediafire.com/file/xhbfy8hn7x5nr5i/Road_To_Terrain_Snapper.zip Enjoy! (The settings.txt file also lets you specify the resolution you would like to run your program at and fullscreen or windowed.) Thank you to macklebee for his help with this on the forums.

Thank you again macklebee. It looks like it works now.

Right now it takes any model you have (doesn't even have to be a road), snaps all of its vertexes to the terrain height below them and exports an OBJ. Unfortunately I don't know anything about textured surfaces and UV coordinates and whatnot so the OBJ will be untextured so you need to retexture it in your modeling program. If someone wants to add that functionality later, they're welcome to do it. I kind of just brute-force the OBJ export. It works fine at the moment but I would have loved to have people be able to rotate the road.

That's very nice of you to say but it's a pretty simple tool. I'm planning on releasing it for free with source. There won't be a GUI so you'll need to provide the map file location and the road file location in a text file that the program reads.

Just be aware that the character controller has at least two bugs at the moment to which 2D/2.5D games are especially susceptible. However, if you're not using slopes then you probably won't notice.

Yes and no. Visually, yes. In actuality, no. If you rotate a model and get a vertex position via model->GetSurface(0)->GetVertexPosition(0) for example, it will return the same vertex position after each turn. I'm playing around with making a road snap to terrain and I want to be able to rotate the road and snap the moved vertices to the proper terrain height.

Could anyone let me know what's wrong with my code? for(int i=0; i<model->GetSurface(0)->CountVertices(); i++) { Vec3 pos=model->GetSurface(0)->GetVertexPosition(i); pos.x=pos.x*Math::Cos(angle)-pos.y*Math::Sin(angle); pos.y=pos.y*Math::Cos(angle)+pos.x*Math::Sin(angle); model->GetSurface(0)->SetVertexPosition(i, pos); } It rotates the model but the more you do it, the smaller the model gets. I suspect there's a better way to do this and I'm open to suggestions (but I need to do it at the vertex level).

They are in the thread macklebee linked in his first post.

In your case I'd check it with a visible entity and see if the pick returns true or false. If it returns true, just make the entity invisible and you'll know if it can pick it or not.

Why would they need to? Can't Lua users upload standalone games anywhere too, including free places like Dropbox, Google Drive, etc.? I agree with this. It's important for users to find what they're looking for. I don't have time to try random "games" that bug a minute in or go nowhere. It would be even better if there were Steam-like requirements that required at least 3 screenshots and optionally a trailer, which could be viewed through the Launcher. Another useful piece of information would be to see how much time people played the game on average. The higher that number, the more likely the game is worth playing.

I didn't think pick worked on hidden objects. Are you sure it's supposed to?

That seems very low for that card and an empty scene but I don't use debug mode so I honestly don't know. If release mode gives you a high framerate then you're probably fine.

Debug mode is slower than release mode. What's your video card? And how fast is it in release?

Thank you. Got it through your code. I was simply missing the cast. Terrain *terrain = (Terrain *)world->GetEntity(i); And in C as well, GetHeight returns 0 (which is not correct) while GetElevation returns a proper height.

Right. That's what I linked above thinking that this really isn't possible, despite the video. So I guess we'll need a definite from Josh. But maybe this could still be done with some physics collision detection trickery.

Sorry to necro this but how do you do this in C? Anyone have a code example since the functions don't seem to be documented (or invisible for some people again)? I tried traversing the entities but world->GetEntity() doesn't recognize GetHeight or GetElevation (though I see the functions in Terran.h).