oakmound / oak Goto Github PK

Before 1.4, we should add in more test coverage, possibly in the form of getting 99+% for everything but render first.

There are some very rare crashes we've seen in Oak that we haven't been able to duplicate, but there is one crash in particular that happens fairly frequently (1/20 runs) which terminates the engine as soon as it starts up, reported by the error here. Sometimes this error happens and the engine runs normally, other times it happens and the engine stops.

We believe this is a shiny bug, but we can't track down where it's coming from in shiny if it is. It may be Windows specific. It seems to happen more frequently on Win32 than Win64.

A few packages in oak have tests, those packages being the small utility offshoots (timing, alg) and not the primary focus of the engine (render, event, collision, audio, physics, probably in that order of importance).

Getting tests is probably a higher priority than the rest of the issues out right now.

Render - 30% Coverage

We've discussed render tests before and the one thing we weren't particularly satisfied with were tests that just confirmed that, if you wrote render.NewColorBox(...), the rgba of the type would be a 2d array of whatever color you put in. These tests don't seem very useful, they're sort of Identity tests. That's probably where testing should start anyway, though, then scene composition and manipulation tests with Modify functions.

Event - 95% Coverage

One particular test should be added that will be tricky, and that's that event priorities happen in the right order (Bind N functions at each priority, make sure that they are called in priority order).

Otherwise, making sure that events can unbind themselves and associated events and making sure that UnbindAll calls work will require a lot of effort but should be straightforward.

Collision - 30% Coverage

Collision should be easy to test: add a few types of collision space that collide or do not collide, confirm that the ones that should collide do and the one's that don't, don't. Include some label tests in there and raycasts and this should be done. Coverage will be a mess with all of the different ways to check for collision.

There's some special functions that should also be easy to test like SubtractRect

Audio - 90% Coverage

Audio can't be automatically tested because automatic testing utilities like Travis CI don't have audio devices to play off of. This could change in the future if klangsynthese starts accepting device definitions and one would be a 'mock' device, but it wouldn't make the tests particularly effective.

The methods in audio shouldn't be hard to test, ignoring the automatic testing problem. A lot of things would need to be checked manually or expose more information (audio channels) to make sure they are working correctly, however.

Physics - 100% Coverage

Attachment should be easy (attach a vector to a color box, move one or the other, confirm the other moved), and force / friction should also be doable.

Once these packages have tests, doing coverage analysis and filling in the gaps shouldn't be nearly as much of an endeavor.

We should support config-defined drivers for the engine. Shiny would be one, and openGL / glfw should be one, and vulcan, optimistically, would be one, as examples. Engine drivers should be an exported interface, so that it would be easy to take oak and place it onto another display driver.

Window manager Shiny does not currently let Oak support fullscreen. This should be fixed if possible.

Scenes should be moved to their own package, and the three scene functions should be packaged onto a struct or interface.

A common want is to be able to react to a press and a release on the same collision entity. To do this we'd need to track the LastMousePress just like we track the last mouse event, and on release, if both press and release collide with an entity trigger a MouseClick on the entity.

This would mean that you could press on an entity, drag off of the entity, drag back on, and release to click, but this seems acceptable.

In collision, we have NewRect, which for some reason is exposed even though the goal is for it to only be used internally, and if it errors we log.Fatal(err).

Until 2.0, this should dlog that error instead of Fatal.

At 2.0, it should be unexported, and all space functions should be able to return an error chained down from NewRect.

It would be pretty easy to optionally enforce that the colors used by oak all fit to some image/color palette when drawn, and would allow for some nice visual effects, particularly to emulate retro styles.

For a first benchmarking pass, we should write benchmarks for all of the main loops of the engine:

• Logic Loop
• Event Resolution Loop
• Draw Loop
• Input Loop

... In doing this we should investigate alternative, simpler implementations (that may disable features, and be triggered via config settings).

For example, vector drawing exists in x/image, there's a whole bunch of font libraries there, and there's a utility for colornames that we could add to our accepted color names instead of just accepting the couple we put in for testing.

For event bindings and entities we have the event bus, and for collision spaces we have the collision tree, but we don't allow for manual management for audio channels through some storage struct. This should change, and all of these should be reworked to have similar usage.

To avoid misspelling or not knowing the composition pattern of event or key strings, we should supply constants for all such strings used by the engine.

The existing helper entities use things from draw which made sense prior to the addition of the global draw stack and prior to the addition of multiple layers, and the helper entities also use space functions that manually add to collision's default tree instead of taking in a relevant tree to add themselves to.

