►
From YouTube: Silk.NET Community Meeting & API Review
Description
Join the Silk.NET team on 25 Feb 19:00 UTC for a community meeting as they discuss & review designs for ongoing improvements! Have you used Silk .NET or a similar library, or interested in .NET graphics/compute? Tune into this stream and give the team your thoughts!
0:00 Chapters:
3:03 Introduce the Community Meeting & Silk.NET 3.0
8:48 Review the overview of Silk.NET 3.0 and its goals:
33:04 Review 3.0's Windowing design:
1:02:02 Review 3.0's Multi-Backend Input design:
2:06:56 Review 3.0's Generator & P/Invoke mechanism proposal:
2:53:54 Wrap-up & Q&A
Proposals:
https://github.com/dotnet/Silk.NET/blob/proposal/all-3.0-proposals/documentation/proposals/Proposal%20-%203.0%20%26%203.X%20Software%20Development%20Plan.md
https://github.com/dotnet/Silk.NET/blob/proposal/all-3.0-proposals/documentation/proposals/Proposal%20-%20Windowing%203.0.md
https://github.com/dotnet/Silk.NET/blob/proposal/all-3.0-proposals/documentation/proposals/Proposal%20-%20Multi-Backend%20Input.md
https://github.com/dotnet/Silk.NET/blob/proposal/all-3.0-proposals/documentation/proposals/Proposal%20-%20Generation%20of%20Library%20Sources%20and%20PInvoke%20Mechanisms.md
GitHub: https://github.com/dotnet/Silk.NET
Discord: https://discord.gg/DTHHXRt
A
A
A
A
B
B
B
D
B
I
think
we're
just
gonna
have
to
roll
with
it.
To
be
honest,
I'm
not
saying
the
numbers
haven't
flickered
in
a
while,
so
we're
just
gonna
have
to
go
with
it.
So
hi
welcome
everyone
to
the
community
stream.
The
community
meeting,
so
I
am
Dylan
or
perksy.
I
am
one
of
the
maintainers
on
silk
I'm
joined
by
Kai
and
Thomas,
who
are
other
maintainers
and
then
some
Community
contributors,
tana
and
Bailey
who
have
joined
us.
B
We've
got
a
number
of
community
contributors
that
tend
to
pop
in
on
these
meetings,
but
at
the
same
time,
just
because
you
can't
use
your
human
voice,
it
doesn't
mean
that
you
can't
talk
to
us
in
the
chat.
We
are
looking
up,
the
YouTube
chat
for
feedback
and
at
the
same
time,
if
you,
if
you're
watching
this
on
demand,
you
can
send
us
feedback
over
GitHub
in
our
Discord
server
order.
B
While
we
have
a
Twitter
now,
so
you
can
use
our
Twitter
yeah,
just
just
send
us
whatever
feedback
you
have
wherever
you
can
send
it,
and
we
shall
read
this
and
mull
over
it,
but
yeah.
So
the
main,
the
main
point
of
us
doing
this
meeting
is
because
we
want
to
gather
all
the
feedback
we
can
for
the
new
version
of
civil.net,
because
at
the
moment
we
are
currently
designing
a
rewrite.
We
haven't
actually
started
implementing.
A
B
But
we
are
designing
it,
we've
written
up
the
designs
and
we
want
to
make
sure
that
the
community
sort
of
agrees
with
them
before
we
actually
go
ahead
and
Implement
them,
because
well,
if
we
Implement
something
that
you
all
disagree
with,
then
not
only
have
we
made
the
community
mad.
We've
also
wasted
our
time
and
sort
of
have
to.
We
just
want
to
build
the
best
Library
we
possibly
can
and
yeah.
We.
We
look
forward
to
what
feedback
you
have,
and
hopefully
it
all
goes
to
plan.
B
Our
designs
are
sort
of
favorable
and
we
can
start
implementing
this
thing
so
yeah.
This
is
sort
of
the
start
of
a
new,
a
new
age.
If
you
like
of
thought
on
that
I
know
that
sounds
really
cringy,
but
yeah.
It's
a
new
phase
and
yeah.
So
we've
got
a
number
of
designs
and
another
documents
to
review
if
I
switch
over
to
my
screen.
B
So
this
first
document
we've
got
it
sort
of
goes
over.
What
we're
trying
to
do
with
this
new
rewrite
yeah
it's
sold
on
that
3.0.
We!
It
is
a
major
version,
so
there
will
be
breaking
changes
but
yeah.
All
of
these
documents
are
linked
in
the
description,
so
you
can
have
a
read
with
them.
At
the
same
time,
you
can
just
look
at
us.
B
Look
at
the
stream
as
well
for
the
people
in
Discord,
it's
probably
best
on
bandwidth,
if
I,
don't
if
I
don't
share
my
screen
at
Discord
as
well,
so
you're
just
gonna
have
to
follow
along
with
the
stream
and
appreciate
the
delay.
I
think
it's
around
two
seconds
in
our
initial
testing,
so
yeah.
So
this
this.
It's
still
still
on
that
3.0,
something
that's
been
building
across
the
entirety
of
the
development
of
the
current
version
itself
on.
B
That
is
that,
while
we
thought,
except
on
that
2.0
was
it
sort
of
gave
us
everything
we
needed.
We
realized
we
were
carrying
around
a
lot
of
crust
from
the
older
version
of
cell.net
because
it
had
the
code
base
hasn't
really
significantly
changed,
since
it
was
created
three
years
ago
and
I
know
three
years
is
a
relatively
short
time.
B
It's
it's
in
the
vast
scheme
of
things
because
of
how
fast
on
that
moves.
It's
a
it's
a
perfectly
short
amount
of
time
to
gather
lots
of
lots
of
tech
there
and
just
loads
of
questionable
things
and
we've
over
time
we've
sort
of
realized.
We
could
do
things
a
lot
better
and
especially
with
all
the
changes
happening
in.net
at
the
moment.
We
definitely
wanted
to
design
some
things
that
accounted
for
the
changing
landscape.
So
this
is
the
golden
3.0
really.
So.
First
of
all,
this
is
a.
B
This
is
a
departure
from
a
2.x.
We
are
using.net6
exclusively
seeing
as
you
can
Target
all
of
the
platforms
like
mobile
and
desktop
from
from.net6,
rather
than
the
previous
model,
where
you
had
a
net
core
you
had,
so
you
had
xamarin
and
all
the
other
stuff.
So
we
don't
need.
We
don't
really
need
to
support
those
older
Frameworks
anymore.
B
So
the
second
goal
is
that
we
want
to
sort
of
design
the
API,
so
it's
more
easily
integrated
with
other
systems,
because
I
know
one
of
the
biggest
feature
requests
so
far
has
been
win,
forms
and
WPF
among
a
lot
of
other
UI
Frameworks
and
our
current
apis.
They
that
they're
sort
of
designed
to
be
Standalone.
B
They
don't
really
fit
into
other
Frameworks,
very
well
so
by
our
the
new
API
we've
designed
it's,
it
can
be
as
Bare
Bones
as
you
want
it
or
it
can
be
as
Standalone
as
you
want
it,
and
it
should,
in
theory,
just
give
you
an
object
that
you
can.
That
can
either
represent
a
standalone
window
or
something
integrated
in
with
your
UI,
and
you
can
just
pass
that
around
to
your
code
as
you
see,
but
we've
all
discussed
that
further.
So
that
does
have
its
own
proposal.
B
So
yeah,
when
to
we've
sort
of
covered
that
the
real
windowing
rewrite
now
a
lot
of
one
of
the
most
pain
points.
Painful
points
in
2.x
has
been
the
bindings
generator
now.
This
was
something
that
was
quickly
whipped
together
in
the
early
silk
days
to
well
quickly
get
some
binding
we're
going,
and
it
worked
well
for
opengl
because
that's
the
main
thing
it
was
designed
for.
B
But
then
we
started
duct
taping
lots
of
other
stuff
like
Vulcan,
like
Open,
Sea,
Island,
so
loads
of
other
apis.
On
top
of
it
and
it
sort
of
became
an
unmaintainab,
it's
an
alien
and
then
we've
still
got
92.0
when
we
were
supporting
DirectX
as
well
as
a
whole
load
of
other
libraries
as
well
it
very
it's.
It
wasn't
well
designed.
We
never
gave
it
much
thought
we
just
sort
of
tried
to
show
off
everything
through
the
same
pipelines
as
we
always
have
been
so
yeah.
B
We
would
we
we
figured.
We
should
take
a
step
back
and
well
hey
we
designed
something
that
is
usable
outside
of
cell.net,
because
well
we
it.
While
it's
a
message
only.
It
is
a
good
generator
and
we
want
other
users
to
be
able
to
use
it,
whereas
right
now
it's
very
much
tailored
towards
our
needs
and
B.
B
B
E
B
So
what
we're
sort
of
hoping
with
this
proposal
is
that
we
can
have
a
solid
base
that
both
Terror
effects
and
Silverton
that
are
using
and
sort
of
build
from
that
base,
our
own
sort
of
style,
because
silver.net
will
always
be
a
bit
more
C
Sharpie
than
the
base
material,
whereas
Terror
effects
it's
sort
of
exposing
the
it
sort
of
as
Bare
Bones
as
possible.
So
you
can
just
sort
of
copy
and
paste
almost
C
code
and
it
be
pretty
close
to
what
it
is
when
it's
put
in
Z
Sharp.
D
B
B
But
right
now,
there's
no
immediate
plans
for
metal
bindings,
but
it
is
one
of
the
sort
of
low
prior
lower
priority
items
that
has
been
asked
for
a
lot
and
well,
you
never
know
is
what
we're
trying
to
say,
but
it's
not
in
official
plans
right
now,
so
yeah
it
might
happen.
You
just
have
to
see
how
things
go,
I,
guess
so
yeah.
B
Another
point
of
this
is
we
want
to
make
our
maths
Library
a
lot
faster,
so
that
I
know
there's
a
number
of
jit
changes
happening
to
sort
of
make
it
happen
at
that
layer.
But
at
the
same
time
we
also
wanted
to
use
intrinsics
and
sort
of
expose
our
own,
our
brain
abstraction
layer
on
top
of
the
various
system,
Specific
Instructions.
B
So
that
proposal
we've
already
reviewed
and
it's
currently
being
developed
against
2.x.
However,
it
might
be
depending
how
long
development
takes
that
we
just
move
this
into
3.0
straight
away.
We
will
that's
primarily
being
championed
by
a
community
contributor
at
the
moment,
so
we'll
have
to
see
how
that
goes.
B
That's
interesting,
I
forgot
to
turn
my
notifications
off.
Let
me
do
that.
Actually,
no,
let's
not
do
that,
because
that'll
show
all
my
notifications,
so
yeah
we've
already
reviewed
that
we're
not
going
to
go
over
it
again.
However,
that
link
is
in
that
document.
If
you
wanted
to
have
a
look
at
it,.
D
B
Yeah
I,
don't
remember
where
we
put
the
notes
for
that
I
think
it
was
fairly
recent.
Actually
a
little
different
pull
requests.
I!
Think
it's
on
the
issue.
Is
it
okay?
Oh,
wait.
Hang
on
Sims
Cindy
revision
Is
that
yeah
here
it
is
so
the
meeting
notes
are
on
pull
request
690
if
you're
interested
in
that
I've
just
seen
a
a
question
in
the
chat
from
Matt
is
that
it
does
Morton
BK
already
work
anyway
with
silk.
F
B
There
so
it
just
needs
someone
to
give
it
a
go.
Essentially,
but
yes,
molten
VK
is
a
target
facility.net
already
and
if
it
doesn't
work,
then
that's
something
we
need
to
fix,
but
yeah
it
should
work.
Fine,
so
yeah
in
this
document.
It's
your
sort
of
outline
the
development
roadmap.
Now
I'm
not
going
to
go
through
every
Point.
Here
you
can
give
the
document
of
links
I
read,
but
we're
following
the
same
five
preview
model
that
we've
done
in
the
past
for
two
One
X
and
1.x.
B
B
It's
we're
sort
of
shaping
the
library
a
lot
more
previously
almost
there,
but
we've
just
got
a
lot
of
a
lot
of
behind
the
scenes.
Work
to
do,
but
maybe
some
things
will
change.
I,
don't
know,
but
it's
it's
getting
close
to
the
end
product
and
then
preview.
Four
is
what
we
start
suggesting
hey.
You
should
start
moving
your
applications
to
this.
This
is
getting
pretty
close
to
well,
it
is
production,
ready
it's
what
we
class
production
ready.
B
It
is
probably
at
that
point,
depending
on
how
things
go,
that
we
might
stop
2.x
updates,
because
I
know
we
did
that
at
2.0
development
as
well
as
we
stopped
updating
1.x.
Once
we
had
a
production,
ready
preview
and
in
preview
five,
it
should
be
literally
just
bug
fixes
almost
almost
ready
to
release.
So
it's
at
that
point.
B
So
in
this
in
development
list,
we're
going
to
take
a
much
stricter
stance
on
documenting
is
that
at
the
very
least,
the
implementation
of
everything
should
be
documented.
So
some
use
documentation
could
be
extrapolated
from
that
and
in
addition,
the
community
is
more
likely
to
contribute
because
they
actually
understand
what
we've
written,
whereas
right
now
the
the
silver
Knight
code
base
is
a
bit
of
a
mess
and
unless
you're
in
our
Discord,
which
to
be
fair,
is
a
perfectly
acceptable
resource
with
with
sadly
pretty
much
always
active
in
there.
B
We
should
probably
find
something
better
to
do
with
our
time,
but
no
we're
always
there
so
yeah.
You
can
always
talk
to
us
for
finding
your
feet
in
our
code
base,
but
really
that's
the
only
resource
we
have
for
contributing.
At
the
moment
there
isn't
a
lot
of
planning
we've
sort
of
gone
with
it.
So
we're
being
a
lot
stricter
with
our
proposals
as
well
to
get
the
community
feedback
and
we're
going
to
do
these
Community
meetings
regularly
as
well,
not
a
fixed
interval.
B
We
want
ready
the
barrier
to
entry
for
external
contribution
again
we're
trying
to
solve
this
with
documentation
as
well,
and
our
level
correctness
is
inconsistent.
So
the
the
silk
touch
rewrite
which
we're
going
to
touch
on
later,
which
uses
claim
sharp,
but
our
correctness
should
go
immediately
up,
seeing
as
those
bindings
are
a
lot
more
proven
than
our
sort
of
duct
tape
generator.
B
So
this
sort
of
describes
how
we're
going
to
lay
out
the
documentation
in
the
actual
repo
I,
don't
think
there's
much
much
of
interest
there
and
it
sort
of
says
how
we're
going
to
document
it.
So
the
the
idea
is
that
we
have
four
contributors
and
then
we
have
used
documentation
as
one
ring
for
both
most
of
this
I
presume
is
unobjectionable.
B
But
if
somehow
you
do
have
an
objection,
please
put
it
in
the
chat
or
raise
your
voice
so
yeah
and
we're
going
to
be
continuing
the
monthly
updates
that
we
do
for
2.x
at
the
moment,
because
I
think
sort
of
that
has
proven
to
work,
but
at
the
same
time,
the
libraries
that
we
bind
to
they
change
all
the
time.
So
we
should
probably
keep
up
to
date
we're
going
to
keep
up
with
them
first
Friday
of
the
month
schedule
that
we
do
for
our
updates.
B
So
it's
just
safer
to
keep
up
being
a
minor
version
and
it's
easy
to
follow
as
one
so
breaking
changes.
We've
also
got
an
official
breaking
change.
It.
A
change
policy
now
which
we
didn't
before
we've
left,
it
vague
to
say.
If
there's
a
there's,
an
API,
that's
causing
a
lot
a
lot
of
problems
in
the
community,
we
reserve
the
right
to
remove
it,
which
has
been
a
problem.
In
the
past,
we've
had
some
apis
which
Every
Which
everyone
in
the
community
just
didn't
know
how
to
use
well.
C
B
B
Or
any
thoughts
about
what
we
should
be
doing
in
3.0,
and
what
isn't
that?
Because
we've
We've
mentioned
that
WPF,
winforms,
Maui
and
avalonia
are
a
current
currently
our
priorities
for
UI
libraries.
But
if
there's
anything
else
that
you're
interested
in
we'd
love
to
put
it
on
the
list.
And
likewise,
if
there's
any
Bindings.
That
you're
interested
in
would
love
to
hear
what
you
think.
B
D
Also
pointing
out
that
all
of
the
already
listed
ones
and
also
all
other
potential
ones
are
primarily
aimed
at
making
a
component
or
some
equivalent
that
works.
So
it's
not
about
controlling
the
whole
vpf
window.
It's
more
about
making
like
a
vpf
component
that
you
can
like
embed
and
then
use
the
context
inside
of.
B
To
answer
a
question
from
the
chat:
yes,
so
yeah,
so
one
of
the
things
with
this
with
this
move
to
Clank
show
up
is
to
sort
of
standardize
our
libraries
and
make
it
more
correct.
So
the
the
our
current
generator
it's
very
much
been
bashed
towards
the
shapes
that
we
need
it,
and
not
really.
It's
not
really
aimed
to
be
like
a
general
CC
plus
bindings
generator,
unlike
Clank
sharp,
which
is
and
has
been,
has
proven
to
work
with
a
number
of
libraries.
B
So
as
part
of
this
consolidation,
we
will
be
well.
We
we're
hoping
to
make
salt
touch
more
portable
by
virtue
of
clangshot
being
more
portable,
so
yeah
I
mean
we.
We
actually
contributed
XML
support
for
Clank
show
up
so,
instead
of
outputting
its
bindings
as
C
sharp
code,
we
just
output
it
as
an
XML
tree
that
we
can
parse
in
our
generator
and
then
add
our
right
modifications
on
top.
B
B
B
B
Okay,
so
the
next
one.
Now
we're
actually
reviewing
some
actual
code,
which
is
interesting
and
we
haven't
lost
our
views.
Yet
so
that's
good
to
know
we
haven't
bought
you
all,
so
this
is
sort
of
Kai's
baby,
so
I
will
I
will
pass
over
to
him
at
some
point,
but
so
I
should
probably
just
first
explain
sort
of
what
our
windowing
library
is
before
I
hand
over
to
guy
to
sort
of
go
through
what
his
problems
with
the
current
API
were.
B
So,
since
the
beginning
of
silk.net,
we
have
provided
a
windowing
abstraction
over
the
various
platform,
specific
window
creation
apis.
At
the
moment,
this
is
just
a
wrapper
over
glfw
which
well
in
2.x,
is
a
wrapper
over
glfw
and
sdl,
which
take
us
to
all
the
platforms
that
we
want
to
support
at
the
moment
in
3.0.
C
B
B
B
It's
a
1.x,
whereas
this
one
we're
sort
of
having
it.
It
was
a
common
theme
we're
having
a
step
back
and
sort
of
giving
it
a
proper
look
and
figuring
out
what
we
could
do
better,
and
this
is
how
the
the
design
has
sort
of
come
to
light.
So
we
wanted
to
really
encourage
right
once
one
run
everywhere
where
currently
in
the
2.0
API,
you
have
an
eye
window
and
an
eye
view.
An
eye
view
is
what
you
use
on
mobile
and
then
I
window
is
what
you
use
on
desktop.
B
B
If
we
manage
to
get
support
through
as
well
so
I'm
going
to
hand
over
to
Kai
a
little
bit
to
sort
of
talk
about
his
Philosophy
for
the
actual
design,
because
it
this
was
sort
of
his
brainchild
at
least
initially
and
I,
just
sort
of
did
the
hard
work
of
documenting
it,
but
yeah
the
original
ice
surface,
which
is
coined
in
this
proposal
and
it
sort
of
came
from
Kai,
so
I
shall
hand
over
to
you.
Okay,
right.
D
D
So,
first
of
all,
we
still
have
like
a
main
static
class
that
you
use
to
acquire
a
service,
but
instead
of
having
you
always
create
one
like
it
is
right
now
with
window
we
just
have
get
or
create,
and
this
is
kind
of
like
the
most
important
part
of
this.
You
just
ask
for
silk
to
find
something
to
draw
to
and
on
a
phone.
This
will
just
be
just
the
phone
screen
and
on
Windows
and
Mac,
OS
and
Linux.
This
will
probably
just
be
a
new
window,
and
this
should
be
the
standard
use
case.
D
There
is
still
apis
to
facilitate,
like
multi-window
drawing
on
desktop,
but
that's
not
the
the
main
idea
here.
The
main
idea
is
to
support
the
99
of
applications
that
create
one
window
and
just
need
some
place
to
draw
through,
and
this
is
what
surface
is
so
yeah.
That's
that's,
basically
the
core
that
service
is
just
something
you
draw
to,
and
this
should
be
implementable
everywhere
in
the
window.
D
We
may
have
use
of
more
interfaces.
The
base
interface
is
just
really
basic
stuff,
so
you
get
the
size,
I!
Think
yep,
that's
right!
It's
visible
on
the
stream.
You
get
size,
you
get
to
control.
How
fast
this
Runner
is.
This
should
all
be
kind
of
familiar
to
someone
already
using
silk.net,
it's
all
of
the
standard
events
and
also
standards
stuff,
but
there's
nothing
Advanced
here
you
can't,
for
example,
you
can't
visize
the
window
from
from
this
basic
API,
because
you
can't
do
that
everywhere.
You
can't
resize
a
vpf
component.
D
You
can't
resize
a
phone
screen,
that's
not
something
that's
really
possible,
and
so
all
of
those
kind
of
went
away
and
really
tried
to
keep
the
base
interface
easy
and
simple,
and
then
we
make
lots
of
use
of
type
checking.
So,
for
example,
if
you
wanted
to
oh
yeah,
if
you
wanted
to
do
specific
things
on
a
desktop,
you
would
try
and
see.
If
the
current
surface
you've
been
assigned
implements
a
desktop
surface,
that's
kind
of
the
other
big
API
and
and
there
for
example,
we
can
see
size
is
now
assignable.
D
D
There's
four
for
GL
and
glds
H2,
which
exposed
some
well
GL
specific
things,
so
they
exposed
a
handle.
They
expose
whether
the
current
GL
context
is
current.
They
expose
the
swap
interval
of
the
the
bit
depth
Etc,
which
just
doesn't
exist
on
like
if
you
use
direct
access.
These
all
just
make
no
sense.
So
again,
if
you
want
to
use
GL,
you
check
for
this
interface
and
you
kind
of
use
it
right.
Then
we
also
have
the
same
for
Vulcan
again
very
similar
kind
of
style.
D
You
if
you
want
to
use,
welcome
you
check
whether
ivk
Services
implemented,
and
then
you
can
try
to
enable
it
using
the
function
same
as
GL
and
then
and
then
you
can
use
create
to
create
the
Vulcan
surface,
and
it's
it's
very,
very
similar
everywhere
for
GL
users,
pretty
much.
Nothing
has
changed.
It's
just
you
now,
I
have
to
check
whether
to
cursor
first
supports
GL
and
for
everyone
else.
It's
just
kind
of
gotten
nicer
because,
for
example,
Vulcan
before
you
had
a
separate
property,
you
had
to
like
access,
and
that's
not
very
nice.
D
So
now
you
just
have
exactly
the
same
level
of
support
as
GL
users
had
yeah
and
then
basically
the
last
kind
of
new
API
is
before
we
had
a
sort
of
not
very
widely
known
and
not
very
widely
used,
monitor.
Api
that's
been
replaced
pretty
much
by
ice
cream
and
ice
cream.
Almost
everything
you'd
expect
from
the
screen.
D
It
basically
tells
you
the
basic
properties
and
allows
you
to
modify
the
ones
that
are
commonly
modifiable
and
I.
I
won't
really
go
into
depths
here,
because
it's
not
super
important
yeah,
I
think
I
think.
Basically,
all
of
these
have
been
have
existed
on
silk.net
2
already,
the
only
one
that's
also
sort
of
new
is
I'm
going
to
handle
Source.
This
is
kind
of
a
niche
feature,
but
just
want
to
point
out.
You
still
support
you
having
access
to
the
to
the
native
handle
of
the
window
in
case
you
ever
need
it.
D
D
B
I'll
I'll
be
willing
to
take
it.
It's
fine,
so,
okay,
in
order
to
sort
of
facilitate
a
right
one
to
run
everywhere.
Experience
obviously
there's
it's
very
different.
How
you
start
up
a
application
on
desktop
versus
how
you
start
up
an
application
on
Android
or
iOS
on
desktop
it's
as
simple
as
just
having
a
main
function
in
a
static
class
somewhere,
whereas
on
Android
it's
a
lot
more
complicated
you've
got
to
have
an
activity
on
iOS,
so
it's
also
a
lot
more
complicated.
You've
got
to
have
an
app
delegate.
B
So
what
this
silk
entry
point
sort
of
covers
is
that
you
have
you
make
a
sort
of
like
a
main
function,
and
then
you
just
put
silk
entry
point
on
there
and
then
it'll
Auto
automatically
generate
the
most
appropriate
entry
point
mechanism
for
that
platform.
So
on
Android
it
will
generate
an
activity
for
you
on
iOS.
It
will
generate
an
app
Delegate
for
you
and
on
desktop
and
it
would
just
generate
a
main
function.
The
idea
is:
is
that
you
sort
of
don't
have
to
care
about
these
differences.
B
You
just
put
a
magical
attribute
on
a
function
that
it
automatically
generates
the
code
for
you,
it
sort
of
enhancing
that
right
wants
to
run
everywhere
experience
so
hopefully
that
mostly
covered
that
I
mean
I'm
pretty
sure
these
are
all
pretty
sane.
Restrictions
like
it
has
to
be
a
static.
It
must
return,
void,
etc,
etc.
B
So
yeah,
it's
essentially
just
static
function
that
we
generate
the
guts
for,
and
then
we
call
into
it's
worth
another
thing:
you
can
put
a
desktop
surface
if
you
only
want
your
your
application
to
run
on
desktop
surfaces
or
igl
Surface.
If
you,
if
you
need
a
surface
that
uses
opengl,
you
can
just
put
that
there
and
it
will
automatically
do
the
querying
for
you
as
well
so
yeah,
and
it's
worth
noting
that,
because
of
platform
differences,
this
can
technically
be
called
multiple
times.
B
B
B
B
B
D
So,
for
example,
your
engine
might
see
which
kind
of
apis
are
supported
in
which
versions
and
then
selects
one,
and
then
everyone
Downstream.
Basically,
so
they
expect
this,
and
usually
we
just
kind
of
had
this.
Just
we
just
expected
it
and
if
something
went
wrong,
just
everything
just
kind
of
went
up
in
flames
and
using
this
design.
This
is
basically
interpret
type
safety.
D
So
your
methods
that
kind
of
require
or
expect
Vulcan
just
take
as
a
parameter
ivk
surface,
and
then
there
is
no
way
to
make
it
go
wrong,
it'll,
just
sort
of
work
by
type
safety.
If
you
try
to
call
it
using
without
checking
it'll,
just
not
compile,
and
that's
kind
of
the
main
reason
for
this
design
over
booleans.
B
Yeah,
basically,
it's
mainly
down
to
how
the
how
the
actual
Java
Runner
balls
work
with
respect
to
that
is
that
we
found
in
in
our
two
point
x.
Testing
is
the.
If
you
leave
your
if
you
force
the
application,
when
you
started
back
up
again
for
some
reason,
the
main
function
was
called
again.
It
doesn't
actually
keep
that
runnable
alive.
In
the
background,
if
you
like
in
some
cases
in
some
cases
it
does
as
well.
So
it's
sort
of
inconsistent,
so
we
sort
of
wanted
to
specify
that
hey.
D
B
B
E
It's
thorough
so
ice
you,
you
called
out
the
ability
to
get
the
window
handled.
What
about
the
other
handle
that
you
need
for
Vulcan
and
some
other
specialized
scenarios
which
handle?
Do
you
mean
so
so
to
create
a
surface
like
a
BK
surface
object
or
do
any
kind
of
customization?
You
need
both
the
window
handle
plus
another
handle
which,
in
terafx
I
just
call
the
context
handle
which.
D
D
It'll
it'll
be
the
instance
handle
and
usually
in
so.net.
This
is
typed,
as
instance,
or
VK
instance,
and
has
an
underlying
handle
field
because
we
don't
want
to
have
the
dependency
here.
It
just
takes
a
parameter
and
in
instance,
so
you'll
just
sort
of
have
to
unwrap
the
the
instance
object
from
from
open.
E
D
D
B
We
we've
had
we've
sort
of
put
a
note
there
that
we
reserve
the
right
to
sort
of
put
whatever
handles
that
might
be
relevant
to
our
implementations
for
that
so
for
it.
Well,
you
raise
a
very
good
point
for
winter.
It
would
probably
want
to
put
the
H
instance
the
HDC
and
the
H
wind
in
there,
as
well
as
on
X11
I
mean
for
it
right
now
in
on
the
current
onset,
is
that
this
will
probably
be
just
basically
a
structs
version
of
what
we
have
in
our
native
window
today.
B
I
should
put
a
link
to
that
in
the
Discord
just
so
you
can
sort
of
follow
along
with
that,
but
yeah.
So
for
winter
too,
specifically,
you
have
the
H
wins
the
HDC
and
the
H
instance
for
X11.
You
have
to
display
the
window
for
Weyland.
Do
you
have
the
display
in
the
surface
Etc,
so
it's
open
to
interpretation,
it's
open
to
put
whatever
we
want
in
there.
B
Whatever
we
deem
relevant
on
for
glfw,
specifically,
we
actually
only
get
the
H
wind,
so
we
have
to
query
the
we
have
to
query
the
other
pointers
ourselves
using
get
window
long
and
get
window
long
pointer
and
get
DC,
unfortunately,
but
yeah.
So,
unlike
2.8,
we
can
actually
add
more
handles
without
breaking
so
yeah.
We,
we
will
add
whatever
handles
that
are
most
reasonable
for
the
user
and
what
could
be
useful.
D
B
Yeah
I
I
suppose
I
I
mean
part
of
this
is
I,
don't
know
what
the
official
stance
is.
From
a.net
perspective
on
caring
about
memory,
layouts,
it's
I
mean
obviously
with
our
low
level
Library.
It
seems
like
the
sort
of
thing
we
should
care
about,
but
I
don't
know
I
mean
we
could
put.
We
could
put
a
note
on
there
like.
Should
we
sort
of
like
the
layout
of
this
struct
isn't
guaranteed
or
whatever
I'm
not
I'm,
not
sure
but
yeah?
B
E
B
B
E
A
B
B
D
Sorry
I
didn't
want
me
to
interrupt
you,
so
someone
just
asked
whether
the
glue
code
in
the
startup
is
mandatory.
I
think
they're,
asking
where
the
you
can
also
use
the
API
without
glue.
So
without
the
glue
codes
without
silk
entry
point
and
yes,
you
can,
you
can
just
use
the
surface
type,
there's
a
static
service
type
and
you
can
just
use
that
to
acquire
your
service
that
should
pretty
much
work.
The
same.
B
Yeah,
so
the
glue
code
is
really
just
a
wrapper
around
get
or
create,
as
well
as
to
as
well
as
generating
the
activity
and
the
app
delegate
and
whatnot.
So
it's
sort
of
well,
it's
called
glue
because
it
glues
the
native
the
native
application
model
to
the
surface
class
and
then
passes
control
over
to
you.
Once
it's
done
all
that
so
yeah,
it's
not
mandatory.
B
F
D
F
B
Yeah
yeah
and
ultimately,
if
you
use
the
if
you
use
the
glue
model
for
even
if
your
application
is
desktop
only
on
the
onset,
if
you,
if
you
use
the
glue
model,
then
you
don't
really
need
to
worry
about
when
you
it's
one
less
thing,
you
need
to
worry
about
when
you're
porting
to
mobile.
If,
if
you
bought
the
mobile.
B
Yeah,
you
were
you
called
that
out
yeah,
so
for
for
the
viewers
benefit,
there's
a
weird
bug
with
the
Discord
chat
embed,
not
not
to
call
Discord
out
or
anything
but
there's
a
weird
bug
with
the
embed
where,
if
you
don't
have
a,
if
you
don't
have
a
nickname
for
some
reason,
your
name
appears
as
object
objects.
So
look.
C
C
B
B
B
A
B
D
F
B
F
Just
want
to
make
sure
I'm
not
talking
to
the
wall,
sometimes
it
happens
and
okay.
So
these
are
things
that
we
might
have
found
ourselves,
but
mostly
they
are
a
thanks
to
your
feedback,
the
community
feedback,
and
we
are
very
grateful
for
the
people
that
take
the
time
to
communicate
any
issues
without
or
help
us
improve
the
API.
F
So,
let's
get
right
to
it
and
some
of
the
things
that
we
have
with
the
current
2.0
input.
Api
is
a
lack
of
some
very
specific
functionality
in
particularly
I.
Remember
stumbling
upon
not
being
able
to
detect
the
key
repeats
on
the
key
down
event.
You
have
no
problem
with
that
with
key
chart,
but
if
you're
trying
to
detect,
for
example,
a
rookie
repeats
on
one
of
the
arrow
keys
and
there's
no
way
to
do
that,
something
that
the
community
has
asked
many
times
is
about
capturing
State.
F
It's
not
easy
to
capture
state
with
the
current
Proposal
with
the
current
system,
and
there
is
an
extension
for
this,
but
it's
it's
an
extra
package
that
you
have
to
get
it's
not
just
trivial
to
copy
the
keyword
state
or
something
like
that.
So
that's
something
we
want
to
improve.
There's
also
some
differences
in
Behavior
between
different
backends.
F
In
regards
to,
for
example,
when
the
events
are
actually
raised,
and
we
want
to
help
with
those,
because
some
people
have
been
having
issues,
and
there
are
also
some
annoyances
in
the
current
API.
For
example,
you
have
to
code
as
if
you
could
have
multiple
keywords
or
multiple,
my
phone.
In
reality,
we
just
have
one
of
those
and
one
keyboard
and
one
Mouse,
so
there's
also
something
we
wanted
to
to
make
easier
to
use.
F
I
want
to
start
them
by
looking,
not
actually
after
3.0
proposal,
but
quickly
glance
over
the
enhancing
boot
proposal.
That
I
wrote.
When
was
this
at
the
beginning
of
2021.
This
proposal
is
superseded
by
perksy's
multi-back
and
input
proposal,
which
is
the
one
we
will
actually
be
talking
about.
But
the
reason
why
I
want
to
take
a
look
at
this
proposal
is
to
look
at
some
of
the
things
that
some
of
the
things
that
we
want
to
do
to
improve
and
the
issues
I've
been
mentioning
so.
F
Let's
see
in
particular,
as
I
said,
the
key
key
repeats.
That
is
something
that
this
proposal
aimed
to
fix
and
other
things
are
a
mainly
usability.
It's
not
a
as
much
of
a
functionality
proposal
as
much
as
just
making
the
API
a
night
nicer
nicer
to
look
at
easier
to
use
overall
one
of
the
things
this
proposal
introduces
the
idea
to
instead
of
having
long
parameter
lists,
which
some
of
the
events
or
methods
on
the
current
2.0
were
both
are
have
long
parameter
lists.
F
Instead
of
doing
that,
we
just
put
all
those
into
a
single
struct,
and
this
also
allows
us
to
in
the
future.
If
we're
missing
something,
we
can
just
add
it
to
the
struct.
Without
that
being
a
breaking
change
and
we'll
be
utilizing
a
read-only
record
record
structs
in
the
current
proposal,
we
are
going
to
be
taking
a
look
at
it
later
and
that
should
also
be
nice
and
performant.
F
F
So
when
we
talk
about
a
backend
and
still.net,
we
typically
talk
about
one
of
the
libraries
users
behind
the
scenes
you
know
like
if
you're
making
a
desktop
project,
you
you're
probably
using
glfw
your
sdl
behind
the
scenes,
but
during
the
input
section
we're
going
to
be
talking,
we're
going
to
be
using
the
word
backend
to
mean
input
backend.
So,
basically,
that's
an
implementation
of
our
input
system
over
one
of
these
libraries
I
just
want
to
make
sure
that
people
don't
think
I,
don't
know.
Glfw
is
implementing
these
things
for
us
or
something
again.
F
It's
it's
input.
Backend
means
input
back
and
during
this
section,
all
right
so
without
further
Ado.
Let's
get
to
the
new
proposal:
hey
I
am,
let's
read
the
behind
the
design
decisions.
This
proposal,
while
aiming
to
give
the
same
logos,
feel
as
the
point
over
both.
So
it's
completely
redesigned
to
the
input
API
with
the
following
calls.
So
we're
reading
some
of
the
goals
so
you'll
see
that
it's
mostly
some
redesigns
and
things
that
are
aiming
to
fix
the
issues.
F
I
was
previously
mentioning
one
thing
that
we'll
be
talking
a
lot
about
this
input
contexts.
So
this
is
pretty
much
is
an
object
that
replaces
the
current
2.0
I
input
context.
Only
this
time
it's
an
actual
object,
not
just
an
interface.
It's
a
class
all
input
devices,
regardless
of
what
backing
they
come
from,
can
be
accessed
from
that
Central
input
context
object.
Initially
this
this
proposal
was
purely
stage
based
and
any
event
that
had
to
be
raised
would
be
basically
deducted
from
comparing
the
states.
F
I'm
gonna
skip
over
the
usage
examples
because
it's
supposed
to
mostly
look
like
the
2.0
APL
is
not
supposed
to
look
very
different,
while
in
the
2.0
API
we
have
the
I
device
interface.
Here
we
have
well
it's
very
similar,
but
instead
of
idevice,
we
just
call
this
I
input
device
to
make
it
more
clear.
F
So
yeah
we
have
the
I
input
device
and
from
that
interface,
we're
going
to
get
the
imouse
I
keyword
and
all
the
ones
that
you're
probably
used
to.
If
you've
been
working
with
the
2.0
API,
and
then
we
have
the
backends,
we
have
the
input
backend
and
you
can
see
it
has
similar
properties
with
Name
ID
and
a
list
of
devices.
This
is
not
just
a
separated
per
device
like
you,
don't
have
keyboards
right
now,
you're
just
all
together
in
a
single
list
and
there
is
an
update
function.
F
So
this
is
one
of
the
things
that
are
changing
in
the
current
API
in
the
2.0
API
API
information
is
updated
as
soon
as
it's
available
and
for
some
people
that
has
been
working
perfectly
fine
that
some
people
have
been
happy
having
issues,
because
different
platforms
might
do
that
at
the
different
moments.
So
in
the
3.0
API.
What
we
want
to
do
is
the
information
like
device.
States
events.
Anything
events
are
not
racing.
Device
states
are
not
updated
until
you
go
the
backend
dot
update.
F
One
of
the
things
you
have
to
pass
to
the
backend
update
is
the
input
Handler
we're
going
to
be
talking
about
input
handlers
more
in
a
moment,
and
one
of
the
things
I
want
to
stress
is
how
update
works
and
the
back
end
cannot
just
update
all
and
then
call
events.
Now
things
have
to
happen
in
the
things
have
to
be
updated
in
the
order
in
which
they
happen.
So,
for
example,
if
there,
if
there
was
a
mouse
click,
so
first
it's
going
to
update
by
Mouse
click,
I
mean
down
under
then
up.
F
First,
it's
going
to
update
the
state,
the
mouse
of
the
device
that
was
pressed
for
the
button
to
be
down.
Then
it's
going
to
erase
the
event
well
raise
it.
It's
going
to
report
the
event
to
the
Handler
if
it
implements
the
appropriate
interfaces,
we'll
be
talking
about
the
handlers
in
a
minute
and
then
it's
going
to
update
the
state
of
the
mouse
again
to
be
up.
F
B
F
Handlers
is
very
simple:
they
just
receive
the
events
whenever
our
an
event
occurs.
The
backend
can
report
it
to
the
input
Handler
on
the
update
function.
Looking
at
the
default
input,
Handler
interface
you'll
see
that
there's
just
a
device
connection
changed
event.
You
can
also
see
that
there
is
not
a
long
parameter
list.
F
In
that
event,
it's
just
a
single
struct,
a
connection
event,
and
everything
is
there,
as
we
talked
in
the
enhanced
proposals
that
got
superseded
by
this
one
yeah
we're
doing
that
now,
you
can
see
it's
it's
quite
simple
and
we
have
an
example
also
about
how
the
the
states
have
to
be
updated
in
order.
Something
that
I
also
want
to
stress
is
that
you
cannot
use
different
Handler
objects
to
update
to
receive
events
on
different
objects.
You
have
to
implement
all
the
interfaces
you
have
in
one
class
and
make
any
sense
of
that.
F
B
Just
if
you're
not
in
there
sorry
just
jump
in
the
state
will
still
update.
If
you
don't
have
an
input
back
end
as
well.
If
you,
if
you
don't
it
input
and
sorry,
if
you
don't
have
an
input
Handler
and
you
pass
in
null,
you
would
still
be
able
to
pull
the
state.
For
example,
it's
just
this.
This
input
Handler
model
was
for
the
event
driven
stuff.
If
you,
if
you
decide
to
use
the
event
driven
model,
sorry.
F
Yeah
exactly
so
most
of
the
people
are
not
going
to
be
using
that
API
directly
they'll
be
using
the
input
context.
That's
going
to
be
an
API,
that's
much
more
similar
to
what
we
currently
have
in
2.0
over
that,
but
most
people
are
currently
using
in
2.0
and
if
we
look
at
the
class
for
the
boot
context,
you'll
see
that
basically,
you
have
a
list,
a
list
of
different
devices.
So
you
have
a
list
of
mice,
keywords,
game,
pads,
joysticks
and
any
devices.
That's
not
going
to
those
ones
just
like
in
Ubuntu.
F
F
F
F
Or
what
else
do
we
have?
So,
let's
talk
about
the
list
types
so,
as
we
said
well,
if
you
remember
one
of
the
one
of
the
issues
I
mentioned
that
we
have
with
the
current
ego
system
is
what,
if
you
want
to
use
input
or
I
mean
mouse
or
keyboard
input?
Well,
if
you
want
to
use
the
events,
you
have
to
subscribe
to
the
imouse
or
ikeyboard
instance.
F
However,
the
API
is
basically
built
around
the
idea
that
there
might
be
multiple
mice
or
keyboards
when
in
reality,
you'll
just
have
one
of
those
and
just
say
just
to
make
sure
we're
on
the
same
page.
I
want
to
clarify
if
you
plug
in
multiple
keyboards
to
your
Windows
PC
you're,
not
going
to
see
multiple
keyboards
on
the
on
the
device
list,
because
they
still
get
reported
as
a
single
one.
F
At
the
same
time,
a
fancy
backend
could
still
implement
the
the
ability
to
differentiate
those
keywords
that
goes
for
the
current
2.0
system
and
the
3.0.
However,
you
will
not
have
to
worry
about
the
the
keyboard
changing,
because
now
the
events
are
all
aggregated
together
per
device,
so
you
don't
have
to
subscribe
to
the
key
down
of
each
I
keyboard.
You
just
have
to
go
to
the
keywords,
so
that's
the
list
of
keyboards
and
you
can
subscribe
to
the
key
down
and
whenever
any
keyword
raises
it
has
that
event
raised.
F
F
And
what
else
so?
There
are
other
things
that
mainly
again
still
remain
similar
to
the
point.
Oh,
for
example,
you
can
still
configure
how
most
clicks
work
whenever
those
things
are
not
something
that
the
backend
brings.
It's
just
a
us
saying
all
right.
If
you
click
and
did
not
click
again
for
this
amount
of
time,
then
we
raise
the
click
event.
If
the
the
mouse
did
not
move
enough
in
that
period
of
time
also
again,
and
that
also
gets
checked
and
same
for
double
click,
let's
get
it
today
to
the
device
system.
F
All
right
so
I
want
to
quickly
go
over
the
devices
just
to
show
what
we
will
be,
how
these
interfaces
will
look.
So,
as
we
said
previously,
one
of
the
main
issues
that
we
have
with
the
2.0
system
is
that
you
cannot
trivially
capture
State
and
users
have
been
asking
for
it.
The
extension
package
has
been
made
that
still
what
we
wanted
to
make
in
the
three
point
overboard
proposal
is
for
the
state
to
be
trivially
capturable.
F
So
if
you
take
a
look
at
all
of
the
devices,
what
you're
going
to
see
is
that
they
all
expose
a
single
struct
property
called
state
which
contains
the
state
of
the
device
and,
if
there's
anything
else
in
the
in
the
device,
it's
supposed
to
be
things
that
you
can
set
the
device
but
are
not
and
strictly
strictly
related
to
the
state
of
the
device.
So,
for
example,
you're
not
going
to
get
whether
a
button
is
pressed
or
not
exposed
on
the
imouse
interface
directly,
it's
going
to
be
inside
the
imouse.state.
F
If
you
we
take
a
look
at
imouth
in
particular,
you
can
see
that
it
has
the
mouse
state
state
property
which
has
a
information
about
whether
each
button
is
pressed
or
released.
Information
about
the
position
of
the
mouse
on
the
screen
will
position.
You
know
the
typical
stuff
you
expect
from
our
Mouse
State
and
if
you
look
at
the
other
things
you
have
in
the
eye,
Mouse
interface,
you
have
the
cursor
configuration
and
you
have
the
set
position
now.
Something
I
want
to
mention.
F
F
All
right,
if
you
take
a
if
we
take
a
look
at
the
eye,
Mouse
input
Handler
as
an
example
for
an
input.
Handler
I
do
not
want
to
go
over
every
single
Handler,
just
a
one.
For
example,
you
can
see
basically
yeah
it's
pretty
simple:
it
inherits
the
input
Handler,
so
it
already
has
the
connection
change
the
status
changed
event
and
it
also
exposes
handle
button
down,
handle
button
up,
curse,
remove
and
scroll.
So
those
are
basic.
F
A
A
B
B
F
Keyboard
inputs:
let's
look
at
the
keyboard
input
because
we
have
some
things
to
talk
about
here.
So
if
we
take
a
look
at
the
I
keyboard
interface
and
what
you
can
see
is
there,
it
is
a
keyboard.
State
stay
property,
just
log
in
just
like
in
imouse,
there
is
a
single
state
property
which
you
can
directly
copy,
it's
a
real
read-only
record
struct,
and
then
there
are
the
extra
things
which
are
supposed
to
be
not
strictly
related
to
the
state.
So
what
do
we
have?
F
We
have
the
clipboard
text
in
way
in
case
you
want
to
be
able
to
copy
paste
the
things
from
the
operating
system
copy,
something
from
another
application
into
your
game.
Then
we
have
the
begin
input
and
and
the
input
anyone
familiar
with
these
functions
in
2.0
will
know
that
they
are
not
required
on
desktop
applications
really,
but
we
still
encourage
people
to
use
them
because
we
encourage
people
to
write
things
in
a
way.
That's
more
okay
makes
just
more
more
concise
and
it
would
also
make
the
application
much
easier
to
port
in
the
future.
F
So
the
idea
is
basically
once
you
want
your
user.
To
start
typing,
you
call
begin
input
once
you
don't
want
it
to
be
able
to
type
anymore.
You
call
end
input.
What
would
this
do
if
you're
in
a
phone
for
example,
then
it
would
pull
up
the
keyboard
once
you
call
an
input,
the
keyword
will
go
down
and
your
application
will
again
have
the
entire
screen
for
itself,
and
so
we
had
a
bit
of
a
of
a
discussion
with
how
these
things
should
work.
F
If
you
look
at
the
keyword
State,
you
will
see
that
there's
a
property
called
text.
So
when
you
call
begin
input,
keyboard,
state,
DOT
text,
Will
begin
populating,
you
will
as
low
as
a
as
the
characters
are
being
typed
by
the
end
user.
You
will
start
seeing
that
list
fill
up
with
characters
and
the
moment
you
called
end
input
that
property
will
be
turned
into
null
until
the
next
begin
input
is
called,
and
you
still
have
a
the
key
chart
event
where
RCL
exposing
that
one.
B
F
F
B
A
A
B
F
F
All
right
I
want
to
quickly
look
over
the
eye,
gain
pan
interface.
So
again
it
just
inherits
from
high
input
device.
We
have
the
game,
but
States
and
game,
but
state
state
property
and
not
going
to
go
over
it
because
you've
already
seen
the
other
states
and
then
you
we
have
a
read-on
list
of
Motors
again.
This
is
all
the
things
that
are
not
strictly
related
to
the
GamePad
state
or
things
that
can
be
said.
F
B
E
I
think
it
would
be
sorry,
I
was
gonna,
say
I
think
it
would
be
helpful
to
see
some
code
examples
not
necessarily
today,
since
it'd
probably
be
hard
to
type
them
up
but
code.
Examples
showing
scenarios
like
how
would
a
user
allow
dynamically
changing
between
the
keyboard
and
mouse
and
a
controller
most
modern
games,
for
example.
Allow
you
to
pick
one
up
and
as
soon
as
you
start
using
a
controller,
it
starts
it
takes
over
the
keyboard
and
allows
you
to
start
using
the
controller
immediately.
E
There's
not
an
explicit,
like
I,
have
to
go
to
settings
and
change
my
controls
or
anything
like
that.
There's
some
games
that
even
allow
you
to
use
both
simultaneously,
so
you
can
like
use
a
controller
in
one
hand,
while
using
the
mouse
and
keyboard
with
the
other
hand,
and
everything
works
as
as
expected.
F
E
E
And
as
part
of
that,
you
want
to
determine
that,
for
example,
space
was
hit
twice
and
whether
or
not
another
key
was
hit
in
between
those
two
spaces,
but
you
want
to
determine
that
space
was
hit
exactly
two
times
and
if
there
was
any
input
between
the
two
of
them.
Likewise,
you
may
want
to
know
if
something
was
registered
as
part
of
the
current
frame
or
part
of
a
previous
frame.
F
Yeah
so
as
as
we
discussed,
the
app
backend.update
makes
the
backend
update
things
in
order,
so
the
states
and
the
events
together
have
to
both
be
updated
and
raised
in
order
so
yeah
you
can
determine
whether
it
something
was
pressed
twice
in
between
frames.
If,
if
the
space
bar
say
it
was
pressed
10
times
like
up
and
down
10
times
in
between
two
updates
to
backend
updates,
then
a
yeah.
You
can
still
see
that
through
events,
even
though
the
net
change
on
the
device
state
will
be
none.
E
Right
I
I
understood
that
you
said
it
was
supported,
but
it's
it's
kind
of
hard
to
conceptualize.
What
that
would
look
like
is
what
is
all
I'm
trying
to
say
and
so
I
think
in
in
this
in
the
proposal,
dock
here
it'd
be
helpful
to
see
some
samples
showing
these
kind
of
scenarios
that
a
user
may
want
to
do
and
how
it
used
to
look
like
minimally
versus
what
it
would
have
to
look
like
with
the
updated
API.
F
If
you
subscribe
to
an
input
event
and
have
a
very
slow
update,
Date
Update
rate,
you
can
you
still
get
events
in
between
the
update,
if
you
add
a
input
contacts.update
somewhere
in
the
middle
of
your
update,
look
even
though
your
games
update,
isn't
getting
cold,
then
you
can
still
do
that.
You
can
still
get
events
happening
at
near
nearly
any
time.
B
Yeah
and
on
the
whole
slow
frame
thing
you
could
certainly
keep
track.
I,
don't
know
using
like
an
integer
in
your
in
your
game
like
that
is
that
is
set
to
one
or
zero
repeatedly
for
frames.
You
could
sort
of
determine
in
your
callback
what
frame
you're
on
it's
certainly
something
you
could
do
from
use
perspective,
but
I
agree
with
that.
We
could
probably
do
with
updating
The
Proposal
with
an
example
of
that,
because
you're
absolutely
right,
slow
frames
could
cause
a
problem,
especially
with
input.
F
That's
actually
a
problem
with
the
back-end
because,
for
example,
glfw
does
not
allow
or
all
events
to
be
called
in
in
a
thread
that
it
was
not
created
in
so
fretting
can
be
a
wait.
What
did
I
say?
Gl30
does
not
allow
glfw
ball.
Events
to
be
called,
you
know
for
in
another
thread:
that's
not
the
one
that
called
init,
so
fretting
can
be
restricted
by
the
back
end.
F
Okay
say
something:
fretting
rules
for
the
reference
implementation
will
be
explicitly
documented
and
guidance
for
using
this
type
safely
against
any
first
part,
implementations
will
be
included
in
the
XML
user
implementation.
It
also
says
the
user
is
responsible
for
this
respecting
threading
rules
regarding
the
backends.
F
You
want
to
take
a
look
at
joystick
input.
I
just
glanced
over
it
because
it
was
not
something
very
important
like
if
you've
seen
the
2.0
API.
It's
basically
the
same
thing
with
just
with
the
with
the
changes
we
already
saw
like,
instead
of
having
the
state
on
the
interface
itself,
it's
on
a
on
the
status
tracked.
B
C
B
B
So
I
guess
we
should
probably
just
double
check
on
the
last
meeting
notes.
Now
it's
probably
yeah
most
of
these
don't
really
yeah.
These
don't
really
make
sense
anymore,
because
the
the
input
proposal
has
changed
so
much
since
our
last
review,
primarily
because
yeah
it
was
this,
make
input
State
it
states
drugs
immutable
and
to
have
a
state
read
owner
property
which
we've
implemented
in
this
proposal,
and
it
resulted
in
the
entire
proposal
changing
around
it.
B
But
I
I
think
we've
rectified
the
comments
that
we
came.
That
came
from
the
last
meeting
and
yeah.
One
of
the
comments
from
the
last
meeting
as
well
was
we
should
document
the
change
and
sort
of
put
together
a
migration
guide
for
the
new
invert
and
I
suppose
Hannah's
comments
about
putting
some
examples
together
would
be,
would
feed
into
that
as
well,
but
yeah
I
think
we've
covered
the
comments
there.
F
B
E
E
B
Yeah
I
fully
agree
with
that,
especially
with
like
the
recent
Unity
changes
as
well
they're.
Moving
towards
that
model,
I've
seen
and
you
you
said
it
exactly
it's
the
sort
of
thing
we
could
build
on
top
of
this
API
I
mean
this
one
sort
of
focused
on
exposing
what
we,
what
we
receive
from
the
Native
back
end
and
sort
of
bruising
it
up
a
little
right.
Where
is
it
yeah
you?
E
For
example,
if
you're
using
in
an
Xbox
Elite
controller,
you
actually
have
five
or
six
additional
buttons
on
top
of
these,
and
so
I
wonder
if
having
an
enum
of
exact
values
to
of
named
values
like
this
is
the
necessarily
right
approach
versus
potentially
a
different
model,
where
you
have
effectively
registered
atoms
representing
each
potential
button
that
is
available
and
effectively
giving
them
a
known
ID,
but
not
necessarily
tying
them
strictly
to
a
a.
This
is
a
this
is
B
Etc.
B
Yeah,
so
you're
absolutely
right
on
the
opinionated
thing
is
that
yeah
we've
just
sort
of
Gone
with
the
names
we
we've
sort
of
gone
with.
You
left
W
on
there,
so
we've
just
done
abxy.
We
we
I
I,
know
we've
aliased
some
things
elsewhere
in
the
other
enums,
where
we've
sort
of
we
could
probably
do
something
like
a
like
Circle
equals
a
or
whatever,
but
it's
a
sort
of
the
opinionated
names
but
you're
right
on
the
actual
buttons.
B
Well,
first
of
all,
we're
sort
of
restricted
on
what
the
backer
gives
us.
But
to
be
honest,
we
shouldn't
that's
not
a
good
reason
to
influence
the
API
design.
In
my
opinion,
so
I
suppose
we
could
look
into
something
like
the
like.
What
we've
done
for
keyboards
is
where
you've
got
a.
You
can
have
named
Keys
that
we've
officially
assigned
a
name
to,
and
then
you
could
also
get
like
some
sort
of
scan
code.
I
mean
I.
B
Don't
I'd
need
to
look
into
how
it
actually
works,
natively,
but
yeah.
We
could
move
towards
something
like
having
a
joystick
button,
struct
and
then
you've
got
a
joystick
button
name
if
it's
a
named
key,
but
that
might
be
unknown
and
then
you've
got
the
number
of
it
and
then
Downstream
user
either.
The
downstream
user
still
has
some
way
of
receiving
those
input
events,
even
if
we
don't
necessarily
support
it
in
the
library
itself.
E
B
So
yeah
I
suppose
we
could
well
I,
don't
I,
don't
know
what
does
everyone
else
think
do
you
how?
How
should
we
proceed?
Should
we
revise
the
proposal
to
sort
of
use
that
have
have
a
struct
that
has
a
name
or
something
else
like
an
integer,
it's
similar
to
what
we've
done
with
keyboards,
or
should
we
just
leave
it
for
now
and
potentially
expand
it
in
I?
Don't
know
another
interface
with
another
kind
of
state,
I
don't
know.
What's
everyone
think.
D
So
our
Eden
names
here
are
opinionated
sort
of,
but
I
don't
think
it's
it
helps
if
we
just
make
them
not
names
at
all,
so
I
think
we
could
think
about
like
renaming
them
or
finding
better
names
or
just
introducing
multiple
things
for
the
same
integers
represented
by
the
enum,
but
I.
Don't
think
kind
of
going
back
to
the
less
usable.
Just
use.
Integers
approach.
Is
that
helpful.
E
The
most
trivial
example
is
that
if
you
look
at
the
the
Nintendo
controllers
versus
the
Xbox
controllers,
A
and
B
and
X
and
Y
are
swapped.
And
so
you
know
if,
if
you're
saying,
if
a
user
is
saying
that
a
is,
if
a
is
a
on
the
Xbox
controller
and
it's
X
on
the
PlayStation
controller
you're
going
to
have
a
user,
that's
implementing
the
switch.
That's
either
going
to
that's
implementing
some
code
that
that
works
with
the
Pro
Controller.
D
Right
so
I
think
the
the
best
approach,
I
think
is
to
just
rename
them
to
be
positional,
because
I
think
that's
what
they
are.
I'd
have
to
look
up
again
with
GLW,
because
that's
where
we
took
the
values
from
but
I
think
they're
just
positional
and
then
I
think
we
can
just
expose
like
the
more
nuance
stuff
from
the
special
controllers
via
the
joystick
API.
And
then
the
GamePad
would
just
be
like
a
sort
of
more
basic
kind
of
standard
controller
right
and
then
for
all
of
the
special
stuff.
A
D
I
think
we
can
never
accommodate,
like
all
of
the
controllers,
so
I
I
mentioned
this
when
we
initial
discuss
this
I,
for
example,
have
a
steam
controller
and
they
have
like
a
touchpad.
We
can
never
accommodate,
for
example,
that
it's
just
too
uncommon
and
we
kind
of
have
to
make
some
some
kind
of
opinion
here,
because
otherwise
we
can
just
not
have
a
usable,
gamepad,
Gamepad,
API
right.
C
C
E
Was
gonna
just
suggest
the
same
thing
like
with
when
you
think
about
it?
This
from
the
keyboard
perspective,
you
know,
you've
got
people
from
every
country
and
although
most
keyboard
layouts
are
somewhat
similar,
the
actual
scan
codes,
mapping
to
keys,
don't
line
up,
and
so,
if
you
really
need
to,
you,
can
go
down
to
and
get
the
individual
scan
codes
and
deal
with
that.
E
E
What
does
this
button
represent
for
the
low
level
side
and
then
on
the
high
level
side,
you
could
have
something
like:
oh
here's,
an
Xbox
controller,
a
Pro
Controller,
a
switch
controller
and
a
steam
controller,
because
those
are
likely
the
most
popular
for
and
for
those
you
can
provide
a
nicer
abstraction
on
top
involving
effectively
button
codes
that
give
you
here's
a
triangle
or
here's.
Why.
G
E
E
So
it
would
just
be
extending
that
to
effectively
the
the
controllers
and
game
pads
as
well.
That
way,
users
have
a
nice
and
easy
to
use
API
for
the
common
case,
but
if
they
have
some
some
need
to
support
more
esoteric
features
like
they
want
to
support
support
touchpads,
because
you
know
steam
controller
provides
an
SDK
for
that,
then
you
can
actually
go
and
add
that
support
you
just
have
to
do
some
additional
work
to
to
use
the
more
low-level
API.
Instead.
A
D
So
you
know
me
why
we
might
want
to
like
expose
all
of
the
buttons
but
then
like
if
we
go
to
to
there
and
we
want
to
expose
also
low
level
features,
then
you
know
we
also
want
to
expose
all
of
the
like
Motors
and
then
we
might
also
want
to
expose
like
all
of
the
lights.
Maybe
right
you
want
to
I,
don't
know,
I,
think
some
of
the
PlayStation
controllers
have
like
the
light
system
right
and
so
so
we
would.
D
D
Jlfw
has,
for
example,
support
for
lighting
of
the
controller
right,
so
I
think
we
can't,
or
we
don't
want
to
expose
a
really
like
low
level,
Gamepad
API,
because
if
you
want
to
go
there,
you
should
probably
just
go
for
dedicated
like
API
there
so
like,
for
example,
if
you
want
to
use
all
the
features
of
like
the
DualShock
controllers,
then
use
the
use
the
SDK
they
made,
and
then
you
get
all
the
features
and
we
just
kind
of
provide
you
with
like
the
the
this
works.
Most
of
the
time.
D
G
B
Will
for
for
those
cases
like,
for
example,
we
had
the
we
have
alluded
to
possibly
having
an
open
XR
based
input,
back-end,
so
I
suppose
for
those
cases,
I
think
the
steam
controller
is
probably
our
best
example.
They
have
a
dedicated
SDK
for
actually
using
that
we
could
Implement
an
input
back
in
another
input
back
end
using
the
steam
controller
SDK
that
you
can
then
plug
into
an
input
context
and
receive
events
for
both
steam
controllers
and
other
controllers
as
well.
B
So
the
I
think
the
beauty
of
this
proposal
is
that
we
could
easily
tack
on
something
whether
it
be
another
interface
or
something
else
entirely.
We
could
we
could
Implement
something
on
top
of
this,
that
is
more
specific
and
has
support
for
more
buttons
more
like
touch
pads,
some
lights.
Whatever
else.
E
Basically,
every
operating
system
exposes
this
as
here's,
the
raw
PCI
device
ID
and
here's
a
byte
array
of
the
data,
as
well
as
which
hid
input.
It
came
from
there's
a
there's,
a
well-defined
standard
for
getting
input,
data
from
controllers,
and
it's
just
generic
data
until
you
build
something
on
top
of
it,
and
so
the
low
level
API
is
actually
really
primitive
because
you're
just
returning
an
ID
which
corresponds
to
some
some
actual
encoded
Hardware
information
and
the
raw
byte
data
that
the
device
returned.
E
G
B
D
E
Example,
sorry
I
was
just
gonna
say:
I,
definitely,
don't
think
it
needs
to
be
complicated
and
it
would
just
provide
a
building
block
for
people
who
want
to
support
their
own
things
on
top
of
course,
if
you're
wanting
to
support
the
steam
controller,
you
wouldn't
want
to
go
and
use
the
raw
head
inputs.
You'd
want
to
use
the
SDK,
because
that's
just
going
to
be
more
efficient
and
easier
to
use,
but
it
provides
an
option
for
users
who
need
or
want
to
do
the
thing
without
a
lot
of
additional
work
per
se.
D
So
just
that
there,
for
example,
there
is
an
that.
The
windows
SDK
exports,
of
course,
is
also
somewhat
opinionated,
but
the
way
it
works
for
them
apparently
is
just
having
a
bunch
like
a
huge
enum
which
just
basically
duplicates,
for
example,
their
square
and
then
there's
also
X,
and
apparently
they
do
also
have
different
IDs.
So
I
think
we
could
just
expose
this
and
then
also
like
I
personally.
I'd
also
want
to
keep
the
current
Gamepad
API
to
just
not
ask
every
user
to
deal
with
like
the
tiny
difference.
B
I
think
we've
left
ourselves
enough
room
for
future
expansion
such
that
if
we
do
get
access
to
a
cross-platform
way
to
get
that
low
level
input
or
heck,
even
if
it's
just
a
window
specific
and
and
the
user
adds
that
low
level
back
end.
If
you
like
to
their
input
context,
yeah,
it
is
sort
of
awkward
in
the
it.
The
low
level
interface
in
that
case
would
be
coming
after
the
high
level
interface,
but
it's
it
I
think
it
just
comes
back
to
what
we
can
actually
feasibly
do
today.
G
D
B
B
Then
I
I
think
we
I
think
we've
left
ourselves
enough
room
for
expansion
to
sort
of
add
in
a
more
low-level
thing
later
in
the
future
and
failing
that.
Well,
we
always
have
the
next
breaking
update,
which
we
haven't
even
thought
about,
but
yeah
there's
something
we
could
do,
should
a
cross-platform
way
or
a
preferred
way
for
getting
access
for
this
low-level
stuff.
G
E
So
so
the
way
PCI
works
is
that
every
single
manufacturer
per
se
I
believe
the
technical
term
is
Bender,
is
able
to
go
and
register
themselves
with
PCI
and
get
a
an
ID
allocated
to
them.
That
is
regularly
updated
as
part
of
a
global
registry
that
lists
what
IDs
correspond
to
what
what
company
so
there's
one
specifically
for
AMD,
one
for
Microsoft,
one
for
Nintendo,
one
for
Sony
Etc,
then
within
within
that
vendor
space,
every
single
device
gets
an
ID
and
a
vendor
is
allowed
to
allocate
their
IDs.
However,
they.
E
Yeah
kind
of,
and
so
whenever
you
like,
if
you
plug
an
Xbox
controller
in
the
the
actual
X
input,
SDK,
is
actually
just
effectively
using
the
raw
input
stuff
on
the
back
end
and
it's
saying:
I'm
listening
for
events
from
vendor,
ID
X
and
then
device
ID
Y
and
it
Aggregates.
Those
events
together
gets
the
raw
byte
data
and
then
publishes
it
to
the
end
user
as
a
friendlier
API.
E
G
As
a
temporary
solution
to
cover
kind
of
what
you
discussed
earlier
about
potential
inability
to
determine
like
photos
or
input
positions,
could
we
ex
could
we
expose
at
least
that
I
that
I,
that
vendor
ID
to
the
end
user,
either
in
raw
form
or
as
just
common
vendor,
enums
to
mitigate
that
for
now?
Well
it
until
a
better
better
solution
is
found.
B
So
I
did
a
while
you
were
speaking.
I
did
have
a
look
at
this
and
it
looks
like
glfw
doesn't
have
a
way
to
do
this
today,
however,
I
don't
see
why
we
couldn't
add
our
own
support
on
top
of
glfw
to
do
well,
as
in
like
modify
glfw
itself
as
we've
got
some
other
things
that
we
want
to
change.
So
it
is
possible
that
if
we,
if
we
submitted
a
patch
to
glfw,
it
should
be
a
pretty
trivial
thing
to
add
yeah
it's
just.
G
E
Notably
the
same
vendor
and
device
information
is
exposed
by
Vulcan
by
DirectX,
technically
by
opengl,
although
it's
a
pain
to
get
and
then
the
same
for
any
audio
device
or
basically
any
other
Hardware
device
that
you
have
access
to
in
your
computer.
There's
all
these
same
two
vendor
and
device
IDs.
B
B
B
So
yeah
it's
that
there's
some
issues
with
Blazer,
but
the
3.0
architecture
sort
of
helps
a
bit
with
that
we
have
stuff.
We
need
to
figure
out
primarily
it's
because
we
want
to
design
a
binding,
a
binding
that
will
work
using
both
web
GPU
native
and
web
GPU
in
the
browser.
So
it
it's
certainly
possible.
B
B
Okay,
so
speaking
of
the
generator
Kai
we're
on
to
your
bits
now
so
for
those
of
you,
unfamiliar
we've
got,
silk
touch
is
a
name
of
a
source
generator
in
2.x
and
a
3.0
we're
sort
of
building
out
a
silk
touch
a
bit
more,
so
it'll
be
like
a
full
generator
stack.
Okay,
if
you
want
to
sort
of
run
through
what
we've
got
proposed
here,
if
you
don't
mind,
yes,.
D
D
And
now
we
just
want
the
the
base
tool,
the
scraper,
which
is
the
the
lowest
one,
to
only
read
the
native
signatures
and
then
output
them.
So
this
will
work
using
primarily
using
clang
Sharp
and
a
special
tool
that
that
outputs
XML
from
the
pinbook
generator
and
then
with
a
little
bit
of
support
from
the
xml5's
Chronos,
gives
us,
but
the
main
source
will
be
the
C
headers
and
then
that
one
will
basically
work
on
its
own
and
it
only
outputs
the
literal
native
signatures.
D
So
if
Vulcan
says
this
API
takes
a
void
pointer,
then
this
will
output
a
void
pointer
and
that's
it,
and
then,
on
top
of
on
top
of
that,
we
have
the
emitter
and
the
emitter
is
basically
responsible
for
actually
calling
the
method.
So
this
is
no
marshalling.
It
only
does
the
literal
call
so
for
the
simple
one
so
glfw
it'll
just
emit,
yellow
Imports
and
for
something
more
complicated
ones
like
Vulcan
it'll
use
the
different
Vulcan
loading
functions,
and
this
is
all
detailed
here.
D
There
are
different
attributes
that
we
can
use
to
modify
this
Behavior.
There
is
support
for
the
other
import,
which
is
the
primary
one
we
want
to
use
wherever
possible.
There
is
the
support
for
static,
linking
which
is
important,
unlike
iOS,
where,
where
this
is
necessary,
and
then
there's
also
support
for
expression
based
loading,
which
is
important
for
Vulcan
and
some
other
some
other
sources,
and
this
should
be
very
flexible
as
it
like.
You
can
specify
it
at
the
at
the
type
level.
D
You
can
specify
that
the
individual
function
level
it
should
be
extremely
flexible
and
and
because
it
should
also
hopefully
keep
the
component
pretty
simple,
comparable
to
what
subtouch
is
now
so
after
we've
done
both
the
stages
we'll
have
just
the
the
raw
native
calls.
So
using
just
these
two,
you
can
call
any
function
that
we
bind
to
so
and
you
will
can
function
any
dual
function,
any
dual
FW
function,
any
opencl
function,
Etc,
but
only
using
the
literal
native
type.
So
well,
if
there's
one
pointer,
you
have
to
provide
a
void
pointer
and
that's
it.
D
If
the.
If
the
API
was
a
string,
you
have
to
do
the
Marshall
link
and
yeah
and
then
the
last
bit,
which
is
the
one
that
really
makes.net
silver.net
as
the
overloader,
and
this
tries
its
best
to
based
on
metadata.
We
we
figured
from
the
C
header
and
from
the
XML
files
tries
its
best
to
make
things
nicer
so
often
I
think
the
best
example
here
is
strings.
D
Often
we
will
have
just
a
raw
pointer
that
the
API
wants
and
as
a
user,
you
have
no
idea
how
to
get
this
or
or
you
know
how
to
make
that
work
and
using
the
metadata
we
can
figure
out.
Oh,
this
is
supposed
to
be
string
and
hit
with
eight
format
and
I.
Don't
know
it
should
be
null
terminated
right
and
then
we
can.
D
We
can
generate
a
marshalling
code
to
make
a
c
c
sharp
string
into
this
pointer
and
make
it
the
right
format
and
pretty
much
all
users
know
how
to
get
a
string
right.
So
this
is
really
the
the
complicated
part,
but
also
it
should
be
much
easier
now
that
it
only
needs
to
figure
out
the
the
see
Sharpie
fight
type
and
no
longer
of
the
marshalling
steps,
because
once
we
know
this
white
pointer
is
a
string.
We
also
know
the
Marshall
line,
steps
right,
so
it's
much
simpler
and
again
this
works
on
its
own.
D
D
Some
of
these
are
also
old,
so,
for
example,
native
API.
We
know
that
one
it's
an
attribute
now,
but
it's
it
holds
the
same
sort
of
information
just
as
an
aptitude
instead
of
a
base,
class
and
yeah.
One
important
thing
is
also
that
we
now
support
like
proper
calling
conventions
before
we
well.
We
technically
had
support
for
all
of
these
calling
conventions
and
it
usually
works
pretty
well,
but
now
we
have
actual
like
support
for
all
of
them
and
I
hope
that
this
should
cover
Us
in
all
cases.
D
D
So
they
should
pretty
much
bring
the
library
to
the
point.
It
is
right
now,
so
everything
should
look
the
same
or
slightly
better
than
it
is
right
now
and
then,
as
mentioned
before
things
like
web
GPU,
can
be
built
on
top
of
this.
But
for
example,
you
will
see
there
is
no
like
wasn't
or
JavaScript
call
modifier
listed
here
right
now,
because
it's
not
like
this,
this
isn't
really
extending
our
capabilities.
D
Yeah
filter
just
very
complicated
and
has
a
lot
of
sort
of
old
code
bits
that
we
needed
and
then
later
realized
we
don't
actually
need,
and
so,
for
example,
one
or
two
weeks
ago
we
had
someone
on
the
Discord
ask
about
this
error.
They
got
when
they
tried
to
use,
silk,
touch
themselves
and
it
like,
through,
like
an
exception,
something
like
the
table
is
forced
or
something
and
I
and
I
wrote
the
code.
I
still
had
to
go
digging
like
what
does
this
mean?
D
When
does
this
happen,
and
hopefully
things
like
that-
never
happen
here,
because
it's,
the
in
theory
of
these
tasks
are
very
simple
and
we
can
just
focus
on
making
one
and
then
also
we
can
hopefully
properly
test
this.
So
at
least
like
the
minimum
thing
for
all
of
these
three
stages
is
having
some
basic
integration
tests.
D
So
you
know
make
each
of
the
attributes
at
least
like
test
a
small
snippet.
Then
it
works
and
do
that
on
every
commit,
so
it
doesn't
break
or
like
easily
and
right
now
we
have
none
of
that.
So
silk
touch
and
build
tools.
Both
are
just
kind
of
chugging
along,
and
we
don't
really
know
that
they
work
before
we
like
commit,
so
that
should
also
have
a
lot
with
maintainability
to
just
have
at
least
like
basic
configuration
tests.
D
B
D
D
So
if
we
ever,
for
example,
if
we
ever
wanted
to
make
a
JavaScript
color
convention
right,
it
doesn't
really
make
sense,
but
that
that's
a
possible
goal
of
this-
that
we
have
the
capability
to
call
into,
for
example,
like
an
ijs,
runtime
right
and
and
that's
just
not
possible.
If
we
rely
on
some
predefined
types
of
course,
then
we
again
we
could
Define
our
own
type,
but
it
doesn't
really
I,
don't
think
it
does
anything
for
us
like
it
doesn't
do
anything.
D
It
doesn't
help
with
anything,
and
it
probably
only
complicates
the
code
for
no
Library
reason
like
it's
not
like.
We
would
get
automatic
support
for
the
new
like
colleges
right
if
if.net
ever
like
edit
support
for
I,
don't
know
risk
V
and
they
had
like
a
separate
calling
convention.
It's
not
like
we
would
get
automatic
support.
D
D
Well
so,
for
example,
risk
V.
We
we
of
course
can't
do
anything
about
that,
but
we
can
support
sort
of
it
like
a
pseudo
calling
convention
like
JS
right
so
calling
it
to
JS
is
like
a
native
intro
sort
of
is
is
perfectly
it's
like
a
perfectly
valued
use
case
and
and
there's
no
reason
why
the
runtime
would
ever
have
that
like
as
a
calling
convention,
because
it
because
this
is
like
a
native
color
convention,
but
it
can
still
make
sense
for
us.
D
I'm
not
sure
what
you
mean
yeah
like
in
webassembly
yeah.
We
can
just
like
call
like
that.
We
still
use
the
other
import
right.
But
if
you
look
at
like
calling
to
some
webgl
functions
directly,
you
don't
you
can't
really
do
that
from
wasn't
at
least
not
in
my
testing
and
so
you'd
either
have
to
like
go
to
use
the
in-browser
JS
runtime,
so
calling
the
JS
functions
and
that
that
big
possibility
and
then
I
I,
don't
see
again.
I,
don't
see
the
benefit
of
using
the
runtime
types.
I.
B
D
B
B
I
mean,
while
that
has
runtime
support
now
before
we
could
easily
Implement
that
atop
the
base
calling
convention
and
the
JavaScript
thing
is
another
good
example
is
that,
while,
if
we
had
a
JavaScript
call
modifier,
it
might
not
necessarily
change
the
calling
convention,
but
it
would,
it
will
influence
how
we
generate
code
and
I.
Think
well.
In
my
opinion,
this
this
enum
sort
of
represents
sort
of
like
a
code,
gen
control,
sort
of
thing
referring
to
how
silk
touch
output,
its
code,
essentially.
E
It
is
very
specifically
a
calling
convention
and
the
ability
to
effectively
hack
it
up
was
a
side
effect
of
knowing
and
understanding
the
windows
API
and
having
an
equivalent
way
to
define
it
in
C
sharp
that
happened
to
work.
It
is
still
100
dependent
on
the
runtime
and
and
a
number
of
other
features.
Having
that
work
correctly,
there
are
other
cases
of
conventions
where
you
literally
cannot
hack
it
up.
Vector
call
is
a
good
example.
There
is
no
way
to
hack
that
up
without
runtime
support.
D
To
explain
what
what's
meant
with
the
JS
interrupt,
for
example,
that's
not
like
a
literal
native
calling
convention.
What
what
I
mean
with
that
is
in
Blazer
in
in
Blazer
webassembly,
you
get
access
to
type
I,
think
it's
called
ijs
in
process
runtime,
and
it
effectively
gives
you
just
a
very
simple
method.
It's
called
like
invoke,
or
something-
and
you
can
just
call
like
a
named
JS
export
right,
so
webgl
exports
all
of
their
function.
D
E
That
that
seems
like
a
so
so
to
me,
that
seems
like
a
different
thing.
So
so
that's
basically
the
same
as
Objective
C,
where
there's
not
where
it's
just
the
C
ABI,
it's
the
platform
default
API,
but
in
order
to
call
anything,
you
have
to
go
through
a
obsc
message
send
in
in
similar
functions
like
that
and
to
me
at
least
the
the
kind
of
better
thing
to
do
here
is.
E
You
would
have
two
distinct
things
on
one
hand,
you'd
use,
unmanaged,
call,
confident
type
of,
and
the
benefit
of
that
is
that
you
don't
have
to
understand
it.
All
you
have
to
do
is
take
that
and
blid
it
out
to
the
equivalent
on
the
on
the
corresponding
dll
import
or
other
scenario
that
you're
generating
whether
it's
com
function,
pointers,
dlm,
ports,
Etc,
you,
you
don't
have
to
understand
it.
You
literally
just
split
it
out,
and
then
you
have
a
different
concept
of
here's.
Potentially
some
other
support.
D
The
problem
is
that
the
call
mode
like
I,
think
you're
sort
of
right
that
it
makes
more
sense
to
to
separate
these
because
the
the
calling
convention,
so
the
literal
like
the
cdcl
or
SD
call
these
are
sort
of
associated
with
the
London
port
and,
like
that
kind
of
side
of
the
of
the
calling
process,
and
then
things
like
put
into
like
a
JavaScript
convention-
that's
not
actually
concerned
with
with
modifying
the
behavior
of
their
own
portal
or
whatever
they
are
just
kind
of
separate
Concepts.
So
it
actually
sort
of
makes
sense.
D
D
Yeah
there
there
we
go
so
the
way
it
works
is
that
you
would
have
specified
the
calling
convention
on
the
on
the
method
and
I
I
have
to
actually
say
that
that
doesn't
necessarily
make
sense.
So
we
should
probably
change
that
to
be
called
something
else,
because
it
does
influence
only
the
11
Port.
So
only
is
that
use
static
library
or
use
Dynamic
library
and
doesn't
yeah,
so
we
probably
have
to
kind
of
change
the
name
of
the
attribute,
and
then
it's
probably
worthwhile
suggesting
to
look
at
using
the
types
instead.
D
E
The
the
main
thing
is
that,
as
the
runtime
versions
in
the
future,
it
will
continue
adding
more
call
cons
types.
Those
call
kind
of
types
along
with
unmanaged
call
conf
are
the
official
way
moving
forward
to
represent
any
type
of
calling
convention
information
to
the
runtime
and
so
for
anything
that
you
have
here
as
a
call
modifier
you're
going
to
have
to
go
and
translate
that
to
either
the
attribute
or
the
inline
Syntax
for
for
putting
them
in
a
in
a
function
pointer.
E
So
so
you're
fundamentally
going
to
have
to
have
this
mapping
and
this
understanding
of
those
attributes
anyways.
Unless
you
just
have
the
types
in
which
case
you
can
blit
them.
As
is
you
don't
have
to
understand
what
the
type
is
you
just
have
to
basically
have
an
import
for
system,
runtime,
compiler
services
and
then
just
put,
you
know,
suppressed
GC
transition.
Member
function,
C,
decal
Etc.
D
So
yeah
I
think
that
makes
sense.
Only
question
I'd
have
is
it
in
general
is
like
specified
that
any
type
that's
allowed
on
like
a
function?
Pointer
declaration
is
also
allowed
to
be
passed
into
a
deal
element
Port.
So,
for
example,
is
it
legal
to
pass
the
the
suppressed
GC
transition
type
like
I,
think
there's
a
type
for
that
as
well
that
you
can
put
in
the
function
pointer?
E
So
so
the
way
it
works
is
that
dll
import,
it
takes
the
calling
convention
enum
and
if
it's
one
of
the
four
or
five
well-defined
conventions,
meaning
this
call
Standard
call
fast,
caller
C
decal
that
has
an
existing
well-defined
value.
Then
you
use
that
that
that's
all
you
use
if
it's
anything
else.
E
So
if
you
have
suppressed
GC
transition,
if
you
have
member
function,
if
you
have
any
of
this
other
info
that
goes
on
top
of
it,
then
you
have
to
use
the
you
have
to
use
the
new
the
new
bit.
That's
been
allocated
that
enum
and
add
the
unmanaged
unmanaged
call
cons
attribute,
in
addition,
with
the
appropriate
type
type
of
sequence,.
D
E
A
D
E
That
one
doesn't
matter,
there's
no
there's
not
going
to
be
any
real
dll
bloat,
either
way
there.
The
the
difference
is
that
the
the
dll
import
attribute
is
not
a
real
attribute.
It's
a
it's
effectively
magic
that
gets
compiled
down
to
direct
and
inline
bit
Flags
in
the
metadata,
whereas
any
type
of
user
attribute
is
encoded
differently
and
once
you're
using
user-defined
attribute,
you
don't
have
to
you,
don't
really
have
to
care
about
how
much
space
it's
taking
anymore.
D
Right
so
I
think
then
it's
fine,
then
we
could
probably
rename
the
I
think
we
should
then
probably
split
the
native
API
attribute
into
I.
Don't
know
like
an
entry
point
attribute,
I'm,
better
naming
so
that
the
string
that
also
goes
on
there
is
provided
differently
and
then
we
need.
And
then
we
need
like
a
different
attribute
that
effectively
modifies
the
function
pointer
or
the
dll
report,
and
that
that
that
only
works
in
cases
where
the
emitter
has
already
decided
to
use
a
function,
pointer
or
dll
report.
D
So
in
case
of
a
function
pointer,
it
would
just
put
the
different
types
inside
the
function
pointer
declaration
and
in
case
of
the
other
report.
It
it
figured
out
the
calling
convention
and
put
the
unmanaged
column
convention
in
the
separate
attribute,
and
so
we
probably
want
to
then
split
up
that
attribute.
But
that
shouldn't
be
too
big
over
change.
D
G
B
Yeah
I
know
where
he
sends
it
look.
It
looks
like
we
got
nothing
from
the
YouTube
channel
as
well,
so
I
think
we
should
well,
first
of
all,
I
think
we
should
probably
Circle
back
to
the
original
comments
from
this.
They
mostly
surrounded
around.
We
weren't
sure
what
we
wanted
to
do
with
our
overloads,
because
in
two
point
x,
we
sort
of
re.
Well,
we
try
to
generate
every
single
permutation
of
overload
that
we
think
could
be
possibly
useful
to
the
user.
B
B
We'd
like
to
essentially
have
a
play
around
and
experiment
with
a
number
of
different
things
and
then
circling
back
to
a
community
meeting
with
our
findings,
essentially
having
a
proper
plan
for
how
we're
going
to
tackle
this,
because
we
we
did
try
discussing
a
a
formal
way
like
a
formal
overloading
plan,
but
ultimately,
we've
just
got
to
have
a
play
around
with
it
once
we're
actually
implementing
and
then
Circle
back
to
the
community
meeting
and
present.
Our
findings
essentially.
D
D
G
D
D
G
B
Yeah
we're
we're
going,
we
I
I
think.
Ultimately,
what
we're
asking
of
the
community
is
to
sort
of
let
us
play
around
with
it
figure
out
what
is
best,
because
we
I
think
we're
all
in
agreement
that
the
the
two
point
x
situation
is
well.
It
certainly
gives
you
a
lot
of
options.
It
is
a
bit
ridiculous,
so
I
think
what
we're
sort
of
asking
is
to
have
a
play
around
with
it
and
then
come
back
in
a
future
community
meeting
and
sort
of
present
our
findings
a
bit.
E
D
D
D
That's
what
I
wanted
to
say
thanks
the
way
we
kind
of
well
I
kind
of
thought
it
could
work
is
we
we
need
to
or
we
want
to
build
the
like
most
basic
overloads
into
the
assembly,
so
it
just
makes
sense
to
if
you
have
a
like
a
pointer
argument
and
the
count
argument
to
just
generate
a
span
overload
that
just
makes
sense
and
it
also
extremely
rarely
happens
multiple
times
in
one
method.
So
it
isn't
really
a
problem
in
the
number
of
overload
like
situation
and
then
for
like
other
types.
D
D
They
aren't
really
ready
to
make
so
again,
I
think
that's
that's
kind
of
a
good
way
to
figure
it
out
is
just
to
like
kind
of
play
with
it
right
and
we
have
to
build
the
overloader
regardless
and
then
prioritizing.
It
will
I
think
require
some
experimentation
and
then
eventually,
we
can
kind
of
come
back
to
that
and
look
at
how
how
we
can
do
it
and
what?
E
There's
just
no
way
to
determine
that,
and
so
I
was
going
to
provide
a
way
for
users
to
provide
those
annotations
so
that
a
friendly
overload,
a
single-friendly
overload
could
be
generated.
In
addition,
and
then
the
general
thought
is,
if
you
have
the
fully
blendable
binding
in
combination
with
a
friendly
overload,
you
have
all
the
context
to
be
able
to
generate
everything
in
between
based
on
what
the
user
has
physically
written
in
code.
D
D
This
is
sort
of
the
approach
that
silk
touch
today
takes
just
not
user
facing
but
like
internally
and
it's
I
don't
feel
like
it's
a
good
approach
in
general,
because
it's
kind
of
like
like
like
playing
the
lottery
right
like
maybe
it
works,
and
maybe
it
doesn't
and
you
have
no
way
of
knowing
whether
it
does
and
so
I.
Don't
really
think
it's
that
great
of
an
idea,
but
the
way,
but
this
is
very
similar
to
how
we
wanted
to
handle
it.
D
Just
you
know
like
proactive
matters,
so,
for
example,
we'd
weeds,
provide
you
with
like
we
have
these
information
from
like
the
the
xml5
Chronos
gives
that
this
is
like.
You
have
eight
string,
and
then
we
provide
The
annotation.
That
is
a
GTA
string,
and
then
you
could
like
say.
Okay,
then,
please
also
do
map
this
to
the
to
the
little
like
C
sharp
string
right
using
you
know,
whatever
method
or
like.
If
someone
has
eventually
has
come
out
with
like
a
package
for
each
of
eight
strings,
then
they
could
just
say:
hey.
E
Yeah,
so
I
was
just
calling
out,
there's
also
tricks.
You
can
do
like
this,
where,
if
you
know
the
right
attributes
to
slap
on
the
C
sharp,
you
can
work
around
the
C
sharp
type
system
and
put
optional
parameters
anywhere
in
the
list
and
even
give
things
like
read-only
span
of
char
optional.
You
can
give
them
default
string
values
which
is
otherwise
impossible
to
express
in
regular
C
sharp.
E
This
only
works
when
there's
an
implicit
conversion
from
A
Primitive
type
like
string
or
int
to
the
Target
type.
So
in
this
case,
there's
one
between
string
and
read-only
span
of
char.
So
you
can
make
this
work
and,
of
course
you
could
make
that
string
be
anything
you
could
make
it
you
know
be.
Silk.Net
is
awesome,
and
this
works
for
for
that,
including
with
C
sharp
picking
the
right
overload.
E
E
Technically,
it's
non-spect
c-sharp,
it's
a
side
effect
of
how
the
metadata
is
represented
and
interpreted
by
the
compiler,
but
optional
parameters
are
actually
embedded
using
the
optional
attribute
in
the
default
parameter
value
attribute
which
get
compiled
down
to
the
inline
attributes
in
il.
There
are
also
magic
attributes,
as
it
were.
B
Think
realistically
we're
just
gonna
have
to
sort
of
prototype
all
these
ideas
and
see
what
well
see
what
sticks
because
well
yeah,
there's
a
lot
of
things
to
do,
and
we
really
want
to
do
it
right
and
I
think
we'll
be
especially
before
something
like
the
overloader
we'll
be
shooting
ourselves
in
the
foot
if
we
sort
of
specify
something
without
actually
having
having
gone
and
implemented
it.
So
this
will
I
think
we're.
This
will
be
something
we
come
back
to
in
the
future
community
meeting,
but
I
think.
G
B
B
B
B
A
B
B
I
think
it's
I
I
think
the
whole
directional
button
thing
that
is
I
fully
agree
with
that
because
well
yeah,
especially
the
Nintendo
examples.
Wow
I
didn't
realize.
That
was
a
thing,
so
that's
very
good
to
think
about
so
yeah
renamed
positional
buttons
and
we've
got
plenty
to
think
about
in
the
future
for
future
expansions,
but
other
than
that.
Are
we
all
good
for
that
to
essentially
be
approved.
B
G
F
B
Okay,
cool
awesome,
so
I
think
that
is
everything
for
this.
Unless
anyone
has
any
general
comments
about
3.0
and
I
think
we
should
be
considering
anything
any
of
your
questions
that
we
haven't
go.
This
is
your
last
chance
to
sort
of
raise
questions
on
anything
3.0.
Let
us
know
in
the
YouTube
chat
in
one
of
us,
seemingly
any
of
the
Discord
channels
that.
B
E
D
Of
course,
it's
eventually,
you
want
to
happen
together
with
the
change
to
use
different
method
names
for
approximate
and
non-approximate
and
like
86
math
methods,
I
I
can't
like
tell
you
how
exactly
they'll
look,
but
we
thought
I
says
we
will
probably
just
a
view
value
like
all
of
the
functions.
Look
at
the
if
you
look
at
that
as
an
output
and
then
see
how
it
looks,
I
guess
so
so
yeah
we'll
definitely
like
revisit
it.
G
One
thing
I
did
want
to
mention
so
because
I
I
took
a
look
at
the
software
development
plan
a
week
or
a
couple
of
weeks
ago
and
I
I
did,
and
since
we
brought
up
a
couple
of
things
that
we're
gonna
have
to
meet
back
in
later,
I
I
was
going
to
question
so
should
like.
Should
the
decision
on
what
to
do
with
overloads
and,
for
instance,
those
for,
for
instance,
well,
yeah
I,
guess
mainly
what
to
do
for
overload.
G
C
D
B
Okay,
so
I've
got
nothing
in
the
YouTube
chat,
so
if
that's
everything
then
I
think
we've
covered
pretty
much
all
of
it,
so
I'll
carry
on
watching
for
questions,
but
well.
Thank
you.
Everyone
for
coming!
Thank
you
for
watching
this.
Is
it
it's
finally
good
to
it's
good
to
finally
get
3.0
off
the
ground.
B
I
really
believe
that
we
that
we
can
make
this
the
best
so
well
the
best.net
bindings
library
that
we
possibly
can
and
yeah
just
really
excited
to
finally
be
able
to
get
work
in
this
and
happy
that
no
one
has
any
the
massive
objections
to
what
we've
done
here,
like
oh
you're,
doing
it
all
wrong.
So
that's
really
good,
as
always,
follow
our
progress
in
the
Discord
server,
with
with
far
too
often
so
pop
by
and
say
hello.
B
A
B
As
well
at
silk.net,
or
we
have
our
individual
Twitter's,
which
you
can
find
somewhere
I
believe
in
the
sub.net
readme,
so
yeah,
all
in
all
lots
of
ways
to
contact
us.
Let
us
know
if
you
have
any
other
thoughts
outside
of
this
stream.
I
will
probably
watch
the
comments
as
well.
The
YouTube
comments
once
the
VOD
goes,
live
so
yeah.
Thank
you.
All
everyone
for
coming
I
think
it's
been
a
very
good
meeting
and
very
excited
to
finally
get
3.0
off
the
ground.
B
C
G
E
I
guess
I've
got
one
more
question
that
came
to
mind
when
what
is
the
plan
for
DOT
net
seven
and
have
either
of
you
looked
at
generic
math
yet
or
are
planning
to
look
at
generic
math
and
ensure
that
what
I've,
what
I've,
designed
and
and
am
designing,
is
in
the
correct
shape
to
work
for
silk.
Moving
forward.
B
B
F
E
Yeah
it,
it
wasn't
mostly
a
question
of
like,
if
of
like,
when
silk
will
do
it,
but
more
like
once
these
apis
ship,
they're
shipped
there's,
no
changing
them,
and
so
there's
a
window
here
of
about.
You
know
four
or
five
more
months,
where
I'm
able
to
accept
input
and
make
changes
accordingly,
and
so,
if
silk
does
have
any
plans
around
them
doing
an
investigation
and
getting
feedback
on
either
apis
that
are
missing,
shapes
that
might
not
quite
work
or
make
sense,
and
things
like
that
would
be.
D
So
I'll
sorry
I
didn't
mean
to
interrupt
you
just
just
quickly.
I
I
I'll
definitely
put
it
on
my
list,
then
to
like
soon
see
whether
we
could
Implement
them
before
they
can't
ship
it
until
like.
Well,
it's
it's
in
some
like
stable
release,
but
I'll
definitely
investigate
how
and
if
we
could
Implement
them,
then
yeah.
E
Yeah,
it's
definitely
not
an
ask
to
go
and
Implement
them
today,
but
more
to
take
a
take,
a
look
at
them
and
make
sure
that,
if
there's
any
egregious
errors
that
they
get
called
out,
because
if
there's
something
that
silk.net
would
like
and
it's
not
covered
until
after.net
seven
ships.
Well
then
it's
effectively
too
late
to
add
it
for
at
least
another
year
and
in
some
cases
ever
depending
on
what
that
change
is
and
if
it
would
be
breaking
or
not.
E
B
Awesome
so
yeah
yeah,
that's
an
excellent
ad
I've
added
it
to
the
GitHub
tracker
as
well.
Along
with
what
was
the
other
thing,
I
did
to
investigate
fixing
the
silver.net
maths
inline
nuances
that
Tana's
brought
up
in
passing,
so
yeah
a
lot
to
be
getting
along
with,
but
now
that
we've
got
the
the
3.0
proposals
all
sorted.
Hopefully
we
can
just
crack
on
with
it
and
start
implementing.
B
B
G
D
D
G
Related
to
the
meeting,
it
was
more
reminiscing
about
something.
So
no
you
go.
No,
no
really!
Really!
Please
please
go
ahead!
I
I,
don't
know.
I
I
was
gonna,
say
I
I.
Remember,
because
how
I
I
first
met
her
ski
I
I
want
to
say
was
in
The
Stride
Discord
server
when
he
was
when
he
was
asking.
If
it
would
be
okay,
if
he
could
try
and
Port
stride
to
silk.net,
and
he
was
really
excited
for
at
the
time
he's
like.
A
F
B
Very
very
excited
for
something
about
that,
and
we
should
it's
something
that's
going
to
solve
everything.
It's
still
that
3.0
is
going
to
solve
everything.
Don't
worry,
yeah,
yeah,
I,
appreciate
we've
been
done
with
this
before,
but
given
that
this
is
a
complete
rewrite,
I
feel
a
lot
more
confident
about
it,
rather
than
just
a
lot
of
extra
stuff,
that
is,
that
is
cool
tacked
onto
it.
So.