VoxelWar Discussion thread

[LeCom]

People liked AoS because it boiled the ideas of voxel FPS down to the core: buld then snip.

Themes in some shooters (like WW2 or WW3) can often obstruct gameplay, to the point that players can't be creative with the game because all of the game's content pertains to that specific style. (TF2 actually tries to get around this despite its '60s style.)

How AoS was "marketed" was pretty simple: here's the download, here's the server list, now go play. The trailer's just gameplay, what'd you expect.
How AoS+ was marketed, though, was more of meta-creativity: the game explicitly instructed you to "be creative." For some reason this idea of telling people to be creative seems to be an increasingly popular marketing scheme. And many people just don't like being told to do things.

So if you want to compete, it's because you can bring the voxel genre all the way down, back to the fundamentals.
And if you can manage to do that plz add buttons and elevators ok thanks

@Basic gameplay: You have a point, indeed. However, there's already a very simple voxel FPS, and it's dying atm. Moreover, I tried to imply that the changes should be very small, exactly for the purpose of strategic creativity. I could say that "back to the roots" is the opposite of getting out of this overpopulated niche, but then there's no game that resembles the old AoS version, so no idea.
@Themes: The best thing is just to leave it to the servers, just like the game modes and maps.
@Marketing: I can't say how negative being told to do what you want is, I'm not a psychology expert. Though what I can say is that AoS 1.0 wants you to be creative when there's not much to be creative about lol. It's like AoS 0.75 zombies: if the enemy can fly anywhere or nuke your whole castle, there's no point in building anything. Yeah, that again concerns your argument of game simplicity.

@bloodfox: No, the voxel + fps combination is a beautiful thing I wouldn't want to discard. And about the CoD part: One can just open a server with CoD theme (it's obvious that an AoS successor just HAS to add custom models on servers, at least) and then do the gameplay video on that. That wouldn't even be fraud, since there actually would be such a server in that case :P

[longbyte1]

Putting themes on servers rather than the game as a whole is exactly my point! But in order to do this, the game needs to have a solid framework that gives power to the community, not to the developer.

AoS's mistake was that we depended on Aksoy to give us monthly updates, hopefully balancing whatever we wanted to balance or fixing X issue. And if he didn't then we just complained more until he responded. But AoS's main problem is the limited net protocol. For the server to make and break blocks we have to pretend that somebody invisible is doing it, block by block. We can't use RLE/zlib to communicate big changes on the map without forcing a reload. We cannot make things move smoothly or click on blocks to interact with the map. We also don't really have a say in the specific parameters of the client, such as custom weapon models, ammo, speed, and loadout.

So then why doesn't Iceball fit our needs? Here's where it falls short:

• Hardly any public face; more effort seems to be placed on the open-source end of the project than actually campaigning to get people to play the game. 1000+ commits but no player base?
• Ugly. Now this seems like a subjective point but it's awfully true. It still looks unfinished.
• Server still doesn't give clients resources.
• GPL.

Can we ever get people to play Iceball and overcome these problems?
Or should we start all over again?

[bloodfox]

Iceball is lub. iceball is life <3.
but tbh, as much as I love that shit, staying with it won't work. approach a new idea without that fucking dumbass idea of making it a voxel FPS

[LeCom]

Oh good then I'm not the only one seeing faults in the development of IB (not saying that it's crap though). GM and his team just have wrong priorities. They seem to emphasize on miscellaneous or unimportant things, while IB itself has nothing to offer as a game. It's more like a game engine, but very complex and hard to mod.

[Warp]

Oh good then I'm not the only one seeing faults in the development of IB (not saying that it's crap though). GM and his team just have wrong priorities. They seem to emphasize on miscellaneous or unimportant things, while IB itself has nothing to offer as a game. It's more like a game engine, but very complex and hard to mod.

I think that's right, well put. Complex and Hard to mod is definetly a issue when someone doesn't have much experience with things.

[jadedctl]

Anyone happen to have a copy of VoxelWar's source?
It looks like the forums and site are down....

[Icarus North]

Anyone happen to have a copy of VoxelWar's source?
It looks like the forums and site are down....

bloodfox (and others I assume) have been after VXW's source for a long while now. LeCom doesn't seem all that friendly in giving it out though, dunno why. Try decompiling it or something, it's something I'd do. Just don't distribute it without telling others it is LeCom's intellectual property and making an effort to link your distro to his post on this site.

[longbyte1]

Uhh, did he make his own raycasting engine from scratch?

[LeCom]

Uhh, did he make his own raycasting engine from scratch?

