VoxelWar Discussion thread

[Mr.Torch]

Ye, I don't hate OS, it's just that voxlap appeals to me because it can run on a shitty PC. (Mine)

Just make the goal of this client to run faster than the original on old PCs. :)
(Might never reach it, but you'll have a great client)

[LeCom]

Well, the Voxlap port is slower than the original Voxlap right now, but the advantage over the old Voxlap is that you can actually edit it without fucking it all up, and add stuff or change it. However, the pure Voxlap still runs with a framerate similar to .75, because the font renderer in .75 is a piece of slow crap 8-) (this is also the reason why .76 has a better framerate).
But there's a lot I can change, to increase its speed. I just don't care that much about performance yet, as there are more important things, and it is still able to run with 60 FPS on semi-modern PCs that get a shitty framerate on openspades. Later, it will be possible to rewrite it in ASM, which will make it a lot faster, but I guess that somebody else will have to do it, as I never learned ASM. When it's worth rewriting pieces in ASM, I think it will already be quite popular.

Oh, and for a game like this, good client performance should be one of the biggest targets for every good programmer.

Concerning graphics/progress, I think I'm going to keep this for a while:

perpixelshading_2.png (98.36 KiB) Viewed 11949 times

Note that I started with Voxlap's C renderer, which couldn't render any shades at all, so I'm kinda finished with voxels for now. I'm emphasizing on kv6/sprites rendering, as it is essential for any kind of client. I had some progress, it can put a 2D sprite into the world and kinda render it, but there are still some problems with math, distance, voxel overlapping etc.

[Spidercooce]

You should focus a bit more on better framerate as one of the appeals of .Voxlap is that it can run on your grandma's rig.

But awesome work! if I had money I would donate :)

Edit: In the final version add the option to disable good shading and lower the graphics.

[VladVP]

If everything else fails, we might as well use GPU acceleration. It didn't make sence in the last millenium, when Voxlap was made, but practically every single piece of crap that can be called a computer has it today.

Also, I love the shading you've implemented to the sides of voxels, but it's probably no good in the future. If we really want the OpenSpades look, we need polygon-like interpolation, mapping of textures to voxels and a shading engine that doesn't look like the ancient egyptians wrote it.

If you need impromptu help with optimisaton and assembly I can send you my Skype account name. I am pretty much online there 24/7.

[LeCom]

You should focus a bit more on better framerate as one of the appeals of .Voxlap is that it can run on your grandma's rig.

But awesome work! if I had money I would donate :)

Edit: In the final version add the option to disable good shading and lower the graphics.

Right now I focus on making it draw any kind of kv6 cause it can't do that yet :P
Then comes speed,
Then maybe improve the graphics even more, although I think what I have here is enough.

If everything else fails, we might as well use GPU acceleration. It didn't make sence in the last millenium, when Voxlap was made, but practically every single piece of crap that can be called a computer has it today.

If you mean something like opengl, look at how shitty openspades works. You know how Voxlap works, and I'm sure you know how OpenGL's 3D rendering works, so you should know why OpenGL is definitely not suitable for rendering voxels. The only thing I could imagine the GPU being good for is anti-aliasing the whole screen after Voxlap rendered its part (which would make a lot of sense, since software anti-aliasing would reduce FPS from 60 to 1). Maybe it could accelerate fog, if it is able of blitting an RGB image on the screen with an external alpha buffer? Voxel rendering is one of the last things that even today the CPU does better than the GPU, but it still IS the case.

Also, I love the shading you've implemented to the sides of voxels, but it's probably no good in the future. If we really want the OpenSpades look, we need polygon-like interpolation, mapping of textures to voxels and a shading engine that doesn't look like the ancient egyptians wrote it.

Ehhhhh I never planned to go that far. What I did is just some *optional* eye candy to make it look a bit better than Voxlap, it's really only some kind of experimental toy. Best is to emphasize on performance and on reducing rendering bugs.

If you need impromptu help with optimisaton and assembly I can send you my Skype account name. I am pretty much online there 24/7.

You're probably Mandarine from #homo IRC, aren't you? If I need help, I will query you :)

[bloodfox]

Well, the Voxlap port is slower than the original Voxlap right now, but the advantage over the old Voxlap is that you can actually edit it without fucking it all up, and add stuff or change it. However, the pure Voxlap still runs with a framerate similar to .75, because the font renderer in .75 is a piece of slow crap 8-) (this is also the reason why .76 has a better framerate).
But there's a lot I can change, to increase its speed. I just don't care that much about performance yet, as there are more important things, and it is still able to run with 60 FPS on semi-modern PCs that get a shitty framerate on openspades. Later, it will be possible to rewrite it in ASM, which will make it a lot faster, but I guess that somebody else will have to do it, as I never learned ASM. When it's worth rewriting pieces in ASM, I think it will already be quite popular.

