Thanks for the link Richi007, I'll be sure to look into that!

Ok, now I have yet another question!

In my game I want to allow the player to select multiple units through a selection box. I currently use "mouse_dir3d" to c_trace into the 3D world from the camera position and issue orders, select units, etc. However, when the user creates a selection box and lets go of the mouse button, the game needs to "trace through" all of the pixels in the selection box to see if a unit resides there.

Basically the loop looks like this:



My problem is that while mouse_dir3d handles all of the calculations that determine the direction vector for tracing, those calculations aren't made available for me to modify and apply to any pixel on the screen (rather than the one the pointer currently resides on). So how can I "trace into" a pixel on the screen without moving the mouse and using mouse_dir3d?

you can use vec_for_screen!
converts your screen coordinates to world coordinates....

Thanks for the swift reply Richi007! That function will save me a lot of time and effort.

Actually, by the time you had posted your reply, I had almost come up with my own algorithm. It was almost perfect, but there was a severe error in my calculations that was causing mouse clicks on the lower right side of the screen to affect things on the upper left side of the screen, and vice-versa for every other direction I chose.

Oh well, that's just talk. Thanks again, man.

Although i haven't programmed the box selection yet. I have some ideas how to realize that.
You requier a Collision algorihtm for example sphere to box( or simpler point to box).
You create a box then you loop through all ents and check them against the box
if they are in the box they are selected if not they are unselected.
I believe to use serval c_traces is quite slow and inacurate.

muffel

You are right. A loop of c_traces is actually quite slow. The only way to get a loop like this running at a good speed is by skipping over multiple pixels. But then it's not very accurate.

Well, apparently the engine knows what pixels are occupied by units, as it uses this information during the rendering phase to draw the units onscreen. Now if I were using my own engine, I would simply create an array of handles for every pixel onscreen during the rendering phase. Then all I would have to do is reference this array during my box loop to see what units occupy what pixels. No calculation required.

Obviously this isn't my engine though, so even if the engine keeps information like this I haven't a clue where or how this information is retained by the engine of if I can even access it.

Pointers, anyone?

This is pretty much how I once did a selection test:

Geez, should've thought about vec_to_screen! Man, it's been way too long since I've used Gamestudio.

Thanks man. I'll try applying that method to my own game.

EDIT: Yep, works like a charm. Thanks again, Saturnus.

About the terrains... You can still get a smooth terrain (also depends on settings in MED Importing) using Photoshop and Bluring the heightmap. For lowering level of the terrain use (for example) 3 lower pixels than current level (or higher) to make a 'transition' to the lower plane (wich is 4 pixels lower). Thats just an example , but it'll create flat levels with smooth transitions between different layers. And then , you still have the option to surround your level with jagged mountains
You can still form the terrain , like in MED or any other model editor , in Photoshop. The difference is that you're not viewing it in 3D , but its enough to shape it by hand with the tools provided.

Also thanks to Saturnus works for me also very well.
i should stop thinking to comlicated

muffel

@EpsiloN: Unfortunately I don't have Photoshop and there's no way I'm going to try downloading it on my connection, so that won't work. :\

Besides, I think I'll be ok without having slopes. It makes the game that much easier to program, since I don't have to deal with path finding between multiple floors. I'll keep the mountains and dips in my terrain, though, to provide obstacles for ground units. Of course I can also make air units that can move over these obstacles without problems.

On that same note, unit selection and ordering is working, so now I want to add path finding. I've played around with the scripts MrGuest referenced to me, but I noticed that both their speed and accuracy drops dramatically when there are a lot of nodes in a level.

So I was wondering, what do most game developers do to solve this problem? I'm guessing they precompute the various paths available to the AI before the game even starts, but how is that accomplished?