- Distance for object rendering: CONTROL's Draw Event, controlled by "global.darkness" variable.
- De-rendering things behind your back: CONTROL's Alarm 0 event. (It deactivates things outside your field of view at the same distance in all directions but you could adjust this using parent_camera.direction to take a step in the direction the camera is looking when computing the region to keep active)
- The size of the camera is controlled by two things: obj_player's collision mask (currently a 8x8 sprite) which is used for collisions in the XY plane, and the zheight variable (the height along the Z axis) which is used for collisions on the Z axis, which defaults to 24 - the actual variable used to compute the camera perspective is zdelta but it's currently computed based on zheight (so the player's eyes will always be roughly where their head should be)
UPD: Could you also by any chance help me with importing other d3d-models in the game? I accept "no" as an answer. If you could, I will write the problem I am having.
1 year ago(+1)
Oh, seems like I misunderstood your question! Aspect ratio of the in-game view, not the collision mask of the object.
- For output window size, this is controlled by the Game Maker room viewport properties. The most important one is the first room of the game (titlescreen) because this room's viewport size sets the initial game window size when the game loads, but you should change all of them to use the desired window size (the fields for "width" and "height" for both camera properties and viewport properties)
- After doing this, most stuff should adapt automatically, with one exception: CONTROL's draw event has a line running d3d_set_projection_ext. One of the arguments here is the aspect ratio (specifically the "1.76" near the end - it's the "aspect" argument in the argument listing), you should change this according to the aspect ratio you're using: for 4:3 it's 1.333 (4 divided by 3), for a square window (1:1 aspect ratio) it's 1, and so on.
"D3D models" as in models exported by GM or as in 3D models in general? I've seen a lot of OBJ loader scripts on the forums over the years so I never saw a need to make one myself, and plenty of video tutorials going over it as well:
thank you a lot for your answers!! all works fully well now :)
no, i am not talking about importing itself (didn't write the question fully before getting your agreement to help me more, because i've already wrote a lot of questions), but about integrating them in the game. in fact, the only question is about collision. if I have imported eg. a pyramid, how to make an object solid (i.e. so the player would go through), when it has not a just-a-box shape?
one of the possible crutchy solutions would be check if player is touching the object and grow players z until it stops touching it. shitty one, but i will be happy even with it, if you could game me an idea, how to check a collision between d3d-object and the player.
1 year ago (+1)
There's a system for more advanced collision check functions, it's used by the different ramp objects: the zcheck_script_bottom and zcheck_script_top variables. These are called with two arguments, the x and y position we're doing a collision check over, and should return the top/bottom Z value of the object at that point.
Pyramids are actually a pretty complicated shape (4 triangular regions with different slope) but I think the easiest way is to check the x and y position difference vs the centerpoint of the pyramid - e.g. if the x difference is larger than the y difference AND the point you check has a higher x value than the center of the pyramid, you're on the right-hand quadrant, so you'd lerp from the top Z value of the pyramid to the bottom Z value of the pyramid using the x difference divided by half the sprite_width of the pyramid object. (The left hand quadrant does the same calculation but mirrors the x difference, and the top and bottom uses the y difference and the sprite_height instead)