[RELEASE][DEVELOPMENT] RSX (RealSpaceX)

[Broak]

Very good job, this will lead to many changes in the scene GunZ, but you adapt fps.


If I'm not mistaken that they were working with Gunbi.

 

[SecretsOThePast]

I'd really like to integrate this and improve on it, but seems like it's still giving me issues. Specifically, deferred.txt without all the post processing effects and such is giving me issues. I've tried everything you said to do above, and haven't had any success. I even only enabled the deferred processing, and still a black screen.

I'm running the same DXSDK that you are using and such as well, Nvidia control panel is set to application controlled with default settings for that. I also tried disabling AA forced in the control panel, as that used to fix this issue on my 770 GTX. I am at a loss at why this is happening.

 

[cheaterastic]

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 ^_^.

 

[grandao]

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 ^_^.

It seems SecretsOThePast was the only one trying to use it, but he was having a 'black screen' issue and I could not help him because I could not test it on the hardware he was getting the issues, idk but he may be dropped it.
I continued to work on it but the project is going slow (currently halted) as I don't have much time to dedicate to it. I think you're not going to see it in any server (unless I make a server myself) as most of the devs with enough knowledge to make it happen (like Secrets) seems retired.
FYI it is much more than 1 year and 5 months, I guess I started it in 2012 or 2013 (see how it is going slow), but I guess if I worked on it full time I could finish it (it is already playable, but I want to polish it) within 6 months.
If I had some support I could setup a 'beta' server, but alone I can't do much, I can't even work on it how could I have time to manage a server, deal with users, hackers, DDoSes etc?

 

[YeiserGs]

I 'll work on that development Vere as I can advance ..

I had seen a while ago but due to lack of time does not work

 

[Scarty]

what about creating a group of all the community developers and make something nice, I know since alot of them leaved the programming is abit low in this community unfortunately but i think it is possible to make nice features or atleast masangpls.

 

[jetman82]

To fix the black screen issue, open deferred.txt and lighting.txt and set the vertex shaders to 3_0.

Update:

If anyone is unsatisfied with the filtering quality of the textures, open deferred.txt, find this:

sampler2D diffuseTexture : register(s0);

replace it with this code:

sampler2D diffuseTexture : register(s0) = sampler_state{
MinFilter = Anisotropic;
MagFilter = Linear;
MipFilter = Linear;
MaxAnisotropy = 16;
};

 

[Keristrasza]

Feel like I ought to mention that I've used some of your map-related code here:

You must be registered to see links

 

[grandao]

I'm glad you used it! If I knew about this amazing work earlier I'd like to help at least with a few PRs.
I already cloned it but I had time to only see a few commits diffs. I'd like to know what are your plans for further development?
How is the vulkan support implementation going?
Since this release I did a few enhancements in the code and also some post-processing effects, and with vulkan support it gives lots of possibilities for new graphics features. I'm really excited!

feel free to send me a PM so we can talk further.

 

[Keristrasza]

I already cloned it but I had time to only see a few commits diffs.

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'd like to know what are your plans for further development?

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.

How is the vulkan support implementation going?

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.


Also, prop_pottery_stand_k02_phy seems to be missing. Was it missing in Gunz 2 as well?

 

[grandao]

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

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 mean for the whole game (including RS3).
Indeed the collision performance is not good currently. 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.

Is there any reason to use lightmaps for RS3 instead of the real time lighting already implemented (Deferred rendering)?

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.

If I find some time I may work on it.

Also, prop_pottery_stand_k02_phy seems to be missing. Was it missing in Gunz 2 as well?

I guess yes.

 

[HellSniper]

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)

Import the map into 3ds max, create a simplified version of the map (has to be a closed volume / no holes, otherwise it gets funky), name it "hide_name" (the prefix being case sensitive) and export.

You must be registered to see links

should tell you all the information you'd need about maps (specifically making them).
I imagine knowing how a map is made could help you guys modifying the engine.

 

[Keristrasza]

I mean for the whole game (including RS3).

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 work

Indeed the collision performance is not good currently.

it's not just the fps performance, it's just super awkward all around. you bounce back and forth on walls (because of

You must be registered to see links

), you slide down walls weirdly when you bump into them, you start randomly standing in the middle of some walls and you bump into stuff like lamps and the super detailed geometry. just look at 0:18 and 1:46 of

You must be registered to see links

, it's SO awkward.

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.

cool! why didn't you use that in the first place? o:

Is there any reason to use lightmaps for RS3 instead of the real time lighting already implemented (Deferred rendering)?

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.

My video should tell you all the information you'd need about maps (specifically making them).

