What if you use the same TCastleRootTransform or TCacheAbstractTransform for the server side of the game? This object is located in Items, which has a physics update method called UpdateIntersectTime. The scene for the server could be assembled in the editor or in a separate castle-design, and it could also be tested in the window. In a server build, it would run in a loop without a window — just this object. Have you tested this approach? It seems to me like the simplest and cleanest option for the server.
1 Like
thanks
yes it could work I haven’t tested it but I think it’s fine only for small player counts.
Imagine 20 matches each with 20-30 players TCastleRootTransform FPS would drop badly even with armature only (no mesh, no texture),
and physics calculation would be wrong compared to client smooth FPS because the scene graph update rate would be inconsistent.
My current approach:
-No 3D model loading on server
-One TKraft instance per match - just for raycasting
-GetBoneWorldTransform = pure math, microseconds - full bone world position simulation
-Already tested and working!! - 0% CPU per match
Maybe I’ll try TCastleRootTransform approach after I finish what I’m working on - but I think the real bottleneck with that approach would be CPU from scene graph overhead …
With my current approach, I think the bottleneck is bandwidth, not CPU - which is a much better problem to have 
Hello
Just uploaded my first test build for a small online TDM shooter I’m working on.
It’s in early development and the server is only online during certain hours.
Game Link: online shooter game (TDM) by hanipino87
Server Time:16:00 – 00:00 (GMT+1)
Thanks for checking it out!
1 Like
Hey everyone,
I just uploaded a test build of my online shooter game (Team Deathmatch mode) to itch.io.
You can download it here: online shooter game (TDM) by hanipino87
Notes:
The server is NOT always online. It typically runs from 16:00 to 00:00 (GMT+1).
The server may also open randomly at other times. This is a work-in-progress test build – expect bugs and changes. Your feedback helps shape the game!
Download, play.
2 Likes
On my Windows system, it shows me that it cannot allocate context with 16 samples.
This is something we try to handle on the engine side, at least by default: if you use TCastleWindow with the Open (or just let the default call Application.MainWindow.OpenAndRun from the main program do it), then we gracefully fallback to “no anti-aliasing”. Tested it now on the same system, using Window.AntiAliasing := aa16SamplesNicer in the initialization of examples\3d_games\walking_adventure → and the game runs, and I see in log OpenGL context: OpenGL context cannot be initialized. Multi-sampling (anti-aliasing) turned off, trying to initialize once again..
It seems you initialize context in a different way, so it doesn’t fallback in case we cannot get the requested number of samples for multi-sampling? If you describe how do you initialize the context (using TCastleWindow? anything non-standard?) I can see is there anything on the engine side I could improve to avoid this problem
1 Like
hellow
My current initialization code (GameInitialize.pas):
initialization
DecimalSeparator := ‘.’;
Application.OnInitialize := @ApplicationInitialize;
Window := TCastleWindow.Create(Application);
Application.MainWindow := Window;
Window.Width := 800; //1600
Window.Height := 450;
Window.AntiAliasing := aa16SamplesNicer;
Window.DepthBits := 24{16}{24};
Window.StencilBits := 8{0,8};
Window.ParseParameters;
What I do in ApplicationInitialize: I run background tasks like PingServer in a thread and synchronize UI updates back to the main thread.
Could this also be causing the issue!
I’ll comment out these lines for now:
Window.AntiAliasing := aa16SamplesNicer;
Window.DepthBits := 24{16}{24};
Window.StencilBits := 8{0,8};
Then I’ll recompile and upload the EXE without 16x anti-aliasing. This should work !
Thanks for the help
ShooterGameHTE.zip (3.8 MB)
Thank you – I confirm the new exe starts flawlessly for me, I see the screen to join, character animates cool:)
I admit I don’t know why the past version failed – what you show is standard,
- you set
aa16SamplesNicerand the standard way to create a window should fallback on non-anti-aliased window. - the 24 and 8 values for depth and stencil are our engine defaults,
DefaultDepthBitsandDefaultStencilBits, so setting them doesn’t break change anything, - doing things in threads (the usual disclaimer for anyone reading: call engine from one thread) should not cause any issues here.
So, I don’t know why your original code didn’t do automatic fallback on non-anti-aliasing. Is your main program code standard, just calling Application.MainWindow.OpenAndRun ?
To give background how does the engine make “fallback, in case GPU doesn’t support requested AntiAliasing”:
-
TCastleWindow.Openwithout parameters executesOpen(@DefaultRetryOpen) -
TCastleWindow.OpenwithRetry: TGLContextRetryOpenFuncparameter first tries to create context, catchesEGLContextNotPossible, and ifRetrycallback returnstrue– it means we have downgraded our requirements and should try again, soOpen(Retry)calls itself recursively, -
DefaultRetryOpenhas a few rules how to “downgrade” the context, and the first is that ifAntiAliasing <> aaNonethen setAntiAliasing := aaNone.
This mechanism worked with our examples\3d_games\walking_adventure\ example yesterday when I tested, it could fallback from AntiAliasing 16 to none on my current system.
I described above so that possibly you can debug if the flow goes like this in your full application.
If you want to stay with the current workaround, that’s of course cool, though I’m happy to debug it more and get you back to “use anti-aliasing with 16 samples on GPUs that can do it”, we would have to debug what goes wrong in your particular application. You can share more of your code, either pubilcly or privately with me, maybe I can spot the mistake. The first thing I would check is that main program – does it look like standard engine main program, basically just doing Application.MainWindow.OpenAndRun?
Naturally, if there’s a bug in engine and we don’t do the fallback when we should – then I want to fix it:)
1 Like
Hi Michalis
Yes, my main program is standard engine main program - it just calls Application.MainWindow.OpenAndRun.
I disabled my dedicated GPU and used only the integrated GPU. I got the same error as in the screenshot.
I also tested the example examples\3d_games\walking_adventure\ and got the same error.
Maybe it’s because I’m using an older version of the engine (I’ll explain why later).
Maybe there is a small bug in the engine.
Thanks!
Oh, so your experience with walking_adventure was different than my test. Then likely indeed using the old engine version was a culprit.
If the newer version of the engine is causing you trouble, let me know I want our engine to keep good backward compatibility and encourage everyone to upgrade often:) If we have a regression, I’m happy to fix it.
1 Like
Hi, guys, a small reminder, if the engine code was obtained before this patch removed dupe EGLContextNotPossible, it caused wrong reinit flow by phomm · Pull Request #704 · castle-engine/castle-engine · GitHub then it definitely would fail, as there was a small issue with the fallback mechanism, which was not “falling back” properly to the GL context without antialiasing.
So a possible solution if you still need old engine code/version, @hal09 , just include this tiny patch
2 Likes
What version of effekseer are you using?
Yes, the problem in the old version is exactly that.
In procedure TCastleWindow.Open(const Retry: TGLContextRetryOpenFunc);
We should use:
(E is CastleInternalContextBase.EGLContextNotPossible)
Because EGLContextNotPossible is declared in both CastleWindow and CastleInternalContextBase.
I tested this and it works.
Thanks guys!
There is only one version supported by Castle Game Engine, and that is the one used. I made only small modifications.
Second one is not used at all and could be safely removed. bc otherwise, when you would need to update engine (if you use git, and not redownloading whole package), it would conflict.
But ofc, your way works as well, by providing unit-scoped name of exception type
2 Likes
