b6fcf803e7
* WIP: Invader AI - Adds debug mode for visualizing bounding boxes - Adds rectangle and line drawing (for debug mode) - Invaders move as a close approximation to the original game - TODO: Demonstrates that the blit function needs to ignore black pixels (or "transparency") - TODO: The invader movement code is really bad * clippy and fmt * Refactor Invader movement * Support "transparency" in blit function * Scale player movement to 60 pixels per second, regardless of frame rate. * Add assertions in blit to prevent drawing out of bounds * Add bullets, shoot with space * Add lasers, and improve the bullet animation a little bit * fmt |
||
|---|---|---|
| examples/invaders | ||
| img | ||
| pixels-mocks | ||
| shaders | ||
| simple-invaders | ||
| src | ||
| .gitignore | ||
| .travis.yml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| README.md | ||
A tiny hardware-accelerated pixel frame buffer. 🦀
But why?
Rapidly prototype a simple 2D game, pixel-based animations, or an emulator for your favorite platform. Then add shaders to simulate a CRT or just to spice it up with some nice VFX.
pixels is more than just a library to push pixels to a screen, but less than a full framework. You're in charge of managing a window environment, event loop, and input handling.
Features
- Built on modern graphics APIs: DirectX 12, Vulkan, Metal, OpenGL.
- Use your own custom shaders for special effects.
- Hardware accelerated scaling on perfect pixel boundaries.
- Supports non-square pixel aspect ratios.
Comparison with minifb
The minifb crate shares some similarities with pixels; it also allows rapid prototyping of 2D games and emulators. But it requires the use of its own window/GUI management, event loop, and input handling. One of the disadvantages with the minifb approach is the lack of hardware acceleration (except on macOS, which uses Metal but is not configurable). An advantage is that it relies on fewer dependencies.