| *** Okina <Okina!~Yukari@user/yukari> has joined #bzflag | 00:10 | |
| *** FastLizard4 is back | 00:46 | |
| *** FastLizard4 is now away: AWAY from keyboard | 01:02 | |
| *** FastLizard4 is back | 01:57 | |
| *** bz-next <bz-next!~bz-next@user/bz-next> has joined #bzflag | 02:48 | |
| bz-next | I have a prototype WebGL BZFlag map viewer tool hosted at https://bz-next.github.io/mapviewer2/mapviewer.html | 02:51 |
|---|---|---|
| bz-next | It currently only works for maps that only use textures from the game and/or images.bzflag.org, but it supports meshes, drawinfo, animated textures (texture matrix), dynamic color, almost all of the features of the regular client | 02:52 |
| bz-next | still some bugs to work out, and I recommend reloading the page before opening a new map, but it could be useful for anyone doing map making, since it can be faster to load in the viewer than start a server and join it in the client | 02:53 |
| bz-next | and you don't need to install anything to use it :) | 02:53 |
| bz-next | there is a stable version without texture support at https://bz-next.github.io/mapviewer/mapviewer.html as well, I'll move the prototype there once it's cleaned up | 02:54 |
| *** FastLizard4 is now away: AWAY from keyboard | 03:01 | |
| bz-next | In general, the idea is to rework the bzflag codebase to support a new renderer based on the cross-platform Magnum library, and open the doors to new development without having to muck around directly with low-level opengl calls that make portability a nightmare | 03:31 |
| bz-next | Currently, I have a client that can join a server and render the world, chat, view the scoreboard. A map viewer tool that is cross-platform, building for desktop and webgl from the same codebase, all based on an in-progress refactor of the bzflag codebase | 03:33 |
| *** Okina <Okina!~Yukari@user/yukari> has quit IRC (Remote host closed the connection) | 03:34 | |
| *** Okina <Okina!~Yukari@user/yukari> has joined #bzflag | 03:34 | |
| bz-next | The idea is to use the map viewer app as a base to test cross-platform support with web, and hammer out any big incompatibilities early. The map viewer is just about done and should achieve that. Then the next step is rendering tanks and bullets in the new system. Magnum comes with phong and pbr shaders that are pretty cross platform, which covers a lot of ground already. | 03:36 |
| bz-next | The map viewer also can be used as the basis for a webgl-powered map editor in the future. I'm trying to keep the map viewer code simple, under 1000 lines in 1 file, so that it can be used as a good base to build tools and such with | 03:37 |
| bz-next | And just generally trying to focus on solving the most annoying problems out of the gate: bringing map geometry into one place where it's accessible, supporting cross compiling for web and windows (need someone to build on mac eventually, but it's cross platform and cmake based so it should be doable), and a bit of necessary refactor of client code that's a bit too tangled up with rendering logic | 03:42 |
| Agatha | wow that is very cool! | 03:46 |
| bz-next | you can follow progress at bz-next.github.io and github.com/bz-next/bz-next | 03:46 |
| Okina | This is amazing, it will be my go-to tool for all my mapping projects, especially with how easy it will be to see map generations . | 03:48 |
| Okina | (Even my scripts only go so far and this is better.) | 03:49 |
| moriah | ~bz-next++ | 03:51 |
| bz-next | I really want to make it easier for people to make stuff based on the core game code | 03:52 |
| bz-next | since there's a lot of magic in the codebase and it would be annoying to have to re-implement a bunch of stuff every time you want to make a new tool | 03:53 |
| Okina | ^This | 03:53 |
| bz-next | for example, the problem of only bzfs being able to read .bzw files making it hard to make a viewer/editor from the codebase is now *kinda* solved with a rough port of bzwreader into a separate library in the repo | 03:56 |
| Agatha | One thing I'd like to see is some mipmapping, antialiasing, and screen resizing. Easy to do and major QoL improvement. | 03:56 |
| bz-next | for sure. the desktop version has those, I am just bad at web dev | 03:56 |
| bz-next | I don't know how to resize a <div> well on a website lol | 03:57 |
| bz-next | I'll try to roll some of those improvements into the next stable version of the viewer | 03:58 |
| *** FastLizard4 is back | 03:59 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 264 seconds) | 04:12 | |
| bz-next | The other main refactoring task that I foresee is that there is a general issue in the codebase with tangled up logic flow in what are essentially event handlers. For example, a user IDs a flag or something -> function call to flag-specific routine -> function call to update the HUD. And now you have the HUD being updated from all sorts of places, which makes it hard to bring in a new UI or even generally reason about what's going on | 04:14 |
| bz-next | So I think there should be a really basic event bus, where different elements can subscribe to notifications about various kinds of events. That way, the HUD isn't orchestrated from 100 different bits of code. All the HUD logic could live inside the HUD, and it would just respond to events on the bus that it's interested in | 04:15 |
| bz-next | That way the HUD, for example, can define its own behavior instead of its behavior being defined by all the various things that are interested in being displayed on the HUD. It makes it possible to modify/update the HUD or plug in new UI | 04:16 |
| bz-next | since a lot of those wacky function call chains terminate somewhere in direct opengl calls it needs to be restructured anyway... | 04:19 |
| *** FastLizard4 is now away: AWAY from keyboard | 04:47 | |
| *** Okina <Okina!~Yukari@user/yukari> has quit IRC (Remote host closed the connection) | 05:11 | |
| *** Okina <Okina!~Yukari@user/yukari> has joined #bzflag | 05:11 | |
| *** bz-next <bz-next!~bz-next@user/bz-next> has quit IRC (Quit: Leaving) | 05:21 | |
| *** bz-next <bz-next!~bz-next@user/bz-next> has joined #bzflag | 06:00 | |
| *** Okina <Okina!~Yukari@user/yukari> has quit IRC (Quit: Leaving) | 06:38 | |
| *** rodgort <rodgort!~rodgort@static.38.6.217.95.clients.your-server.de> has quit IRC (Quit: Leaving) | 06:45 | |
| *** bz-next <bz-next!~bz-next@user/bz-next> has quit IRC (Quit: Leaving) | 06:50 | |
| *** rodgort <rodgort!~rodgort@static.38.6.217.95.clients.your-server.de> has joined #bzflag | 07:01 | |
| *** FastLizard4 is back | 07:34 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 08:12 | |
| *** FastLizard4 is now away: AWAY from keyboard | 09:44 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 10:45 | |
| *** Guest1203 <Guest1203!~Lars@ip-213-49-149-240.dsl.scarlet.be> has joined #bzflag | 10:46 | |
| *** Guest1203 is now known as larsvc | 10:47 | |
| larsvc | Heya! Is this a dev channel? I was wondering if I could pose some questions about the sourcecode to get a better understanding of it | 10:48 |
| *** FastLizard4 is back | 11:45 | |
| blast007 | yeah, this is the main development/support channel for BZFlag | 11:46 |
| *** FastLizard4 is now away: AWAY from keyboard | 11:50 | |
| larsvc | Alright, awesome! I am working on a thesis involving anticheat and in particular updating pointerpaths at runtime. So I wanted to try apply some of the protections I created to BZFlag. | 11:57 |
| larsvc | The core idea is that the gamedev could use the ProtectedInt/Float type instead of a regular int/float to protect it. I wanted to try and modify the code to make the enemy players positions protected. | 11:57 |
| larsvc | I found a lot of different playerstate related classes and was wondering how exactly they interact and which one would specifically store the enemy states | 11:58 |
| blast007 | are you talking about in the client itself, with the cheats you're protecting against being ones that hook onto the process and read memory? | 11:59 |
| larsvc | Yes exactly | 11:59 |
| Lantizia | blast007 / Juest: just in case you were curious... https://wiki.fsfe.org/LocalGroups/Potteries/Calendar/2024-02-13 | 12:03 |
| Lantizia | not sure if anyone has ever been to one of those events? | 12:04 |
| Lantizia | unfortunately i took most of the photos when people were on openarena and not bzflag lol | 12:04 |
| blast007 | the Player class is used both by the local player and remote players, and that uses a PlayerState class that stores things like the position and velocity. playing.cxx has code that handles network data from the server, such as player updates that include updated position and velocity data, with the new state being unpacked inside the Player class's unpack function, which calls an unpack ... | 12:05 |
| blast007 | ... function in the PlayerState class. | 12:05 |
| blast007 | the network packet codes for those updates are MsgPlayerUpdate and MsgPlayerUpdateShort | 12:06 |
| larsvc | Okay, why does the player class store a state and a inputPos? Smth related to deadreckoning? | 12:10 |
| *** FastLizard4 is back | 12:19 | |
| blast007 | seems like it. the only time inputPos and inputVel are set is inside setDeadReckoning, which copies the values from the player state | 12:27 |
| larsvc | Alrighty, thanks a lot for the info! I'll try to apply it and see how it goes. Cheers! | 12:28 |
| *** FastLizard4 is now away: AWAY from keyboard | 12:59 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 13:32 | |
| *** bz-next <bz-next!~bz-next@user/bz-next> has joined #bzflag | 16:32 | |
| Agatha | How does a ProtectedInt/Float work? | 17:35 |
| *** larsvc <larsvc!~Lars@ip-213-49-149-240.dsl.scarlet.be> has quit IRC (Quit: Client closed) | 19:18 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 23:55 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!