Would the best way to test the game on multiple cards not be to have a release with 'Please report bugs on this forum topic:' followed by the link to here, on the bottom of the top screen? And put the same in the download description.
My point along with most people biting our nails off waiting for a release is that we dont mind if it is glitchy or slow, we (me at least
) really just want to play the game!
And so i BEG you...please give us an update version. It will be like Aperture Labretories, testing made fun
So dont do a Glados and do release it! Please.
No, it's not that easy, it's just not how it works. I need some very specific data, and the builds I need tested are potentially unstable/dangerous for the filesystem (hopefully not, but you never know). I can't just release something like that in the wild and hope for the best; no matter how many warnings I put, most people won't read them. Same goes for that data I need, you can bet almost none of the people who try it will actually report back, and of those who do only a few will give enough detail for it to be useful.
So no, there won't be any public releases until everything's been tested and fixed, and begging's not going to change that, sorry.
lucasade said:
On a different note: the water spreading system. Is it possible to check for bricks on each face of a water block. If water is detected, it can stop bothering to check that face ever again, but if something else is detected, it will scan it.
However, if no brick is detected, the game will create a water block on the corresponding face.
As for when it should scan for changes, i think a good idea is check if player is in proximity/close enough to actually modify a brick that would affect the water. That should reduce lag surely.
Thanks for trying to help me, but it's not that easy.
I can't go scanning all blocks every frame for something like that. Do you have any idea how slow that would be ?
The most viable option would be scanning the blocks when I stream them in, then make list them and then process them individually on a frame by frame basis. Unfortunately, this would end up requiring loads of memory and at least *some* processing power to get working. (basically what I'd be doing is a spread algorithm, so that list would by all accounts be growing exponentially)
Of course this could be solved by simply limiting how far the water can spread. But that brings another problem, how do I store such data ? I can't make the map files any bigger (well, I can't make each individual block cluster column any bigger), so I can't store any more information than I already am. An idea I had was to make different water blocks, each with a different "spreading factor" (I actually had this idea just now, as I was typing this
), this way I wouldn't need to store any extra data, but I'm not sure this would reduce the memory requirements enough in extreme situations.
So in short : maybe, I'll have to run some tests.
QUOTE(Sir_Voe @ Aug 4 2011, 02:01 AM)