elgopher / pixiq Goto Github PK

Add support for sampling keyboard input. This can be a separate package keyboard

var window *opengl.Window = ...
keys := keyboard.New(window)
screenLoops.Loop(window, func(frame *pixiq.Frame) {
   keys.Update()
   if keys.Pressed(keyboard.Left) {
   
   }
})

or even simpler:

var window *opengl.Window = ...
keys := windows.Keyboard()
screenLoops.Loop(window, func(frame *pixiq.Frame) { // Loop will execute Update()
   if keys.Pressed(keyboard.Left) {
   
   }
})

Suggested Keyboard functions:

• Update - polls events and update the keyboard state
• Pressed
• PressedKeys
• Key Serialization/deserialization
• Keys mapping
• Unknown Keys
• JustPressed
• JustReleased
• Create public Fake with methods for Appending and Clearing Events (optional, this can be done later)
• Implement Stringer in Key
• Add examples with comments
• Tokens should not be public anymore - we have a String() metdhod implemented + methods for serialization/deserialization

The keyboard package should be platform-agnostic and should poll events from external source (such as opengl Window using the dedicated interface).

At the moment there is no easy way to have two opengl contexts running at the same time. On the other hand two windows created out of one opengl works.

This fake is used extensively by Pixiq in unit tests. Should be publicly available for everyone willing to write unit unit tests without OpenGL. It might be in a pixiq/fake package

Some keys are like toggles - caps lock and num lk. In order the change the state of the modifier user has to press and release the button. Game might use this information somehow.

At the moment the keyboard package does not provide such information. Maybe we can add an API for checking the state of mentioned buttons. Something like:

keyboard.CapsLockOn()
keyboard.NumLockOn()

At the moment keyboard package can be used for checking the state of the keyboard. This is enough for most games. But some games have text input fields and support entering diacritic characters. They take also into the consideration the layout of the keyboard.

The API might be a new package which will provide some kind of buffer:

text := textinput.New(window)
text.Update()    // standard Update() method executed each frame
text.Text()         // text entered so far in UTF-8 (normal Go string)
text.Clear()       // clear the buffer 

• Example files should be placed in cmd/examples
• Files should have extensive comments

The doc should link to docs/architecture.md and docs/testing.md. It should encourage to make any kind of contribution - starting from submitting issues and writing docs to submitting pull requests.

Draft design can be found on wiki page Compiling and running Accelerated Functions

TODO:

• create glsl/blender package. Implement Fill function which will fill selection with specified color (more like gl.clearn than bucket tool).
• create glsl/shader package for compiling fragment shaders and preparing calls
• add image.Selection#Modify
• adapt Open GL C api to glsl/shader package

To avoid situation when Image and AcceleratedImage don't match in size we should hide opengl.NewAcceleratedImage. There is no need for such method. The opengl.NewImage method is enough.

At the moment developer has to write following code to instantiate glclear tool:

clearTool := glclear.New(gl.Context().NewClearCommand())

Thats a lot. We can simplify this piece of code to something like this:

clearTool := glclear.New(gl.Context())

What is needed is the new interface in glclear package:

type glContext interface {
    NewClearCommand() *gl.ClearCommand
}

Document should be short and contain basic information about pixiq package primitives (Image, Selection, Color, Screen, Loop) and coordinate system used by Pixiq (origin is on top-left corner, x is always before y in method signatures etc.). It should be approachable by beginner. Experiment with visual documentation - maybe create Pixel Art animated image describing basic primitives?

At the moment pixiq package has two different responsibilities: images and looping. These functions are independent of each other, therefore should not be a part of the same package. Moreover pixiq
name of the package does not mean anything. It does not suggest what should be placed in the package. I propose two different packages: image and loop and leave pixiq package empty forever.

Subtask 1: Move images to image package

