|
|
f8ed79c81f
|
small improvement to player's sprite (and create subdirectory for player's sprites too, as I expect there will be quite a few)
|
2025-02-22 06:02:28 +00:00 |
|
|
|
20338996b8
|
add back files with annotations to mlb (took them out before because smlfmt can't parse vector expressions, and also can't parse mlton's ffi syntax)
|
2025-02-21 13:37:41 +00:00 |
|
|
|
40fff7729f
|
add 'newKeys' field (list of key codes pressed in frame) to frame input type, so we can change key bindings at runtime later
|
2025-02-21 11:57:29 +00:00 |
|
|
|
6cd7edb5ab
|
draw options screen when that is selected
|
2025-02-20 14:25:20 +00:00 |
|
|
|
9feae2bb0f
|
add function to make text vec to its own module so it can be reused across different modes
|
2025-02-20 06:13:33 +00:00 |
|
|
|
6d39c17a11
|
when play button is focused on title screen and either attack or jump button is pressed, start level
|
2025-02-20 05:46:00 +00:00 |
|
|
|
dab81e3904
|
begin function for drawing title screen
|
2025-02-19 04:07:27 +00:00 |
|
|
|
6ca2d379f7
|
bring in cozette-sml so we can draw text
|
2025-02-19 03:48:38 +00:00 |
|
|
|
25b2c41355
|
begin title screen by adding title screen type
|
2025-02-19 03:39:36 +00:00 |
|
|
|
6b4b637624
|
done adding LevelType.level_type as a field of GameType.game_type, and having main loop go through GameUpdate.game_type -> LevelUpdate.update
|
2025-02-18 13:48:17 +00:00 |
|
|
|
afe878c05d
|
begin parameterising level so that it fits into larger type (with different modes like TITLE, LEVEL, SETTINGS, etc.)
|
2025-02-18 13:16:52 +00:00 |
|
|
|
d3200745d0
|
allow player to have a different width/height that is not a perfect square, (now we have Constants.playerWidth and Constants.playerHeight, having deleted the previous size in Constants.playerSize)
|
2025-02-18 12:31:22 +00:00 |
|
|
|
18495a0cca
|
successfully parse controls from file (but todo: save controls imperative shell on load)
|
2025-02-17 03:48:31 +00:00 |
|
|
|
99669dd0b6
|
add function to convert string to CoreKey.key_code (for parsing/loading controls from files)
|
2025-02-17 01:39:41 +00:00 |
|
|
|
f2f1eeab8e
|
additional scaffolding of user's key mappings in imperative shell
|
2025-02-16 13:17:14 +00:00 |
|
|
|
47bda26da5
|
begin coding functionality for remapping keys
|
2025-02-16 12:45:29 +00:00 |
|
|
|
e758a5a13c
|
refactor falling_enemy to be contained in FallingEnemyMap, instead of a plain vector
|
2025-02-15 01:42:29 +00:00 |
|
|
|
b239dfa04d
|
add functionality to have enemies tract to player's attack
|
2025-02-14 12:59:22 +00:00 |
|
|
|
e00db5d8a3
|
make enemies move per loop (calling update EnemyMap by calling EnemyBehaviour)
|
2025-02-14 10:43:27 +00:00 |
|
|
|
46a1836ae2
|
additional refactoring, moving player type into its own directory
|
2025-02-14 10:13:03 +00:00 |
|
|
|
93aebe5fa1
|
a bit of refactoring with regards to enemy's structures and files
|
2025-02-14 09:06:32 +00:00 |
|
|
|
c5cea8dcb3
|
partial refactoring so we use EnemyMap.t for collection of enemies
|
2025-02-13 13:36:30 +00:00 |
|
|
|
265c8db88a
|
implement EnemyMap functor (todo: migrate from 'enemy vector' type to 'EnemyMap.t' type)
|
2025-02-13 12:14:50 +00:00 |
|
|
|
f1521acec1
|
refactor file order in preparation for adding GapMap for enemy
|
2025-02-13 11:24:44 +00:00 |
|
|
|
51401231e1
|
update state of falling enemies per loop
|
2025-02-08 09:49:32 +00:00 |
|
|
|
1c105193e2
|
extract a couple of collision functions to a separate module for reuse
|
2025-02-08 08:39:04 +00:00 |
|
|
|
23cf480dad
|
reimplement enemy-filter loop (now enemy's reaction, and decision to possibly filter, is fully under enemy's control - physics, damage reaction, whether to filter or update enemy's state, etc.)
|
2025-02-08 01:05:39 +00:00 |
|
|
|
1be44335cb
|
add asset for ChainEdge (attack)
|
2025-02-07 13:42:38 +00:00 |
|
|
|
e1e20230d6
|
rip out player-enemy.sml and let player react to enemy collisions independently of enemy reaction to player
|
2025-02-06 17:37:48 +00:00 |
|
|
|
e1e1228983
|
delete pointer quad tree because it is twice as slow to construct as the vector-based implementation
|
2025-02-01 10:11:32 +00:00 |
|
|
|
bf3f0b3927
|
done implementing pointer quad tree (next: benchmark the two)
|
2025-02-01 09:54:35 +00:00 |
|
|
|
28380957b3
|
start implementing new quad tree that only uses pointers (just to test performance between vector-using implementation and only-pointer-using implementation)
|
2025-02-01 09:44:22 +00:00 |
|
|
|
9e9675aaab
|
decrease memory consumption of quad tree by refraining from storing bounding box metadata (except for the global root which stores the width and height)
|
2025-02-01 01:03:57 +00:00 |
|
|
|
e23e2f0997
|
precompute graph to be used for dijkstra's algorithm, resulting in CPU usage that never exceed 7/home/humza/Downloads/sml/oh-my-stars/fcore/path-finding.sml with 5 enemies and eliminating lag
|
2025-01-31 04:32:53 +00:00 |
|
|
|
a24ada0f37
|
implement code for precomputing reachable platforms so it can be reused (but haven't modified implementation of Dijkstra's algorithm to use it, and haven't added it to game type yet)
|
2025-01-31 03:46:28 +00:00 |
|
|
|
bbb957f016
|
get path-finding.sml to use function in build-graph.sml to find reachable platforms, and remove now-dead code from path-finding.sml
|
2025-01-30 13:06:32 +00:00 |
|
|
|
fac7a81767
|
trace path we can (move right + jump) using quad tree, as it is easier to implement than a pure math based approach
|
2025-01-29 19:12:24 +00:00 |
|
|
|
7138a05cd3
|
move quad tree helper functions which are useful in quad-tree.sml and will be useful in quad-tree-fold.sml, to quad-tree-type.sml, so quad-tree.sml only exports public API suitable for users
|
2025-01-29 07:07:54 +00:00 |
|
|
|
6369be21fa
|
tentatively refactor quad tree to make it more succinct + eliminate a class of potential bugs (passing wrong quad values through recursion)
|
2025-01-27 23:27:52 +00:00 |
|
|
|
174a99a5a0
|
switch implementation of heap from being based on heap.sml (heap as described by one of Chris Okasaki's papers) to being based on bin-vec.sml (simple vector storing elements in sorted order); more performant this way for cache reasons
|
2025-01-22 18:22:34 +00:00 |
|
|
|
3939b0b3e2
|
done implementing functor to search through quad tree, adding to priority queue (for Dijkstra's algorithm)
|
2025-01-19 23:56:52 +00:00 |
|
|
|
1ba42462ba
|
progress implementing dijkstra's algorithm for path finding using quad trees
|
2025-01-19 22:45:51 +00:00 |
|
|
|
4459a676ac
|
implement bin-vec (vector that always stores its elements in order, for binary search)
|
2025-01-19 12:06:56 +00:00 |
|
|
|
8c651b2221
|
implement heap which stores distance for later use with Dijkstra's algorithm
|
2025-01-19 11:07:45 +00:00 |
|
|
|
84ea0ce24b
|
code functor to fold through a specified region of the quad tree, without having to allocate an intermediary list or using a closure (which both have runtime costs)
|
2025-01-18 22:54:34 +00:00 |
|
|
|
0c01b224d0
|
slight refactoring to help with extensibility of adding enemy variants later
|
2025-01-14 11:50:27 +00:00 |
|
|
|
7290d9865d
|
have enemy physics working and applied to enemy
|
2025-01-12 23:58:21 +00:00 |
|
|
|
27fbe1c12e
|
create enemy patch structure
|
2025-01-12 23:28:03 +00:00 |
|
|
|
8906d244eb
|
extract player patch types and functions to its own module
|
2025-01-12 19:25:05 +00:00 |
|
|
|
9280a12911
|
functorise physics for player
|
2025-01-12 12:36:26 +00:00 |
|
