so, two-week project reportback
this time: render buffers. as i mentioned last time i'd been kinda circling around rendering problems for a while, and in december i'd spent some time writing
so uh the first week or so was spent working on that: i wrote new code that manually allocated a 'chunk' of heightmap data and stored that, rather than having a haskelly data structure. i also decided to try overallocating space for buffers so i could statically index their values -- basically certain parts of the world geometry might be 0 vertices, as in they might not exist at all, or they might be 4, or 8, or 12 vertices. allocating the correct value for each one would make the math a lot more complicated, so instead i'm allocating space for 12 vertices for every piece, even if the actual map doesn't use it at all, because then if i want to look up "where is this chunk of world geometry stored in the buffer" it's just a matter of counting out however many 12-vertex chunks come before it, instead of having a big lookup table.
so i did that and performance increased drastically. instead of the program taking up a ~2gb allocation to render 7 chunks, it took up ~200mb. increasing that to 37 chunks only bumped that up to ~250mb, so presumably a lot of that is just general haskell allocation. it also runs faster, since, all that allocation it was doing took time.
this is kind of wild -- like, i knew haskell allocation wasn't really very fast, but it's still pretty wild to see a 10x improvement just from switching to a simpler allocation model.
steps in redoing the render buffer:
at first i tried only rendering hexes
then i moved on to hexes and tris
then joins
then i actually calculated out tri values correctly
and then finally i got tri values calculating across 'chunk' edges so that there weren't big visible seams
this code is still pretty basic and i haven't ported over a bunch of stuff that was in the older code yet, most notably slopes, and i didn't get around to writing up the code that would actually update chunk height data + rerender hexes, which is the big thing that i'd have to do if i want to actually use this code to, you know, deform the landscape or w/e. still, this is a pretty big chunk of work.
i kinda squandered the latter half of this project, and that's because uhhh a few days ago i finally released the big twine game i've been working on for the past two years. kinda burying the lede here. so that's out! check it out! but also kinda obsessing about its release made me incapable of focusing on doing the nitty-gritty work of fixing up some buffer indexing code, so, i didn't actually get a huge amount of stuff done for this 2-week project.
still calling it a success though, because, wow 10x improved memory allocation.
this time: render buffers. as i mentioned last time i'd been kinda circling around rendering problems for a while, and in december i'd spent some time writing
Storable instances for heightmap data.so uh the first week or so was spent working on that: i wrote new code that manually allocated a 'chunk' of heightmap data and stored that, rather than having a haskelly data structure. i also decided to try overallocating space for buffers so i could statically index their values -- basically certain parts of the world geometry might be 0 vertices, as in they might not exist at all, or they might be 4, or 8, or 12 vertices. allocating the correct value for each one would make the math a lot more complicated, so instead i'm allocating space for 12 vertices for every piece, even if the actual map doesn't use it at all, because then if i want to look up "where is this chunk of world geometry stored in the buffer" it's just a matter of counting out however many 12-vertex chunks come before it, instead of having a big lookup table.
so i did that and performance increased drastically. instead of the program taking up a ~2gb allocation to render 7 chunks, it took up ~200mb. increasing that to 37 chunks only bumped that up to ~250mb, so presumably a lot of that is just general haskell allocation. it also runs faster, since, all that allocation it was doing took time.
this is kind of wild -- like, i knew haskell allocation wasn't really very fast, but it's still pretty wild to see a 10x improvement just from switching to a simpler allocation model.
steps in redoing the render buffer:
at first i tried only rendering hexes
then i moved on to hexes and tris
then joins
then i actually calculated out tri values correctly
and then finally i got tri values calculating across 'chunk' edges so that there weren't big visible seams
this code is still pretty basic and i haven't ported over a bunch of stuff that was in the older code yet, most notably slopes, and i didn't get around to writing up the code that would actually update chunk height data + rerender hexes, which is the big thing that i'd have to do if i want to actually use this code to, you know, deform the landscape or w/e. still, this is a pretty big chunk of work.
i kinda squandered the latter half of this project, and that's because uhhh a few days ago i finally released the big twine game i've been working on for the past two years. kinda burying the lede here. so that's out! check it out! but also kinda obsessing about its release made me incapable of focusing on doing the nitty-gritty work of fixing up some buffer indexing code, so, i didn't actually get a huge amount of stuff done for this 2-week project.
still calling it a success though, because, wow 10x improved memory allocation.
