I wouldn't call it "unproven." It's more like "uncommon." Windows 10 is the only platform to actually take advantage of DX12 features. DX12 is not entirely implemented on Xbox One, still. This makes DX12 effectively a niche API since it doesn't service Windows 7, Playstation, or Switch. Most developers are not going to bother with it unless their upstream engine middleware implements it. If they own the engine, the developer is likely going to ignore something that is inadequately cross-platform. I think we'll have to wait for a new generation of consoles before developers build DX12 expertise.
Is DX12 support even a possibility for the future?
- Thread starter pacmanGOD8u
- Start date
Interesting that I can google minecraft fps lag and it come up with people trying to figure out how to fix fps issues....
Oh so you are saying I can put however much scenery I want in my park and have it still run 60fps all the time? interesting....
lol. Minecraft. Great game but it still can have it's laggy moments.
I've read that post of AndyC and it also explaines why Battlefield can't do total destruction on a map. It was a big feature in BF 3 but was so minimum it made you wonder why so little.
It would take massive amounts of calculation and that's not the way the game's been build. They did improve it in newer BF's though.
My personal feeling the game is optimized, I still strongly believe some users that have descent machines have some issues in there that might caus more lag than others.
Maybe it's because my parks aren't that massively themed and littered with buildings and scenery objects.
I've read that post of AndyC and it also explaines why Battlefield can't do total destruction on a map. It was a big feature in BF 3 but was so minimum it made you wonder why so little.
It would take massive amounts of calculation and that's not the way the game's been build. They did improve it in newer BF's though.
My personal feeling the game is optimized, I still strongly believe some users that have descent machines have some issues in there that might caus more lag than others.
Maybe it's because my parks aren't that massively themed and littered with buildings and scenery objects.
Last edited:
I don't expect game tu run butter smooth with a lot of scenery. But it lags too early. I have park with not so much scenery and 12k guests. It's laggy. When I close and delete bulging, leaving bare rides and paths, I gain around 15 extra fps. It never gets to run smoothly, unless I start fresh map. Weird, isn't it? Also as for BF1, that's what is optimization about. If certain feature is cause of potential lags on current, it has to go....
WingardiumLevicoaster
Volunteer Moderator
So I can think of an example in my own career related to optimisation. Querying data. There are countless ways to optimise a database query and several tools to help you do so.. but if you are querying millions of records of data over and over again and performing complex calculations optimisation can only take you so far. There comes a point where there are limited things left you can do without taking out calculations that may be required for the report or functionality. In one case, I had to start precalculating data at off peak times on the server (which counts as optimisation!) but that was the limit on what I could do and it wasn't as fast as we would have liked, but it was doing a lot of work. Now obviously a different situation to game development.. but the same problems occur. Using DX12 by your definition I would say would not count as optimisation as it isn't a current constraint. To Upgrade Cobra to use it as well as DX11? From a project management and company point of view: Does the development time + money invested in such a drastic change not to mention the complete QA overhaul for the engine and it's potential to affect every other project Frontier has that uses Cobra, make the gains worth it in customer satisfaction on profits? I wouldn't be convinced myself.
Last edited:
Vampiro
Volunteer Moderator
I think that would mean the objects and the simulation would have to go
.... I don't think thats a good idea [tongue]Joël
Volunteer Moderator
Can you point me to the "official definition" of game optimisation that you are referring to?
When a game drops below a certain fps, it doesn't have to mean that the game is unoptimised or that optimisation is at an unacceptable level.
I recommend that you read up on what game optimisation means. There are several articles that you can read, such as this one from PC Gamer, although articles tend to only lightly scratch the surface of what goes into optimizing a modern PC game.
I think that would mean the objects and the simulation would have to go
Very unfortunate generalization. Yes, pbp would have to be done differently or replaced with different system that would reduce number of objects.
What is simulation here? Simulation was in first rct as well. Again, it depends on what is being simulated, how it's implemented. Some things should be simplified. And as you said, the game should scale the simulation, right?
Generally, one of the problems here is too many objects and second problem are leaks.
Joël
Volunteer Moderator
I think that would mean the objects and the simulation would have to go
That would certainly not be a good idea, as that would mean that features that make Planet Coaster 'Planet Coaster' would have to be removed, which would in turn lead to a less enjoyable game (although that last part is an opinion). Something I explained in one of my previous posts.
Joël
Volunteer Moderator
Too many objects? You realise this is dependent on how the player uses the game, not dependent on the game itself?
Leaks? What kind of leaks? Can you provide us with more information about these leaks? Please do share that with us, because if there are leaks in the game code, any information about the leaks that you've mentioned can be used by the QA team to come up with a fix.
Last edited:
This is a game. I hope you realize casual player will hardly play this game the way it won´t cause lags. Developers are supposed to design the game the way players don´t need to think about optimization. The only limitation here should be the number of objects, however, in PC, you must care about how you place objects. You know, most people don´t understand this stuff.As I said many times, this is wrong and whole building system could have been done in different ways and I believe even less HW expensive and easier to use.As for leaks, I cannot. I unninstaled the game and I honestly won´t install it anytime soon.However, it definitely is not allright if game lags even when park gets closed, guests are gone and all PbP structures are deleted.... So the problem is somewhere else, clearly.As for the simulation, if it´s that complex, ok, but why having this complex simulation if there is bscly no gameplay? PC is mainly sandbox building game, it´s lacking on management side and therefore, I think simulation should be also simplified in favour of better optimization.
WingardiumLevicoaster
Volunteer Moderator
You have lags with no guests or scenery? [weird] That sounds like a hardware issue, rather than the game. I have not had this problem myself and I am sure many would agree with me. Have you tried posting in tech support? Maybe there is something you can do to help it. Maybe this is why we are struggling to understand your point of view. Hoping your issue can be resolved if that is the case. [happy]
I have no problem with HW for sure, I tested it, recently changed bad component and also have no problems with other games nor some very HW expensive software.To be exact, it doesn´t lag when I start fresh map. But when park grows, it gets laggy. So I close the park, let guests leave and delete PbP (leaving only rides and paths), but there is only minimal improvements, which is strange.
Every "new" game has a learning curve because non of them are exactly the same. I couldn't build what I can build now, 6 months ago... Frontier gave us alot of freedom in building, it's a game that asks for using that creative spirit of yours. You like it or you don't... there's no shame in not beign that creative as someone else, that's why the workshop is arround... no one said you have to build anything you can use what others made.
I'v played manny games and alot of games with leaks, most of the time those games crash or freeze on any kind of system... so far planet didn't crash once on my system (900+ gameplay hours)
About performance that has always been linked to the hardware you play the game with, we already know when, what and why FPS drops, we also know what they did so far to improve it the best way they can.
The complex calculations are actually there for better management, they made a custom build and very complex system as base component for guests, staff, shops etc...
So they can keep adding more and more management features, Rome wasn't build in one day either,... some things need time... making a game like Planet Coaster is one of them.
I'm sorry If I am mistaking this, but do you mean that a tree that I place upside down can cause more lag than if I put it the right way up?
Casual players don't overdecorate their structures and rides, so I'm finding it very hard to believe they won;t play it because of the lag.
I can for sure say I am the stereotype of a casual player, and I notice no lag at all.
Are you experiencing lag when your park is closed? Why don't I have this issue?
And lag in a 12.000 guest park? Sounds like nothing out of the ordinary.
Last edited:
That´s not what I´m talking about. I´m talking about it could have been designed with easy to use tools that would also lower amount of used objects. A perfect example could be fences for instance. At this point, yopu have to place them as single object, piece by piece (or even in worse case, place one piece of fence build off several other pieces). If we had "click and drag" tool, it would lower the objects the fence is build off. Same goes for walls. If there was system "click and drag", similar to the sims, it would be easier to use and could be more optimized along with a lot of other pros (instead of having hundreds of object in the menu having just few variants of plain walll where player would then apply texture).
Ah, we are looking at the game in a way of "how it should have been done".
So it's better to say: "The way the game has been designed it is well optimized."
"If they would have designed it in another way it MIGHT have been better performing and easier to work with".
We don't know if it would have been better optimized because it was never designed that way.
So it's better to say: "The way the game has been designed it is well optimized."
"If they would have designed it in another way it MIGHT have been better performing and easier to work with".
We don't know if it would have been better optimized because it was never designed that way.
Last edited:
Yes, I'm sure that there are things that could have been done in the design of the game that would lower the object count. For instance, your fence tool -- in the naive case, a tool that drops 50 fence pieces automatically incurs no less overhead than manually dropping those 50 pieces. However, a spline-based fence tool could cheat by representing the fence simply as that spline (with attributes describing the fence type, colour, etc.) and have the engine render that as part of a GPU shader or similar. The problem is that doing something like that is incredibly complex, and the gains from doing so would be marginal as fences will constitute only a tiny fraction of the number of objects in the game. You could extend the concept to other areas like walls and scenery, but your tradeoff here is in flexibility.
There are other things that could have been done, like allowing the player to 'bake' groups of objects into a larger, immutable, object. Again, the complexity here is in taking that object and extricating the visible geometry, dynamically creating the textures / maps / shaders for the new object (at all LODs) and to do that in a performant manner that itself doesn't impact upon the game. One of the tradeoffs here is that at present the game can store one texture per scenery piece in video memory and keep it there. All instances of that object share the same texture, so the engine doesn't have to be transferring large quantities of texture data all the time. If we were baking bespoke textures for bespoke objects, the engine would have to manage which of those is visible when, and frankly I would expect that to have an impact on the hardware required to run the game (e.g. more video memory, more RAM).
In short: on the face of it, there are plenty of things that the devs *could* do to reduce object counts. I would wager that during development they considered most -- if not all -- of them and settled on the current design as something that was a) deliverable in the given timescales; and b) scalable enough to run on low- to mid-end hardware.