Pragma - A work-in-progress multiplayer sandbox engine
155 replies, posted
[QUOTE=Silverlan;52506464]Alright, camera now rotates as well:
[T]https://pragma-engine.com/sharex/2017-07-25_23-45-13.gif[/T]
[/QUOTE]
[video]https://youtu.be/m3zvVGJrTP8?t=2m[/video]
2:00
Anyways you're doing a [sp]Inter[/sp]stellar job Silverlan, really impressive work.
I'm still bummed that this isn't open source :(
[QUOTE=Silverlan;52506464]Alright, camera now rotates as well:
[T]https://pragma-engine.com/sharex/2017-07-25_23-45-13.gif[/T]
I've also added an auto-complete configuration for ZeroBrane for pragma functions and classes:
[T]http://sciolyte.com/sharex/2017-07-26_00-00-25.gif[/T]
The auto-complete data is generated from the wiki, saves me a lot of manual work.[/QUOTE]
you accomplished is a matter of days what space engineers couldnt well in the time span of months
also, where could I submit crash logs and bug reports to?
it crashes when loading a map if I try to use VR mode (any resolution)
[URL="https://files.catbox.moe/ay2i5o.mp4"]Also, this happens in fullscreen 1920x1080
[/URL]
[QUOTE=da space core;52507546]you accomplished is a matter of days what space engineers couldnt well in the time span of months
also, where could I submit crash logs and bug reports to?
it crashes when loading a map if I try to use VR mode (any resolution)
[URL="https://files.catbox.moe/ay2i5o.mp4"]Also, this happens in fullscreen 1920x1080
[/URL][/QUOTE]
To be fair, that's a spinning wooden pallet and not a spaceship made of 100 or more individual blocks.
This engine is seriously impressive so far, I can only imagine how much you can do with more support. Backed your patreon
[QUOTE=da space core;52507546]also, where could I submit crash logs and bug reports to?[/QUOTE]
[URL=http://steamcommunity.com/id/silverlan/]Add me on steam[/URL] or just [URL=mailto:florian.weischer@gmail.com]send them to me via mail[/URL].
[QUOTE=da space core;52507546]it crashes when loading a map if I try to use VR mode (any resolution)[/QUOTE]
Hm... I'll have to switch my GPUs to check the VR module, I'll try to get around to that today.
[QUOTE=da space core;52507546][URL="https://files.catbox.moe/ay2i5o.mp4"]Also, this happens in fullscreen 1920x1080
[/URL][/QUOTE]
That's something related to chromium embedded, but I think I know what's causing it, I'll try to fix it for the next update.
[QUOTE=FlandersNed;52507592]To be fair, that's a spinning wooden pallet and not a spaceship made of 100 or more individual blocks.[/QUOTE]
I didn't have a spaceship at hand, so...
[video]https://youtu.be/yc1LVVg8o0I[/video]
[QUOTE=Funion;52507621]This engine is seriously impressive so far, I can only imagine how much you can do with more support. Backed your patreon[/QUOTE]
Thank you! :v:
[QUOTE=Silverlan;52507898]
I didn't have a spaceship at hand, so...
[video]https://youtu.be/yc1LVVg8o0I[/video]
[/QUOTE]
Now I'm seriously impressed. Well done.
I also got to ask: does the engine support 3D skyboxes like source does? Or does it work differently?
[QUOTE=FlandersNed;52508001]
I also got to ask: does the engine support 3D skyboxes like source does? Or does it work differently?[/QUOTE]
There's no need for a 3D skybox. All world-objects are rendered after the skybox, so they will be rendered even if they're actually behind it:
[T]http://sciolyte.com/sharex/pragma_2017-07-26_13-27-49.png[/T] [T]http://sciolyte.com/sharex/pragma_2017-07-26_13-34-22.png[/T]
As for the size, you can use [URL=https://wiki.pragma-engine.com/index.php?title=Entity_setscale]Entity:SetScale[/URL] (Scales physics as well):
[CODE]
local ent = ents.create("prop_static")
ent:SetModel("props/vending_machine02.wmd")
ent:Spawn()
ent:SetScale(50)
ent:SetPos(Vector(0,3000,-4000))[/Code]
There's also a keyvalue for it in hammer.
[EDITLINE]-[/EDITLINE]
[QUOTE=da space core;52507546]it crashes when loading a map if I try to use VR mode (any resolution)[/QUOTE]
I've checked the VR module and there were a few bugs I've fixed, but nothing that would cause a crash. Can you [URL=http://steamcommunity.com/id/silverlan/]add me on steam[/URL]? Crash dump most likely won't be enough to figure out why it's crashing for you.
It's funny how many games have problems with characters standing on moving objects. It's near impossible to stand on a car in most games without getting thrown off or killed magically.
If you're properly doing friction when changing between moving objects to inherit the velocity, that's pretty damn cool. If you're able to do it without killing the character in the process, that's even cooler.
Would be interested to see how it works when jumping between objects moving in different directions.
I'm unable to launch. I get the following error:
"Unable to load library 'bin\cengine.dll': The specified module could not be found.
(126)"
Is there a file missing from the download? I downloaded the launcher and ran the update and validated game files.
In 2009 I signed up for FP so I could keep up to date on your Half-Life Renaissance addon, and eight years later you're amazing me with something even more massive. Well done, and I'm really excited to see where this goes!
I may as well ask cause it hasn't been asked yet in this thread, but how much of a performance boost will Pragma have over Source, especially cause it's using Vulkan? I know you can do so much more stuff already with Pragma than with Source, but I'm wondering if I'll have better fps as well (or if I will have to cave and finally upgrade my shitty GTX 760 rig)
That'd be interesting to know, even for me who sits on a powerful PC, and what kind of performance we can expect in serverside. Gmod/source already had a lot of problems with several people working on, let's say moving vehicles at once.
Is supporting the performance of building physic heavy contraptions something you are interesting in, or are we more at a basic level to get "caught" up to source/gmod ?
give me spacebuild in this engine
i lost many a good crew member on account of the source engine suddenly deciding that it wanted to break the legs of everyone on a ship
let me fly again
[QUOTE=IAmAnooB;52512398]That'd be interesting to know, even for me who sits on a powerful PC, and what kind of performance we can expect in serverside. Gmod/source already had a lot of problems with several people working on, let's say moving vehicles at once.
Is supporting the performance of building physic heavy contraptions something you are interesting in, or are we more at a basic level to get "caught" up to source/gmod ?[/QUOTE]
if this can support multiple threads, then it will already be leagues ahead of gmod in terms of performance.
thats easier said than done though, from what I understand with the difficulty of developing for multiple cores
[QUOTE=da space core;52512575]if this can support multiple threads, then it will already be leagues ahead of gmod in terms of performance.
thats easier said than done though, from what I understand with the difficulty of developing for multiple cores[/QUOTE]
Developing for multiple cores isn't [b]fundamentally[/b] hard, at least in my limited exposure to it. The real problem is figuring out how to do so [i]logically[/i].
Multicore development, also referred to as multithreading, requires components that can be calculated independently and in any arbitrary order. This makes things that are incredibly computationally intensive and most beneficial [b]to[/b] make multithreaded, such as physics, also incredibly difficult to do so. Because not only are physics computationally intensive, but they're computationally dependent as well.
You can't reliably calculate the physics of one end of the map independent of the physics of the end of the map, because it [i]might[/i] be the case that a giant stack of dominoes is falling from one end to the other. That last domino would be influencing the physics on the other end of the map, but that last domino was influenced by the first domino on the one end of the map. And so the other end is dependent on the one end - and, as such, you can't compute them separately.
There are ways around this, such as doing computations to split the world into sections of "there is absolutely no physical way anything in this section is influence any other section", and then having [b]those[/b] compute independently, but they're not naive solutions. Multithreading physics is an undertaking, not because it's "hard" to actually write the multithreading code, but because it's "hard" to split the actual systems up [b]to[/b] write the multithreading code.
And then that's not even considering the eternal problems of [b][url=https://en.wikipedia.org/wiki/Deadlock]deadlock[/url][/b], where multiple threads need to use the same resource, but only one can edit it at a time, and [b][url=https://en.wikipedia.org/wiki/Race_condition]race conditions[/url][/b], where the outcome of a system is dependent on the order of operations performed, and multithreading introduces no guarantees that the operations will be performed in order (in fact, it's generally assumed that multithreading guarantees that the operations will [b]not[/b] be performed in order).
I've dealt with multithreading / multi-core application development on a small, casual scale. And it can be a headache to multithread even the simplest of systems.
Multiplayer hasn't been tested much as Silverlan stated.
Has anyone here tried to fill a server with more than 2 players?
If so, how did that go?
[QUOTE=Funion;52512391]I may as well ask cause it hasn't been asked yet in this thread, but how much of a performance boost will Pragma have over Source, especially cause it's using Vulkan? I know you can do so much more stuff already with Pragma than with Source, but I'm wondering if I'll have better fps as well (or if I will have to cave and finally upgrade my shitty GTX 760 rig)[/QUOTE]
No clue, haven't done much testing on that front. I did some performance improvements a while back and after that gm_fork (which uses the max map size of source) seemed to run at 60 FPS for everyone who tested it, so I haven't done any optimizations since then.
[QUOTE=IAmAnooB;52512398]
Is supporting the performance of building physic heavy contraptions something you are interesting in, or are we more at a basic level to get "caught" up to source/gmod ?[/QUOTE]
I highly doubt physics are going to be a problem. I'm using the bullet physics engine, which is pretty stable for the most part and can handle quite a bit with very little performance impact.
In general I won't optimize unless there's a reason to, so if performance problems do show somewhere, I'll do my best to do something about it.
[QUOTE=Cloak Raider;52512557]give me spacebuild in this engine
i lost many a good crew member on account of the source engine suddenly deciding that it wanted to break the legs of everyone on a ship[/QUOTE]
I'd love to see some spacebuild action, if you've got some suggestions for anything else that could be useful, let me know!
Anyway, still working on the wall-movement / localized movement. Got the camera movement down I think, just need to fix the third-person animations and give it the final touches:
[video]https://youtu.be/5HzVs6-Ctj0[/video]
Are you planning on supporting Bullet 3's OpenCL GPU solver too?
I imagine that might help when running physics for more complex contraptions.
[QUOTE=Funion;52512391]I may as well ask cause it hasn't been asked yet in this thread, but how much of a performance boost will Pragma have over Source, especially cause it's using Vulkan? I know you can do so much more stuff already with Pragma than with Source, but I'm wondering if I'll have better fps as well (or if I will have to cave and finally upgrade my shitty GTX 760 rig)[/QUOTE]
I'd give it a shot. Vulkan has [I]much[/I] lower overhead than any of the rendering systems source has used in quite some time anyways, and this engine is already quite apparently lightweight and well-written. Thus I'd expect lower overhead and just better performance, period.
[QUOTE=ace13;52513220]Are you planning on supporting Bullet 3's OpenCL GPU solver too?
I imagine that might help when running physics for more complex contraptions.[/QUOTE]
Nah, the bullet 3 GPU implementation was very bare-bones last time I checked and it's not being actively developed:
[QUOTE=Erwin Coumans]
Nothing is 'up'. The OpenCL work was mainly sponsored by Advanced Micro Devices, but AMD didn't allocate any resources on the project.
Bullet Physics development is controlled by what contributors such as myself are working on during working hours. My employer gets to decide what I work on, even though it has been almost 100% Bullet open source work during working hours:
From 2003-2010, Sony Computer Entertainment employed me, working on Bullet, and their focus was video games, in particular for Playstation.
From 2010-2013, Advanced Micro Devices employed me, and they wanted me to work on OpenCL acceleration for Bullet.
From 2014 onwards, Google employs me, and currently I am working on Robotics simulation for Google, so my contributions to Bullet are on mainly on improving simulation quality.
As far as I am aware, there are no contributors working on Bullet OpenCL at the moment.
Hope this clarifies things,
Erwin[/QUOTE]
Source: [URL=http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=10783]http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=10783[/URL]
This was 2 years ago mind you, but I don't think much has changed in that regard since then.
[QUOTE=paindoc;52513236]I'd give it a shot. Vulkan has [I]much[/I] lower overhead than any of the rendering systems source has used in quite some time anyways, and this engine is already quite apparently lightweight and well-written. Thus I'd expect lower overhead and just better performance, period.[/QUOTE]
Complex maps are still gonna be problematic I think. I'm trying to keep everything as dynamic as possible, so no BSP or similar. I've been working on a [URL=http://dcgi.fel.cvut.cz/home/bittner/publications/chc++.pdf]CHC++[/URL] implementation a while back, which should help with that, but it's not finished yet.
Do you predict that performance in large, [U]open[/U] maps will be much better this time around?
[QUOTE=Silverlan;52514935]Nah, the bullet 3 GPU implementation was very bare-bones last time I checked and it's not being actively developed:
Source: [URL=http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=10783]http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=10783[/URL]
This was 2 years ago mind you, but I don't think much has changed in that regard since then.
Complex maps are still gonna be problematic I think. I'm trying to keep everything as dynamic as possible, so no BSP or similar. I've been working on a [URL=http://dcgi.fel.cvut.cz/home/bittner/publications/chc++.pdf]CHC++[/URL] implementation a while back, which should help with that, but it's not finished yet.[/QUOTE]
If khronos keeps their promise of either merging OpenCL with Vulkan or redoing the API to be more like Vulkan it might end up being possible to accelerate some of that stuff yourself. I hope they do that because OpenCL is somehow worse than CUDA right now (and I despise Cuda tbh)
Also, if you ever want a hand/help with like debugging graphics issues I can always try to fiddle around and help identify issues. I'm not too skilled though - the little Vulkan renderer on my github is about the best I can do tbh. And using renderdoc isn't that hard :v:
Considering chipping in on patreon though just to support a Dev doing cool stuff. [I]Really[/I] sign me the fuck up if you ever do like technical/in-depth devblogs people like me could learn from. Going to have to read through that CHC paper for sure, though
Impressive, I've always been interested in trying to make a basic engine, but I wouldn't even know where to start. What are the most useful resources you've found?
So I noticed the sliding on sloped walls was similar to source, so I decided to test something...
[video]https://youtu.be/hH6qtC5oxzI[/video]
Apparently I've accidently created surf physics.
[QUOTE=Minelayer;52515000]Do you predict that performance in large, [U]open[/U] maps will be much better this time around?[/QUOTE]
The map size itself doesn't really change anything about performance, it's all about the amount of details on the map.
I can't really make predictions, since it also heavily depends on your system. Again, if performance problems come up, I'll tackle them, there's always something that can be optimized.
[QUOTE=paindoc;52515257]
Also, if you ever want a hand/help with like debugging graphics issues I can always try to fiddle around and help identify issues.[/QUOTE]
Thanks, I might take you up on that at some point. :v:
[QUOTE=tom1029;52515437]Impressive, I've always been interested in trying to make a basic engine, but I wouldn't even know where to start. What are the most useful resources you've found?[/QUOTE]
Well, I pretty much started with [url]http://www.opengl-tutorial.org/[/url] (The engine was originally running on OpenGL) and went through the tutorials.
For the other system I didn't use tutorials for the most part, I just experimented a lot and went with whatever I thought was the best way to do it.
As soon as I try to load a map, I just get "A terminal error has occured", followed by the usual "Pragma.exe has stopped working"
Is the decision on using the BSP format for maps final? Because creating maps with convex shapes is not something I would ever want to go back to. For me it just feels outdated and like a pain in the ass.
[QUOTE=Rixxz2;52515677]As soon as I try to load a map, I just get "A terminal error has occured", followed by the usual "Pragma.exe has stopped working"[/QUOTE]
Did you change any settings?
In most cases this because of out-dated drivers, make sure they're up to date. Also, intel GPUs are currently not supported.
I've added you on steam.
[QUOTE=DasMatze;52515696]Is the decision on using the BSP format for maps final? Because creating maps with convex shapes is not something I would ever want to go back to. For me it just feels outdated and like a pain in the ass.[/QUOTE]
You can use models just fine, convex/brush-like geometry and models are handled almost exactly the same internally.
[QUOTE=Silverlan;52515702]Did you change any settings?
In most cases this because of out-dated drivers, make sure they're up to date. Also, intel GPUs are currently not supported.
I've added you on steam.
[/QUOTE]
Ahh, I'll check it out when I get back home. I don't think I've updated the drivers for my 1070 since I reinstalled W10, which was like half a year ago, so that may very well be it
[editline]28th July 2017[/editline]
I'm Danish now apparently
Edit:
Turns out the problem wasn't driver related, it was MSAA. Turned it off, and now it works.
[QUOTE=Silverlan;52515522]So I noticed the sliding on sloped walls was similar to source, so I decided to test something...
[video]https://youtu.be/hH6qtC5oxzI[/video]
Apparently I've accidently created surf physics.
The map size itself doesn't really change anything about performance, it's all about the amount of details on the map.
I can't really make predictions, since it also heavily depends on your system. Again, if performance problems come up, I'll tackle them, there's always something that can be optimized.
Thanks, I might take you up on that at some point. :v:
Well, I pretty much started with [url]http://www.opengl-tutorial.org/[/url] (The engine was originally running on OpenGL) and went through the tutorials.
For the other system I didn't use tutorials for the most part, I just experimented a lot and went with whatever I thought was the best way to do it.[/QUOTE]
Well, if you ever do open-source parts of this expect me to be around to "help" with pull-requests and "fixing" issues ;p
[QUOTE=tom1029;52515437]Impressive, I've always been interested in trying to make a basic engine, but I wouldn't even know where to start. What are the most useful resources you've found?[/QUOTE]
I'm not nearly as experienced as Silverlan, but the following books are helpful (presuming you're using C++). Use libgen.io to download them:
- Any of the game engine gems series. Not so good for architecture, but loads more actual source code examples than the Game Engine Design book.
- Clean Code uses Java for examples, but has been really good for learning better habits. Counts a ton with my larger projects (especially things like my work project and my renderer that can be distributed)
- Game Engine Design helps get a systemic view of what components make up a game engine. Just lacks good examples, imo.
- Effective Modern C++, Optimized C++, and if you're still brushing up on new C++ stuff C++ Primer, 6th Ed. Modern C++ has made so many things so much easier. std::unique_ptr/std::shared_ptr practically give you GC in C++, for example.
I'd recommend staying away from Vulkan unless you're comfortable with modern OpenGL and can use DSA stuff quite well: DSA OpenGL (4.4+ iirc) prepares you well for Vulkan's complete lack of a state machine, and the way it handles objects. Its a really tough API if you're new to graphics programming, though. If you're a masochist and/or like complicated systems and low-level APIs you may be fine though. I also like to look through projects I find on github. One of the better ways I've learnt about programming stuff is by transcribing open-source code in my own words and tweaked for my own use-case/project. Its also provided plenty of examples of what [I]not[/I] to do lol
I feel like I'm hijacking the thread, so my apologies if that's the case.
Sorry, you need to Log In to post a reply to this thread.