Oh, and for a game like this, good client performance should be one of the biggest targets for every good programmer.

Concerning graphics/progress, I think I'm going to keep this for a while:

perpixelshading_2.png

Note that I started with Voxlap's C renderer, which couldn't render any shades at all, so I'm kinda finished with voxels for now. I'm emphasizing on kv6/sprites rendering, as it is essential for any kind of client. I had some progress, it can put a 2D sprite into the world and kinda render it, but there are still some problems with math, distance, voxel overlapping etc.

Infact, I would love it if you kept it like that! :D

[VladVP]

If everything else fails, we might as well use GPU acceleration. It didn't make sence in the last millenium, when Voxlap was made, but practically every single piece of crap that can be called a computer has it today.

If you mean something like opengl, look at how shitty openspades works. You know how Voxlap works, and I'm sure you know how OpenGL's 3D rendering works, so you should know why OpenGL is definitely not suitable for rendering voxels. The only thing I could imagine the GPU being good for is anti-aliasing the whole screen after Voxlap rendered its part (which would make a lot of sense, since software anti-aliasing would reduce FPS from 60 to 1). Maybe it could accelerate fog, if it is able of blitting an RGB image on the screen with an external alpha buffer? Voxel rendering is one of the last things that even today the CPU does better than the GPU, but it still IS the case.

I don't think you are realising the capabilities of a GPU. Despite the name and intent, it is able to carry out advanced MIMD operations much much faster than a CPU can. Why do you think they build supercomputers exclusively out of GPU parts and crypto brute-force software usually runs on the GPU? The only minus is that it takes time to carry over instructions and data to the GPU, so you usually only do it if there is a lot of data to process, or the process itself is very tedious and complex. But this fits perfectly in our case. This can potentially boost performance tenfold on faster systems.

If you need impromptu help with optimisaton and assembly I can send you my Skype account name. I am pretty much online there 24/7.

You're probably Mandarine from #homo IRC, aren't you? If I need help, I will query you :)

Well, I am on freenode most of the time, so chances are that I won't notice you at all. However I can guarantee that you will receive an answer on Skype.

[LeCom]

Ah kk, so you mean abusing the GPU as a CPU, not using the GPU's rendering algorithms for drawing voxels. That's something different, indeed.
Well, I don't really know much about that; how useful it could be depends on what the GPU can do. In general, usually many games have problems with GPUs not supporting a super new command used in the game(the reason why openspades with OpenGL doesn't run on many PCs at all), so adding complex stuff that depends on special commands might be a problem.
However, I had the idea of moving the shading code from gline to hrend, so a lot of slow stuff is on 1 small spot, which would make accelerating measures, like SIMD or your idea, more effective and easy to add. The slowest functions are hrend****, gline and dmulrethigh, (whose bit shift is useless btw and the subtraction can be replaced by a comparison), others don't matter; dmulrethigh in gline can be replaced by prediction, so we can almost cross both out, leaving hrend**** 's RGB pixel operations as the worst performance eater. GPU commands probably could be added, but I think that SSE would accelerate the Voxlap rendering quite a lot (as SIMD is the best to accelerate RGB commands), and every old rig has SSE. As I said, maybe it's possible to use it for screen anti-aliasing.
Oh, one important thing you are probably forgetting is that modern PCs that support such GPU stuff already achieve a very good performance on .75, just because technology improved over time, especially RAM. DDR3 probably can double the framerate compared to DDR2.

Right now, I really only have one important question that I can't answer on myself: Wtf does drawboundcube do? Or at least, how does it find out the x and y screen position, or the x, y and z position of the kv6 voxel?

[VladVP]

Ah kk, so you mean abusing the GPU as a CPU, not using the GPU's rendering algorithms for drawing voxels. That's something different, indeed.
Well, I don't really know much about that; how useful it could be depends on what the GPU can do. In general, usually many games have problems with GPUs not supporting a super new command used in the game(the reason why openspades with OpenGL doesn't run on many PCs at all), so adding complex stuff that depends on special commands might be a problem.
However, I had the idea of moving the shading code from gline to hrend, so a lot of slow stuff is on 1 small spot, which would make accelerating measures, like SIMD or your idea, more effective and easy to add. The slowest functions are hrend****, gline and dmulrethigh, (whose bit shift is useless btw and the subtraction can be replaced by a comparison), others don't matter; dmulrethigh in gline can be replaced by prediction, so we can almost cross both out, leaving hrend**** 's RGB pixel operations as the worst performance eater. GPU commands probably could be added, but I think that SSE would accelerate the Voxlap rendering quite a lot (as SIMD is the best to accelerate RGB commands), and every old rig has SSE. As I said, maybe it's possible to use it for screen anti-aliasing.
Oh, one important thing you are probably forgetting is that modern PCs that support such GPU stuff already achieve a very good performance on .75, just because technology improved over time, especially RAM. DDR3 probably can double the framerate compared to DDR2.

