VoxelWar Discussion thread

Miscellaneous projects by the Build and Shoot community.
1066 posts Page 68 of 72
LeCom
Post Demon
Post Demon
Posts: 866
Joined: Sat May 24, 2014 8:07 am


longbyte1 wrote:
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
Deuced Up
Posts: 336
Joined: Sun Jul 21, 2013 7:27 pm


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
Post Demon
Post Demon
Posts: 2206
Joined: Mon Oct 21, 2013 4:32 pm


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
Post Demon
Post Demon
Posts: 866
Joined: Sat May 24, 2014 8:07 am


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
Green Master Race
Green Master Race
Posts: 704
Joined: Mon May 19, 2014 4:07 pm


LeCom wrote:
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
Deuce
Posts: 1
Joined: Sun Nov 08, 2015 7:25 pm


Anyone happen to have a copy of VoxelWar's source?
It looks like the forums and site are down....
Icarus North
Green Master Race
Green Master Race
Posts: 578
Joined: Sat Aug 30, 2014 11:16 pm


jadedctl wrote:
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
Deuced Up
Posts: 336
Joined: Sun Jul 21, 2013 7:27 pm


Uhh, did he make his own raycasting engine from scratch?
LeCom
Post Demon
Post Demon
Posts: 866
Joined: Sat May 24, 2014 8:07 am


longbyte1 wrote:
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
Deuced Up
Posts: 155
Joined: Sat Sep 21, 2013 10:52 pm


LeCom wrote:
longbyte1 wrote:
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
Post Demon
Post Demon
Posts: 866
Joined: Sat May 24, 2014 8:07 am


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
Deuced Up
Posts: 155
Joined: Sat Sep 21, 2013 10:52 pm


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.
LeCom wrote:
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
Post Demon
Post Demon
Posts: 866
Joined: Sat May 24, 2014 8:07 am


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
Green Master Race
Green Master Race
Posts: 578
Joined: Sat Aug 30, 2014 11:16 pm


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
Deuced Up
Posts: 155
Joined: Sat Sep 21, 2013 10:52 pm


LeCom wrote:
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.
LeCom wrote:
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.
LeCom wrote:
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/
LeCom wrote:
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.

----
Icarus North wrote:
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.
1066 posts Page 68 of 72
Return to “Noteworthy Picks”

Who is online

Users browsing this forum: No registered users and 1 guest