chore: migrate tests to vitest (#3381)
managed to migrate the engine leak & memory reporters, although it took a bit of rigamarole. Mainly because, as opposed to karma, the reporter runs in node and not the browser. So I have to track the data needed separately in some global hooks _within_ the browser environment, which the reporter then reads and creates the logs if needed.
However, it seems the memory tracking is regularly reporting >1 mb, so I'm not sure if it's tracking properly or if things have changed with the new browsers. My only theory is that because the timing where memory is read is during an `afterEach` _before_ the test's `afterEach`, it's running before any potential cleanup. The timing of this is not something that's easy to control, unfortunately. I did try to prove this theory by doing the memory analysis on the next test's `beforeEach`, but it didnt seem to change the results, so it may not be an issue.
Implementation is done in `src/spec/vitest/__reporters__/memory.ts` and `src/spec/vitest/__reporters/memory.setup.ts`
---
I noticed CouroutineSpec was an offender for >10mb memory, which spins up additional engines. I added a short 100ms wait after the engine.dispose and the memory usage did drop, so it does seem like this is prone to scheduled garbage collecting.
---
I was able to run the garbage collector (if exposed, currently only on chrome) and this makes the reports more accurate
[#1119] Decouple Actor from Collision System (#1125)
Closes #1119
## Changes:
- New `ex.Collider` type which is the container for all collision related behavior and state. Actor is now extracted from collision.
- Added interface `Clonable<T>` to indicate if an object contains a clone method
- Added interface `Eventable<T>` to indicated if an object can emit and receive events
- `ex.Vector.scale` now also works with vector input
- `ex.BoundingBox.fromDimension(width: number, height: number)` can generate a bounding box from a width and height
- `ex.BoundingBox.translate(pos: Vector)` will create a new bounding box shifted by `pos`
- `ex.BoundingBox.scale(scale: Vector)` will create a new bounding box scaled by `scale`
- Added `isActor()` and `isCollider()` type guards
- Changed collision system to remove actor coupling, in addition `ex.Collider` is a new type that encapsulates all collision behavior. Use `ex.Actor.body.collider` to interact with collisions in Excalibur ([#1119](https://github.com/excaliburjs/Excalibur/issues/1119))
- Add new `ex.Collider` type that is the housing for all collision related code
- The source of truth for `ex.CollisionType` is now on collider, with a convenience getter on actor
- The collision system now operates on `ex.Collider`'s not `ex.Actor`'s
- `ex.CollisionType` has been moved to a separate file outside of `Actor`
- CollisionType is switched to a string enum, style guide also updated
- `ex.CollisionPair` now operates on a pair of `ex.Colliders`'s instead of `ex.Actors`'s
- `ex.CollisionContact` now operates on a pair of `ex.Collider`'s instead of `ex.Actors`'s
- `ex.Body` has been modified to house all the physical position/transform information
- Integration has been moved from actor to `Body` as a physical concern
- `useBoxCollision` has been renamed to `useBoxCollider`
- `useCircleCollision` has been renamed to `useCircleCollider`
- `usePolygonCollision` has been renamed to `usePolygonCollider`
- `useEdgeCollision` has been renamed to `useEdgeCollider`
- Renamed `ex.CollisionArea` to `ex.CollisionShape`
- `ex.CircleArea` has been renamed to `ex.Circle`
- `ex.PolygonArea` has been renamed to `ex.ConvexPolygon`
- `ex.EdgeArea` has been renamed to `ex.Edge`
- Renamed `getWidth()` & `setWidth()` to property `width`
- Actor and BoundingBox are affected
- Renamed `getHeight()` & `setHeight()` to property `height`
- Actor and BoundingBox are affected
- Renamed `getCenter()` to the property `center`
- Actor, BoundingBox, and Cell are affected
- Renamed `getBounds()` to the property `bounds`
- Actor, Collider, and Shapes are affected
- Renamed `getRelativeBounds()` to the property `localBounds`
- Actor, Collider, and Shapes are affected
- Renamed `moi()` to the property `inertia` standing for moment of inertia
- Renamed `restition` to the property `bounciness`
- Moved `collisionType` to `Actor.body.collider.type`
- Moved `Actor.integrate` to `Actor.body.integrate`
- Removed `NaiveCollisionBroadphase` as it was no longer used
- Renamed methods and properties will be available until `v0.24.0`
- Deprecated collision attributes on actor, use `Actor.body.collider`
- `Actor.x` & `Actor.y` will be removed in `v0.24.0` use `Actor.pos.x` & `Actor.pos.y`
- `Actor.collisionArea` will be removed in `v0.24.0` use `Actor.body.collider.shape`
- `Actor.getLeft()`, `Actor.getRight()`, `Actor.getTop()`, and `Actor.getBottom` are deprecated
- Use `Actor.body.collider.bounds.(left|right|top|bottom)`
- `Actor.getGeometry()` and `Actor.getRelativeGeometry()` are removed, use `Collider`
- Collision related properties on Actor moved to `Collider`, use`Actor.body.collider`
- `Actor.torque`
- `Actor.mass`
- `Actor.moi`
- `Actor.friction`
- `Actor.restition`
- Collision related methods on Actor moved to `Collider`, use`Actor.body.collider` or `Actor.body.collider.bounds`
- `Actor.getSideFromIntersect(intersect)` -> `BoundingBox.sideFromIntersection`
- `Actor.collidesWithSide(actor)` -> `Actor.body.collider.bounds.intersectWithSide`
- `Actor.collides(actor)` -> `Actor.body.collider.bounds.intersect`
chore: migrate tests to vitest (#3381)
managed to migrate the engine leak & memory reporters, although it took a bit of rigamarole. Mainly because, as opposed to karma, the reporter runs in node and not the browser. So I have to track the data needed separately in some global hooks _within_ the browser environment, which the reporter then reads and creates the logs if needed.
However, it seems the memory tracking is regularly reporting >1 mb, so I'm not sure if it's tracking properly or if things have changed with the new browsers. My only theory is that because the timing where memory is read is during an `afterEach` _before_ the test's `afterEach`, it's running before any potential cleanup. The timing of this is not something that's easy to control, unfortunately. I did try to prove this theory by doing the memory analysis on the next test's `beforeEach`, but it didnt seem to change the results, so it may not be an issue.
Implementation is done in `src/spec/vitest/__reporters__/memory.ts` and `src/spec/vitest/__reporters/memory.setup.ts`
---
I noticed CouroutineSpec was an offender for >10mb memory, which spins up additional engines. I added a short 100ms wait after the engine.dispose and the memory usage did drop, so it does seem like this is prone to scheduled garbage collecting.
---
I was able to run the garbage collector (if exposed, currently only on chrome) and this makes the reports more accurate
chore: migrate tests to vitest (#3381)
managed to migrate the engine leak & memory reporters, although it took a bit of rigamarole. Mainly because, as opposed to karma, the reporter runs in node and not the browser. So I have to track the data needed separately in some global hooks _within_ the browser environment, which the reporter then reads and creates the logs if needed.
However, it seems the memory tracking is regularly reporting >1 mb, so I'm not sure if it's tracking properly or if things have changed with the new browsers. My only theory is that because the timing where memory is read is during an `afterEach` _before_ the test's `afterEach`, it's running before any potential cleanup. The timing of this is not something that's easy to control, unfortunately. I did try to prove this theory by doing the memory analysis on the next test's `beforeEach`, but it didnt seem to change the results, so it may not be an issue.
Implementation is done in `src/spec/vitest/__reporters__/memory.ts` and `src/spec/vitest/__reporters/memory.setup.ts`
---
I noticed CouroutineSpec was an offender for >10mb memory, which spins up additional engines. I added a short 100ms wait after the engine.dispose and the memory usage did drop, so it does seem like this is prone to scheduled garbage collecting.
---
I was able to run the garbage collector (if exposed, currently only on chrome) and this makes the reports more accurate