I didn't say we had to use it. I said that we could use it as a last resort if everything else fucks up in terms of performance.

Right now, I really only have one important question that I can't answer on myself: Wtf does drawboundcube do? Or at least, how does it find out the x and y screen position, or the x, y and z position of the kv6 voxel?

Listen, when you stumble upon someone else's code that is impossible to understand, you rewrite the shite. No bullshit. If you are confused about how something works, try converting the assembly to pseudocode function consisting of consistent expressions. Trust me, as long as you know what the inputs represent, it becomes fully clear what exactly it does.

[LeCom]

[9th Juny]

Ah kk, so you mean abusing the GPU as a CPU, not using the GPU's rendering algorithms for drawing voxels. That's something different, indeed.
Well, I don't really know much about that; how useful it could be depends on what the GPU can do. In general, usually many games have problems with GPUs not supporting a super new command used in the game(the reason why openspades with OpenGL doesn't run on many PCs at all), so adding complex stuff that depends on special commands might be a problem.
However, I had the idea of moving the shading code from gline to hrend, so a lot of slow stuff is on 1 small spot, which would make accelerating measures, like SIMD or your idea, more effective and easy to add. The slowest functions are hrend****, gline and dmulrethigh, (whose bit shift is useless btw and the subtraction can be replaced by a comparison), others don't matter; dmulrethigh in gline can be replaced by prediction, so we can almost cross both out, leaving hrend**** 's RGB pixel operations as the worst performance eater. GPU commands probably could be added, but I think that SSE would accelerate the Voxlap rendering quite a lot (as SIMD is the best to accelerate RGB commands), and every old rig has SSE. As I said, maybe it's possible to use it for screen anti-aliasing.
Oh, one important thing you are probably forgetting is that modern PCs that support such GPU stuff already achieve a very good performance on .75, just because technology improved over time, especially RAM. DDR3 probably can double the framerate compared to DDR2.

I didn't say we had to use it. I said that we could use it as a last resort if everything else fucks up in terms of performance.

Yeah, you're right. I must have forgot that you only want it as a last option, sorry.

Right now, I really only have one important question that I can't answer on myself: Wtf does drawboundcube do? Or at least, how does it find out the x and y screen position, or the x, y and z position of the kv6 voxel?

Listen, when you stumble upon someone else's code that is impossible to understand, you rewrite the shite. No bullshit. If you are confused about how something works, try converting the assembly to pseudocode function consisting of consistent expressions. Trust me, as long as you know what the inputs represent, it becomes fully clear what exactly it does.

Well, I have absolutely no experience with ASM. I could try reverse-engineering "normal" x86 assembly, but more than half of that function is using MMX/SSE commands, and reverse-engineering SIMD is harder. Also, my problem IS that I don't know what every input should be; I know what the arguments are for, however, it is accessing weird global arrays whose entries seem to represent something different each. It's actually possible to understand how Voxlap works, as long as it's written in C.
But you can kinda forget that crap, I just wrote a function that draws a pixel for every block of a kv6 sprite (from one side, no rotation), so it's possible to access the kv6 voxel data. I think it's better to write my own kv6 raycaster, than trying to get that half working shit running. That may be a bit slower and look crappy, but it might be possible to improve it.

_____________________________________________________________________________________________________________
[10th Juny]

***Progress***
Ok, so I made it render KV6, but it is still far from being ready.

KV6_Renderer.png (51.1 KiB) Viewed 11853 times

I have to add KV6 rotation (some math shit), and make it not render blocks that are behind other blocks (you see a grey line in the intel, which actually shouldn't be rendered). It's actually not as slow as I thought, even that version, which is supposed to be extremely slow, and it looks as good (I mean bad) as Voxlap's kv6 renderer ^^

[VladVP]

T-that's actually impressive. Good fucking job. Perhaps this is where we should start applying the interpolation magic, to achieve the OpenSpades look. Okay, I am all in, put up a repo and I'll start contributing as soon as I can.

[bloodfox]

so did you just make an intel sprite?

[VladVP]

so did you just make an intel sprite?

No, Voxlap renders kv6 files by generating 2-dimensional sprites and rendering them onto the screen. This is also why falling objects look so odd in the game.

[Zekamalikyd]

when's Juny?

[bloodfox]

now