Currently, we request an output audio stream with f32 samples and fail if we don't get it. It would be better to handle any kind of audio output stream samples and convert on the program's behalf.

Since resources are built into binaries this may be a big win, allbeit at the cost of increased startup times

Upon reflection, forcing custom vertex and fragment shaders to be set dynamically is a mistake, we should allow them to be set every frame.

The implementation should store a HashMap<String, GLInt> that maps fragment and vertex shaders to compiled shaders. Every frame, it will ask the program for the vertex shader and fragment shader to use, and compile, link, and cache them.

I don't anticipate that this will create a noticeable performance hit, but if so this feature may need to be reconsidered.

This may already work, but we should make sure that we do the right thing on high-DPI and non-high-DPI displays on all platforms.

All source files, including the default vertex and fragment shaders, should have top-level comments describing their purpose and organization.

All user-facing functions should have doc comments.

• Add a minimal example to the readme showing off as many features as are possible while keeping the example simple
• Add a test that extracts and builds code in the readme to make sure it stays up to date

For bonus points, include a simple logo interpeter

Allow programs to save and load their state. Saves will be managed by the user outside of the program.

Saves may have an optional parent, which indicates that the save is in some way derived from the parent save, for example the parent save may be a prior game state, or a previous document state.

I'm not sure what the UI should be, but program designers shouldn't have to worry about managing saves, they should only worry about loading game state when presented with a save, and creating a save from the current game state when asked to.

This isn't set in stone, but my thinking is to use msgpack as the save format, and games can use serde to save and load to msgpack values, which will then be serialized to disk by the runtime.

Games should be saved in a location appropriate to the system, for exmaple ~/Library/Application Support/pxl/saves/NAME/TIME-PARENT.msgpack on on macOS.

Also, we should use the crate name the key for a game's saves, so that we are guaranteed to avoid collisions as long as the game is published to crates.io.

Allow the game to detect when the window has resized. Games should be able to ignore this event if they want to render at a fixed resolution.

Should lock aspect ratio.

Currently, if the render thread takes to long, the synthesize thread will block on the program lock, causing buffer underruns and audio glitches.

Fixing this will probably involve complicating the API, unfortunately.

Doesn't need to be anything fancy, just some links, or maybe even just a redirect to the git repo

Just a few simple tools, save and undo, fixed 256 color palette

It would be nice if there was some simple way to get documentation that could be presented to users automatically.

Perhaps an optional function fn documentation() -> String that returns the documentation for the program, and allow users to access it in a separate window or overlay.

Some kinds of games, for example first-person shooters, will be hard to play if it isn't possible to lock and hide the cursor. We should support this.

This will probably have to wait until there is a battle-tested abstract graphics API that works across all platforms that we want to support. I'm interested in the gfx-rs HAL, but it seems like it's still early days for that. We could also expose an OpenGL context, assuming we can get that working on all platforms.

The pxl API would be to have a low-level render function that has access to the HAL context and does the current single-texture rendering by calling Program::render. Then, an author can replace this function if they want to do something that is impractical to do with the high-level rendering function.

There may also be interested intermediate steps that don't expose a full low-level rendering API, but still provide opportunities to take advantage of GPU-side rendering. For example, we could provide a simple API to allow the user to create and access textures on the GPU and perform blitting/blending operations with them.

Not sure what to test, but test as much as is feasible

To allow authors to easily share and publish their games, we should implement a webassembly or emscripten runtime that works in the browser.

It would be nice if we provided functionality usable from a build script to set an icon in the executable.

This will be a bit annoying since we'll need to figure out how to support multiple platforms.

If you're interested in helping with the Linux and Windows implementation, do let me know!

When the close button is pressed, allow the program to indicate that it shouldn't quit, for example if the player would lose progress.

Alternately, it may be best for it to be impossible to cancel a quit, and instead we can let the program return a save object in response to a quit request.

Authors should be able to create transparent windows by writing an alpha value of less than one.

This is easy to enable in winit, but when I tried to get this working but ran into weird issues with junk being left in the buffer. Will probably take some debugging to get right.

We'll need to make sure we're doing the right thing with respect to premultiplied alpha.

Once things are in a good state, publicize pxl to:

• r/rust
• rust forum
• rust game dev IRC
• facebook
• twitter

The runtime currently requires that an output device supporting stereo/48khz/f32 audio must exist. I did this for simplicity, but if there are devices out there that don't support this, it'll be necessary to reconsider.

• Give examples of using all features
• Make one tutorial, or a tutorial per feature
• Comment heavily

• Load unifont from a bitmap
• Render some sentences, including non-latin text
• For bonus points render a simple rogue map

I've experienced performance degradation when not building with release mode, although not sure if that's still an issue. If it is, we should include instructions in the docs for building with release mode.

Travis for unix and AppVeyor for Windows

All playable games should be installable through cargo

I'm wary about adding this feature, since it may tie us to the specifics of OpenGL, but it would be really cool to allow users to submit their own primitives, vertices, attributes and uniforms.

Currently, shader compilation and linking happens while holding the program lock. The audio callback may thus have to wait for shader compilation to complete, which could result in a buffer underrun if it takes too long.

Ideally we should do shader compilation after releasing the lock.

Quit, minimize, full screen, etc, using the expected windows/mac/linux shortcuts

Upon reflection, forcing pixel buffer dimensions to be static is an unnecessary restriction. Allow users to change the dimensions, possibly every frame. Of course, if a program continuously increases the dimensions this may cause allocations every frame, but this is easy for an author to avoid.

Allow programs to set an imgui overlay, for simple UI creation. This will necessarily expose the imgui-rs API, so we should make very explicit that this part of the API is unstable, and we may bump the imgui-rs version to a non-backwards compatible version without changing the pxl major version.

The alternative is to bump the pxl major version whenever imgui-rs releases a non-backwards compatible change, which may be preferable.

To avoid slow rebuilds

Give comprehensive instructions for building binaries for all platforms in a dependency-free/statically linked form for distribution.

It may also be preferable to not support this directly, if it's easy for authors to implement themselves.

• Movement: x and y, and possibly dx and dy
• Pointer button presses

The following are passed to shaderotoy shaders, and might be a good place to start:

uniform vec3 iResolution;
uniform float iTime;
uniform float iTimeDelta;
uniform float iFrame;
uniform vec4 iMouse;
uniform vec4 iDate;

Should support feeding it all events and then asking things like "is this button down?" or "was this button pressed since last frame?"

• binary blobs
• update quote, syn, proc-macro2, etc
• glsl shaders (will be precompiled?)
• images
• audio
• text
• format generated code with rustfmt if available
• add readme and document extensions
• bitmap fonts
  • multiple sizes
  • font metrics
• ttf fonts
• messagepack encoded objects
• json encoded objects

Using large images with pxl-build is prohibitively slow. It should be fast, even with enormous images. I think I'll need to generate binary blobs with the build function, and access them with include_bytes!() or extern symbols that are resolved by the linker.

Additionally, it is not tenable to store images and uncompressed RGBA 32 bit floating point. I'll need to define an image class that has the ability to convert between various formats to a display pixel.

The runtime currently does not clean up the audio stream properly. I'm not sure if it makes a difference, but just in case we should dispose of it properly.

We should add as many useful and interesting shaders as possible to the shaders example

Should load a song as a static resource, and play it with some kind of visuals effect. Possibly just a grid of four cells that change color according to keyboard events and frequency bands. Or perhaps a spectrogram would be cool.

A friend was unable to build, I believe because cpal was unable to find libalsa. If there is a dependency needed on linux, we should document it. Also, we should submit a PR to cpal documenting the dependency in their readme.