thanks!!! 8) I'll def watch that later

 

[grandao]

Yes the collision is really buggy (very hackish) currently but I think it is fixable (yet I did not invest much time in it). I did not tried to use the nxb file because I discovered it lately.

I think the 200 FPS figure is heavily related to the bad collision performance and in newer code I also added frustum culling for both objects and lights which improved a bit the perf. Anyway lightmaps will (probably) be always faster, but currently (Gunz 1 maps) it is low quality and 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.

Anyway I get your point concerning 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. 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.

Edit
BTW how is server-side antilead / lag compensation working? does it improve gameplay or it has some cons?

 

[Keristrasza]

I did not tried to use the nxb file because I discovered it lately.

oh, okay. could you post it when you have time? O:

Anyway lightmaps will (probably) be always faster, but currently (Gunz 1 maps) it is low quality

They can get pixelated in certain spots but otherwise look fine, and like I said it can be improved

and 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, 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 dynamically

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.

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.

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.

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.

BTW how is server-side antilead / lag compensation working?

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.

does it improve gameplay or it has some cons?

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.


In general, it should be better though, since it would completely stop an entire class of cheats and you wouldn't have to do the awkward kind of anticheat mechanisms people try to add to P2P antilead (which end up making normal hit reg worse, usually).


The downsides would be that server lag will lead to gameplay lag, and spiking will make your shots less reliable.

edit: 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!

 

[HellSniper]

They can get pixelated in certain spots but otherwise look fine, and like I said it can be improved

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.
Lightmaps are serviceable the only thing missing is raytracing, thats something worldedit doesnt support (surprisingly), if you need/want raytracing you will have to edit the bitmap after generating.
Example

You must be registered to see links

vs

You must be registered to see links

, ~3,5mb to 24mb, though thats mostly because the bitmaps are .. bitmaps which arent small and they dont get compressed.
Ignore the fact that its a minecraft map, just a random map i had handy right away.
I know that im derailing your discussion to a degree, sorry for that.

 

[Keristrasza]

oh, okay. could you post it when you have time? O:

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 guess

Example low resolution vs high resolution

Re: pixelation I was thinking more of something like

You 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.

~3,5mb to 24mb, though thats mostly because the bitmaps are .. bitmaps which arent small and they dont get compressed.

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 know that im derailing your discussion to a degree, sorry for that.

Not my thread but I find your posts relevant, personally! ^^

 

[HellSniper]

I was thinking more of something like

You 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.

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.

Im also assuming the maps with bad pixelation that you are thinking of are made with gzmap and fsrad, while both are decent / good tools, when poorly configured you dont get the best outcome.
When generating the lightmap with worldedit you get to pick the min and max size for the uvw faces in pixels (so max 64 means 64x64 pixels for the biggest group of faces and min 8 -> 8x8 for the smallest group of faces).
To reiterate if your uvw face space is tiny or your bitmap has a small resolution you will end up with nasty pixelated edges of shadows and / or low quality in general.
Worldedit uses 1024x1024 for the bitmap while you can set your own size with fsrad, for better or worse.
There is also a bug with fsrad/gzmap generated lightmaps that causes random splotches of pure white / black all over the place due to overlapping of some sorts, doesnt happen with worldedit.

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.

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.
I would prefer to have the bitmap as a dds to lower performance impact and possibly memory usage / load time.
Yes the lm file is for the most part just a container, it stores the bitmap and a different uvw set than the map itself uses.

 

[grandao]

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!

I'm glad it worked, in your git tree it seems you also implemented 'logical fps limiter' does both fps limiter work as intended?

Off topic
I (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.
I also find very interesting your use of class member pointers, of all the code I read in my life it seems you're the first I see using them.

I know that im derailing your discussion to a degree, sorry for that.

Your thoughts are welcome.

I think the problem with lightmaps are the shadows, to get good results (sharp shadows on contact points & soft shadows far way) you need relative large resolutions

 

[Keristrasza]

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.

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 bad

I would prefer to have the bitmap as a dds to lower performance impact and possibly memory usage / load time.

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 complex

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 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 that

I (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.

yeah it's terrible, I'll try to do better with that XD


anyhow I got the deferred shading stuff sorta working and added specular reflections,

You must be registered to see links

. it makes the lighting look much better IMO.


there are some artifacts like

You must be registered to see links

where it just refuses to light the area to the right of the lamp for some reason, even though the normal map looks ok. not really sure how to debug issues like these effectively with d3d9, software like renderdoc, the VS shader debugger, etc. don't tend to support it cuz too old. :|