These are chat archives for bjz/gfx-rs

20th
Jun 2014
Brendan Zabarauskas
@brendanzab
Jun 20 2014 00:19
I would rather go through PRs. I will get travis working with it
Dzmitry Malyshau
@kvark
Jun 20 2014 01:28
@bjz any feedback on #3?
Dzmitry Malyshau
@kvark
Jun 20 2014 01:40
@bjz I seriously don't want #3 to block the triangle example. It would be nice if clients could pass commands directly to the device (excluding the renderthread layer). Do you think it is difficult to achieve with the current architecture?
I don't see a problem with it (theoretically) Yes, this path loses great deal of abstraction, but 1) it's optional 2) the client <-> rnderthread protocol is far from being done, and 3) GLFW and GL are still abstracted out.
Brendan Zabarauskas
@brendanzab
Jun 20 2014 01:41
hmm
What is the most rudimentary you need to get up and running? Then perhaps we can re-sculpt it later?
We definitely want to get something rendering as soon as possible
A simple Clear and Finish set of methods could be implemented easily at first
Can I do that?
Dzmitry Malyshau
@kvark
Jun 20 2014 01:52
@bjz sure. So as I understood, you want to have the renderthread pass-through for now?
@bjz I'm working on the render <-> device interface, you can do client <-> render meanwhile
Dzmitry Malyshau
@kvark
Jun 20 2014 02:02
FYI, here is the Makefile I'm using locally: https://gist.github.com/kvark/9ec100056e5d4487dc08
Brendan Zabarauskas
@brendanzab
Jun 20 2014 02:19
@kvark awesome, could you commit that, with the license at the top?
@kvark #5
sorry for the wait
Dzmitry Malyshau
@kvark
Jun 20 2014 02:20
@bjz no worries, will review shortly
Brendan Zabarauskas
@brendanzab
Jun 20 2014 02:26
@kvark if you are happy, feel free to hit the big green button :)
Dzmitry Malyshau
@kvark
Jun 20 2014 02:27
Brendan Zabarauskas
@brendanzab
Jun 20 2014 02:28
:D
Dzmitry Malyshau
@kvark
Jun 20 2014 02:30
@bjz Your turn now! (#6)
Dzmitry Malyshau
@kvark
Jun 20 2014 02:46
I'm already lost in all those clients and servers... Have been trying to figure out where to hook stuff for the past 30 mins :(
Brendan Zabarauskas
@brendanzab
Jun 20 2014 02:47
:(
sorry - is it too difficult?
would naming things differently help?
Dzmitry Malyshau
@kvark
Jun 20 2014 02:48
that's my hope
Brendan Zabarauskas
@brendanzab
Jun 20 2014 02:52
make new issue maybe?
Dzmitry Malyshau
@kvark
Jun 20 2014 02:53
@bjz sure
@bjz I think I figured out where to hook up, at last
Dzmitry Malyshau
@kvark
Jun 20 2014 03:46
@bjz I'm crashing in glfw swap_buffers. Could that be because we initialize it in one thread (main) but use in another (device thread)?
Brendan Zabarauskas
@brendanzab
Jun 20 2014 03:47
what does your example code look like?
Dzmitry Malyshau
@kvark
Jun 20 2014 03:47
I'm not doing anything yet
just running the bare triangle example
what do you get when you run it?
make examples && bin/ex-triangle
Brendan Zabarauskas
@brendanzab
Jun 20 2014 03:49
it runs fine for me
the swap_buffers is happening on the main thread
Dzmitry Malyshau
@kvark
Jun 20 2014 03:50
ah ok
Brendan Zabarauskas
@brendanzab
Jun 20 2014 03:50
the device::Server has markers to stop it being moved out
annoying names again :(
sorry
Dzmitry Malyshau
@kvark
Jun 20 2014 03:52
@bjz wait, so despite the fact you are spawning a new task for the device, it's still on the main thread? hmmm I do see that in the stack trace, so this must be true :)
Brendan Zabarauskas
@brendanzab
Jun 20 2014 03:53
yep!
that is the idea
sorry if it wasn't clear
wait... there is no thread spawned for the defice
Dzmitry Malyshau
@kvark
Jun 20 2014 03:55
@bjz so these are green threads then? and we can mix and match them with natives?
Brendan Zabarauskas
@brendanzab
Jun 20 2014 03:55
there is a thread for the renderer task, spawned by gfx::start, and a game task spawned in the example
Dzmitry Malyshau
@kvark
Jun 20 2014 03:56
@bjz so we got 2 threads? ok, why do we have the duplex channel between the renderthread and the device then if they are not separated by a thread boundary?..
Brendan Zabarauskas
@brendanzab
Jun 20 2014 03:56
swap_buffers gets called on the call to .update() in the example code
they are
see this is why I think it might be too confusing... :(
Dzmitry Malyshau
@kvark
Jun 20 2014 03:58
@bjz yeah... bear with me for a moment please. There are 2 duplex streams, which are supposed to correspond to 2 thread boundaries. So we must be having 3 threads, correct?
Brendan Zabarauskas
@brendanzab
Jun 20 2014 03:58
gfx::start spools up a render task, and gives you two things - one which must always live on the main thread, and one you can move off into your own thread
so you end up with three threads in the end
but the third one is up to the user to spool up
however they want to
we don't control that
Dzmitry Malyshau
@kvark
Jun 20 2014 03:59
@bjz ok, seems a bit more clear now. Thanks!!
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:00
is that an ok sounding architecture though? if so I might need to improve the comments
and docs
Dzmitry Malyshau
@kvark
Jun 20 2014 04:02
@bjz I just confirmed - it's not my local changes. I'm crashing with what we have in master...
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:02
see we could spool up a game task for the user, then block on the main thread, but you said you didn't like that idea
hmm
osx right?
Dzmitry Malyshau
@kvark
Jun 20 2014 04:02
linux
AMD open-source driver
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:03
so you get no info?
Dzmitry Malyshau
@kvark
Jun 20 2014 04:03
@bjz I said I didn't like the idea? My vision of the architecture was way too simplified when we discussed it. Not saying it turned out bad (or good), but I need to evaluate it yet.
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:04
do the glfw-rs examples work for you?
Dzmitry Malyshau
@kvark
Jun 20 2014 04:04
certainly
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:04
hmm
Dzmitry Malyshau
@kvark
Jun 20 2014 04:04
I got the triangle, remember? :)
brendanzab @bjz has to figure out how to use C-reduce
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:05
actually - that wouldn't help here
as it is runtime
Dzmitry Malyshau
@kvark
Jun 20 2014 04:06
we are simply doing something wrong, and OSX implementation swallows it
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:06
lol platform::glfw::GlfwPlatform$LT$C$GT$.Platform$LT$GlApi$GT$
<>
Dzmitry Malyshau
@kvark
Jun 20 2014 04:06
heh
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:07
yeah, it's probably something stupid I am doing :(
@kvark could you try changin line 17 in the triangle example to let platform = gfx::platform::Glfw::new(window);?
instead of let platform = gfx::platform::Glfw::new(window.render_context());
Dzmitry Malyshau
@kvark
Jun 20 2014 04:09
same crash...
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:09
hmm
comment out everything after the line 20?
oh wait
that wouldn't do anything
it would work
because the crash is on swap_buffers
Dzmitry Malyshau
@kvark
Jun 20 2014 04:10
it's fine if I forbid call to swap_buffers
but we are not doing anything aside from that, so the experiment makes very little sense
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:11
yep
could you try just swapping buffers only once?
ie. take it out of a loop?
Dzmitry Malyshau
@kvark
Jun 20 2014 04:13
same crash
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:13
.>_<
Dzmitry Malyshau
@kvark
Jun 20 2014 04:14
@bjz worry not, I'll figure this out
but the triangle will have to wait till tomorrow
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:15
could you remove the task spawn before the device loop?
I doubt that would do anything
Dzmitry Malyshau
@kvark
Jun 20 2014 04:16
@bjz I tried just calling swap_buffers directly where the sample creates the context, and it still crashes. So I just need to find the difference between this and my triangle
@bjz got it, make_current() was missing
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:18
OHH
facepalm
Dzmitry Malyshau
@kvark
Jun 20 2014 04:18
@bjz I'd expect GLFW to handle that more gracefully
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:19
yeah
should the make_current method be part of Platform? dunno if that is more specific to glfw
Dzmitry Malyshau
@kvark
Jun 20 2014 04:21
I've just put it into GlfwPlatform::new for now
brendanzab @bjz still thinks the platform stuff will have to be rejigged
Brendan Zabarauskas
@brendanzab
Jun 20 2014 04:22
yeah that sounds good
kvark @kvark having a hard time dealing with the function loaders (get_proc_address) with this level of abstraction
Dzmitry Malyshau
@kvark
Jun 20 2014 04:28
That's it for me today. I'm sitting on a changelist buy don't want to PR until it somehow works. g'night!
Brendan Zabarauskas
@brendanzab
Jun 20 2014 05:00
@kvark thanks for your awesome help as usual! <3
o/
Dzmitry Malyshau
@kvark
Jun 20 2014 12:02
@bjz Any reason why get_proc_address() is not a member of glfw::Context?
Dzmitry Malyshau
@kvark
Jun 20 2014 12:40
@bjz My problem is that gfx-rs side only sees Context methods of Glfw window, so we are unable to load GL entensions with get_proc_address(). It should be moved in to Context, or better - encapsulated into a separate trait GlProvider, which would contain get_proc_address() and extension_supported(). I'd submit a PR but I've got to go back to work now.
Dzmitry Malyshau
@kvark
Jun 20 2014 13:25
@photex \o/
Dzmitry Malyshau
@kvark
Jun 20 2014 13:57
@bjz I can't make myself to create an issue about names. Once if figured the scheme, it's not longer as confusing to me as it was ("can't unsee!")
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:12
the issue is the get_proc_address is not threadsafe :(
hm
I probably should look how ogre does it
Dzmitry Malyshau
@kvark
Jun 20 2014 15:16
@bjz I don't get it. We are not using it from different threads. Why thread safety is blocking us here?
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:20
no, that is why it is not implemented on glfw::Context
Dzmitry Malyshau
@kvark
Jun 20 2014 15:21
@bjz so can we have it (with extension_supported()) in a separate trait then?
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:22
yeah
Dzmitry Malyshau
@kvark
Jun 20 2014 15:23
@bjz that would solve it for me, we'll just use <C: Context + GlProvider> in the platform
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:24
yeah, I can rijig it later to make a nicer external API
I had some nebulous ideas on the walk to work - but noting very concrete yet
Dzmitry Malyshau
@kvark
Jun 20 2014 15:28
@bjz that's teasing! idea about what?
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:32
hmm - so this is the backend implementation in Piston: https://github.com/PistonDevelopers/piston/blob/master/src/gl_back_end.rs
@mitchmindtree o/
mitchmindtree
@mitchmindtree
Jun 20 2014 15:35
aye :sparkles:
this is cool!
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:37
^_^
@mitchmindtree you are working on a sound lib?
mitchmindtree
@mitchmindtree
Jun 20 2014 15:38
yep, on "rust-dsp" atm
(i tried for dsp.rs haha)
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:39
@mitchmindtree depending on what it turns out like, me and @photex might use it on voyager
we want some procedural sound/ambience and stuff
similar to in knytt, but in 3d :D
mitchmindtree
@mitchmindtree
Jun 20 2014 15:40
I've been trying to get a nice real-time, non-blocking audio IO going in Piston, but it's been tricky
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:41
why is that?
is that a Piston problem?
mitchmindtree
@mitchmindtree
Jun 20 2014 15:41
well, it's working fine,
the tricky part is exposing it the right way in piston
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:42
ah
see for us we would probably want a standalone thing
mitchmindtree
@mitchmindtree
Jun 20 2014 15:42
because it the callback runs at a completely different rate (samplerate / buffersize)hz to the main "Game" loop (~60hz)
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:42
something similar to gfx-rs but for sound
mitchmindtree
@mitchmindtree
Jun 20 2014 15:42
bjz yeah, this is what I'm leaning towards now
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:43
different process, with a pump for main thread stuff
mitchmindtree
@mitchmindtree
Jun 20 2014 15:43
it seems to be a bit too painful trying to get something with such low level access into piston in a way that doesn't seem to intrusive
exactly
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:44
and a handle to allow for communication from a game thread
mitchmindtree
@mitchmindtree
Jun 20 2014 15:44
haha, this is exactly what it is atm in piston
tbh, I think the only problem is that it's actually in piston, and not an external lib haha
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:44
ah
mitchmindtree
@mitchmindtree
Jun 20 2014 15:44
it would probably make more sense to have it separately anyway
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:45
the sound you mean?
mitchmindtree
@mitchmindtree
Jun 20 2014 15:45
I'm not sure how many gamedevs who use piston would need such low-level access anyway - piston already has sdl2 where you an just load in samples/sounds and play them back
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:46
ah
see I would like a high level thing with positional audio and stuff
mitchmindtree
@mitchmindtree
Jun 20 2014 15:47
rust-dsp would make it possible to have a lot lower level access, though also with high-level way of using it all too
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:47
nice
mitchmindtree
@mitchmindtree
Jun 20 2014 15:48
the reason I started it in piston is because it had everything I needed besides the audio callback, and I thought piston might need one eventually anyways
but it's starting to seem like it'll be better off as an external thing
hows gfx coming along?
@bjz how long have you been working with rust btw? you have a nice set of bindings up your sleeve!
Dzmitry Malyshau
@kvark
Jun 20 2014 15:50
@mitchmindtree gfx-rs is still too young to brag about any kind of success. We'll be able to tell more after 26th
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:51
@mitchmindtree gfx is still very early, but it is going lots faster now @kvark has started helping out
Dzmitry Malyshau
@kvark
Jun 20 2014 15:51
@bjz I really see nothing to learn from piston's GL backend. It's very custom and limited. Mine is far better, you'll see when I submit that PR with a working triangle ;)
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:52
@mitchmindtree probably been using/contributing to rust for 2 years now
mitchmindtree
@mitchmindtree
Jun 20 2014 15:52
@bjz niiicccee
@bjz have you been working in rust pretty exclusively for the last couple years? do you do any other low-level stuff in C or C++ still?
Dzmitry Malyshau
@kvark
Jun 20 2014 15:53
@bjz functions like tri_list_xy_f32_rgba_f32_uv_f32 in the back-end hurt my eyes...
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:54
@mitchmindtree the hope is that gfx will be independent of stuff like resource loading - it should be possible for us to hook up a purely procedural font end
mitchmindtree
@mitchmindtree
Jun 20 2014 15:54
@kvark agreed haha
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:54
@kvark indeed
mitchmindtree
@mitchmindtree
Jun 20 2014 15:54
@bjz that's super exciting :-)
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:54
@kvark so where would the specification of API and compatibility happen?
@kvark would that be a dynamic thing?
Dzmitry Malyshau
@kvark
Jun 20 2014 15:55
@bjz could you be a bit more specific? what API do you mean, and what side of the compatibility?
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:55
API as in gl/d3d
mitchmindtree
@mitchmindtree
Jun 20 2014 15:56
@bjz I put the generative music engine on halt a couple weeks ago to start porting it to Rust.
My C++y friends keep telling me I'm crazy
but I just keep telling them to try it before saying that... haha.
brendanzab @bjz wonders if the device could even be more decoupled, and passed in on gfx::start - dunno if that is too astronautical
Brendan Zabarauskas
@brendanzab
Jun 20 2014 15:57
@mitchmindtree you are not crazy!
:D
but I am biased :P
mitchmindtree
@mitchmindtree
Jun 20 2014 15:57
@bjz thank youuu! (that does help haha)
tbh, #rust and #rust-gamedev have helped immensely - i'm not sure if I would still be rusting if it wasn't for the awesome help on there
actually... I probably still would be. haha
Brendan Zabarauskas
@brendanzab
Jun 20 2014 16:01
whe I started there was ~100 people on #rust
:P
mitchmindtree
@mitchmindtree
Jun 20 2014 16:01
@bjz what drew you to it at first?
brendanzab @bjz has to get back to servo now - it's (:00 here
Brendan Zabarauskas
@brendanzab
Jun 20 2014 16:01
*9:00
@trevorah you can't edit /me statuses :(
@mitchmindtree wanting to do systemsy stuff in a typesafe, memory safe lang
with nice abstractive power
mitchmindtree
@mitchmindtree
Jun 20 2014 16:03
@bjz how'd you find it though?
Brendan Zabarauskas
@brendanzab
Jun 20 2014 16:03
via hacker news
mitchmindtree
@mitchmindtree
Jun 20 2014 16:03
ahh
same
Brendan Zabarauskas
@brendanzab
Jun 20 2014 16:03
@photex morning!
trevorah @trevorah is trying to edit (edited)
Andy Trevorah
@trevorah
Jun 20 2014 16:08
@bjz there is no edit button, but you can press up to edit the last message
Brendan Zabarauskas
@brendanzab
Jun 20 2014 16:09
@photex are you keeping up to date?
@trevorah oh ok, thanks
Chip Collier
@photex
Jun 20 2014 16:15
hi folks
just read the backlog
@kvark replied to your comment on the data.rs gist
tl;dr why don't we just wrap the generation and warn users that it'll happen
also, if u16 doesn't account for enough generations, we can u64 instead
users will have far bigger issues if they wrap that while holding on to a handle from a previous generation that's been invalidated
Dzmitry Malyshau
@kvark
Jun 20 2014 18:14
@photex What kind of warning do you have in mind? Just print something in the console output? Problem is that once we cross the generation boundary, the safe zone is over... One of the base principles of Rust itself is that there are no compromises - it is either safe of unsafe. So if we are following the same methodology, and we want gfx-ts to be safe... then a warning is not the solution.
@photex also, I kinda like (u16,u16) handle type, so that it fits into 4 bytes. Switching generations to u64 will make each handle to be 16 bytes most likely (4x times), and since we are gonna pass them a lot between threads, it may hurt
Brendan Zabarauskas
@brendanzab
Jun 20 2014 18:19
where was @photex's comment?
Dzmitry Malyshau
@kvark
Jun 20 2014 18:19
@photex the good about the solution I propose is that while still having 4 bytes per handle, we can safely allocate 4 billion times (each id that runs out of generations becomes blocked, so the other ones are used)
@bjz see comments to data.rs
Dzmitry Malyshau
@kvark
Jun 20 2014 18:29
@bjz how would checked arithmetic help here?
Brendan Zabarauskas
@brendanzab
Jun 20 2014 18:30
"To be completely pedantic... we need to make sure the generation doesn't overflow"?
Dzmitry Malyshau
@kvark
Jun 20 2014 18:33
@bjz so you are in favor of simply crashing when we get out of generations (for a single handle)? that is more or less within Rust philosophy, but I think we can do better
Brendan Zabarauskas
@brendanzab
Jun 20 2014 18:33
no idea
the checked arithmetic operators return options
just a thought is all
Dzmitry Malyshau
@kvark
Jun 20 2014 18:35
@bjz checked arithmetic or not is an implementation detail. The main question is - how do we resolve the generation overflow. My proposal is to permanently ban the handle once it's generations are over.
Brendan Zabarauskas
@brendanzab
Jun 20 2014 18:35
interesting
yeah that might be best
and you mean to force the creation of a new handle?
brendanzab @bjz wonders what would gw do
Brendan Zabarauskas
@brendanzab
Jun 20 2014 18:37
:P
Dzmitry Malyshau
@kvark
Jun 20 2014 18:37
let's summon @gw!
Brendan Zabarauskas
@brendanzab
Jun 20 2014 18:38
he is aussie - it's 4:30am on Saturday
heh
btw, you mean @glennw
Dzmitry Malyshau
@kvark
Jun 20 2014 18:41
@bjz applied to the EntityData implementation in the shelve, my idea would be to not remove the handle from data if the generations are over. Keep it there - we'll always be able to check if it's actually invalid by looking at the generation count
Dzmitry Malyshau
@kvark
Jun 20 2014 18:48
@bjz @photex does that make sense? I think it's almost a steal for what we get in return ;)
Brendan Zabarauskas
@brendanzab
Jun 20 2014 18:52
seems pretty good
photex will know better though
the generation count reminds me of a counting bloom filter
actaully no
hmm
mitchmindtree
@mitchmindtree
Jun 20 2014 18:59
@bjz REAL aussies are still up at 5am
... or maybe just crazy ones shifty eyes
Brendan Zabarauskas
@brendanzab
Jun 20 2014 19:02
oh wait, you are an aussie too
I am an aussie in SF :D
mitchmindtree
@mitchmindtree
Jun 20 2014 19:03
when do you finish your internship over there?
you think you will stay in SF?
kvark @kvark is curious if Mozilla pays for internship and/or providing the apartment to live in
mitchmindtree @mitchmindtree is also curious
Brendan Zabarauskas
@brendanzab
Jun 20 2014 19:08
@kvark both
Dzmitry Malyshau
@kvark
Jun 20 2014 19:09
@bjz that's a contract then... dunno why they call it internship
@mitchmindtree you got a nice website
Brendan Zabarauskas
@brendanzab
Jun 20 2014 19:09
shhhh - I am learning. :)
Dzmitry Malyshau
@kvark
Jun 20 2014 19:10
ah, so tax evasion? understood
brendanzab @bjz goes to lunch
mitchmindtree
@mitchmindtree
Jun 20 2014 19:10
@kvark thanks! It's definitely due for an update
@kvark I like your dp btw :-)
GITS 4evaaa
I made a tune super inspired by gits a while ago!
A friend did a film clip for it http://vimeo.com/41616720
woah, didn't expect that haha
anyways, it's littered with samples from the anime
Dzmitry Malyshau
@kvark
Jun 20 2014 19:14
@mitchmindtree haha, glad you recognized it! nice movie as well :)
Chip Collier
@photex
Jun 20 2014 19:14
@kvark the big reason I don't want to just disable a cell is that if you have some problem with generations overflowing you can effectively DOS the engine
which seems unlikely to be done without purpose
you're also introducing memory fragmentation
which defeats the whole purpose
the warning I referred to was just in the documentation
not a runtime log or anything
just explaining the caveat
I don't think it's particularly safe or unsafe either way honestly
you're handle is either valid or not
the bigger problem with this is handle invalidation
if you remove it, it's swaps with the item on the end
which invalidates any handles for that last item
the molecular musings post touches on a solution for that
but I hadn't really grokked it
Dzmitry Malyshau
@kvark
Jun 20 2014 19:21
@photex I read it yesterday, and didn't see a solution outside of just "please be careful to not overflow"
also, let's structurize your points. Here is what I see:
  1. DoS possibility
  2. memory fragmentation
  3. you don't think it solves anything
is that a correct recap?
Chip Collier
@photex
Jun 20 2014 19:22
yep, but add 4) I honestly don't mind your solution. I'm just making sure we discuss it (helps me understand everything)
Dzmitry Malyshau
@kvark
Jun 20 2014 19:28
@photex ok, so let's go through the points:
  1. I don't see why anyone would want to do that. Device is not exposed to the network, so we can assume whoever works with it is trusted
  2. could you explain this bit? AFAIK, my solution covers that 1% of usecases where we alternatively either crash or go unsafe. Even if memory gets fragmented, it's an exception case and we can live with it
  3. pretty much explained it in 2.
  4. sure, no worries! I might be easily missing bits myself too