• Create a new package image
• New image should be created using `image.New(w,h,AcceleratedImage)
• Get rid of pixiq.NewImages
• Add OpenGL#NewImage(w,h)
• Remove last parameter from opengl.Run
• Update docs

Subtask 2: Move loops to loop package

• Create a new package loop
• Loop should be run using loop.Run(screen, func(frame))
• Get rid of pixiq.NewScreenLoops
• Change the Screen interface - it should have only 2 methods: Image() (or Selection()) and Draw(). The opengl.Window should create the Image, not the loop. Thanks to that we will be able to get rid of this nasty type assertion in Window.Draw.
• Remove second parameter from opengl.Run . Maybe remove the Runmethod completely?
• Update docs

All those colors can be defined as variables in colornames package

Add a short document docs/testing.md with guidelines how to write good automated tests. This document will be linked in CONTRIBUTING.md file (not yet done).

Because glfw.PollEvents() is not called each frame the window eventually hangs.

the poblem was found in unreleased version (master branch)

opengl.Windows.Open function should be extendable. Right now new hints can be added easily. Just add another implementation of WindowHint. But there should be also a possibility to add a new option such as: title of the window, specify monitor where the window will be open, change the cursor image etc. These are hot hints, so the name should be changed.

nit: NoDecoration struct may be changed to function as well.

Should be really easy (and fast) to get and set pixels on the image:

• add setting/getting pixels on the whole image
• add setting/getting pixels on the image selection

Add support for getting and setting pixels outside:

• the image itself
• outside the selection

The screenMock is too complicated imho. It should be simplified.

Add a way to create a custom GL blender with custom program or fragment shader:

• Add methods for setting uniforms

Add instructions how to prepare environment for using the Pixiq:

• Go 1.13 with modules, something like go get -u github.com/jacekolszak/pixiq
• GLFW dependencies: https://github.com/go-gl/glfw#installation

Instructions should be for following operating systems:

• Linux - Ubuntu, Fedora
• MacOS
• Windows

Just run examples/keyboard/pressed/main.go. It is incredibly slow on MacOS and Intel GPU.

Potential problems:

• race during sending/downloading texture. After TexSubImage2D the actual pixels are not yet sent to GPU. Flush/Finish? should be issued after passing pixels slice as input or output. For uploading texture we can just copy the pixel slice and not block.
• Clear also does not work #92 for similar reason

This method should simplify the process of creating screens and images using OpenGL acceleration and GLFW windowing library. It should look like this (more or less):

opengl.Run(func(screens pixiq.Screens, images pixiq.Images) {
}

OS: MacOS Catalina
GPU: AMD

• When gl.ClearCommand is run the resulting framebuffer is always blue: 0x0000ff3b
• examples/tools/clear/clear.go is extremely laggy

Similar problems can be observed on Intel GPU.

More information about failing tests can be found in the CI build:
https://buildkite.com/pixiq/multiplatform-test/builds/8

Add a list of major milesones in a form of a list of checboxes.

There is a chance that a single frame processing will take more time than expected. The usual cause of the problem might be an inefficient image manipulation. But some pieces of code in the loop have to be executed in timely manner. One such piece is an input handling.

My initial idea is to create a new kind of optimzed loop which will support multiple callbacks, each executed at his own pace:

optimizedLoop := loop.NewOptimizedLoop(window)
// this function gets called at normal rate (at most 60 times per second)
optimizedLoop.Set(60, func(frame *pixiq.Frame) {
     // here goes the input processing
})
// this function gets called at lower rate (at most 30 times per second)
optimizedLoop.Set(30, func(frame *pixiq.Frame) {
     // here goes the screen draw
})
optimizedLoop.Execute()

Add loader package for loading png images (and maybe other formats too). Internally package should use standard image go package for decoding png files.

Potential solution (in pseudo code):

type Loader struct {
  func Load(io.Reader) LoadedImage 
}

type LoadedImage {
  func NewImage() *image.Image
  func CopyTo(target image.Selection)
  func Width() int 
  func Height() int
}

User might open a window with zoom specified as an integer. 1 means no zoom. 2 means that each pixel will be 2 times bigger etc.

For now this might be implemented only in opengl package. There is no need to expose such information to the pixiq package or others. Screen.Width() and Screen.Height() already return width and height not multiplied by zoom.

At the moment opengl package panics if he is not able to create an OpenGL context or open a new window. According to Effective GO panicking is not the correct way of reporting errors.

opengl package could return an error instead, but that might greatly complicate the use of API. Maybe add an additional method for checking the compatibility of the platform? Or create two variants of New: NewOrPanic() or New() error. We need to think about it.

• Add API
• Add opengl+glfw implementation using textures
• API should use pixiq.Image which can be modified by user. Updated image should be presented on the screen
• Should clean resources after window is closed
• Should be possible to open multiple windows
• When user clicks close button window should be closed (or event signaled)
• Should not generate much garbage to be collected by GC
• works on Linux + Nvidia drivers
• works on Linux + AMD drivers
• works on Linux + Intel drivers
• works on Linux + Mesa drivers
• works on Windows + Nvidia drivers
• works on MacOS + AMD drivers

Design and draw Pixiq logo. It should be PixelArt and might be animated.

Add more blending modes such as:

• destination
• destination-over
• source-out and destination-out
• source-in and destination-in
• source-atop, destination-atop
• xor

More information about alpha compositing can be found here:

https://ciechanow.ski/alpha-compositing/

New blending modes should be added to blend (CPU-based blending) and glblend (GPU-based blending)

Create a short document how Pixiq was designed and how it should be extended. This document will be linked to Contribution.md document (not yet available). Stuff which should be included:

• - hexagonal architecture, abstractions - describe design choices already made + how the API will evolve
• - Pixiq should be more like a library, not a framework
• - pixiq package should be small
• - pixiq package should be stable and backward compatible as soon 1.0.0 version is reached
• - new functionality should be added to new packages (and even to different modules)
• - few notes about SOLID, TDD etc.