These are chat archives for bjz/gfx-rs

30th
Jun 2014
Dzmitry Malyshau
@kvark
Jun 30 2014 00:10
@bjz I feel like I need to redo #28 from scratch again...
Brendan Zabarauskas
@brendanzab
Jun 30 2014 00:16
@kvark I need to do some other things now, but I'll have a look at the recent activity after!
sorry!
Dzmitry Malyshau
@kvark
Jun 30 2014 00:17
@bjz understood
Coraline Sherratt
@removed~csherratt
Jun 30 2014 00:25
I can work around #31, #32 is an easy fix. I am just documenting problems as I find them. If I get something working and have a stack of assorted bug fixes it is good to know what they were for.
Dzmitry Malyshau
@kvark
Jun 30 2014 00:27
@csherratt Thanks! #32 is a good catch, no idea how I put this in so wrong :)
@bjz I'm confused. When I run "make deps" inside gfx-rs, it detaches them from head revisions and fails to compile (apparently missing some commits). However I can go there directly, checkout master and build them just fine.
@bjz Oh well, I think I figured this out. "make submodule-update" should somehow see that I'm on the newer revision and do not reset it.
Dzmitry Malyshau
@kvark
Jun 30 2014 00:35
@bjz r? #33
Dzmitry Malyshau
@kvark
Jun 30 2014 01:48
@csherratt #36 is ready for your indexed needs
Coraline Sherratt
@removed~csherratt
Jun 30 2014 01:58
There is a few unrelated changes in this that make it a little hard to review.
It looks ok.
Dzmitry Malyshau
@kvark
Jun 30 2014 02:06
@csherratt True. There are changes from #28 that I happened to re-implement there. Now that I got all the #28 stuff here, I'm thinking about just pushing it into the same PR for review. The thing I want to add is mesh/program attribute matching with a simple handle cache.
@csherratt @bjz should I push it to #36 or create a new PR for it?
Dzmitry Malyshau
@kvark
Jun 30 2014 02:14
@csherratt Changes I'm talking about are the last 2 commits from this branch. Please feel free to review, if you have time.
I'm trying to code/push as much as I can now, so tomorrow at work I can just manage the pull requests, review others code, and such
Coraline Sherratt
@removed~csherratt
Jun 30 2014 02:29
#33 looks fine.
@kvark if I merge 33 can you rebase 36?
Dzmitry Malyshau
@kvark
Jun 30 2014 02:32
I believe #36 doesn't really need a rebase, because it contains the very same commit (the first one) as #33
I've got no problem rebasing if needed for #36
Coraline Sherratt
@removed~csherratt
Jun 30 2014 02:36
I'm indifferent, just avoids closing #33 without a merge.
ok #33 is merged, #36 can be rebased then merged.
Dzmitry Malyshau
@kvark
Jun 30 2014 02:46
#36 is ready, please feel free to merge it
Coraline Sherratt
@removed~csherratt
Jun 30 2014 02:47
So Slice is created by the api user? They can upload a large geometry buffer and use this to split it up?
Dzmitry Malyshau
@kvark
Jun 30 2014 02:48
@csherratt Originally, I thought that the user will deal with SubMesh (handles of them), but since the material logic does not exist yet, I figured that just Slice would require less code from both sides, at least for now.
Coraline Sherratt
@removed~csherratt
Jun 30 2014 02:49
ok
it looks like the Slice path looks to be correctly exported so it should work. So no worries there.
Dzmitry Malyshau
@kvark
Jun 30 2014 02:51
@csherratt awesome
I'm off to bed. Feel free to merge #36, and have a look at my shade branch when you get a chance. Also, great thanks for your contribution, @csherratt !
Coraline Sherratt
@removed~csherratt
Jun 30 2014 02:54
it's merged
Dzmitry Malyshau
@kvark
Jun 30 2014 02:57
thanks, I submitted #37 for the binding upgrades, no need to look at my shade branch any more.
Brendan Zabarauskas
@brendanzab
Jun 30 2014 04:07
yay, git submodules
:[
Dzmitry Malyshau
@kvark
Jun 30 2014 12:13
@bjz #38 - just something to think about while our architecture is not yet set in stone...
@P1start hello! What brought you here, my friend?
Sven Nilsen
@bvssvni
Jun 30 2014 13:17
@kvark I posted a link on #rust-gamedev
Coraline Sherratt
@removed~csherratt
Jun 30 2014 17:13
Does anyone know how to unit test gfx-rs?
Brendan Zabarauskas
@brendanzab
Jun 30 2014 17:15
@csherratt it would be cool if it was possible to unittest components
@csherratt would encourage a more pure architecture
Coraline Sherratt
@removed~csherratt
Jun 30 2014 17:16
hmm.
Dzmitry Malyshau
@kvark
Jun 30 2014 17:35
@bjz @csherratt @photex please let me know what you think about #38 when you have a chance (either here or in the issue directly)
Brendan Zabarauskas
@brendanzab
Jun 30 2014 17:36
really sorry, I need to really focus on work right now
only got a few weeks left on my internship, need to hit something out of the park
I will get to it this evening
Dzmitry Malyshau
@kvark
Jun 30 2014 17:37
@bjz no worries, I've got lots of work myself
Dzmitry Malyshau
@kvark
Jun 30 2014 21:07
I think I really got a breakthrough on our shader parameters. @bjz @csherratt @photex - please review the idea on #19 (last big fat comment). Sorry for verbosity - it's a difficult nut to crack, so requires a big hammer ;)
kvark @kvark has just fixed the string arguments in this code
Coraline Sherratt
@removed~csherratt
Jun 30 2014 21:24
@kvark would an environment be unique per shader?
oh wait... oh I see
And environment is purely a lookup table into the shader's already bound parameters. If you try and use an environment with an incomparable shader you will get some type of error or warning.
So in that way, it you only eat the cost of the validation the first time you use an environment with shader.
My only wonder is if we can make fn set_env_uniform(&mut self, EnvironmentHandle, EnvUniformHandle, device::shade::UniformValue); avoid passing UniformValue in as as enum.
So can EnvUniformHandle be type safe...
Dzmitry Malyshau
@kvark
Jun 30 2014 21:33

@csherratt:
Thanks for looking into it!

would an environment be unique per shader?

User is free to mix and match environments with different programs

And environment is purely a lookup table into the shader's already bound parameters

The EnvironmentShortcut is a lookup table, not the Environment

If you try and use an environment with an incomparable shader you will get some type of error or warning

Yes, we'll need to handle these cases, they are inevitable regardless of the approach we take.

So in that way, it you only eat the cost of the validation the first time you use an environment with shader

Right!

avoid passing UniformValue in as as enum

We can have render::Client to wrap that up, and to have multiple methods (set_env_vec4, set_env_mat4, etc). I don't think this is needed, but we can vote on that ;)

So can EnvUniformHandle be type safe

Dunno if we can make it safer without adding overhead/complexity. Improvement proposals are welcome!

Dzmitry Malyshau
@kvark
Jun 30 2014 21:39
I'll be back in an hour...