If you mean me, I wrote both from scratch, yes, how else.
PS: The SVO 4DOF raycaster is kind of finished and is actually shitty on CPUs, something like 10 FPS for 320x240 on a 2.4 GHz CPU and DDR3 RAM (single thread only and infinite visibility tho') and still a view rendering glitches. But it shows that it's possible and that it's not far away from our 60 FPS Full HD target(and consider how fast GPUs are in comparison).

[Marisa Kirisame]

Uhh, did he make his own raycasting engine from scratch?

If you mean me, I wrote both from scratch, yes, how else.
PS: The SVO 4DOF raycaster is kind of finished and is actually shitty on CPUs, something like 10 FPS for 320x240 on a 2.4 GHz CPU and DDR3 RAM (single thread only and infinite visibility tho') and still a view rendering glitches. But it shows that it's possible and that it's not far away from our 60 FPS Full HD target(and consider how fast GPUs are in comparison).

Port it to GLSL for great justice performance

Also, use beamcasting starting with e.g. 16x16 regions, then recursing down to suit

Note I haven't done the latter yet but if you combine the two you'd probably use a mipmap pyramid for your texture and do several FBO stages

[LeCom]

Tbh the only way I ever programmed a GPU was via SDL2's rendering API because I was always a voxel and raycasting/tracing fanboy. But fine, I think my hardware supports PND3D's GLSL mode, so why not try it.
At the moment I AM using a mipmap pyramid. Couldn't figure out anything else that would be good in a game with changing, and possibly complex terrain.
I had confirmed with some tests that the main reason for the slowness was the fact that the CPU has to cycle through every single pixel. That's I'm figuring out how to implement an algorithm that casts like only one single ray for the upper mip levels, and then divides into several new rays when going down in the level.

I see, people are still asking for source. Dunno if I even can get the external drive containing it, but may I ask for what purpose at least? Note that it's pretty much what used to be called spaghetti code back then, aka weird and mostly make-shift stuff aka it's better to rewrite it than continuing to work with it (also the problem with Voxlap).

[Marisa Kirisame]

If you want to improve performance, throw more cores and SIMD lanes at it ;) OpenMP makes the "more cores" thing easy. Just make sure you do something like this:

Code: Select all

int y;
#pragma omp parallel for
for(y = 0; y < height; y++)
{
    int x;
    Uint32 *dest = ((Uint32 *)(screen->pixels + screen->pitch*y));

    for(x = 0; x < width; x++, dest++)
    {

and not this:

Code: Select all

int x, y;
Uint32 *dest = (Uint32 *)screen->pixels;
#pragma omp parallel for
for(y = 0; y < height; y++, dest += (screen->pitch-width)/4)
{
    for(x = 0; x < width; x++, dest++)
    {

as the threads will share the same x + dest and will dissolve into a scattered mess.

The SIMD approach works better if you do something like this:

Code: Select all

for(x = 0; x < width; x += 4)
{

__m128 posx, posy, posz;
__m128 velx, vely, velz;
__m128 time;

...

posx = _mm_add_ps(posx, _mm_mul_ps(time, velx));
posy = _mm_add_ps(posy, _mm_mul_ps(time, vely));
posz = _mm_add_ps(posz, _mm_mul_ps(time, velz));

...

}

Rather than:

Code: Select all

for(x = 0; x < width; x++)
{

__m128 pos;
__m128 vel;
float time;

...

pos = _mm_add_ps(pos, _mm_mul_ps(_mm_set1_ps(time), vel));

...

}

Oh, and it's best to code that sort of stuff in C, as even I am not better at coding assembly than a C compiler.

That's I'm figuring out how to implement an algorithm that casts like only one single ray for the upper mip levels, and then divides into several new rays when going down in the level.

Yep, that's beamtracing.

[LeCom]

I'm not relying that much on multithreading. Especially since the speed up per core is only around 70% of a core's power. Then most hardware usually only has 4-8, and changing to beamtracing would make it hard to parallelise (btw any idea why google returns basically nothing usable for beamtracing?). Dunno about SIMD yet, my usage of MMX in the voxlap hack was pretty much of a fail. Btw I don't really get your recommendation, you want me to use 128 bit registers for stuff I can do with floats, instead of doing the actual SIMD thing?
Also, yes, C rules if it comes to these things. I was considering D for some time because of its high-level stuff (compiled+high-level=speed?), but I doubt so now.

[Icarus North]

LeCom post source pls

And how tf does this topic have nearly 70 pages, It's like the biggest topic in this forum

[Marisa Kirisame]

I'm not relying that much on multithreading. Especially since the speed up per core is only around 70% of a core's power. Then most hardware usually only has 4-8,

For raytracing I get very close to double speed for two actual cores. For hyperthreading I still see an improvement, although not as much. It still helps.

and changing to beamtracing would make it hard to parallelise (btw any idea why google returns basically nothing usable for beamtracing?).

Just group the work into, say, 32x32 regions. It will be serial within the regions, but the regions will be traceable in parallel.

Dunno about SIMD yet, my usage of MMX in the voxlap hack was pretty much of a fail. Btw I don't really get your recommendation, you want me to use 128 bit registers for stuff I can do with floats, instead of doing the actual SIMD thing?

No, I'm saying use the 128-bit registers to operate on 4 rays at once, rather than using them as a 4-float vector.

Also if you arrange the 4 rays into 2x2 blocks it'll be easier to beamtrace and you may also slightly reduce the level of divergence. With that said, _mm_movemask_ps() is also useful (maskmove = copy while masking some values out, movemask = copy the top bit of each value and shove it into an int).

If you're curious and would like to have a nosey around with SSE stuff, the guide you want is the Intel Intrinsics Guide, which used to be a Java program but is now a notably nicer web app: https://software.intel.com/sites/landin ... sicsGuide/

Also, yes, C rules if it comes to these things. I was considering D for some time because of its high-level stuff (compiled+high-level=speed?), but I doubt so now.

I once wrote a raytracer in C++ which used virtual functions. The fact that I used virtual functions had negligible performance impact, because compilers these days are actually pretty good.

I don't know how good D's compiler is though. If you have no issues with C, then just stick with C.

----

And how tf does this topic have nearly 70 pages, It's like the biggest topic in this forum

Biggest active thread. Biggest thread used to be the original Iceball thread but jdrew's shitty clan managed to beat that record by treating the thread like a chat room.