PS3-emulator voor Windows en Linux krijgt ondersteuning voor 10k-rendering

RPCS3, een PS3-emulator voor Windows en Linux, heeft ondersteuning toegevoegd om games te kunnen renderen in resoluties tot 10k. Als games de assets hebben, dan zien games er in de emulator daardoor veel scherper uit dan in de originele versies voor de PlayStation 3.

Om games in elk geval op 4k te kunnen renderen is een gpu nodig met ondersteuning voor Vulkan, zeggen de ontwikkelaars. Games draaien op de PlayStation 3 op 720p-resolutie. Als games grafisch gedetailleerd genoeg zijn, kan de emulator die details nu laten zien. Het maximum is 10k. "Maar we betwijfelen of veel mensen de benodigde setup hebben om beelden in 10k te bekijken", aldus de ontwikkelaars.

Behalve ondersteuning voor hogere resoluties heeft de emulator ook anisotropic filtering aan boord om textures er beter uit te laten zien op die hoge resoluties. De ontwikkelaars tonen het verschil met renderen in 720p met de games Ni no Kuni: Wrath of the White Witch, Demon’s Souls, Yakuza 4, Catherine en Tekken 6. De rendering op hogere resolutie werkt op alle games, behalve als Strict Rendering Mode benodigd is. De ontwikkelaars werken aan een update om het ook voor die games beschikbaar te maken.

Reacties (65)

ODF 11 oktober 2017 21:04

Als dit onder Linux werkt moet het ook met wat aanpassingen op de PS4 (FreeBSD) kunnen werken als Sony meewerkt.
De PS4 mist nog de backward compatibility die de XBOne wel heeft voor de XB360, en met deze emulator zou dat moeten kunnen.

SuperDre

Sony PlayStation 3
Sony

@ODF • 11 oktober 2017 23:44

Kijk eens even bij de specs wat je nodig hebt om deze emulator op 'normale' snelheid te kunnen draaien. Dat kan een PS4 of PS4 Pro dus niet. Misschien de opvolger, maar de huidige echt niet. Wel is het jammer dat ze geen PS1 en PS2 emulator uitbrengen voor de PS4, want die draait dan weer wel (ook natuurlijk nog steeds niet alles, alhoewel PS1 wel).

Genius-General 11 oktober 2017 19:42

Oke dus als ik dit goed begrijp hebben verscheidende game ontwikkelaars hogere assest al in hun game verwerkt maar nooit laten tonen op de ps3?

Hedva @Genius-General • 11 oktober 2017 19:49

Als je een game ontwikkeld die voor zowel PS3, PC en weet ik het wat uit moet komen. Waarom zou je überhaupt de moeite nemen om voor al die systemen andere assets te maken.
Je maakt dan gewoon de beste kwaliteit en pleurt die dan in alle systemen. Dat een systeem (bv PS3) die niet maximaal kan benutten is dan jammer.

.oisyn Moderator Devschuur®

Sony PlayStation 3

@Hedva • 11 oktober 2017 21:17

Je maakt dan gewoon de beste kwaliteit en pleurt die dan in alle systemen. Dat een systeem (bv PS3) die niet maximaal kan benutten is dan jammer.

Dat is gewoonweg niet hoe het werkt. In het geval van textures zijn je assets over het algemeen psd's. Een game laadt geen psd's, die laadt speciaal geprepareerde data die direct in het videogeheugen te zetten is, meestal block compressed. Je asset build pipeline bouwt die data aan de hand van de gecreëerde assets, en die zal die dus doorgaans ook voor PS3 in een lagere resolutie bakken dan voor PC.

Bovendien wordt alle data over het algemeen dynamisch ingestreamed terwijl je de game aan het spelen bent (anders zit je continu op loading screens te wachten). Dan wil je dus ook niet dat je textures in hogere res op disc staan, want je wilt helemaal geen tijd spenderen om die data in te lezen danwel eroverheen te skippen (disc seeks zijn helaas erg duur voor optische media)

[Reactie gewijzigd door .oisyn op 25 juli 2024 09:37]

Durandal @.oisyn • 12 oktober 2017 01:26

Allemaal voor de hand liggend, maar waar komen die hogere resolutie textures dan vandaan?

.oisyn Moderator Devschuur®

Sony PlayStation 3

@Durandal • 12 oktober 2017 01:51

Nergens. Als je op de PS3 dicht tegen een muur gaat staan, dan is diezelfde muur in 4k niet ineens scherper. Waar het waarschijnlijk om gaat is dat voor veel zaken gewoonweg niet de hoogste resolutie mipmap wordt gebruikt in de gemiddelde scene, omdat het object te weinig pixels beslaat op je scherm. Mipmaps zijn verschillende resoluties van dezelfde texture, waarbij elk volgend miplevel slechts een kwart van de pixels van de huidige miplevel beslaat (de helft in horizontale én verticale richting). Een texture van 1024x1024 heeft dus ook "versies" van 512x512, 256x256, etc, tot aan 1x1.

Welnu, als zo'n texture op een muur geplakt zit, en die muur is op je scherm maar pak 'm beet 500 pixels (wat niet zo gek is bij een resolutie van 1280x720), dan zal de GPU blenden tussen de 512x512 versie en de 256x256 versie. Teken je exact datzelfde plaatje op een hogere resolutie, dan wordt dus ook een hogere mipmap gepakt, en ziet het er ineens scherper uit.

En dan heb je nog anisotropic filtering, wat vooral effect heeft op polygonen die de diepte in gaan (denk aan vloeren, plafonds en muren die haaks op de kijkrichting staan). De gradienten in texturecoordinaten in horizontale en verticale richting zijn dan niet meer in verhouding (isotropisch). Bij trilinear filtering, wat op PS3 hardware vrij standaard was, wordt in dat geval de mipmap gepakt die overeenkomt met de richting met grootste gradient (horizontaal in het geval van een muur), met als resultaat dat de resolutie in de andere richting (verticaal dus) ook afneemt. Met anisotropic filtering worden er veel meer samples genomen uit verschillende mipmaps, waardoor je die resolutie weer terugkrijgt. Hier kun je het verschil goed zien; let op het verschil in horizontale resolutie aan de bovenkant van het plaatje. Met 16x anisotropic neemt hij per pixel dus 16x zoveel texture samples dan gewoon bij trilinear filtering. Iets waar de PC vandaag de dag natuurlijk makkelijk mee kan dealen gezien de verdere lage kwaliteit van de content.

[Reactie gewijzigd door .oisyn op 25 juli 2024 09:37]

johnbetonschaar @.oisyn • 12 oktober 2017 10:08

Nergens..

Dit is dus volgens mij niet waar, en staan er wel degelijk hogere resolutie assets op de disc van (veel) PS3 spellen, die worden gedownsampled voordat ze door de game worden ingeladen. Dat is waar het extra detail vandaan komt. Je kunt dit ook heel duidelijk zien op de vergelijking in de filmpjes: er zit daadwerkelijk veel meer detail in de high-res versie dat onmogelijk door filtering kan komen. Wat er waarschijnlijk gebeurt in veel PS3 spellen is dat zeer hoge resolutie assets van disc naar een texture met een x aantal mip-map levels wordt gedownscaled en op de HDD gecached voor streaming. Hogere MIP-map levels worden gewoon niet gegenereerd en zijn nooit in het VRAM aanwezig omdat dat simpelweg niet past (slechts 256 MB op een PS3). Een emulator kan bij het inladen de code detecteren die de textures inlaadt en voorbereidt voor gebruik (vermoedelijk een SDK functie die eenvoudig te onderscheppen is) en dan hogere resolutie mip-maps genereren.

Om een lang verhaal kort te maken staan er dus wel degelijk assets op de disc in veel hogere resolutie dan nodig (dit staat ook gewoon op de RPCS3 site). Ruimte zat...

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 09:37]

.oisyn Moderator Devschuur®

Sony PlayStation 3

@johnbetonschaar • 12 oktober 2017 12:04

die worden gedownsampled voordat ze door de game worden ingeladen

Zie .oisyn in 'geek: PS3-emulator voor Windows en Linux krijgt ondersteuning voor... waarom dat extreem onwaarschijnlijk is.

er zit daadwerkelijk veel meer detail in de high-res versie dat onmogelijk door filtering kan komen.

Ik denk dat je serieus onderschat hoe klein de kans is dat de top mip in volle glorie te zien is bij een dergelijk lage resolutie als 720p. Zeker voor iets als de main character, die over het algemeen extra texture budget krijgt voor close ups in cinematics. Ter indicatie, volgens mij waren textures van Lara in Tomb Raider (2013) 1024x1024. Wordt gewoon ingeladen, maar zie je zelden omdat ze tijden reguliere gameplay hooguit de helft van de hoogte beslaat. Er wordt dus slechts gesampled uit de 512 mip of lager.

Een emulator kan bij het inladen de code detecteren die de textures inlaadt en voorbereidt voor gebruik (vermoedelijk een SDK functie die eenvoudig te onderscheppen is)

Nee, er is geen kernel call voor, en een SDK functie is nauwelijks te onderscheppen want die wordt gewoon meegecompileerd met de executable. Ik zeg niet dat wat je suggereert onmogelijk is, maar ik durf mijn hand er wel voor in het vuur te steken dat dat niet iets is wat ze doen, gelet op de informatie die ze erover naar buiten gebben gebracht.

johnbetonschaar @.oisyn • 12 oktober 2017 16:56

Toch lijkt ook deze omschrijving van de feature te suggereren dat het zo werkt:

https://arstechnica.com/g...mes-could-look-this-good/

Ik denk dat je serieus onderschat hoe klein de kans is dat de top mip in volle glorie te zien is bij een dergelijk lage resolutie als 720p. Zeker voor iets als de main character, die over het algemeen extra texture budget krijgt voor close ups in cinematics.

We hebben hier wel te maken met een systeem met zeer beperkt VRAM he... Als de hoogste mip-map levels zelden gebruikt worden (wat natuurlijk heel erg afhankelijk is van hoe dichtbij de camera komt, en dat is vooral bij een third-person perspectief behoorlijk dichtbij), dan lijkt het me dat je als developer ervoor kiest om ze helemaal niet in VRAM te hebben: dus textures met een lager aantal mipmap levels. Als dat gelijk ook het formaat is waarop de assets op de Blu-Ray disc staan (als mip-mapped texture files) dan kan een emulator niks meer doen om met meer detail te texturen. Het verschil in de originele visuals en de high-res versies in de video is dermate groot dat ik niet geloof dat er 'alleen maar' wat getweaked is in de rendering waardoor er standaard een hoger mip-map level gekozen wordt. Maar misschien heb je gelijk hoor, ik kan zo snel geen technische details vinden hoe het geimplementeerd is, maar lees wel op verschillende plekken dat 'PS3 game discs hogere resolutie assets bevatten dan de PS3 aan kan'.

Nee, er is geen kernel call voor, en een SDK functie is nauwelijks te onderscheppen want die wordt gewoon meegecompileerd met de executable.

Dat snap ik, maar emulators kunnen wel degelijk SDK calls onderscheppen, het hele idee van HLE [1] is hier op gebaseerd. Een emulator kan vrij eenvoudig run-time herleiden welke adressen overeenkomen met welke SDK functies, en ze vervolgens monkey-patchen met een aangepaste versie. UltraHLE voor de N64 is grotendeels zo geimplementeerd.

Ik heb verder geen kennis van de PS3 SDK, maar het lijkt me totaal niet onmogelijk dat daar functionaliteit in opgenomen is om via simpele library calls high-res assets van disc te lezen, mipmap levels te genereren, alle mogelijke formaat conversies (texture compression bijvoorbeeld) toe te passen, en het resultaat te cachen voor in-game. Lijkt me ook vanuit het perspectief van de content creation pipeline erg handig namelijk: exporteer high-res versies naar disc, en produceer de low-res in-game assets in realtime. Als je dan later besluit om de game te porten naar PS4 kun je een aangepaste binary met de originele game disc gebruiken, om maar eens iets te noemen.

[1] http://emulation.gametech.../High/Low_level_emulation

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 09:37]

.oisyn Moderator Devschuur®

Sony PlayStation 3

@johnbetonschaar • 12 oktober 2017 17:09

Toch lijkt ook deze omschrijving van de feature te suggereren dat het zo werkt:

Als je doorklikt naar de tweet waar ze naar linken, dan klinkt dat anders heel erg als het originele verhaal dat ik hier typte. Het feit dat ze op de PS4 gewoon trilinear filtering doen zorgt ervoor dat er heel veel detail verloren gaat.

.edit: per ongeluk op "verzenden" geklikt

Het verschil in de originele visuals en de high-res versies in de video is dermate groot dat ik niet geloof dat er 'alleen maar' wat getweaked is in de rendering waardoor er standaard een hoger mip-map level gekozen wordt

Totaal mee oneens, ik zie niets wat meer vereist dan gewoon een standaard upres en anisotropic ipv trilinear filtering. Vergeet niet dat de filmpjes van 720p naar 2160p gaan. Elke pixel in 720p wordt gedefinierd door 3x3 pixels in 4k. Dat verschil is enorm. Ik heb daar genoeg van gezien bij de port van Rise of the Tomb Raider naar de Xbox One X in het afgelopen halfjaar

Dat snap ik, maar emulators kunnen wel degelijk SDK calls onderscheppen, het hele idee van HLE [1] is hier op gebaseerd. Een emulator kan vrij eenvoudig run-time herleiden welke adressen overeenkomen met welke SDK functies, en ze vervolgens monkey-patchen met een aangepaste versie. UltraHLE voor de N64 is grotendeels zo geimplementeerd.

Tja, maar ten tijde van de N64 deden ze nog niet aan link-time code generation, waarbij de SDK dus statisch in je binary staat

. Bovendien is het helemaal niet gezegd dat een game dergelijke SDK functionaliteit gebruikt. Wij deden onze downsamples op de cell met zelfgeschreven code. Natuurlijk niet voor textures, want dat is zinloos, maar wel voor render targets.

om via simpele library calls high-res assets van disc te lezen, mipmap levels te genereren, alle mogelijke formaat conversies (texture compression bijvoorbeeld) toe te passen, en het resultaat te cachen voor in-game

Behalve die laatste bestaat dergelijke functionaliteit wel in een of andere vorm, maar elke serieuze AAA game heeft gewoon een asset build pipeline die data gewoon in een formaat giet waar de console direct wat mee kan, omdat je anders tegen serieuze streaming performance of install times aanloopt. En je wint er echt niets mee, het is helemaal niet 'makkelijker' om het zo te doen vanuit development perspectief omdat je dan de cooktime alleen maar verplaatst naar de console zelf en dus trager is dan je eigen PC, of nog beter, het hele netwerk (onze build pipeline is volledig gedistribueerd). Nog even afgezien van de gigantische hoeveelheden data die je dan continu loopt te kopiëren. Als ik weer even kijk naa Rise, die heeft meer dan 1TB aan kaal geauthorde assets. Op disc is dat echter nog maar iets van 20GB (afhankelijk van hoeveel talen erin zitten).

En dit doen met het oog op forward compatibility... ik kan je vertellen dat niemand zich daarmee bezig houdt. Dat komt pas als de volgende console daadwekelijk uit is

.

.edit: ik heb het trouwens even snel gecheckt door wat 4k dingen te pakken uit het filmpje en die te downscalen naar 720p - het resultaat is nagenoeg identiek aan het origineel in 720p, wat suggereert dat het extra detail louter uit de hogere res komt. Ik zal vanavond eens wat screenshots uploaden.

[Reactie gewijzigd door .oisyn op 25 juli 2024 09:37]

Gomez12 @johnbetonschaar • 13 oktober 2017 00:52

Ik heb verder geen kennis van de PS3 SDK, maar het lijkt me totaal niet onmogelijk dat daar functionaliteit in opgenomen is om via simpele library calls high-res assets van disc te lezen, mipmap levels te genereren, alle mogelijke formaat conversies (texture compression bijvoorbeeld) toe te passen, en het resultaat te cachen voor in-game. Lijkt me ook vanuit het perspectief van de content creation pipeline erg handig namelijk: exporteer high-res versies naar disc, en produceer de low-res in-game assets in realtime. Als je dan later besluit om de game te porten naar PS4 kun je een aangepaste binary met de originele game disc gebruiken, om maar eens iets te noemen.

Oftewel wat je hier eigenlijk zegt is dat je je originele game op de PS3 slechter laat draaien (want hij moet opeens allerlei graphics gaan down-scalen etc wat gewoon performance kost) zodat je in de toekomst je game niet opnieuw kan verkopen op een nieuw platform.

Plus dat als je PS3 het near-realtime kan doen (zeg dat een gemiddelde game voor 20 uur textures bevat) dan kan een goed opgezette computer dit met dezelfde kwaliteit in 6 uur doen.
Oftewel voor eenmalig 6 uur computertijd ga je elke digitale download en cd groter maken met echt factoren . Nee, dan zet je dus zoals .oisyn al zegt een buildstraat op die je textures gewoon rescaled etc met een hogere kwaliteit dan welke console dan ook real-time kan doen (je blijft dan ook meestal niet in de buurt van die 6 uur zitten voor alle textures)

Wat er in de realiteit gewoon gebeurt is dat er bij een nieuwe console er gewerkt wordt aan een "aangepaste binary" en tegelijkertijd wordt de buildstraat opnieuw aangegooid met de nieuwe resoluties erin gezet, dan wordt dat hele zwikkie opnieuw op dvd/cd/download gezet et voila, het nieuwe platform heeft een deluxe versie die gewoon weer full-price verkocht kan worden.

Ipv jouw aparte idee van een aangepaste binary verkopen (voor minder geld want je levert opeens geen textures meer mee) die alleen maar bruikbaar is voor mensen die de originele disc zouden hebben.
Jouw idee beperkt je markt en zorgt ervoor dat je minder winst maakt. Waarom zou een bedrijf dat ooit gaan doen?

johnbetonschaar @Gomez12 • 13 oktober 2017 15:29

Oftewel wat je hier eigenlijk zegt is dat je je originele game op de PS3 slechter laat draaien (want hij moet opeens allerlei graphics gaan down-scalen etc wat gewoon performance kost) zodat je in de toekomst je game niet opnieuw kan verkopen op een nieuw platform.

Ik volg hier weinig van. Wat ik zeg is dat er op de disc high-res versies van assets zouden kunnen staan, die bij het opstarten of bij installatie worden ingeladen en gedownscaled/gecomprimeerd, zodat ze daarna rechtstreeks in de engine worden gebruikt worden. Zelfs voor een PS3 is dat een klusje van niks wat niet meer dan enkele seconden hoeft te kosten. Het voordeel dat je zou kunnen hebben is dat je voor een geremasterde versie de assets van de originele game disc zou kunnen gebruiken, maar dat is maar 1 voorbeeld dat toevallig net in me opkwam. Er zijn nog genoeg andere voordelen te verzinnen van hogere kwaliteit assets shippen dan in-game nodig zijn, denk aan bijvoorbeeld hogere texture kwaliteit in cut-scenes dan in-game (iets wat in heel veel PS3 spellen duidelijk zichtbaar is) zonder dat je de high-res assets in VRAM hoeft te hebben in-game. Als de SDK faciliteiten heeft om dit snel een eenvoudig te doen en je hebt toch een sloot aan opslagruimte, waarom zou je dan al je assets kapot gaan comprimeren op disc, en is het dan nog realistisch dat een emulator zoveel meer detail uit die gecomprimeerde assets kan halen?

Maargoed misschien dat iemand die daadwerkelijk met de PS3 SDK en build pipeline heeft gewerkt er maar iets van zeggen want het blijft maar speculatie op deze manier...

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 09:37]

.oisyn Moderator Devschuur®

Sony PlayStation 3

@johnbetonschaar • 17 oktober 2017 18:20

Zelfs voor een PS3 is dat een klusje van niks wat niet meer dan enkele seconden hoeft te kosten

Eens even zien, Rise of the Tomb Raider had op de Xbox 360 (vergelijkbare hardware) 650MB aan textures. Dat was op ideale resolutie, jij zegt natuurlijk dat er 1 of 2 mips bovenop zitten. Voor elk miplevel betekent dat een vermenigvuldiging van 4, dus jij zegt dat er dan 2,6GB of zelfs 10,4GB aan textures op de BR disc staan. Met een read speed van 9MB/s, kost dat dus resp. 288 seconden (~5 minuten) en 1155 seconden (~19 minuten). Echt wel een stukje meer dan 1 seconde

.

Het is echt quatsch. Als je al een hele asset build pipeline hebt (en ik snap best dat bepaalde kleinere indy games dat niet hebben en wellicht gewoon letterlijk png of jpg files lopen in te laden, maar voor een serieuze AAA game is dat gewoonweg niet te doen vanwege de enorme hoeveelheid aan content en onbruikbare source assets die toch geconverteerd moeten worden), dan stel je de boel gewoon optimaal af. Je gaat niet hogere res textures meeshippen, want dan moet je dus ook weer een installer of caching mechanisme voor die dingen gaan inbouwen wat ook weer extra points of failure met zich meebrengt, terwijl je al die meuk niet eens nodig gaat hebben.

En goed, stel nou dat die high res textures idd op disc staan. Dan stel jij dus dat de emulator in staat is dit uit te vinden. Daarop zeg ik: no way. Echt niet dat ze op een generieke manier kunnen ontdekken dat er textures in een hogere res worden uitgelezen, worden gedownsampled en worden weggeschreven naar hdd, zodat op een compleet ander punt de brondata gebruikt kan worden als ze op een of andere manier een GPU texture descriptor kunnen matchen met wat ze van disk gelezen hebben. Want die data gaat niet direct van een file naar de juiste plek in videomem, daar zit vaak nog enkele lagen aan custom filesystem meuk tussen. En dat weten ze op een of andere manier allemaal op een generieke manier te tracken

[Reactie gewijzigd door .oisyn op 22 juli 2024 14:50]

johnbetonschaar @.oisyn • 18 oktober 2017 11:14

Met een read speed van 9MB/s, kost dat dus resp. 288 seconden (~5 minuten) en 1155 seconden (~19 minuten). Echt wel een stukje meer dan 1 second

Die 1 seconde ging om het downscalen van een paar 100MB aan textures, niet om het inlezen. Dat zal natuurlijk niet echt 1 seconden duren maar ook geen minuut, het gaat om het idee. Het overgrote deel van de PS3 games wordt al direct volledig van BR naar HDD gekopieerd, en ja dat duurt inderdaad zomaar een kwartier voor een flinke game, bij sommige games zelfs het dubbele (volgens mij heb ik voor MGS4 zelfs een dikke drie kwartier zitten wachten voor ik kon spelen).

En goed, stel nou dat die high res textures idd op disc staan. Dan stel jij dus dat de emulator in staat is dit uit te vinden.

Dat zeg ik niet, ik zeg dat *als* er een mechanisme in de SDK in de vorm van een functie die bijvoorbeeld zegt 'texture = generateMipMapsAndCompress(jpg_in)', dat een emulator die vrij eenvoudig kan onderscheppen en monkeypatchen (HLE van SDK functies kan gewoon, dit is geen aanname, dit is gewoon mogelijk en wordt daadwerkelijk door emulators gedaan, ook van moderne consoles). In plaats van een 3D texture van N mip-map levels krijg je er een van N+1 mip-map levels met lagere compressie en een grotere RAM footprint. Ik kan me voorstellen dat je die niet zomaar kunt gebruiken omdat je daarmee de memory layout van de game verandert, maar ook daar kan een emulator vast wel weer een truc op verzinnen door de graphics API calls te onderscheppen voor de texture setup en pas daar (als de boel naar de VRAM van jouw GTX 1080 gaat) de high-res texture te substitueren.

terwijl je al die meuk niet eens nodig gaat hebben.

Dat is dus maar de vraag, als je in cutscenes of indoor scenes of minder zware scenes of wat dan ook hogere mip-map levels wilt kunnen gebruiken, maar niet de memory footprint wilt vergroten wanneer de textures niet gebruikt kunnen worden, dan kan ik mee heel goed voorstellen dat je verschillende versies van de assets wilt kunnen genereren op de console zelf, vanuit assets die de hoogste kwaliteit hebben die nodig is. Als dit met een paar simpele pre-processing SDK calls op install-time (tijd die je toch al kwijt bent) dan zijn er meer voordelen dan nadelen om het zo te doen.

Dat dit op moderne consoles niet gebeurt lijkt me logisch, een PS4 heeft 8GB geheugen dat voor textures gebruikt kan worden, tegen 256MB VRAM voor een PS3. En moderne games hebben in zijn algemeenheid al veel hogere texture kwaliteit op elk moment in de game. Maar als geheugen zo extreem beperkt is dan zijn er ineens heel andere overwegingen dan wat extra installatietijd om assets te genereren/cachen.

Maargoed je hebt ongetwijfeld gelijk dat het zo niet zal werken, ik heb nog nooit een AAA game op een PS3 gereleased dus wat weet ik er van. Maar technisch gesproken is het op emulatie niveau volgens mij gewoon allemaal mogelijk (ik meen zelfs dat er voor sommige emulators high-res texture mods bestaan voor originele games, ik kan me zo snel even niet voor de geest halen voor welke emulators).

Edit: Dolphin kan dit dus bijvoorbeeld:
https://forums.dolphin-emu.org/Forum-custom-texture-projects

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 09:37]

.oisyn Moderator Devschuur®

Sony PlayStation 3

@johnbetonschaar • 18 oktober 2017 11:46

Die 1 seconde ging om het downscalen van een paar 100MB aan textures, niet om het inlezen

Dan nog klopt het niet, goede kwaliteit texture compression is een best prijzige operatie. En die compressie wil je wel doen, want dat scheelt een factor 4 tot 8 - dan passen er niet alleen meer textures in het geheugen, maar het kost ook minder bandbreedte op de GPU.

ik zeg dat *als* er een mechanisme in de SDK in de vorm van een functie die bijvoorbeeld zegt 'texture = generateMipMapsAndCompress(jpg_in)'

Je had het vooral over het cachen van die meuk op harddisk, of er nou een SDK call voor is of niet. Want ik heb al uitgelegd dat je dat niet on the fly wilt doen tijdens het inladen. Leuk dat het in een seconde kan, maar een seconde heb je niet als je dynamisch aan het streamen bent tijdens het spelen van het spel. Dan heb je per frame slechts een handjevol milliseconden om extra dingen te doen. Dit nog even naast het feit dat je die hoge res texture dan nog steeds in het geheugen moet laden, wat zoals je zelf al zegt nogal krap is op de PS3.

een PS4 heeft 8GB geheugen dat voor textures gebruikt kan worden

5. 5,5 in het geval van de Pro

Maar technisch gesproken is het op emulatie niveau volgens mij gewoon allemaal mogelijk

Ik zeg ook niet dat het compleet onmogelijk is. Ik vind het alleen extreem onwaarschijnlijk dat deze emulator dat doet.

ik meen zelfs dat er voor sommige emulators high-res texture mods bestaan voor originele games

Ja, maar dat werkt natuurlijk wel een tikkeltje anders. Per game heb je dan gewoon een resource database met hogere res assets die de originele resources in videomem replacen. Dat is gewoon handwerk.

[Reactie gewijzigd door .oisyn op 25 juli 2024 09:37]

Gomez12 @johnbetonschaar • 13 oktober 2017 20:05

[...]
Maargoed misschien dat iemand die daadwerkelijk met de PS3 SDK en build pipeline heeft gewerkt er maar iets van zeggen want het blijft maar speculatie op deze manier...

Tja, ik zou zeggen lees eens wat .oisyn doet/deed etc. Zijn reacties speculatie noemen is ietwat ondoordacht.

johnbetonschaar @Gomez12 • 14 oktober 2017 13:17

Tja, ik zou zeggen lees eens wat .oisyn doet/deed etc. Zijn reacties speculatie noemen is ietwat ondoordacht.

Zo was het natuurlijk niet bedoeld. Wat ik er mee bedoel is dat de PS3 een vrij uniek apparaat is kwa hardware, SDK en de limitaties en mogelijkheden van de architectuur, en dat de manier van ontwikkelen en deployen zeer waarschijnlijk heel erg afwijkt van PC-achtige systemen met sloten RAM/VRAM (dus ook PS4/XBone). Ik ging er voor het gemak even van uit dat .oisyn niet zelf met de PS3 heeft gewerkt anders had hij dat wel gezegd lijkt me

. Het is ook de eerste keer dat ik een emulator zie die zomaar ineens zoveel extra texture detail tevoorschijn weet te toveren, dus zo ver gezocht is het ook weer niet.

johnkeates @Hedva • 11 oktober 2017 20:21

Dat kan je toch in je build targets specificeren. PS3 krijgt dan assets die op een lagere resolutie gegenereerd worden, scheelt enorm veel bandbreedte... maar blijkbaar doen ze dat niet ;-)

Blokker_1999

@johnkeates • 11 oktober 2017 20:33

Zolang het op de disc past, waarom achterwege laten? Elke asset die je dropt kan per toeval toch ergens gebruikt zijn dus moet je na het verwijderen weer tijd en geld gaan steken in het testen van het spel om zeker te zijn dat je geen fouten hebt gemaakt. Je wil niet weten hoeveel ongebruikte assets er vaak meegeleverd worden op een gamedisc, gewoon omdat het verwijderen ervan weer extra risicos met zich meebrengt.

De enige keer dat het zwaar is migelopen met het niet verwijderen is met de hot coffee mod van GTA:SA.

johnkeates @Blokker_1999 • 11 oktober 2017 20:34

Huh? Je hebt toch gewoon een dependency chain die tijdens de build alles wat je nodig hebt meetrekt...

Blokker_1999

@johnkeates • 11 oktober 2017 20:42

Voor code? Ja. Maar assets zijn geen code. Die compileer je ook niet. Die moeten gewoon present zijn. Je zou inderdaad weer iets kunnen gaan schrijven dat alle assets probeerd op te lijsten en nagaat of je ze meegeleverd hebt. Of je zou gewoon alles wat je hebt kunnen meeleveren. 2x raden wat het eenvoudigste is ...

johnkeates @Blokker_1999 • 11 oktober 2017 20:47

Assets zijn geen magische dingen, het is gewoon data. Als je een game engine gebruikt laadt je over het algemeen models in, die op hun beurt weer gespecificeerd worden door de game rules. Die models zelf hebben dan weer textures nodig, en ook die zijn dus requirements. Alles in software is gespecificeerd. Als het nergens geladen wordt is het dus geen asset die je mee hoeft te nemen tijdens een release.

De enige reden dat een asset gebruikt wordt is als het door een map, model of gamescript geladen wordt. Als een asset dus nergens voor komt kan het ook niet geladen worden. En stel dat je later een modificatie maakt en die uitrolt als een patch, en je dan dus wel iets extra's nodig hebt, dan kan je dat tegelijk met de patch meesturen. Dat is ook precies hoe dat nu gedaan wordt. Het feit dat er dus betere textures of andere assets in games gevonden wordt heeft waarschijnlijk niks te maken met "laten we alle assets maar gewoon in de release droppen met een glob op *".

.oisyn Moderator Devschuur®

Sony PlayStation 3

@Blokker_1999 • 11 oktober 2017 21:21

Maar assets zijn geen code. Die compileer je ook niet

Klopt, assets cook je. Komt eigenlijk op hetzelfde neer. Assets zoals gecreëerd door de artist zijn over het algemeen absoluut niet in een formaat dat handig is voor een game. Daarom heb je een asset build pipeline die alles omzet naar de juiste datastructuren en formaten, zodat dingen in het geheugen kan worden geladen en direct beschikbaar zijn voor bijvoorbeeld de GPU (die niets snapt van PSD of PNG data oid).

[Reactie gewijzigd door .oisyn op 25 juli 2024 09:37]

Gomez12 @Blokker_1999 • 13 oktober 2017 01:11

Zolang het op de disc past, waarom achterwege laten? Elke asset die je dropt kan per toeval toch ergens gebruikt zijn dus moet je na het verwijderen weer tijd en geld gaan steken in het testen van het spel om zeker te zijn dat je geen fouten hebt gemaakt. Je wil niet weten hoeveel ongebruikte assets er vaak meegeleverd worden op een gamedisc, gewoon omdat het verwijderen ervan weer extra risicos met zich meebrengt.

De enige keer dat het zwaar is migelopen met het niet verwijderen is met de hot coffee mod van GTA:SA.

Je haalt hier 2 dingen door elkaar : Assets selecteren en assets rescalen / re-cooken (zoals .oisyn het noemt).
Assets selecteren gebeurt idd bijna nooit voor 100% omdat er over het algemeen wel genoeg ruimte op disc is (en de 80/20 regel dan gaat gelden, de laatste 20% uitzoeken kost je 80% van de tijd)
Alleen assets rescalen / re-cooken gebeurt simpelweg altijd. Als een console maar 720p aankan dan worden alle assets simpelweg max 720p gemaakt door een buildstraat, dan worden er echt niet daarnaast nog eens 1024p exemplaren bijgeleverd omdat de ruimte er toch is, nee die 1024p die lopen in een heel ander traject van de buildstraat voor een heel andere release.

Voor een 720p console lever je gewoon geen andere textures dan 720p mee, want het zou onnodig en stompzinnig zijn.

P.s. Hot Coffee Mod waren nog niet eens overbodige assets. Overbodige assets zijn assets die gewoon helemaal niet vanuit code te bereiken zijn. Oftewel totaal niet gebruikt. Hot coffee mod had gewoon nog steeds code die er gebruik van maakte, oftewel dat waren gewoon reguliere assets

mikesmit @Genius-General • 11 oktober 2017 20:06

Het verwijderen van de ongebruikte assets is enkel noodzakelijk wanneer er ruimte ristricties zijn (zoals op de xbox360 vanwege dvd). De ps3 gebruikte toen al blurays voor zijn games waardoor compressie van texturen en/of het optimaliseren van de disc ruimte bijna een non-issue waren

.oisyn Moderator Devschuur®

Sony PlayStation 3

@mikesmit • 12 oktober 2017 09:24

Sorry maar dat is echt niet waar

. Texture compression wil je sowieso, want dat scheelt videomem en gpu performance. Daarnaast wil je resources hoe dan ook lossless comprimeren aangezien optische media een gigantische bottleneck vormt bij streaming. Beter lees je dus minder in en decomprimeer je on the fly (iets wat zeker met de cell architectuur zeer goed te doen is). Ook wil je disc seek times zo veel mogelijk voorkomen, en dus is het van belang om resources zo dicht mogelijk bij elkaar te zetten.

bakuku @Genius-General • 11 oktober 2017 19:59

Het gebeurd vaker dat games een hoger resolutie als backbone hebben maar de grafische kracht van de console deze niet tot stand kunnen brengen.

Dit zag je bijvoorbeeld al bij de PS2 en eerdere consoles. De bron materiaal is van hoger kwaliteit dan de output. Meestal om een constante gameplay of image te waarborgen.

Bij een emulator, hoe moeilijk dat ook is om volledige hardware na te bootsen, lopen niet altijd tegen de limieten van een console eenmaal deze op punt zijn. Kijk bijvoorbeeld naar de Dolphin Emulator, die draait enorm soepel en biedt ook mogelijkheden om je game in hogere resolutie te spelen. Ze kunnen de bron materiaal beter benutten en optimaliseren.

Denk ik

Stranger__NL @Genius-General • 11 oktober 2017 20:28

En met vectorgames is het natuurlijk altijd al zo geweest. En de textures zijn vaak wat hoger dan er werkelijk getoond wordt.

Het resultaat: Mario Kart WII ziet er op de Dophin emulator opQHD echt VELE malen mooier uit dan op de originele WII. En eigenlijk zien alle WII games er beter uit op de PC-emulator.

https://www.youtube.com/watch?v=y1T8il0q0DQ

darknessblade @Genius-General • 11 oktober 2017 21:26

meeste game ontwikkelaars hergebruiken veel assets,
is het zelfde met disney films tegewoordig.

waarom zou je een nieuwe tafel maken als die andere tafel ook prima op dat plekje past.
zo zijn namelijk ook veel easter eggs gemaakt, door simpelweg het model er in te importeren.

Kapitein187 11 oktober 2017 19:42

Hebben veel games assets hoger dan de "standaard" resolutie? Of moet dit door modders gemaakt worden?

Kraanmachinist @Kapitein187 • 11 oktober 2017 19:47

In sommige gevallen wel, soms heb je inderdaad modpacks maar vaak zijn het de vectoren die scherper worden en blijven de textures (bijv op een muur) op dezelfde resolutie.

SuperDre

Sony PlayStation 3
Sony

11 oktober 2017 19:50

En dat is waarom emulators een enorm voordeel kunnen hebben, nooit begrepen waarom dat bv met de PS1 emulator op de PS3 ook niet gedaan is, want de PC variant kon in die tijd PS1 games er al veel mooier uit laten zien. En nu zie je ook maar weer dat de games zelf vaak textures met hogere details gebruiken, en die hebben hier dan nauturlijk helemaal baat bij.
Ze zijn in iedergeval al een heel eind op weg.

W00fer @SuperDre • 11 oktober 2017 22:49

Er is upscaling als je PS1 games op PS3 speelt. Niet naar 1080 maar wel grafische verbetering.

JannyWooWoo @SuperDre • 12 oktober 2017 18:23

De PS1 emu op de PS3 heeft gewoon texture smoothing features hoor, ff op de Playstation knop drukken en aanzetten.

Voor de rest was er niet veel speelruimte aangezien de emu maar op 1 CELL core draaide.

SuperDre

Sony PlayStation 3
Sony

@JannyWooWoo • 12 oktober 2017 19:08

De PS1 emu op de PS3 'poets' het spel niet zo mooi op als bv Bleem of de OSS PS1 emulator.

JannyWooWoo @SuperDre • 12 oktober 2017 22:48

Sure, maar voor wat het deed was het best knap. Een complete RISC CPU emuleren op een enkele PowerPC core. Bleem had ook 3D acceleration nodig en was van de grond op daar voor geschreven.

Hoewel, de PS2 emulatie was nog een stuk knapper wat dat betreft.

Reden dat mijn reflowed OG 60GB PS3 (maar tegenwoordig met een 1TB SSHD) nog steeds een HDMI poort op mijn TV bezet.

SuperDre

Sony PlayStation 3
Sony

@JannyWooWoo • 13 oktober 2017 09:02

Bij mj is de ps3 ook nog steeds het enige dat aan mijn projector hangt.

MightyFool 11 oktober 2017 20:54

Jammer dat de ontwikkeling van de Xbox 360 tegenhanger dood is. Maar dat komt waarschijnlijk omdat PS3 meer exclusives heeft en Xbone achterwaartse compatibiliteit

MedionAkoya 11 oktober 2017 21:21

10K! Ik moet nog een scherm tegenkomen die 10K kan weergeven.

Offtopic: Dolphin is wel vermakelijk, maar niet geheel foutloos (filmpjes zijn vervormd, kaart in Twilight Princess word in regenboogkleuren weergegeven ). Volgens mij heeft Dolphin ruzie met met mijn Nvidia-kaart, op Intel wordt alles normaal weergeven maar wel met stotteringen.

CaptainEvillian @MedionAkoya • 13 oktober 2017 15:05

Multi monitor? Je kan het zo gek maken als je wilt.

ViPER_DMRT 11 oktober 2017 23:09

Assets dit, assets zo .... Ik word echt oud.

Vroeger waren mensen gewoon goed in hun craft..... *Kuch, Klaag,zanik*

Wat je met 64Kb al niet kon doen....

cavey @ViPER_DMRT • 12 oktober 2017 10:26

Jammer dat mensen je downmodden. Het is geen troll of flamebait of wat dan ook, zelf vind ik het zeer informatief, al is het wat off-topic

+1 voor farbrausch en 64k's.

geerttttt 11 oktober 2017 19:42

Maar de grote vraag is. Kun je met zo'n ps3 emulator ook online gamen?

mikesmit @geerttttt • 11 oktober 2017 20:08

Nee natuurlijk niet. Psn vereist verificatie van de console en de hardware. Als dat te emuleren was waren er toentertijd al hardware mods geweest voor de ps3 zodat de aimbot lullen ook de online ervaring op console konden verzieken

geerttttt @mikesmit • 11 oktober 2017 20:24

Tja, als je de hele ps3 met z'n cellen cpu kunt emuleren, moet een online verificatie ook te doen zijn zou ik zeggen...

Anoniem: 221563 @geerttttt • 11 oktober 2017 20:30

Als je een soort clone/dump van je originele PS3 maakt zou dat theoretisch gezien mogelijk moeten zijn.

Een PS3 die Sony niet kent zal geblokkeerd worden.

Rouwette @geerttttt • 11 oktober 2017 20:13

Of originele disks draaien.

geerttttt @Rouwette • 11 oktober 2017 20:23

Sort of, schijnbaar. Je kunt je originele disks rippen om te gebruiken in de emulator. Ze hebben er een tool voor.

Ge0force 11 oktober 2017 20:39

Fantastisch wat die mannen voor elkaar krijgen! Ik heb hier nog een ps3 en een stapel games liggen, maar die wordt nauwelijks gebruikt vanwege de lage beeldkwaliteit. Games als Demons Souls in 1440p moet fantastisch zijn!

mikesmit @Ge0force • 12 oktober 2017 06:52

Resolutie != beeldkwaliteit

Vergelijk maar eens een blu-ray met Netflix... ik weet ook vrij zeker dat, wanneer je deze games niet meer speelt door de grafische kwaliteit, dat je ze ook niet op de emulator zal spelen

Ge0force @mikesmit • 12 oktober 2017 09:30

Een hogere resolutie en toegevoegde effecten zoals anisotropic filtering zullen wel degelijk voor een betere beeldkwaliteit zorgen, maar je moet er inderdaad geen wonderen van verwachten. Toch zou die emulator een motivatie zijn om oudere ps3 exclusives nog eens te spelen, als is het maar omdat mijn ps3 ergens opgeborgen in de kast ligt en ik dagelijks op mijn pc game.

KaiZas @mikesmit • 12 oktober 2017 13:55

Moet je anders eens kijken wat er momenteel gaande is met Breath of the Wild. Ondertussen hebben ze bij Cemu zelfs 60fps voor dat spel, waar het op de WiiU en de Switch amper de 30 haalt. Ziet er tig keer beter uit op m'n ulltrawide en een hogere framerate. Speel het liever daar als elders hoor.

Jeffrey88 11 oktober 2017 20:51

Toch spijtig dat ze tot 10K roepen , en “maar” 4K tonen 😓

i7x @Jeffrey88 • 12 oktober 2017 09:00

Precies, hoe kun je nu het verschil zien op je 10k display, die jij ongetwijfld op je bureau hebt staan?

Jeffrey88 @i7x • 12 oktober 2017 10:28

Omdat deze 4K /720P vergelijking zelfs op een niet 4K scherm goed zichtbaar was.

Hogere texturen zijn niet altijd afhankelijk van het scherm waar je mee te doen hebt ‘-)

Op dit item kan niet meer gereageerd worden.

PS3-emulator voor Windows en Linux krijgt ondersteuning voor 10k-rendering

Lees meer

Reacties (65)

Sorteer op:

Weergave: