Hi, I’ve been working on a portal occlusion system to optimize my FPS game framework.
Here’s is how it works. There are volumes delimiting “areas” or nodes forming a graph which are connected by “portals” as edges.
The algorithm starts by traversing the graph from the area where the camera is located. Then finds if any portal is inside the frustum (yellow), if so it “shrinks” the frustum according to the size of the portal and creates a new frustum (cyan) which is used to check the area behind the portal.
All the spatials inside any of the frustrums are set with CullHint.Never or Always if outside.
Here’s a visualization:
camera view, all the red boxes seen here would be occluded by the system
Here’s in my test game:
With portals off 115 objects are rendered:
With portals enabled it’s reduced to 58, about half.
Here is a debug view. The yellow line shows the area limits and the red boxes are the portal frustums, because the frustums are clipped in screen space they always look rectangular.
The portal data is generated from my level editor very simply by marking lines in a top-down view. White and yellow lines define the area limits and Magenta is where the portals are added.
The algorithm is very simple, but the math took me some time to get right.
Thankfully I found this blog post that explains it in very easy terms and I just followed that guide step by step.
I wrote the code as a separate library in case someone find this useful: repo. I plan to make some improvements and share more detail in another post.
No new screenshots but another optimization update.
I applied Texture Arrays to my game maps, since most textures are of the same size I can bound them all together into an array, batched all into a one geometry and it allowed me to save a lot of render calls.
For instance in the screenshot above I lowered it from 58 objects to 36.
Doing a more realistic test in my under development game I measured the same scene: it had 207 objects before portals, 110 after portals and now 59 with texture arrays.
I’m using the SteamDeck as reference system and each optimization improved framerate by 16%, so around 32% in total.
I didn’t know about this technique before, seems very useful. It allows to bound an array of textures to a single texture parameter, then add a third component to the UV coors with the index in the array and use it to sample the texture. The limitation is that all textures must be of the same size and format.
I followed TestTextureArray.java as reference and modified my already modified Lighting.j3md shaders to optionally accept a new “DiffuseArray” param and read the text coords as vec3 (in case the array param is defined). Since I’m not using normal maps I didn’t bother to change that part, but it’d the same.
One small extra thing I had to do. I set a special param to my materials that’s not used by the shaders but by some visual effects (step sounds, particles and damage decals, etc.), so since I merged all the materials together I could only have one value for the whole geometry. So instead I added a new vertex buffer to the geometry (Usage.CpuOnly) and copy the effect id value for each vertex.
Then whenever I need to find the effect I pick the geometry and take the value from one of the vertices of the colliding triangle, neat!.
finally got a decently looking base for bullet impact
turns out i was using an ancient version of particlemonkey that had a couple bugs. If anyone is interested how to use the latest one but is not very familiar with gradle, heres how
integrated the bullet impact vfx with the main project, also improved the recoil and it feels much better (it doesnt feel perfect yet, but doesnt make you nauseous)
Here is an easy way.
The Server announces itself to a group network sending very basic information. you can do this using a DatagramSocket and sending using a separate thread
String message = "Hello From Game Server";
DatagramSocket socket = new DatagramSocket(new InetSocketAddress(0));
InetSocketAddress group = new InetSocketAddress("230.0.0.0", 4444) //any address or port
DatagramPacket packet = new DatagramPacket(messageBuffer, messageBuffer.length, group);
while(threadRunning){ // set this flag when the game starts to end the thread
socket.send(packet);
Thread.sleep(500);
}
socket.close();
The Client just needs to listen to the messages being sent to the address group and interpret the messages so that it knows it is a game server. To do this you create a thread that uses a MulticastSocket. Once a message from a server is received process it to make sure it is from a game server and add the address to a server list.
MulticastSocket socket = new MulticastSocket(4444);
NetworkInterface netIf = NetworkInterface.getByIndex(0);
socket.joinGroup(new InetSocketAddress("230.0.0.0", 0), netIf);
byte[] receiveBuffer = new byte[1024];
int triesLeft = 20; // To add a limit
while(isRunning && triesLeft-- > 0) { //Set isRunning = false when you connect to the server for real
DatagramPacket packet = new DatagramPacket(receiveBuffer, receiveBuffer.length);
socket.setSoTimeout(500); // to not let the socket be hanging forever if there are no servers
try {
socket.receive(packet);
String message = new String(packet.getData(), 0, packet.getLength());
String ServerAddress = packet.getAddress().getHostAddress();
// Process message here
}catch (Exception ex){
// Process errors here
}
}
isRunning = false; // Just in case the tries finish first
socket.close();
IMO it may not be the best way for a lobby-ish implementation but it is simple enough to work
Multicast is pretty neat for peer-to-peer discovery. A long time ago, I’d even used a Jini-like approach to have all of the PCs in my house share a jukebox application to coordinate the playing of MP3s. Great at parties since I have computers all over the place.
We also used it at “day job” for simple peer-to-peer discovery for some Java simulation stuff. Turns out that many corporate-style routers will have multicast turned off by default. I think had we ended up continuing with that, we’d have opted for a match-up server because that was probably going to be easier than having everywhere modify their network rules.
And I also just started working on a new zone/realm in my game called the Necrotic Abyss, which will be a very dark area filled with skeletons and undead enemies, and the player will occasionally be warped here to complete quests trials related to the Necromancy skill. I’ll likely tweak the lighting a bunch, but for now I managed to get a decent feel with purple skull lamps that glow and light up the pathway to the objective.
