Re: SCP-860 implementation list + discussion
Posted: Tue Dec 24, 2013 7:45 am
As promised here's the writeup. Wall of text incoming:
I'm gonna assume you know how to replicate risingstar's step algorithm in B3D, just make sure the tile values are stored in a dim array. I can't remember what Miro wanted it seeded to, but it shouldn't change too much.
Like the Pocket Dimension and other non-seeded rooms, stick the forest at the edge of the room array (can't remember what it was called, just follow Regalis' pattern and it should be fine) When you add the room to the FillRoom function, load each asset into the room's objects array, and hide them.
As for tile generation, I used event state as a global timer, and the remaining 2 event states as tile coordinates. So basically, every few frames or so, read from the forest dim array, copy the appropriate mesh from the room's object array, enable collision, do other stuff to the tile, place tile at an awkward positive Y coordinate to prevent clipping into the PD, increment stuff, and continue until the forest is finished. When the player leaves the forest you can just re-initialize the dim array(s) to delete everything. (You should probably define tile as a type and store them in dims so you can keep track of how many trees/other stuff there are per tile and use the index to appropriately hide stuff. I was going to do this to fix stuff, but never got around to it)
During generation, the GPU doesn't take that great of a hit in performance. The greatest drop anyone's ever recorded was an average of 1-2 FPS, so you don't need to worry about how often or when the forest generates a tile.
My optimization code was pretty meh, it was incredibly sloppy in order to get a quick release within a few days or so. (Ironic, isn't it?) Apparently, B3D's renderer isn't that effective at hiding things that aren't in the camera's range, so I had to do that manually. (Again, if you index tiles and their contents, this is much easier on the CPU as you can just use the player's position) Tree's are pretty simple, just slap em' on the tile however you wish. Same for rocks. I can't exactly remember how I got the leaves to work, but I'm pretty sure I made them separate from the trees, though, that could just be because I have no idea how to export stuff with fragmotion. I never really got Miro's grass to work well up close due to B3D's renderer doing weird things over the Z axis. I only ever got two benchmark reports, so I didn't have a very accurate depiction as to how optimized the entire thing was. But from what I've seen, the GPU takes a pretty heavy load when I introduce leaves to the forest. I still have no idea why this is, but my guess is that the renderer doesn't like rendering too many alpha textures.
We never really did anything with the monster, and I don't know if the concept is even finalized, but I'd recommend against using A* or an equivalent algorithm for movement. It just doesn't feel worth it with the lack of complexity it's design currently has. That and just remember to load all the data for it when the game starts, rather than when the forest generates.
So that's basically what I did with the forest, everything else was really easy or was for dev purposes.
If something doesn't make sense or I forgot something, let me know.
Good luck.
oyea, risingstar said he might work on it, which is pretty cool.
[insert skeptical comment about how this project will never be finished because nobody bothers to keep interest in it longer than a week here]
I'm gonna assume you know how to replicate risingstar's step algorithm in B3D, just make sure the tile values are stored in a dim array. I can't remember what Miro wanted it seeded to, but it shouldn't change too much.
Like the Pocket Dimension and other non-seeded rooms, stick the forest at the edge of the room array (can't remember what it was called, just follow Regalis' pattern and it should be fine) When you add the room to the FillRoom function, load each asset into the room's objects array, and hide them.
As for tile generation, I used event state as a global timer, and the remaining 2 event states as tile coordinates. So basically, every few frames or so, read from the forest dim array, copy the appropriate mesh from the room's object array, enable collision, do other stuff to the tile, place tile at an awkward positive Y coordinate to prevent clipping into the PD, increment stuff, and continue until the forest is finished. When the player leaves the forest you can just re-initialize the dim array(s) to delete everything. (You should probably define tile as a type and store them in dims so you can keep track of how many trees/other stuff there are per tile and use the index to appropriately hide stuff. I was going to do this to fix stuff, but never got around to it)
During generation, the GPU doesn't take that great of a hit in performance. The greatest drop anyone's ever recorded was an average of 1-2 FPS, so you don't need to worry about how often or when the forest generates a tile.
My optimization code was pretty meh, it was incredibly sloppy in order to get a quick release within a few days or so. (Ironic, isn't it?) Apparently, B3D's renderer isn't that effective at hiding things that aren't in the camera's range, so I had to do that manually. (Again, if you index tiles and their contents, this is much easier on the CPU as you can just use the player's position) Tree's are pretty simple, just slap em' on the tile however you wish. Same for rocks. I can't exactly remember how I got the leaves to work, but I'm pretty sure I made them separate from the trees, though, that could just be because I have no idea how to export stuff with fragmotion. I never really got Miro's grass to work well up close due to B3D's renderer doing weird things over the Z axis. I only ever got two benchmark reports, so I didn't have a very accurate depiction as to how optimized the entire thing was. But from what I've seen, the GPU takes a pretty heavy load when I introduce leaves to the forest. I still have no idea why this is, but my guess is that the renderer doesn't like rendering too many alpha textures.
We never really did anything with the monster, and I don't know if the concept is even finalized, but I'd recommend against using A* or an equivalent algorithm for movement. It just doesn't feel worth it with the lack of complexity it's design currently has. That and just remember to load all the data for it when the game starts, rather than when the forest generates.
So that's basically what I did with the forest, everything else was really easy or was for dev purposes.
If something doesn't make sense or I forgot something, let me know.
Good luck.
oyea, risingstar said he might work on it, which is pretty cool.
[insert skeptical comment about how this project will never be finished because nobody bothers to keep interest in it longer than a week here]