Do we even need to move away from ENet?

[Ericson2314]

ENet is made by a pretty well respected game developer. It is specifically meant to address issues with UDP and TCP alone. I feel like there isn't much point abstracting over it for the purposes of swapping it out for something else, especially seeing that virtually everything supports posix/win threads, it's one dependency.

[Lensman]

Not really, but why be tied to one library? It's a very thin abstraction, and I'd rather have it now rather than later. I'm trying to take advantage of async operations, and rather than rewriting an socket interface for ENET (which i did consider) I felt this to be cleaner, and will make it easier to integrate websockets for WebGL clients etc. Hope you see where I'm coming from, and it really is a thin layer (~2ms latency)

[Ericson2314]

Ok, I see a bit, but I was more worried about code complexity than latency.

[Lensman]

I'll try to streamline it once I've got somthing robust. Last thing I want is lots of maintennance work. I really just wanna get on with the client, but this is taking priority. Good to see some commits on the Voxlap port there, I still can't get it to compile, but I can with the original, so I suppose I could start with that and retrofit it onto your port when it's matured. TBH, I've had a lot of success with OGL 1.2 shaders and clever geometry optimisation, but I am in your mind set of make it work on OLD hardware - and even better on new hardware. Choices ;)

[Ericson2314]

Are you on Windows? Yea I've been on Linux a while and something broke on the windows end. I know msvc cannot handle the struct within the union on Voxlap.h. But I have no idea what's messing with MinGW. I'll look too it tomorrow. Feel free to open up an issue in github or post in my thread on BnS with your compile problems.

Ok well I haven't done much networking programming so I'll trust your judgement.

[Ericson2314]

OK, the struct issue is fixed in voxlap.

[Ericson2314]

Voxlap now builds with move msvc and mingw. It isn't running meaningfully with MingW though. Also I mutated the history (yeah, it's a dirty trick but a usefull one when you are trying to port so that ever commit introduces no bugs.

If you could do some git-bisect-ing and try to figure out where the mingw version breaks that would be great.

[Lensman]

Hi. Just got back on the net after getting a new router. I got it to build okay in msvc (needed xmmintrinsics.h and a few tweaks) I haven't tried your new changes yet, but I'm looking forward to it. Also have it working with an OpenGL context and PBO using SDL, but it's only running at 15fps due to using NO_ASM branch. I fixed the white sprite drawing as well with a little hack. I was hoping that i could use Voxlap to send a depth buffer to GL and do z reconstruction and shading there, but back to the drawing board for now. Good work by the way, that code is mostly voodoo magic. Ken Silverman is obviously an evil mad genius ;)

[Ericson2314]

wholly shit! that's a lot of work! please push immediately, don't worry about merging, I will do that. How good are you with git, because I would love to do some pretty hefty history managing after I pull it.

[Ericson2314]

My goal is generally to push back build system changes as far as possible. Still keep commits small but merge in small bug fixes to the commit if they were introduce if the fix does change structure/LOC etc. This all helps find bugs later.

Seeing that you actually understand what's going on. (I tried to do my port in a minimal way so I didn't need to understand the voodoo, want to see if you can abstract the direct uses of directX in voxed, and kwalk?

Also, check out slab6. It's not techincally voxlap but it shares a lot of code. If we can trim it down to something voxed size (I am pretty sure one is based on the other) and make it require voxlap, that would be GREAT! Fault_Check also pulled some code from voxlap allready to hack in vxl loading, it's in the fault_check branch.

[Lensman]

Just pushed changes to my no_asm repo. I'll take a look at kwalk, voxed slabs6 and see what you mean about direct use of directx. I'm not too good with git, but it's pretty well documented now so history munge should be managable.

[Lensman]

Windows is entangled with those 3, in the sense that the menu, keys and presentation layers are using windows specific handles and functions. The options I see are; 1) make them all work with SDL / QT or similar. 2) rewrite and combine functionality into one app.( functionality is all map and sprite related ) 3) leave them out I'm going to do a rough function and handle count to see which one will require least modification. I have modified polydraw so I do have a feel for how Ken wrote his windows apps.

[Ericson2314]

https://github.com/Ericson2314/Voxlap/pull/6 I think it's probably best if we continue the conversation here. (I made a "reverse" pull request and replied;)

[Lensman]

Great thanks. Got voxed to compile, after commenting out some messagebox functions related to save / load. Similar in voxed, slab6 and kwalk. Should be easier than I first thought. So, basically we need a file /save load mech that works cross platform. Do you have any suggestions?