Chip Collier
@photex
Jun 20 2014 19:29
  1. If the argument is about safety, then disabling a cell is certainly unsafe vs a generation overflow (my opinion).
  1. when a generation is maxed and you can't add a new item in it's place, now you have a cell that is going to have to be skipped.
oops, that should be 2.
that's it. I think operationally it seems rare, but the engine data wasn't entirely meant to be used behind the scenes
I had anticipated it's use in game threads, scene graphs, etc
multi-line
ahh ok Shift-Enter
Dzmitry Malyshau
@kvark
Jun 20 2014 19:50
@photex
  1. why is disabling unsafe? EntityData may guarantee that nothing tries to use that handle
  2. for all managing purposes, this handle is going to behave as being already used. I don't see any overhead of this in the code. Where do you see it being skipped exactly?
Chip Collier
@photex
Jun 20 2014 19:52
if you delete an item, generation is incremented, if it reaches LAST_GENERATION then from that point forward, the cell this relates to is no longer able to be used
so when iterating over the collection, you now have to check for a generation that equals LAST_GENERATION
if it does, then this is a disabled cell, so we skip it
did I misunderstand this?
Dzmitry Malyshau
@kvark
Jun 20 2014 19:54
@photex that's correct, yes, but when are you going to actually iterate the valid handles? I don't see it in your code.
Chip Collier
@photex
Jun 20 2014 19:54
you would presumably be iterating over the data that the handle refers to
now you have to include the handle generations in that work
this code wasn't entirely worked out either :)
Dzmitry Malyshau
@kvark
Jun 20 2014 19:56
@photex wait, wait. "iterating over the data that the handle refers to"?
Each handle has 1 data associated. What iteration do you mean exactly?
Chip Collier
@photex
Jun 20 2014 19:58
well, these handles are related to a Vector, when a system in the game performs it's update loop it's over that Vector
the iterator hasn't been implemented yet
Chip Collier
@photex
Jun 20 2014 20:05
lunch time :)
Dzmitry Malyshau
@kvark
Jun 20 2014 20:07
@photex oh well, so you are describing something outside of the code... I'll need to see that to understand. Perhaps, @bjz knows better what you have in mind?..
My understanding is that nothing (outside of, possibly, some debug functionality) will need to iterate the valid handles (where different types of handles are used for, to say, vertex buffers, shaders, meshes, materials, etc). The game (or for some handles - the render thread) keeps track of the handles it uses, and iterates over its own structures.
Chip Collier
@photex
Jun 20 2014 21:13
nothing will iterate the handles
but they will iterate what the handles point to
if you can't make a new handle
then you can't effectively make a new item in the collection
anyway, there is clearly a problem with this design. Perhaps we should redesign it from first principles
Brendan Zabarauskas
@brendanzab
Jun 20 2014 21:19
so what is the problem?
this is with the data-oriented way of doing things?
Dzmitry Malyshau
@kvark
Jun 20 2014 21:46
@photex could you explain it on an example with a particular handler type?
@cmr ohi!
Brendan Zabarauskas
@brendanzab
Jun 20 2014 21:56
@cmr o/
@cmr: still keeping this pretty quiet seeing as we have lots still to figure out
Dzmitry Malyshau
@kvark
Jun 20 2014 22:13
@bjz I'm trying to get what's the problem with my proposal according to @photex , and so far it seems that I misunderstand the whole concept of handler management.
Brendan Zabarauskas
@brendanzab
Jun 20 2014 22:19
@photex do you think this is something we can re-engineer later? It would be awesome just to get something rendering. I know this is pretty fundemental though.
@kvark gw might be on IRC soon
@kvark perhaps you could ask him - he has tons of experience with this design
Dzmitry Malyshau
@kvark
Jun 20 2014 22:21
@bjz ok, will try to catch him
@bjz btw, the whole handler management thing is not required to get something rendering
Brendan Zabarauskas
@brendanzab
Jun 20 2014 23:18
@kvark I reckon just implement something then we can squabble over it in a PR :)
It will probably be easier with something more concrete
Dzmitry Malyshau
@kvark
Jun 20 2014 23:21
@bjz you know, I'm on my way to it...
Brendan Zabarauskas
@brendanzab
Jun 20 2014 23:27
:D
sorry
Dzmitry Malyshau
@kvark
Jun 20 2014 23:30
@bjz it's cool, I understand your position