This means that existing entities rely on legacy behavior, and new entities that have a cleaner API and don't rely on this behavior would be great. The existing entities are still useable for simple programs or for programs where the problematic functions aren't called.

We have an email address (that we rarely check) but other Go libaries have Gitter pages or gophers slack channels for regular communication about the library. We should emulate this, once there is a demand for it, and should choose what method is the most appropriate. I would lean towards a channel on the gophers slack right now.

We've attempted this in the past and the result was that the engine would compile but refuse to start, and then eventually run out of memory drawing nothing. At least some of those issues were related to the tight input and event handling loops not releasing their schedule priority. Who knows about the memory issues.

Right now Oak just accepts configs through LoadConf which takes in a relative filepath. Oak's config should be able to be

1. Manually set option-by-option
2. Imported via an io.Reader instead of just a filepath

That probably also warrants the config struct being exported, although the option-by-option constructor will probably use variadic functional args.

At the same time, users should be able to disable / enable some features of the engine through the Config that they currently can't. Batch loading at startup should be able to be turned off (it's maybe even better that it starts disabled and needs to be manually enabled), and gesture support should be able to be turned on. Considering how costly the keyHold loop is, as well (it more or less hogs an entire core), that should probably be able to be disabled. I think it makes more sense for that to be enabled by default, though.

Every message the engine outputs (as an error or otherwise) should be able to be localized to non-English languages as we get support for those languages. The act of translating our messages to other languages isn't going to happen any time soon realistically, but we should at least support the potential for this in the future.

Oak has a SetLang function but it isn't used for anything. The idea for this would be to move strings off to a subpackage, like oakerr but maybe with a different name (maybe oak/lang + oak/lang/oakerr) and add in support for 639-2 languages using the codes in https://godoc.org/golang.org/x/text/language.

Does Oak cross-compile / compile on a Linux Machine with ARM architecture (eg. a Raspberry Pi)?

Oak can draw lines and polygons, but not circles. We should add that.

While we're drawing polygons, the line drawing mechanism needs to change so that there's less duplicate code there.

Modify has a simple implementation but this should be pulled out to a separate more fully featured package

Animation and Sequence have almost identical function sets, with the only difference being 1. How they are initialized and 2. That Animations have a set of frames and a pointer to a sheet.

We either need to give Animation functionality to change its set of frames, so that it has unique functionality separate from Sequence, or we should have Animation initialization functions just create sequences.

This is potentially a breaking change, if we choose the latter option.

Oak should be able to import SVG

According to golang/go#11818, shiny is ~dead, and we should fork it if we want to add additional functionality to it.

We aren't trying to approach an ECS type engine, but it would be nice if the user of the library could either disable the event bus from trying to do anything, or could plug in an alternative implementation of the event bus. This could just come down to a config setting set before oak starts.

This would also mean that users wouldn't need to use an event bus that was as internally complex as ours, if they don't need the priority system, but would introduce problems if we started providing more entities that bound to non-default priorities (we already have one in the AttachSpace).

With fonts or characters that fall below the height of the font in pixels, some bits get cut off after calling 'ToSprite' on a text object. This should be fixable just by finding the appropriate function to measure text height in the truetype/freetype libraries.

Right now ToOutline in shape will use a straight 45 degree line to find a starting point for a shape's outline:

x . . . .
. x . . .
. . x . .
. . . x .
. . . . x

But this will fail for particularly wide or tall shapes. The diagonal used should be dependent on the width and height of the given shape to be successful on more input shapes.

Currently resizing of the window is fully on the implementing user.
Oak should be able to programmatically resize a window regardless of content.

One issue with the collision package is that we have far too many raycasting functions that all perform similar things but act as overloading with different arguments. This is a sign that we should be using optional variadic arguments to construct different types of raycast queries, as more often then not there are a number of static variables like label sets or angle ranges that don't need to be re-applied every function call.

While we're doing this we want to add yet another feature to raycasting, the ability to pierce or ignore the first n elements in the target set. The use case for this is specifically an enemy that exists in a wall, and needs to shoot out of the wall, but does not want to shoot through other walls. In this case we would indicate the raycast pierces one element, which would always be the first wall, and would only report collision of the second hit element.

I just installed oak by following the instruction in the README:

go get -u github.com/oakmound/oak/...

Got this output

# github.com/200sc/klangsynthese/audio
../../200sc/klangsynthese/audio/encoding.go:18: undefined: EncodeBytes
../../200sc/klangsynthese/audio/encoding.go:23: undefined: EncodeBytes
../../200sc/klangsynthese/audio/format.go:28: undefined: EncodeBytes

