Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any interest in adding non-JS versions of the lesson code? #245

Open
justinclift opened this issue Jul 24, 2019 · 7 comments
Open

Any interest in adding non-JS versions of the lesson code? #245

justinclift opened this issue Jul 24, 2019 · 7 comments

Comments

@justinclift
Copy link

justinclift commented Jul 24, 2019

The lessons use javascript to explain things, which likely works really well for a javascript-literate audience.

Being as WebAssembly is now gaining good adoption, and WebGL can be used in that (thus no need for javascript), would having ports of the lesson code to other languages be useful?

As a Go developer getting my head around WebGL, it's the kind of thing I'd find useful as it was non-trivial to get working. Fairly sure other Go developers would pick things up faster with Go examples too. 😄

For an initial start, this is the first lesson basic triangle (etc) ported to TinyGo:

If this kind of thing would be useful, I'm happy to chuck it and the rest (in progress) in a suitable PR of some sort. Just not sure where. 😉

@greggman
Copy link
Member

greggman commented Jul 24, 2019

That's pretty cool.

There was a point where I was thinking about porting the site to C++ and be about OpenGL. I feel it's important to have live editable samples and so for example here's a live C++ compiler running in the browser.

https://tbfleming.github.io/cib/

Unfortunately it's a 10meg download. Sure that will get cached but I also wonder how much life is left in OpenGL. Another problem is there are no debugging tools in the browser but still, seeing the code run and being able to edit a few things like a color, a shader, the number of things draw, or the speed etc, live, is important IMO.

As for GO, looking at your code, I'd think expect a better interface than

gl.Call("drawArrays", primType, primOffset, primCount)

Like maybe this?

https://github.com/gopherjs/webgl/blob/master/webgl.go

Also it makes no sense to get the WebGL constants from the WebGL context. Just hard code them.

In other words

 types.staticDraw = 35044    // GOOD
 types.staticDraw = gl.Get("STATIC_DRAW");    // bad

That's perfectly valid to do. The values are meant to be constant integer values that you can hard code.

There's also OpenGL bindings

https://raw.githubusercontent.com/go-gl/gl/master/v4.1-core/gl/package.go

I guess there's lots of questions. Like where should Go WebGL usage match Go OpenGL ? As another example should it be types.staticDraw or types.STATIC_DRAW. I'm assuming the former is more go like where as the later is more OpenGL/WebGL like. I notice the OpenGL bindings seem to use the second style to match OpenGL.

I'm also not sure how to present things. Would there be 2 language selectors at the top of the site, one for human language (english, japanese, russian, etc.) and another for computer language?

I guess that make me wonder, are you just suggesting a collection of the examples running in Go? Or are you suggesting the articles have Go versions with Go code in them.

Lots of questions...

@justinclift
Copy link
Author

justinclift commented Jul 25, 2019

Thanks @greggman. Updated those initial porting examples with hard coded values, as per MDN docs. 😄

As for GO, looking at your code, I'd think expect a better interface than

gl.Call("drawArrays", primType, primOffset, primCount)

A better interface would indeed be welcome.

The GopherJS/WebGL repo looks interesting. Will experiment a bit with that, and see if it works as-is with TinyGo's wasm output. @dmitshur may have some insight here. 😄

Note - I'm using TinyGo (https://tinygo.org) instead of the standard Go compiler for now, as TinyGo uses LLVM for code generation resulting in much, much smaller .wasm files.

TinyGo produced ones are generally 2-3% of the size compared to standard Go compiled ones. eg 10kB vs ~300kB. 😉

Eventually the standard Go compiler might produce acceptably sized .wasm files. It's just not looking any time soon though. 🤷‍♂️

@justinclift
Copy link
Author

justinclift commented Jul 25, 2019

I guess that make me wonder, are you just suggesting a collection of the examples running in Go? Or are you suggesting the articles have Go versions with Go code in them.

For the moment, lets see how I go with just making Go versions of the examples. If I do get them all done 😉, we can think about doing something with an on-the-fly coding-language drop down (JS/Go/etc) selector for fully dynamic articles.

One step at a time though, etc. 😄

@justinclift
Copy link
Author

justinclift commented Jul 25, 2019

Interestingly, although that gopherjs/webGL repo isn't compatible with the current Go/TinyGo approach, it's just a case of slightly mismatching data types.

It might be pretty simple to copy it to a new repo then adjust the data types to work.

Will find out. 😄

@justinclift
Copy link
Author

justinclift commented Jul 25, 2019

Initial conversion, adjusting data types to work with Go's webassembly layer (syscall/js) instead of using GopherJS, and use hard coded constants for the values (copied from MDN) instead of retrieving them at runtime.

    https://github.com/justinclift/webgl

Seems to work ok, so the above lesson example code has been updated to use it.

Review, thoughts, etc, welcome. 😄

@justinclift
Copy link
Author

@j7b ^^^ Of any interest?

@justinclift
Copy link
Author

4th example (the final one from the very first page):

    https://github.com/justinclift/tinygo-webgl-fundamentals-lesson-4 (running demo)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants