davis.anthony
Veteran
I've not played it yet, are the graphics a substantial improvement over Portal RTX?
Next-Generation NVMe SSD and I/O Technology [PC, PS5, XBSX|S]
- Thread starter Shortbread
- Start date
I've not played it yet, are the graphics a substantial improvement over Portal RTX?
GhostofWar
Regular
I posted the portal video in the rtx remix thread, I am mentioning it here becausxe apparently it uses RTX IO via vulkan extensions and not through DS. I'll just leave the link to the RTX IO article here though.
nvm just saw previous page, I'll go back to day drinking in the corner
nvm just saw previous page, I'll go back to day drinking in the corner
I only played the first couple of mins so difficult to say but they look about the same to me. tbh Portals graphics never really stood out for me anyway.
davis.anthony
Veteran
This developer is causing a shit storm on Twitter with comments like this.
Yea I saw that. Pure BS.
They also had the nerve to respond after that it wasn't their intention to sound like Xbox was worse just that it "needed more work" ala Baldur's Gate 3..
They knew exactly what they were doing in an effort to draw attention to their crappy looking game.
GhostofWar
Regular
Had to go lookup the game, had never heard of it. After seeing it, it looks average even for a game from last gen.
This is the logical conclussion, if your going to make those claims it better at least look like it wasn't possible 10 years ago.
Agreed, it just makes no technical sense at all. In order to be avoiding loading screens between environments they would need to be streaming data in the background and since both systems have similarly powerful CPU's and hardware decompression units as well as the same amount of memory and we can assume asset quality, the only variable there would be how quickly you can fill up a portion of roughly 10GB VRAM allocation with new data from disk. And that's essentially 1 second on PS5 vs 2 on XBSX. So unless they only start streaming 1 second before the new environment is displayed on screen and then have a 1 second load screen on XBSX (which would be an obviously ridiculous way of doing things and very easily fixed) then there is no way this can be down to drive speed.
Even the response itself sounds like it was written by a 14 year old trying to sound way more knowledgeable than they actually are.
Yea.. the more this generation goes on, the more I'm convinced that Sony simply went overboard on their SSD to improve the lives of their developers more than anything else. I think Sony made a fine decision, but I think Microsoft made the RIGHT decision for their platform. What I mean by that is that their own developers, as well as 3rd party developers, will have to target the entire range of hardware out there regardless because of PC. It would make no sense for MS to push so far ahead when all the developers for their platforms would never target that spec to begin with.
This game, from what they've shown, does not warrant this type of attitude from the developers. They've said "well those videos/pics were from 2 years ago.. a lot has changed"... but they haven't shown anything... so until they do.. they're just stirring up shit to get people to talk about their game.
GhostofWar
Regular
possibly more bullshit, the video I linked above was from 5 months ago.
I don't see what's controversial or even strange about it?
If a game is designed around the PS5 with no considerations for other platforms, it will mean a lot more work to get it to work.
Doesn't mean not possible, or it may not have been an issue if the engine/game was designed differently from the start.
Same with XSS development.
Looking at the visuals, there's no evidence that it's designed around the PS5 with no consideration. It looks like UE4 and limited asset complexity. There's not enough content on screen to warrant longer periods of loading. Even if not streaming, and actully loading whole 8GB levels in, the difference shouldn't be PS5 instant and XBS requiring loading screens.
That said, the 'loading screen' isn't described. You could maybe be looking at insta-load on PS5 and a 2 second blip on XB or something assuming everything is aligned to max out PS5's storage.
At this point though, to validate the statement we'd need a good technical argument for what data access is in play to justify the load bandwidth requirement that'd account for the proposed load time differential.
davis.anthony
Veteran
The developer said there's a boss battle where the area completely switches 4-5 times (ala R&C style) so I'm gussing that's what he's talking about.
He's also claiming all footage released up to now is from 2 years ago when they were using UE4 but now they're on UE5.
He's also claiming all footage released up to now is from 2 years ago when they were using UE4 but now they're on UE5.
D
Deleted member 11852
Guest
I think possibly that @Jay was suggesting that it was developed first on PS5, rather than being specifically optimised for it, and that the game just happens to work OK on that platform - in part because of the speed of PS5's SSD can hide a lot of inefficiencies in a game's I/O stack, level-design, asset usage and data arrangement.
Having found it easy to do on PS5, because they hit no barrier, you then try to put the same game on a platform with less I/O overhead and then you run into issues.
There are other videos showcasing supposed UE5 footage. If using UE5, won't performance be aligned with that? Is there anything UE5 that loads insta on PS5 but with a delay on XBSX?
Perhaps, but the detail of the tweets is that the SSD is too slow. The immediate expectation there is transfer speeds and/or latency. Footage also show s a simplistic game with barely any AI etc., so one wouldn't be expecting CPU to be overloaded or anything. This looks like an indie with no reason to believe they are pushing limits. They have no prior experience from their website and socials. The trailer is lots of cuts to really simplistic content - weakly animated generic peoples, etc. So do they even have XB devkits?
As a source, I don't see merit to it and highly doubt it has any insight. I can't see anything pointing to an IO system being stretched or the devs doing anything UE hasn't been doing from HDDs for years.
D
Deleted member 11852
Guest
Right. it looks like they took their codebase they was running on PS5, with probably little to no optimisation, ported to Xbox and found that the Xbox SSD was not hiding the inefficiencies that the PS5 was.
If you have a modern games comprising tens of gigabytes of data, and don't think about level design, assets or streaming against the target hardware, you'll stretch the I/O. Not because the SSD, CPU, RAM or bus is slow, but just because you've made no attempt to optimise. Modern powerful hardware is fairly lenient in this regard and you can get average results with little optimisation with the hardware brute-forcing it.
I had a quick look at the dev's tweets and there is nothing in there to suggest they've done any optimisations. It really does look like they threw this game together quickly on PS5, ported it and realised how badly optimised it is. If you are half-arsing it - and it kind of looks like they are - it's much simply to insert loading screens to hide I/O than it is to retool your data/assets/streaming stack top-to-bottom.
I reckon this is all there is to it. I don't subscribe to the notions that the dev are out to bash Xbox, this is just their general inexperience in developing games, porting games and doing nay and kind of social media comms.
Could be. However, the game was revealed for PS5 and I can't see any evidence they even have XB devkits and this isn't just theoretical! I wouldn't put them down as bashing XB or even using pro PS propaganda to further their game, but the comment looks to me unfounded speculation.
Just like GTA 5 where the "in" file was read over and over again until someone in the community fixed it
Just saw a similar problem in the software I had to analys. There was a simple try-catch mechanism, nothing to strange. Problem was, the data that came in always landed in the catch block. That was no problem with a few records in the loop, but some customers had a few hundred thousands of those and than the loop needed over a minute just parsing that stuff.
Fixed the problematic access no longer landing in the catch block and the whole thing was now parsed in a few milliseconds. Funny thing is, I fixed such a problem a few years ago (also not in "my" code)
Always reminds me that a simple check is always worth it and that simple problems like these could make some that is fast in most cases can simple destroy every performance target you'd have. But they will always be somewhere in the software as the code just did run fine when it was tested.
Similar threads
