ported to Go but ex1 doesn't work

[TotallyGamerJet]

This project is really cool. I have had a fascination with graphics for a long time but haven't found something that really interests me until this. I ported this project to the GO programming language using a tool called CXGO.

I then went ahead and converted by hand the ex1 c code found in main.go.

Everything runs without any errors but I don't get any triangle displayed. It appears that shaders are getting the vertex data but I don't know why nothing shows. I know my code is in Go and not C but since you understand the project better than I do maybe you'll spot something wrong in my code. Or give suggestions on what to look for if cxgo introduced a bug.

My project is here

[rswinkle]

I've never used Go but I got what you're getting. Since glClear is working, that rules out not getting the result to the screen properly. I suspect it's a mistake in the translation to Go that's changing the behavior. Other than that I couldn't say without more research since I'm completely unfamiliar with Go's syntax/semantics. I see you're almost exclusively a Go programmer from your repos, no C or C++ which would be my recommendation if you wanted to just get up and running quickly.

I'll look into it a little more but I can't make any guarantees.

Unrelated, in your fork of PortableGL, your one commit is changing GLvoid from an enum to a macro. Is that something to do with how CXGO treat's void?

[TotallyGamerJet]

Yeah I’m pretty much exclusively a Go programmer although I do have experience with C.

Thank you for actually looking at it! I did have to remove GLvoid bc cxgo doesn’t handle typedefs to void nicely. I just changed it to a define so all instances of it would be replaced with just void. Do u think that could break things?

I appreciate your help and I’ll continue to looking for the issue.

[rswinkle]

Yeah, I can't even add print statements to figure out what's going on because I can't figure out how to call get the equivalent of stdout to pass to fprint_vec4 (and similar functions that take a FILE in C and a stdio.File in Go). I would first make sure that the vertices coming out of the vertex shader are the same as in the C version and then that the fragment shader is being called (ie the whole thing isn't being culled or clipped when it shouldn't).

[TotallyGamerJet]

Thanks for giving some things to look for.

here is something you can actually answer. In ex1.c there is a variable frame_time but it is only ever assigned to and never used. Is it supposed to be used as the first argument in the printf?

[TotallyGamerJet]

Okay! I've got some success. The fragment shader is never called. Now I just have to figure out why it's not.

To answer your question on how to get stdout you'd write: stdio.Stdout()

[TotallyGamerJet]

So I think I found the issue. mat4 is an array and C passes arrays by references so functions that receive them will change the callers array. But Go passes arrays by value so changes to the array don't filter up. make_viewport_matrix is suppose to fill the matrix but it didn't because it was just an array and not a pointer. I made it a pointer and everything started working. I ported ex2 as well. I am going to keep rewriting the exercises and demos but I think this is good to be closed!

[rswinkle]

I wouldn't say C passes arrays by reference. C passes everything by value. The name of an array is really just a pointer to the first element. It's why you see people using both and [] interchangeably for "array" parameters (I prefer personally because I feel it's more accurate). The main difference between an array and a pointer in C/C++ is if the array is declared (rather than allocated), sizeof will return the actual size of the array rather than the size of the pointer. Also if it's a declared array, you can't modify the pointer.

Congrats on getting it working though. Never thought I could legitimately add a Bindings section to my README but I definitely will add a link to your pgl repo.

[rswinkle]

Oh, I forgot to answer your question. frame_time is there because the FPS printing code dates back to the very beginning of the project (the demo main.cpp) and I used it to calculate rotation matrices there. It's been copy pasted to practically every demo/example, used in some, deleted in others, but clearly not all of them :-/ Thanks for pointing it out.