YaruFPS Basic FPS Engine

I did some googling and it looks like the issue is that the batch of trianges becomes so big the players' graphics cards can't handle it. (800 MB VRAM sound very small these days but ah well...) 

So we need to reset the drawing batch every 1000 triangles. I tried to figure out the easiest way to do that and here's my idea.

1) Create a new script with the following function:

function triangles_break_batch(quads=6){
     global.triangles_so_far += 2*quads
     if(global.triangles_so_far >= 1000){
         global.triangles_so_far -= 1000
         draw_flush()
     }
}

2) Init global.triangles_so_far to 0 somewhere before any 3D drawing, e.g. In CONTROL's create event.

3) Put this new triangles_break_batch function at the start of the Draw event of all terrain objects. You'd compute "quads" like so,

//For a block or wall
triangles_break_batch((image_xscale + image_yscale + image_xscale*image_yscale)*2)
//For a floor or slope
triangles_break_batch(image_xscale*image_yscale*2)

• 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)

Check the creation code of the room and you'll find this bit, this is what arranges the objects in 3D space:

The idea is that the level is arranged in chunks 640 pixels wide (for this room in particular - you can use whichever value you want here), every subsequent chunk is put on top of the previous one.

There's a handful of backgrounds for different grid sizes which can be used to help judging distance, the one used in this room is 640 pixels wide. (I've tried an approach where multiple floors are on different layers for a different project but IMO it's an even worse experience since there's no depth perception)

If you're really sure you wanna do this with layers instead, you could try changing the lines in terrain_flat_to_3d from

z = 64*(x div global.level_chunk_width)
x =     x mod global.level_chunk_width

into

z = 64*(depth div 100)

so the depth value (which is obtained from the layers by default) is used instead. (In this case you probably want to start from a fresh room - by default layers have their depths spaced 100 units apart but the layers in the dungeon_test rooms use compatibility values)

I'm using the same EULA for games and assets for convenience since a lot of the content would be the same. The line you're referring to is for my games ("Games" in the EULA), it doesn't apply to engines and other asset packs ("Assets" in the EULA).

The only thing I'm asking for this engine is, don't let other people (outside of your team) have the source code, only compiled game executables. So making a game with this engine and distributing that is totally OK. Uploading a copy of say, Dracula's Tower to Steam and claiming you made it is not OK.

I don't; I prefer questions (and more importantly, answers) being somewhere they're publicly accessible, so they can help more than one person.

I'm not sure if I can wholeheartedly recommend this engine for new projects anymore since it just barely survived the GMS1-->GMS2 transition (it's originally made in GM6, so this is the third layer of compatibility functions...) and Yoyo have hinted at new 3D tech being on the roadmap, it might be completely obsolete in the near future. Depends a bit on project scope, of course.

Oh wow, I expected people to use this engine for simple Doom clones and you went ahead and made a fantasy immersive sim?? Nice job!

They're defined in the default compatibility location, scripts --> macros. (Lines 22-25). There's a machine gun example weapon as well, but it's sort of hidden so it's easy to miss.

No, it's not normal. Are there any error messages while importing the project?

Also, make sure the compile target isn't set to "Windows (VM)", it might default to that since it's what I had selected when exporting the source file.

It might be better to keep the internal speed computations as-is (measured in 60 per second), but have anything that changes x/y/z (e.g. "x += xspeed") take the delta into account instead ("x += xspeed*delta"). Changing the internal speed computations won't feel right until you change every acceleration, friction, maximal speed, etc... if you just change the "make speed affect coordinates" bit there's a lot less things that needs changing.

Scripts can have multiple tabs, collide_3d_circle is a tab of collide_3d.  zcheck_script_bottom is a variable that's set to different variables for each terrain object, there's no actual script with that name. (Blocks use collide_block_bottom, slopes use the collide_slope_*_bottom family)

I think the collision-checking bug with bullets is because collidecheck() uses place_meeting() to check for collisions, so the bullets need to have a sprite to be able to collide with the terrain.

