Most visitors online was 8830 , on 6 Feb 2024
Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!
Join Today!What other server have implemented this development?
Hmmm. I know this is still in development right? But the post was dated April 2015, today is September 2016. Almost 1 year and 5 months. And I think it's long enough for this to be developed completely. Hope to see in other server ^_^.
I would expect the diffs to be pretty uninteresting. I imagine a lot of the content is just me removing Korean comments and reformatting code. o-oI already cloned it but I had time to only see a few commits diffs.
For the RS3 map stuff? Uh, I guess make a simple .col file for collision since the current stuff is a disaster (never made a map so I'm not even sure how you normally do this) and adapt the current lightmap generator to the new maps (there's no lighting currently). Past that, could use a better algorithm like Radiosity for generating better lightmaps with GI, do HDR lighting and add some other post-processing stuff.I'd like to know what are your plans for further development?
It's not very interesting so far. I've only implemented rendering of RS2 maps. You can start it with "Gunz.exe /vulkan", but the only thing you can do is fly around Mansion. XDHow is the vulkan support implementation going?
I would expect the diffs to be pretty uninteresting. I imagine a lot of the content is just me removing Korean comments and reformatting code. o-o
I mean for the whole game (including RS3).For the RS3 map stuff? Uh, I guess make a simple .col file for collision since the current stuff is a disaster (never made a map so I'm not even sure how you normally do this) and adapt the current lightmap generator to the new maps (there's no lighting currently). Past that, could use a better algorithm like Radiosity for generating better lightmaps with GI, do HDR lighting and add some other post-processing stuff.
If I find some time I may work on it.It's not very interesting so far. I've only implemented rendering of RS2 maps. You can start it with "Gunz.exe /vulkan", but the only thing you can do is fly around Mansion. XD
I don't think it should be too hard to make it minimally functional under Vulkan. As far as I can see, you'd just need to implement the D3D9-related parts of MDrawContextR2, MFontR2, RMesh, RMeshNode and RVisualMesh for Vulkan and most things should work.
I guess yes.Also, prop_pottery_stand_k02_phy seems to be missing. Was it missing in Gunz 2 as well?
I guess make a simple .col file for collision since the current stuff is a disaster (never made a map so I'm not even sure how you normally do this)
idk, off the top of my head just finish stuff like the server-based netcode and the last few sqlitedatabase functions and fix bugs I guess? not surew hat to add after all the existing features workI mean for the whole game (including RS3).
it's not just the fps performance, it's just super awkward all around. you bounce back and forth on walls (because ofIndeed the collision performance is not good currently.
cool! why didn't you use that in the first place? o:I think the .nxb file (from gunz 2) contains all the collision data, it seems to be a serialization of physx data. I think it is possible to replace bullet with physx and try to load the .nxb directly.
it's a bunch of static lights lighting static geometry, so there doesn't seem to be much benefit to dynamic lighting that I can see, and it just ends up being slow. I get ~1,500 FPS right now on a GTX 760 (~2,500 on RS2 Mansion for reference), so for you to get 200 FPS on a GTX 670 (which is better iirc) is pretty bad. lightmaps would have a much lower overhead and would let you add more details like ambient occlusion without any additional overhead.Is there any reason to use lightmaps for RS3 instead of the real time lighting already implemented (Deferred rendering)?
thanks!!! 8) I'll def watch that laterHellSniper said:My video should tell you all the information you'd need about maps (specifically making them).
oh, okay. could you post it when you have time? O:I did not tried to use the nxb file because I discovered it lately.
They can get pixelated in certain spots but otherwise look fine, and like I said it can be improvedAnyway lightmaps will (probably) be always faster, but currently (Gunz 1 maps) it is low quality
Right, but you can still use lightmaps for the static parts, which is what already happens: Lightmaps are used for the map itself, but players are lit dynamicallyand if one intends to add some kind of dynamics with physics simulation eg the chandelier moving or fall when you shot it, the flags in mansion 2 map you'll have to have dynamic lights.
Right, that's just a problem with the awful frame-dependent logic all over the code, which needs to be fixed also. There's no inherent reason that you shouldn't be able to play pretty smoothly at 60 FPS.I myself only feel the gameplay smooth when locked at 300-500 fps and I think it is bad because gameplay shouldn't be too dependent on FPS.
That's actually a really good idea. I thought of decoupling logic and rendering by just running them on different threads (which totally fails without a lot of changes), but just skipping the rendering seems like it'd work really well. It'd be easy to implement too.To fix this I thought in decouple the game update (tick rate or whatever it is called) from the rendering. In a hackish way I would draw at a constant rate (like 120 FPS) and run the game update loop as fast as it can be run, the implementation would be just skip drawing new frames if the time passed since last frame is < 8 ms. Idk if it will work as intended but it may be a solution decoupling the gameplay feeling from GPU performance.
Haven't tested it much but it seemed to work well in the few basic tests I did. It's only meant to prevent stuff like damage reduction hacks that rely on the client-side hit reg, so it only handles hit reg and meds and stuff, not things like movement/physics, which should mean that it doesn't consume too many resources, unlike e.g. CSGO servers.BTW how is server-side antilead / lag compensation working?
Compared to 100% trusting P2P antilead between legitimate players without packet loss, it can pretty much only get worse, since that's based on enemies' positions on your screen and so is always completely accurate, even if you're spiking.does it improve gameplay or it has some cons?
Depends on the resolution of the lightmap you end up generating, you can go really high resolution so pixelation isnt much of an issue (you can also super sample for antialiasing) however then you will get a really big lm file and i think the loading time of the map tanks quite some.They can get pixelated in certain spots but otherwise look fine, and like I said it can be improved
just noticed it's already included in the files, nevermind XD I'll look at the Gunz 2 source sometime to look at the structure I guessKeristrasza said:oh, okay. could you post it when you have time? O:
Re: pixelation I was thinking more of something likeExample low resolution vs high resolution
Yeah that's pretty silly, especially for that map (or at least what I can see of it) since there are only two colors and the pixels are all clustered, so it seems like it'd compress incredibly well. The .lm file should just store the names of normal texture files or sth instead, and then you'd just pick w/e format you want.~3,5mb to 24mb, though thats mostly because the bitmaps are .. bitmaps which arent small and they dont get compressed.
Not my thread but I find your posts relevant, personally! ^^I know that im derailing your discussion to a degree, sorry for that.
Thats one strange stray shadow, given the light source location i dont think a shadow would end up there, im assuming you edited the bitmap? because thats not on any mansions i have lying around.I was thinking more of something likeYou must be registered to see links(although I've never seen something that bad in an actual map). Your low resolution example looks fine. In fact, the interpolation is inadvertently creating soft shadows, so it actually looks more realistic in that sense.
It may look like its just 2 colors but worldedit ends up with ~5-6 main shades of grey with my setup (a global illumination setup), it does compress decently however, yes.Yeah that's pretty silly, especially for that map (or at least what I can see of it) since there are only two colors and the pixels are all clustered, so it seems like it'd compress incredibly well. The .lm file should just store the names of normal texture files or sth instead, and then you'd just pick w/e format you want.
I'm glad it worked, in your git tree it seems you also implemented 'logical fps limiter' does both fps limiter work as intended?I just implemented a basic version of the logic/rendering decoupling thing -- At 60 visual FPS, I get ~20k logical FPS in RS2 mansion and ~8k in RS3 mansion, and there are no issues as far as I can tell (other than the usual ones you get at high FPS, except 10x worse XD). Pretty incredible idea you had, thanks for sharing it!
Your thoughts are welcome.I know that im derailing your discussion to a degree, sorry for that.
nah it's just my bugged worldedit XD the point wasn't that particular shadow, just that if you wanted a precise shadow for something complex like a tree, it'd get pretty badHellSniper said:Thats one strange stray shadow, given the light source location i dont think a shadow would end up there, im assuming you edited the bitmap? because thats not on any mansions i have lying around.
yeh I'll try to add support for such a lightmap format sometime, shouldn't be too hard to do. high poly count rs2 maps being slow also sounds like a fixable problem caused by bsp trees, the 16 bit indices creates a hard limit of 2^16 vertices so there's no way ppl are making maps that are all that geometrically complexI would prefer to have the bitmap as a dds to lower performance impact and possibly memory usage / load time.
yeah they work perfectly and it'd surely be very helpful to ppl with older hardware. though, it still doesn't help if the normal fps just goes down to like 20, at least not unless you cap visual fps at something even lower than thatgrandao said:I'm glad it worked, in your git tree it seems you also implemented 'logical fps limiter' does both fps limiter work as intended?
yeah it's terrible, I'll try to do better with that XDI (personally) think your commits are a bit too large (as you usually also clean up comments etc) so it is sometimes dificult to get the relevant changes.