Expected

No output

Software

$ go version
go version go1.8.3 darwin/amd64

    System Software Overview:

      System Version: macOS 10.12.5 (16F2073)
      Kernel Version: Darwin 16.6.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: Peter’s MacBook
      User Name: Peter Hellberg (peter)
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 12 days 21:52

Particle Sources should have their recycle mechanics overhauled. This should make particles more efficient.
Since particles are performance intensive how the recycling of particles works needs to be carefully considered otherwise it can end up making performance much worse rather than better.

This is mostly here to recognize that we are aware of this issue; we are unable to reliably replicate this to then attempt to fix this:

Very rarely at startup the engine will run slow (if at all) and some memory conflict in dynamicTicker.go will be raised.

You should be able to swap out key binding sets, and probably read and write them to file

We have a number of examples on using oak in the examples directory, but it'd be nice if we had a real webpage you could use to navigate the examples.

At the same time, we want to start populating a wiki for simple code snippets.

Both of these things would be much easier if we could use oak in javascript.

Examples still refer to bitbucket.org/oakmoundstudio/oak

We should make a branch for breaking changes so we can resolve those issues-- this would be particularly useful for smaller changes like renaming.

func lifecycleLoop(s screen.Screen) {
initControl.Lock()
if lifecycleInit {
dlog.Error("Started lifecycle twice, aborting second call")
return
}
lifecycleInit = true
initControl.Unlock()
dlog.Info("Init Lifecycle")

We should work some magic and get a pure go syscall-powered usb driver, so we can support controllers.

This is a pseudo-constant issue.

We rushed out a lot of documentation so that we had -something- on our functions, but a lot of the docs written are insufficient for representing how to use said function.

What needs to be done here: people who are not familiar with this project should just look through the code, and ask questions about exported functions and types that are not clear. After those questions have been asked, someone familiar with the code should clarify the documentation, and then either the asker or the maintainer can make a PR to update the documentation appropriately.

Because these changes should be rather small, this is a friendly issue for first-time contributors.

In the same vein, for writing code, we have insufficient tests throughout the project and tests could be written by those unfamiliar with the project to demonstrate difficulties with the API or documentation.

There needs to be a way to force aspect ratio to be maintained.

Considering they are items that go on the draw stack, this name would make more sense. This would be a breaking change, for 2.0.

Renderable modifications right now are our highest memory usage function, other than maybe loading audio. All modifications right now modify the element in place, but do so using functions that allocate new RGBAs (except for InPlace modifications, but there are very few of those). Either two functions should exist, to modify in place or not, or a function that would .Copy() and them .Modify() should exist for the use case of not modifying something in place. Then all modifications that could operate on an rgba and not allocate a new one would.

1. Support any shape function.
2. Let size change over time

Is there plan for ios & android support?

We'd like to know how fast we can draw and update texts. Right now we redraw the text every frame, but it'd be nice if we could find a way to not do that

The way to not do that is to draw it to an rgba once and then move that rgba around, but that makes modifying texts way harder. It's possible we could split Text into two types-- Static and Modifiable (of which only the former would be a render.Modifiable because it would be an rgba, to confuse terms)

When drawing a vertical line (xDelta == 0), the function goes into a corner case that sets thickness equal to 1 regardless of value passed in.

The offending line is here:

The desired behaviour is to allow vertical lines to be drawn at different thicknesses (while applying color + color gradients properly).

We ran into an issue today where we needed to represent explicit directions, and we didn't want to represent them as vectors. We've resolved this problem a number of times but couldn't use an existing solution due to circular dependencies. This might justify the addition of directional types (perhaps to alg). This would be something along the lines of

type Direction2 int
type Direction3 int

With associated consts

const(
    Up Direction2 = iota
    Right Direction2
    Down Direction2
    Left Direction2
    
    North Direction2
    East Direction2
    South Direction2
    West Direction2
)

etc.

However, there would need to be a good way to abstract the similarity between these directions, at least in part via conversion to floatgeom.PointXes, and we would need a good way to abstract the different groups of directions-- relative vs cardinal, angle between points in a set. It would make sense for there to be a set of points for 4-way, 4-way-diagonal, 8-way, and 6-way movement, for different tile layout types-- expanding this to 3 dimensions in similar sets as well. This would require that a Direction has a query function for knowing what DirectionType it is in, and at this point it looks like direction should be it's own package.