I think bullets might leave you off-center when shooting upwards/downwards because of the coordinate computation in the ss_pistol / ss_machinegun scripts... right now they're created at 60% off the player's height instead of in their absolute center, but the camera is placed at 80% of the player's height. (I suppose 60% felt like the height you'd have your hands at when holding a gun, if your eyes are at 80%? Or maybe it's just an oversight)

Could you please upload the screenshot directly (or copypaste the error as plaintext) instead of using a URL shortener? I have no way of knowing if that link is a valid image or a site that will steal all my credentials.

Depends a bit depending on which object, but most block-type objects are 4 d3d_draw_wall and 2 d3d_draw_floor calls (so the top, bottom and sides can have different textures).

Thanks, I'll look into it... arguments checking is a relatively new thing compared to how long the YaruFPS code base has been around. I don't remember exactly how the script works, it might be that it uses the same argument signature as the other collide scripts but doesn't actually USE all the arguments.

Shouldn't be impossible, I'll see what I can do!

The main idea is that you make the level in "layers" corresponding to different Z layers, then the engine puts them together when the room loads (moving everything to the first layer, and adapting their Z values accordingly). It's mainly there to make it easier to design 3D levels in GM's room editor and doesn't have any benefits other than that.

(There's a bunch of backgrounds that add a grid to the Room Editor; those backgrounds are used to figure out the size of the Z-slices, so it gets a bit more WYSIWYG than if you had to keep track of a "slice_width" variable or somesuch)

There's also the terrain/ceiling-terrain (which is probably what I named "Level Grid" originally... was a while since I touched the source code last!), which is essentially support for less rectangular ground, and which can be randomly generated. Its purpose is to make the ground in outdoors / cave areas look less like it's made out of cubes, but I couldn't figure out good ways to CONTROL it from within the editor, so it's a bit of an experimental feature. There's special objects that will generate (and draw) terrain if you place them in a room, TERRAINCONTROL and TERRAINCEILCONTROL, look into the init_terrain() script (which has a commented-out block of code that randomly generates terrain) and the "field" room for an example of how to use it.

The "layers that get stacked on top of each other" and polygonal terrain features aren't mutually exclusive, either, so this could be used for levels like a tower in the middle of a forest, or such. (In Dearelict, the trees are actually just very tall cylinders with a bark texture, players just ASSUMES they're trees that stretch so far into the darkness they can't see any of their leaves. Tricks like this can be useful to save CPU power for enemies and stuff like that, GM and 3D rendering isn't really a match made in heaven...)

First of all,  the easy thing: the level grid size is based on the width of the background you use for the level grid. (See the script terrain_flat_to_3d for the details). So basically, if you want a grid that's 2560 pixels wide, use a background that's 2560 pixels wide. Any size should work, but unless it's a multiple of your room grid size it's gonna be hard to keep objects from different layers aligned :P

For the second question... the 3D maths is kinda hard... which is why I skipped that part in the engine :P You'll need to find a reference point (e.g. the player's x, y and zbottom), then find the delta X/Y/Z to the tip of the gun, then spawn the bullet there. If you know the length of all the 'moving parts' (e.g. "spine", "shoulders" and "arm+gun"), you could just compute the X/Y/Z vectors of each part individually and then the tip of the gun should be there.

For each thing...

• X coordinate should be lengthdir_x(1,angle against 'forwards')*lengthdir_x(1,angle against 'up')*(length of thing along X axis)
• Y coordinate should be lengthdir_y(1,angle against 'forwards')*lengthdir_x(1,angle against 'up')*(length of thing along Y axis)
• Z coordinate should be lengthdir_y(1,angle against 'up')*(length of thing along Z axis)

And since the spine is always just Z coordinate and shoulders are always just XY coordinates, this should be possible to simplify a bit. But yeah, it won't really get any easier than this, so guess why games like Wolfenstein and Doom had the gun in the middle so you didn't need to keep track of anything other than the Z coordinate :P

It should work in theory (since there's compatibility scripts converting the old 3D functionality into new), but I've had some issues converting other 3D engines to GMS2 so I can't say with certainty it will. (For instance, there's a bug with drawing transformed models with <1 scaling factors that causes massive slowdowns). Still a bit torn whether it'd be better to make a GMS2 version from scratch of all my engines or convert them and try to deal with version differences.