^^^
- Delta Timing
It isn't too hard. There's tutorials explaining how to do it if you look for them. In a nutshell, delta timing takes a precise measurement of the time elapsed since the last frame was rendered, and uses that to adjust the speed of movement and other execution timing, so that the game appears to run more smoothly, even if it's dropping frames due to lag. In smaller projects it's not really needed, but if you have a lot going on in the game such that you're taxing the CPU, it's very handy.How exactly does delta timing work, and how hard is it to impliment?
Super easy to implement if you do it at the start, it is really just multiplying a few numbers by a global delta. Of course, there will also be some game logic that would need to be done a tad different, however.How exactly does delta timing work, and how hard is it to impliment?
Drag and Drop level editor is a great feature, but that's not the engine, it's a utility to support development with the engine.* easy drag and drop editor (Super Mario Maker)
* fall back options for missing textures and missing sprites
How many is "a lot"? What build target? What kind of hardware? And what exactly do you mean by "data structured data" -- could you describe your approach in more detail? Is your engine publicly available?If you're looking to raise your FPS by a lot, try swapping out solid objects for data structured data.
I've noticed block objects will cause a ton of FPS problems if I put a lot in my room.
Recently made an engine based off of this and it works great. I'm also using less code for collisions
than I would if I used the native GM functions (place_free, collision_rectangle, etc).
I agree, don't use solid objects unless you have a good reason. For 90% of applications, collision grids will do just fine in a platformer and are waaay faster. No matter how many walls you have in a collision grid, the time it takes to check a collision will always be the same (Excluding short circuit evaluations, but that's basically nothing).If you're looking to raise your FPS by a lot, try swapping out solid objects for data structured data.
I've noticed block objects will cause a ton of FPS problems if I put a lot in my room.
Recently made an engine based off of this and it works great. I'm also using less code for collisions
than I would if I used the native GM functions (place_free, collision_rectangle, etc).
Ah sorry.How many is "a lot"? What build target? What kind of hardware? And what exactly do you mean by "data structured data" -- could you describe your approach in more detail? Is your engine publicly available?
//obj_controller create event
block_x = ds_list_create();
block_y = ds_list_create();
block_width = ds_list_create();
block_height = ds_list_create();
alarm[0] = 1;
//obj_controller alarm[0] event
//Some blocks might have been added after the controller so the controller may never find these unless we go 1 step in time
with(obj_block){
ds_list_add(other.block_x, x);
...etc.
ds_list_add(other.block_height, sprite_height);
}
for(var i = 0; i < ds_list_size(obj_controller.block_x); i++){
var blockX = ds_list_find_value(obj_controller.block_x, i);
var blockY = ds_list_find_value(obj_controller.block_y, i);
...etc.
//Do platform collision checking here
}
I think you missed the point that this would be one all inclusive package for any platformer.Anyone who talks about adding double jumps and air dashing and wall jumping and all this **** are buffoons. All you need is pixel by pixel iterated movement, pixel-perfect collision, pseudo-acceleration/deceleration to work on a rounded, pixel-perfect grid. Slopes, gravity, jump-through platforms. Many flexible methods of input (Keyboard, joystick/controller, reading from replay recordings of input, etc). At most, delta time. Done.
Like if you define your levels to have a certain texture or whatever for a tile, and then it gets deleted or corrupted, that a default texture/tile is displayed so your level might look garish (to point out the texture), at least it doesn't look like a pit or something.Drag and Drop level editor is a great feature, but that's not the engine, it's a utility to support development with the engine.
What did you mean by "fal back options" exactly? Can you give me a concrete example of how that would work? I take it you're assuming the engine will read textures and sprites from external files... what should it do if those are missing?