#PS2 Emulation

1 messages · Page 1 of 1 (latest)

final bough
#

a braindumping ground for PCSX2 work

image.png
#

@analog delta 👀

#

reading some of the old source for PCSX2, this could be possible ... (pre 0.9.6) when SM2 D3D9 was a thing

#

im hackin on this for now while the nvidia wizards chew on the F.E.A.R issue

#

rasterized for now because the camera is handled by the rasterizer frontend. but if we could expose it outside of the rasterizer context it might be possible. at the very least we can capture geometry and do texture replacements

image.png
#

@tiny pewter inviting you to this circus

analog delta
#

peepo_clown I was summoned

#

That frametime chart does not insipre confidence

final bough
#

I have it artificially limiting the frames for now which is why its so bad

#

it runs smooth

#

but the default is 3000 FPS KEK

analog delta
final bough
#

hahah yeah, I think when its rendering at 3000 FPS its like in the nanoseconds per frame time

analog delta
#

Is there any way to use the modern PCSX2 emulator and the old rasterizer?

final bough
#

this PCSX version is back when they had support for 240Hz CRTs KEK

#

they removed D3D9 support back in 1.5.2

analog delta
final bough
#

I thought about using GLDirect, but even the modern ones need like GL 3.3-4.4

#

the older ones though around 1.x used 1.4-2.x

analog delta
#

||I'm kind of surpised someone hasn't made their own that just path traces the scene or something||

final bough
#

yeah me too

#

PSX is pretty much all shader based

#

but you can bring it down to SM1 and 2 on the older versions

#

up to 1.5.2 you can build it for SM2, but you need to build it from scratch

#

newer ones support Vulkan

analog delta
final bough
#

but that would be alot of work to bypass the DXVK (remix) stuff and go straight to vulkan since the scene render binds off of d3d9

#

but I dunno, I gotta look at the code

#

it should be possible

#

atleast we have source code KEK

#

you could maybe port the shader stuff on the older ones to a fixed function. the only reason as far as I understand that they went shaders was so they could send the vertexes off of the VPU on the PS2 to the shader directly

honest heath
#

i'm gonna send a message so i don't have to search for this thread every time

analog delta
#

Wonder if the PCSX team would look into if it's possible BinoculaRs

final bough
#

yeah maybe

honest heath
#

afaik they have no interest in Remix

final bough
#

the renderer seems pretty simple though, its a standalone plugin detached from the main source

analog delta
final bough
#

I thought about using mednafen too, but they do too many insane optimizations

honest heath
#

i was involved with testing a while ago, and still am in their server on my alt. most of the comments and such that i've seen have been disinterest and basically "pcsx2 will never work with it"

final bough
#

lol

#

weird for them to say since there is no way they understand how remix works so quick

#

quick to judge I guess

honest heath
#

that's my point

analog delta
honest heath
#

well, yes

#

but also they don't understand Remix as well as they thought

final bough
#

some of it might be in the weeds for how they interact with the VPU or something, but I totally agree, they wrote the whole render pipeline, the data comes from somewhere

#

they support standard texture formats

#

etc

#

Im guessing its probably because they realized it only works with D3D9

#

and they got rid of that 7+ years ago

honest heath
#

yeah, pretty much. but they also said that older builds wouldn't work. that may not have been a dev though, just a contributor

final bough
#

well good thing its open source

honest heath
#

ya, and you know how to do things 😛

final bough
#

I might look at the code for avocado too, and see how easy that would be to extend. I love avocado

honest heath
#

i wish launching that gave me actual avocados

final bough
#

yeh same

analog delta
#

"Play!" is maintained by one guy, could ask him KEK

final bough
honest heath
final bough
#

the bar for figuring out which one is the easiest to extend, will be figuring out which one allows the programmer to have the easiest access to the data to render

#

lots of them are just like "lets use shaders"

#

but I see no reason as to why it is a requirement

#

just give me verticies

honest heath
#

yeah

final bough
#

or give me death

honest heath
#

lol

#

does Play! actually use Dx9?

final bough
#

yep

honest heath
#

surprising given they also support android

analog delta
#

And web browsers

honest heath
#

yeah, that too

#

pretty neat

analog delta
#

I can finally play PS2 games on my fridge

#

thank god

honest heath
#

lol

#

hmmmmm

image.png
final bough
#

it uses SM3 VS shaders, but I dont see why it couldn't make due with fixed or a heavy downgrade of the shaders. they already calculate the triangles on the CPU and pass them into a shader to draw them

#

PS1/2 Emulation

analog delta
#

PS1's on the table PeepoPlotting

final bough
#

it should be

honest heath
#

eventually we will have 3!

final bough
#

mybe honestly

#

those PS3 emulator guys are certified nuts

honest heath
#

in looots of ways

analog delta
#

Such a bizarre choice in processor and just the nonsense it caused.

honest heath
#

ya, it's really interesting

#

want a supercomputer? buy a console 😛

final bough
#

the airforce did it

honest heath
#

yap

#

then Sony tried to take it away

#

software updates, boo

final bough
#

I think they got them just before they removed the linux support lol

#

Sony malding

honest heath
#

yeah

#

lol

final bough
honest heath
analog delta
#

Mark

#

Pls

#

Fix

honest heath
#

i like jokes

honest heath
final bough
#

yeah mark why dont you just write a whole emulator

#

I swear some people

honest heath
#

i want to pin that

analog delta
#

Issue #5062: Rewrite PCSX2 to support Remix

final bough
#

issue description: my katamari limited edition doesn't work with remix, pls fix

analog delta
final bough
#

god I love katamari

analog delta
#

If ya do a renderdoc/apitrace of PCSX2, I wonder if it sends over the verticies all nicely to the GPU.

final bough
#

mmm good question

#

I should learn how to use apitrace

#

at least trace whats going on

#

on a bunch of emulators

#

the play one actually seems pretty interesting if the D3D9 stuff still builds

#

it does use m_device->DrawPrimitive(D3DPT_TRIANGLELIST, 0, 1); for the vertex kick for triangles

#

but it does seem like it wants to use line strips for some things

#

and remix doesn't work with line strips

#

it uses triangle primitives for everything else though

#

in that case the line strip might be able to be tesselated into a triangle list 🤔

#

you could pretty much double up the line points right next to eachother and create a triangle strip by duplicating the line to be right beside the other line. then connect the two perpendicular lines together:

analog delta
#

Are you talking about D3D lines?

final bough
#

yeah

analog delta
#

I know silentpatch had a fix for that in Colin McRae Rally 2

final bough
#

interesting

scarlet yew
#

Mhm

final bough
#

well Play! is definitely a contender, at least it has a D3D9 codebase still in its source tree unlike PCSX2, and actually uses fixed primitve calls for some things. only questions is how well does it actually play games. I'd rather go for PCSX2 last since this is going to require some re-writing and I dont want to have to work on PCSX's dusty ass 10 year old code to go back to the D3D9 pipeline

#

Avocado is nice one for PS1 as well that lets you get access right to the verticies to render, its just modern OpenGL. I dont see a reason why a D3D9 backend couldn't be created that turns the vertices into Primitive fixed calls

analog delta
honest heath
#

lets just write our own

#

here, i'll start

final bough
#

I mean I probably will end up taking an existing implementation and completely write a render pipeline from scratch
aint got time to re-implement a SPU

honest heath
#

PS2

#

that's half of it

#

the other part is emulator

final bough
#

were halfway there

#

oh now we are done

honest heath
final bough
#

ez

honest heath
#

ya, much ez

#

anyway, i'll stop spamming 😛

final bough
#

yeah, I think I will start with avocado. even though the games wont look fantastic anyways, it will be much easier because its a competent codebase, and it shares a similar goalset, which is turning a pipeline that spits vertices from the registers of the hardware out of the GTE/VPU out to a shader, to a set of fixed primitive calls (instead), which PS2 emulator does as well, but in a bit of a different way.

#

I still gotta think on it though

tiny pewter
#

Just caught up to this chat, wow. I'm focusing on my Stalker Trilogy replacements this week since I don't have a lot of time on hand but I have a couple of old PS2 titles laying around if you need any help with testing-- beyond that I don't think I have the DX9 knowledge/expertise to be of much help. 😦

final bough
#

the problem ultimately with emulation is its just doing whatever its told, it has no idea when a scene starts, when a scene ends, what a camera is, etc

final bough
tiny pewter
#

Either way, some very exciting progress 😄

final bough
#

yeah. I got an older version of PCSX half-baked working, but I dread working on that code 😢

tiny pewter
#

So, one commit back and start porting features? 🤣

final bough
#

but even then they were using alot of shaders. but I should probably read over it again. it was possible to limit it in custom builds, but Im not sure

#

maybe yeah

#

but still have to work around problems like how do you create a "virtual" camera in remix that it can track and follow

tiny pewter
#

I've never really gotten into PS2 emulation so I'll probably have to set it up first, thankfully I have an old model just gathering dust.

final bough
#

because remix dumb and needs some point of reference to reconstruct the geometry from in the scene

tiny pewter
#

We kind of have that functionality after all, with the free camera-- we just need some extra weird methods to apply.

final bough
#

as long as the scene renderer can actually capture the geometry, even a fixed reference might work, or maybe spoof it from some local coordinate. I dunno

#

needs a think for sure

tiny pewter
#

That or the ability to hook the camera coordinates into memory addresses so we could just read the player/camera position directly.

#

I feel like the biggest and most interesting thing I want to explore with the whole Ogre project is that I would love to see Remix work in tandem with games instead of working as an unwelcome guest.

final bough
#

yeah I'll have to look to see how the hardware did it back in the day. maybe all the coordinates were offset from some local offset or just 0,0,0. ultimately the code that handles the camera is somewhere in the MIPS code the PS2 is running, but its not clear if its abstracted to the hardware in any way that could be understood

#

the issue is the renderpath from the hardware is just like give me data, okay I draw now

#

it doesn't really know about a camera

tiny pewter
#

I wish we had a port of FFX for reference, but alas 😔

#

I wonder if for the time being, we can enable a debug free camera at 0,0,0 as a fallback behavior instead of looking for a camera in the scene.

final bough
#

yeah maybe. if the scene render is just getting a bunch of pre-transformed verticies, if we know where they are offset from we could probably spoof it with the freecam

#

ultimately under rtx we are viewing the output of the scene renderer instead of the game, so as long as we can get geometry and textures into it that are offset into some world-space, we might be able to fake it

tiny pewter
#

It may even be worth including as an alternative to the existing Fused Transform options.

#

This is still affecting a number of DX8 games and source ports, NewDark especially.

final bough
#

even if we couldnt figure out how the exact transformations are done into the world the game uses, it might be able to be done heuristically

#

if we get a bunch of verticies that build a scene, we dont know how exactly to transform them into our worldspace, but if we know the minumum and maximum distances lengths for all geometry locations in this unknown scene, we could scale it by some value. until it looks "right"

#

but this would have had to been figured out I imagine for PCSX2 during the D3D9 days

#

since all DrawPrimitve calls need to be transformed into a world-space

#

ohhhh! there were instructions on the GTE to translate world-space perspective and the alike 🤔

#

so the GTE actually knows

scarlet yew
#

hmm.. how can we do mesh replacements in emulators tho?

final bough
#

by bringing all the geometry into the scene renderer and doing it once we have the scene renderer view full of what the game would be providing in terms of poly content

#

a mesh is basically just a set of verticies defining some geometry, and some faces

#

the hard part is splitting them out into actual objects independently of the rest of the poly content

#

you could feasibly do it if the mesh has textures applied to it, or some kind of material. then you would derive the bounds of the mesh vertices from the size of the texture to be applied (if you cant just figure it out directly)

#

I'd be more interested in path tracing the existing geometry, adding lights, etc, first to be honest, and upscaling the textures

#

putting them back in would be a whole different story

#

oh, that link sucks

#

a pretty clever hack ontop of GTE::rtps

final bough
#

a good test to see if this will even be worth the time for PS1 level games, will be to use the 3d-screenshot branch in avocado and export a full scene from a running PS1 game. Import it into Omniverse, doll it up and observe 😛

#

😛 PS1 may just not have enough fidelity to make it worth it lol :P. there are some decent 3d world games however. like ape escape, and racing games. at the very least you could do texture replacement, and lighting, but ...
some interesting 3d freecam capture references here:
https://www.youtube.com/watch?v=OPuJcAfVpxc
I'll give it a go tonight. but yeah PS2 might be the only worthy starting point for remix with titles like FFX.

#

most of the same problems still apply in terms of goals to PS2. PS2 will just have more poly's to make it worth it

tiny pewter
#

My PS2 library is mostly gone, unfortunately. But I can test Star Wars: Bounty Hunter. 😛

#

Probably won't go far with it tonight though, I made a huge mistake working on my replacements script and I'm trying to get back to where I was.

final bough
#

its fine, this is still in the brainstorming phase, we dont even have a working solution or a start either than PCSX2 0.9.4

tiny pewter
#

💀 Even now it haunts us

s-l640.jpg
final bough
#

alright yea, PS1 is off the table. there is no depth/Z buffer, too many rasterized items as well, faked polly's etc. and straight up not enough fidelity.

#

PS2 Emulation

#

Play! still looks good, gonna try playing with that

analog delta
final bough
#

shit is wild beyond belief

tiny pewter
#

Programmers are scary.

final bough
#

🅱️ ruh

image.png
#

Play! it probably is. I have no doubt about its compatiblity if its doing this in the browser lmao. I dread having to work on the PCSX code as well, its an aboslute mess 10 years ago. this is still a mess, but slightly cleaner, and far less code.

analog delta
#

Remix in browser? PeepoInvestigate

final bough
#

...

#

I mean, technically you could since its a 64-bit app, and you could compile just the dxvk portion to WASM ... but I suppose you'd need the source for RTXDI and NVGX, etc, and find a way to get the slangh shaders and compilers into the browser. Im sure in 5 years WebGPU will make it possible

#

im actually excited to try play, I mean its pretty light VS_3's. and mostly uses DrawPrimitve for triangle lists ... POG

#

the VS_3s could actually be ported to VS_2s or 1s since it only uses 3 due to the D3DCompiler they use, none of the instructions used are unique to VS_3

#

🙏

analog delta
final bough
#

oh nice, a Play build for x64

#

goodbye bridge

#

get outta heya

honest heath
#

lol

final bough
#

rip nvm, gots to build it, only comes pre-built with with OpenGL and Vulkan

#

brb while I swim in a ocean of CMakeFiles and QT

#

set(ENABLE_AMAZON_S3 ON CACHE BOOL "Enable loading disc from Amazon S3 servers")
🫠

final bough
#

welp TIL. the D3D9 code in Play is only for the music player and frame debugger

#

:notlikethis:

#

it could be done with it, but the entire UI would need to be rewritten

#

PCSX2 it is. rip.
last commit with D3D9 was e091f4233a30697e6ebbd62d53b5fed4f721a9ec

honest heath
#

aw

final bough
#

so it begins:

H:\Share\Sources\pcsx2-remix>git branch -l
  1.4.x
  master
  post-purge-d3d9
* pre-purge-d3d9
olive pond
final bough
#

its rasterized and not working, so I wouldn't get your hopes up too much

#

and that was after a bunch of hacks

#

but there is hope 😛

olive pond
#

😦

#

Are these emulators open source

final bough
#

yes

#

kinda impossible to do it on a closed source one

olive pond
#

Hopefully we can get a dx9 renderer that works with remix for them

final bough
#

thats the idea

final bough
#

welp. it builds with VS2017 after retargettng the solution and fixing up the mscompile.cmd

whole atlas
#

would this ever work? I thought this would be a canvas renderer?

final bough
#

a canvas render? do you mean rasterization?
I mean before it gets rasterized the verticies and geometry is completely available from the VPU. its only once it gets blitted to the screen does it get rasterized

whole atlas
#

oh, interesting!

#

so there is actual depth. mad

final bough
#

we just need to get the geometry out of the VPU and shader layer and call DrawPrimitive on them depending on how we can reconstruct the verticies

#

oh yeah

#

on PS2 for sure

#

PS1 def no

whole atlas
#

just imagining nocturne MontyDemonic

#

I wonder if there is a way to reverse engineer smt nocturne on pc since it uses unity

final bough
#

I have no idea, never played it

whole atlas
#

its a ps2 game being rendered in what I would say is a unity wrapper

final bough
#

interesting

#

you sure its actually emulating the PS2 game?

whole atlas
#

I have no idea

#

this is just what I read when it got announced

#

turned me off buying it

final bough
#

it uses DX11 so I wouldn't be able to reverse it in any meaningful way. if it was D3D9 I would have def considered checking it out

whole atlas
#

yea, was wondering if there was a way to run it in an older version of unity but I guess if its compiled in dx11 and there is no source code then we would be shit out of luck

final bough
#

yeah

whole atlas
#

well at least with this I could potentially just run pcsx2

final bough
#

heh. yeah, we just need to get at the juicy verticies info pushed out of the VPU before it gets mapped to a vertex shader. We have to do a bunch of other stuff on the way too, like rewrite and remove several shaders, figure out how to transform verticies to some kind of world space, camera, etc. But the code im targetting now was the very last commit with D3D9 support. You can bring the shaders all the way back to SM2.

whole atlas
#

wonder how much the code has changed since way back when

final bough
#

But the reason why the shader approach is so attractive for them is because they get verticies right off the VPU, then they just turn them into triangle lists or update vertex buffers on the shader with them and map them right to the GPU

#

so its easier

#

well

whole atlas
#

oh

final bough
#

over 100,000 lines

whole atlas
#

🤣

#

is this in hardware render or in software render?

final bough
#

both

whole atlas
#

so wait, does the newer version of pcsx2 axe the dx9 support?

final bough
#

yes

#

its been gone since 2018 officially

#

no way to get it, code is nuked

whole atlas
#

I know in the last few years compatibility has really improved

#

so how comes a ps1 emulator wouldnt work?

final bough
#

there's just not enough meaningful info to path trace to be honest

#

very low poly count, tons of stuff is faked

#

no depth

#

etc

whole atlas
#

ah!

final bough
#

I thought about it, it would be possible, but im certain it isnt worth it

#

it would also be horribly janky and inaccurate

whole atlas
#

which emulator would you have looked at?

final bough
#

basically all of them for PS1 lol, that are open source atleast

whole atlas
#

just out of curiosity

final bough
#

Avocado is the nicest, it has 3d export support through a GTE rtsp instruction hack

whole atlas
#

I know that pcsx2 and duckstation share alot of code now

final bough
#

yeah

#

duckstation never had an older renderer though

whole atlas
#

but anyways, pcsx2 is where it is at

final bough
#

Play! had one, but it was only for the music player

whole atlas
final bough
#

mednafen has always been OGL

whole atlas
#

I used epsxe for the longest time

final bough
#

I wish there was code for it

#

but its always been closed

#

the plugins are open, but nobody has ever written a D3D9 plugin for it, just D3D7 and maybe 8

#

you could maybe get away with GLDirect on a old pete's GL version

#

but there's just not much to trace honestly

whole atlas
#

yea, petes gpu plugins only go to d3d7

final bough
#

yeah unfortunately

whole atlas
final bough
#

weird flex lol by him

#

just download 1.4.0 (last XP version)

#

works fine

#

its now 6000 commits behind KEK

whole atlas
#

I do not really have any coding expertise but let me know if you need any help

#

yea, there was a big push when duckdev started working on pcsx2

final bough
#

sure no problem

#

Ill probably be working on it for a bit while nvidia chews on my FEAR bug

whole atlas
#

I need something to keep me busy until there is any progress with arx xD

final bough
whole atlas
#

I just need that one issue fixed and I can actually start working on it

final bough
#

surprised nobody has worked on it before today here

#

super compatible

whole atlas
#

probably some sort of busy but I find it hard to work on something I dont really have any knowledge of. But then again its a game I know nothing about and could secretly love 😅 I will take a look

final bough
#

freelancer is great

#

top game back in the day

#

I think mutahar did a video on it with remix

#

some other people are workin on it but they dont share. would be good practice

whole atlas
#

oh its chris roberts

#

thats the star citizen guy, right?

final bough
#

yeah

#

this is a nice compatible one too

whole atlas
#

I did get project eden working too

final bough
#

nice

whole atlas
#

only the world was flipped by 90 dgrees and I couldnt work out how to fix it 😅

#

#game-compatibility message

final bough
#

oh weird

#

left-handed capture or world transform problem?

whole atlas
#

not too sure. will probably test again today

#

could also not make any heads or tails of the graphics settings

final bough
#

I wonder if it exported it with the wrong world axis or something

whole atlas
#

yea I remember playing around with that

#

but after that obtuse wall I just dropped to continue with Arx

final bough
#

gotcha

#

the software rendering for D3D9 GDSx in PCSX2 is pretty interesting though. it mostly tries to convert all the verticies into triangle and point lists then tries to rasterize or blit them to the screen based on the pixel size they occupy, but I think if you can get at that vertex info before it gets rasterized, you might be able to take those triangle lists and submit them as a DrawPrimitive call. I've def seen other emulators do this (that are far too old to work on now).

#

has four different classes of primitives it tries to pack into vertexbuffers:

    InitCVB(GS_POINT_CLASS);
    InitCVB(GS_LINE_CLASS);
    InitCVB(GS_TRIANGLE_CLASS);
    InitCVB(GS_SPRITE_CLASS);
#

yeah, and they reconstruct these primitives directly from the vertex count information in each VPU data packet:

switch(env.PRIM.TYPE)
{
case GPU_POLYGON: data->primclass = GS_TRIANGLE_CLASS; prims = data->vertex_count / 3; break;
case GPU_LINE: data->primclass = GS_LINE_CLASS; prims = data->vertex_count / 2; break;
case GPU_SPRITE: data->primclass = GS_SPRITE_CLASS; prims = data->vertex_count / 2; break;
default: __assume(0);
}
#

sooooo ... if we use SW based D3D9 backend, we can get access to the primitives pretty easily that we could use in D3D9 DrawPrimitive away from the main shader code

#

but then we need to rework the shaders that provide all the effects for the scene 🤔. need to figure out how the SW renderer actually does this without shaders

olive pond
#

What if we just delete the shaders lol

final bough
#

well the SW renderer doesnt really use shaders, it rasterizes everything

#

which would obviously be bad for remix

#

we need to rewrite how the vertex data is turned into primitives and submit them to remix as DrawCalls, without pre-transforming them

olive pond
#

I will leave that to people who enjoy graphics programming I think good luck

final bough
#

so this is pretty much what the SW renderer does:

  1. grabs incoming vertices from the emulated VPU GSS, and packs them into a queue of vertexes to kick out per packet.
  2. the vertexes in the queue get "Kicked" out to vertex buffers which fill up.
  3. a Flush() or Draw() call is made from GSS, which then checks how many vertices are in the current buffer index and assigns the primitive type accordingly (triangle, point, list, sprite) based on vertex count.
  4. Once assigned to a primitive type, the primitive type is tagged onto the vertices at its index in the GSVertexList<Vertex> m_vl; buffer.
  5. The primitive gets put into the rasterizer primitive list Queue and then Synced to the rasterizer workers.
  6. The rasterizer worker picks up the primitive from the Queue, dictates its scale, and rasterizes it to the framebuffer based on how many pixels the primitive occupies in the screen space.
#

So if we take out the middle man for the rasterizer, and take the packed primitives before they get rasterized out, and submit them as a DrawPrimitive to DXVK, it would be a start. Im missing how the rasterizer dictates the scale and how the verticies are pre-transformed, but that can be discovered later.
am off to bed 💤

tiny pewter
#

On SMT3 Nocturne: it's more comparable to Outcast: Second Contact or Doom 1/2 for BethesdaNET. It's the original codebase using Unity as a shell, to streamline the compatibility and multiplatform process.

#

It's on a pretty recent version of Unity where DX9 was deprecated.

final bough
#

thought some more about this in the morning, going to try an approach like this:

  1. Intercept the vertex streams: Like mentioned before, we need to intercept the vertex streams coming off the VPU before they get popped into GS vertex buffers, and figure out how the pre-transform was applied (ideally).
  2. Determine the primitive type: Analyze the intercepted vertex data to determine the primitive type (e.g., triangle list, triangle strip, etc.) based on the number of vertices and their ordering. This step would involve identifying the start and end of each primitive shape based on the connectivity of the vertices. Thankfully PCSX2 already does this for us.
    3.** Create a D3D9 vertex buffer:** Once the primitive type and the count of vertices for each primitive shape is determined, we can create a D3D9 vertex buffer with the appropriate size and format to hold the intercepted vertex data.
  3. Fill the D3D9 vertex buffer: Copy the intercepted vertex information into the D3D9 vertex buffer, ensuring that the vertices are ordered correctly according to the determined primitive type.
    5.** Set the D3D9 vertex buffer:** Set the D3D9 vertex buffer as the active vertex buffer using the SetStreamSource function (or similar), ensuring that it is properly bound to the corresponding vertex attributes like position, normal, texture coordinates, etc.
    6.** Render the primitives:** Finally, we use the FF DrawPrimitive function, specifying the primitive type (e.g., D3DPT_TRIANGLELIST, D3DPT_TRIANGLESTRIP, etc.) and the vertex count for each primitive shape.
#

or alternatively, we can try with using the existing vertex shaders PCSX2 uses and let DXVK create the pass through geometry shader for it which would allow the GS to pass the vertexes directly to DXVK in the form of the shader vertexbuffer data. But this will probably require rewriting bits of the shaders and the pipeline, since it wants to use >VS2, but earlier versions did support straight VS2. this approach would be easier if it worked, so it should probably be investigated first.

olive pond
#

What exactly is the difference between a rasterizer and what you suggest?

#

Is it like merging all the geometry and rendering in one big chunk?

final bough
#

a rasterizer only deals in pixels. so it takes all the geometry and pixel effects and blits them out into one rendered image

#

it does so with the geometry by converting it to line segments and such

#

we do not want rasterization

#

kinda a basic example of polygon rasterization. uses approximation to determine the amount of the pixel each triangle occupies

olive pond
#

Oh I see thanks

final bough
#

api trace works well with PCSX2 under D3D9 HW mode with some tweaks. great debugging tool

whole atlas
#

I learnt about rasterising from photoshop

#

in the context of that, you can resize a vertex object and make it bigger without losing quality but you would need to rasterise the layer if you wanted to merge it down

final bough
#

tbh people should be using apitrace here against remix

#

it dumps everything for you, then you can inspect how its drawing things to see if it uses DrawPrimitive fixed or not, AddLights, etc

#

or you can inspect CreateShader calls directly

#

@fathom cave if a game uses pure rasterization, I'm a little confused as to why the rasterize fallback does not just pass through the original rendertarget or backbuffer view in only some instances. I've seen some games where it just goes complete black in a rasterized context (sometimes until UI textures are selected), and others where disabling ray tracing through the toggle causes the injection not to occur for the drawcalls, and does pass through the rasterization. it seems inconsistent. Have you run into this internally?
For example in FEAR. the menu is rasterized, yet nothing shows up, even when UI textures are selected. but as soon as a level is loaded with a detected camera, it shows the rasterized content. Then backing out of that level retains the rasterized content and suddenly the menu renders fine, without a camera.

#

it seems vanilla DXVK is able to handle these instances ... I wonder if it could perhaps be related to a pixel shader being used to render the entire rasterized context (to a surface) in those games versus the game just writing directly to the backbuffer through rasterization. but I was under the impression the rasterizer in D3D9 used pixel shaders to actually do that, such as Rasterizer -> Fragment -> Pixel Shader -> Pixel.

I tried a little test in remix to double check that it doesn't have anything to do with the default render target of zero selection, by checking the output of the OM state, which should be an aggregate of all the rendertargets available:

for (int i = 0; i <= MaxNumRenderTargets; i++)
  takeScreenshot("rtxImageDxvkView", m_state.om.renderTargets.color[i].view->image())

to no avail, its all blank. much confusion. am probably missing something.

final bough
#

using APITrace here, I can see the triangle list data is def hitting remix, but nothing shows up in any of the rendertargets or pipelines 😦
the vertex shader is a dead simple pass through as well:

VS_OUTPUT vs_main(VS_INPUT input)
{
    VS_OUTPUT output;

    output.p = input.p;
    output.t = input.t;

    return output;
}
whole atlas
#

I have used it but wasnt sure about uploading them here. I think it would be good going forward to have a policy in place for trace files

#

or for anyone who knows how to debug them speak up or create a simple guide with basic things to look out for

final bough
#

you can extract the textures from the trace files, so would probably be sketchy, but if its just for debug purposes and the trace gets deleted after, I dont see a big deal

whole atlas
#

obviously am not saying someone HAS to do it, would be nice to understand it a little

whole atlas
final bough
#

yeah once you let it go through the replay you can inspect any frame and grab the texture

#

a pretty basic thing to look out for is if the game uses heavy Create/SetVertexShader or Create/SetPixelShader calls and little use on DrawPrimitive* or something.

#

if you find a CreateVertexShader call you can inspect the version of the vertex shader in the inspect window

#

and dump its assembly

#

you can kinda already do that though by setting DXVK_SHADER_DUMP_PATH as a system environment variable, and DXVK will do it for you

#

you can then convert the dumped *.dis file output to .html by renaming the extension for it and check it out there

fathom cave
final bough
#

I thought so too, so I tried modifying the code to force every draw call to be a rasterized fallback, and it still would not pass through the original content 😦

#

I tried in both internalPrepareDraw and endFrame

#

as far as I understand, returning with:

return { RtxGeometryStatus::Rasterized, false };

early in internalPrepareDraw should do that, but maybe not

#

it seems that PrepareGeometryforRT calls:

    if (!RtxOptions::Get()->enableRaytracing())
      return { true, false };

anyways before internalPrepareDraw is entered. and I have confirmed that setting is false in my build (enableRaytracing). this should set preserveOriginalDraw ... in DrawPrimitive*

final bough
#

hmm, stuff must not be making it into DXVK with this program for some reason, which is why rasterize is empty to begin with, contrary to APITrace 🤔:
I added this inside the present call

    Rc<DxvkImage> resolvedSrc = m_backBuffers.back()->GetCommonTexture()->GetImage();
    if (resolvedSrc == nullptr) {
      resolvedSrc = m_context->getFramebufferInfo().attachments().color[0].view->image();
    }
    m_parent->EmitCs([
      cSrcImage = resolvedSrc
    ] (DxvkContext* ctx) {
      takeScreenshot(ctx, "testImage", cSrcImage);
    });

its all null, so there is nothing to even output. how does vanilla DXVK do it 🤔

barren lark
#

Keeps crashing

#

1.4.0 and now 1.5.0

final bough
#

1.4 and 1.5 dont work properly without a bunch of hacks, and even then it will be just a black screen due to the shader pass through

#

0.9.4 is the only working one at the moment

#

I've been working slowly on a new render pipeline for the last commit in which d3d9 was still in the GDSx plugin source, but I wont be able to continue until next week as I am away for work.

#

if you use 0.9.4 you need to use the pcsx2t executable, then in the graphics settings, ensure deinterlace is enabled disabled, and select shader model 2.0

#

0.9.4 is still too shader heavy, and you will only get the ability to do texture replacements, no path tracing will be done

#

pcsx2 was never built to use a purely fixed mode outside of the software rendering mode, and even then that wont work with remix because the GS rasterizer will blit everything out to the screen

polar python
#

The one I want to do

IMG_20230708_041900285.jpg
#

as for a old pcsx2 plugin, there's ZeroGS for opengl it somehow went with it but ZeroGS ceased dev a long time ago

#

the reason as i posted about ps1 emulation is the later versions of pcsx2 have ps1 support

final bough
#

I dont think I will be able to get PS1 emulation working with the later versions as I am working off of a ~4 year old codebase which was the last commit which contained DX9 support. it would also require me to duplicate alot of this effort to the PS1 render chain as the PS1 does not use a VPU unlike the PS2, it uses the GTE.

#

not to mention many poly's are faked on PS1 due to the limited nature of the hardware, there really is not much geometry to path trace

#

but I will keep it in mind

#

another fact about PS1 rendering is backface culling is enforced. no poly's are ever rendered which are not facing the current GTE view transform

#

only the avocado emulator for PS1 supports removing backface culling through the 3d screenshot branch, but it us a super experimental hack ontop of the GTE rtps instruction

#

I won’t discount the idea though, I need to look how the latest pcsx2 handled GTE emulation without the same hardware present, and how it was really done on the PS2. I’m guessing there was some kind of emulation interposer that takes the GTE pipeline and emulates it in some way on the PS2 VPU. Not sure

#

According to the interwebs, the IO/P processor on the PS2 included an original PS1 core to provide the backward compatibility which included a GTE bound within that core. I’m guessing pcsx2 added that to the IOP code, somehow

polar python
final bough
#

… yes I am aware. Thanks though

#

See pinned

polar python
final bough
#

Np

red lintel
analog delta
#

Last commit was 10 hours ago so

red lintel
#

Still alot behind of aethersx2 unfortunately

final bough
#

aethersx2 development has been suspended for over a year now

# 
AetherSX2 development is indefinitely suspended.

Due to neverending impersonating, complaints, demands, and now death threats, I'm done.
red lintel
#

Yeah i know

#

But in terms of perfomance the aethersx2 is the one

final bough
#

Oh for sure

polar python
#

any more news on this

reef dome
#

Also interested in hearing about any news on this. I need PS2 Mark Henry to be even more beautiful.

#

Not that I think that's actually achievable, but it's a nice thought.

frank dust
#

So does this work yet?

tribal pendant
#

I don't think so

sly stirrup
#

Has any progress been made recently?

pearl citrus
#

Shader Model = 2

#

Renderer = Direct3D9 (Hardware)

#

Game = the fast and furious (2006)

dawn pike
#

god damn I haven't seen anyone use bandicam in god knows how long

lilac monolith
#

i thought that would be dead with the release of obs

pearl citrus
pearl citrus
#

Game = The fast and furious

dawn pike
#

you're gonna probably need a very old version that's running on dx9 still.

glossy cradle
#

check the logs

sand owl
#

yeah

#
  • the last compatible pcsx2 build
#

v1.5.0-2779

pearl citrus
drowsy herald
#

Any tips on getting this to hook "reliably"? I had a couple times where it hooked and ran the game fine on 0.9.2 but its really spotty. It will hook and run the game without issue a couple times, the other 100 times it locks up on the inital loading screen to the game

#

Literally got it to hook after trying it all morning and closed down the game to load lilypad plugin so I could play then it would constantly lock up on certain parts of the loading screen

final bough
#

There’s a reason there are no instructions for this, because it doesn’t work

#

When I had taken the images originally I did it with a modified copy of pcsx2

#

I gave up on development over a year ago

#

You really gotta read the messages in these channels, I’m not even sure where you even remotely got the impression this worked

#

Sorry to waste your morning

drowsy herald
#

Good morning to you too 🙂

#

I got it hooked right now but thanks for the words of encouragement man

final bough
#

Look, I’m not trying to be a dick here, but your gonna need a lot more than words of encouragement if you want this to work past hooking

#

That’s why you aren’t finding people who can help you with this

#

It’s never been done

drowsy herald
#

Just asking a quick question thats all, I'm not expecting a full tutorial on how to make the impossible happen. It seemed others had it at least hooking and I wanted to see how to get to that point but no worries

final bough
#

If you want this to work you’ll need a full tutorial on how to make the impossible happen 😂. The tips you seek don’t exist. That’s all I’m sayin

#

You can download or build my copy up there from .94 and it could help

#

At least you can render some games main menus

#

But it’s abhorrent

drowsy herald
#

Thanks, I"ll see if that helps any. Honest question, do you ever plan to work on it again? Definitely a big project considering the amount of work needed

final bough
#

I actually do. Currently I’m working on tomb raider legend support, but I really want to return to this one day with lessons learned. The biggest thing which needs to be figured out on this project is exactly how PCSX2 implements the vector unit and culling. There was a short honeymoon with PCSX2 where they used a extremely basic set of shaders to run the pipeline, the problem is the code in that state is soooo ancient, it has support for basically nothing else which the games require to be compatible today.

#

So what really needs to be done is the render pipeline needs to be completely rewritten for basic shader pass through, or the existing pipeline from .94 needs to be ported to the very last PCSX2 version which supported D3D9

#

There’s also many quirks to uncover and fix

#

Like custom texture formats, transforms, exotic VU culling, etc

#

But yes, I really want to do this again 🥹

#

The fourth method would be to take the simple d3d9 pipeline from .94 and convert it to fixed function draw calls

#

I’d say you could do all that in a few weeks if you knew what to touch

#

I also would like someone to help me see if there’s any other ancient pcsx2 style emulators which are source available and can be resurrected

#

I know for a fact there were several emulators during the era which used fixed function before we got TN cards with shader APIs

#

But they are exceptionally rare gems (mostly forgotten to time)

#

From what I understand the Xbox emulator works, but you’d need to ask @tribal pendant or @honest heath as they are the only people I know that understand how that works

#

It’s been awhile. I used to remember how to get that working, it’s been forever tho

tribal pendant
#

It didn't work very reliably and I only ever got it to work in one game which had to be modded first to load straight into the game past the menu, and it wasn't really playable regardless

#

Maybe that's changed now, but afaik it's not really worth trying

final bough
#

Oh darn. I remember you shared some screenshots of the incredibles that looked alright but it’s fuzzy

tribal pendant
#

IMO people's efforts are better spent just integrating the RT pipeline into the emulator itself rather than trying to get remix to work

tribal pendant
final bough
#

Ohhhhh

#

My bad

final bough
# tribal pendant IMO people's efforts are better spent just integrating the RT pipeline into the ...

I’d agree for the most part, but unfortunately they haven’t split the RT pipeline from the main code, otherwise that would be so awesome and I could just start replacing the entire API. the next time I attempt it I might try using just the bridge and extend a bunch of functions out from that API to hopefully make it more consistent to apply the RT pipeline code-wise versus just making remix work like you say

honest heath
#

there are quite a few games in cxbx-r that work now

#

but it's very very hit or miss, and the ones that do work have some issues

pearl citrus
final bough
#

…. Read the back scroll

#

tl;dr PS2 emulation doesn’t work right now. Try something else

dawn pike
pearl citrus
final bough
pearl citrus
drowsy herald
#

For those looking to tinker I found a way to make it hook on every launch + have some affect on the visuals
Use PCSX 0.9.2 + dxwrapper + WinXP Service Pack 2 compat. + Disable Full Screen Optimizations and set the graphics plugin to 'ZeroGS KOSMOS (non sse2) 0.96.0'
It does have issues finding a camera but this is a much more reliable way to get it hooking compared to what I had before. As mentioned before, getting it to hook is just the start so again just for those looking to tinker

sand owl
#

it's pointless

#

that version is wayy too old

drowsy herald
#

of course most games dont run worth a damn on 0.9.2 but again if someone wanted a good starting point to get it to find a camera that would be it

#

0.9.4 and 0.9.8 worked sometimes but would often crash within minutes, the method above hooked every time, while not finding a camera keep in mind lol

final bough
#

It can’t find the camera because it’s still using shaders or pre transformed vertices. So back to the pinned message state (a build that is designed to hook without a bunch of hacks)

sullen root
shrewd hare
#

ill let this out there. this emulation doesn't seem as far along as most. any advancements in a few ps2 games? i have a couple in mind.

limpid flicker
#

This is still in the theoretical stage as far as I am aware. The only emulators that kind of work with Remix are CXBX Reloaded (albeit almost always with missing geometry) and Project64 (only a few games known to work and too many issues to be viable for remastering)

sand owl
#

It doesn't work

rustic sable
#

So pcsx2 is still not working?

#

What about PSP Emulator?

sand owl
#

no chance

#

most emulatora use vulkan these days

honest heath
#

PPSSPP does support DX9 in older builds, and unlike PCSX2 those builds were actually usable

#

but i don't think it'll work with Remix, even with the shader hack

viscid radish
honest heath
#

emulators just tend to have pretty hacky and insane rendering methods lol

viscid radish
#

ik dolphin uses compressed verts but it might be worth trying other emus with d3d9 backends with the fake camera build

#

i could give ppsspp a go in a bit

viscid radish
#

ppsspp works on x64 and x32 but i cannot open the remix menu

image.png
#

ill try adding a rtx.conf with the fake camera enabled and see if it hooks into something

#

ok nvm it crashes when the fake camera is enabled 🥀

olive pond
#

So I added dx9 back into pcsx2 and remix hooks into it

image.png
obtuse gust
olive pond
#

Just looked at how they did it with dx11 and 12 and made dx9 draw the meshes and textures

#

With some help from an AI

obtuse gust
#

Any plan to share the file(s)?

olive pond
#

Yeah I will share after figuring out a couple things

pliant lark
olive pond
#

Yeah I managed to fix it now

pliant lark
#

What games have you tested on it?

olive pond
#

Just FFX so far

olive pond
#

got depth working better

image.png
pliant lark
#

I wish emulator devs would make a push for working depth buffers

#

I know dolphin is trying to improve graphics mods but bro I dont know if they are still working on it

olive pond
#

We may have raytracing with a very shiny Tidus

image.png
sand owl
#

Is this the latest pcsx2 but with dx9 brought back?

#

or the old ass ancient version?

obtuse gust
#

New, as you can see the UI is the one that’s used today

olive pond
#

Some updates. I somehow broke the shininess but Remix is picking up geometry and the camera as well as trying to raytrace. So if someone wants to figure out how to get stable hashes and replace some assets as a test that would be awesome. When you build it you will have to add the remix files to bin/

obtuse gust
#

I wouldn't know how to do that but I'd love to test the current build you got going on now, I have many games to try

olive pond
#

Going to figure out how to do the github release stuff

obtuse gust
#

Roger, I'm so hyped!

olive pond
tawdry zealot
#

I got The Warriors to boot up but it crashed when I tried to take a capture. Odd thing is all the textures appear to transparent for some reason and it's interesting in how they're named as if their coordinates of where the mesh is located or some kind of hex code.

📎 CF35D22D40CCDE7E.dds
olive pond
#

That was me trying to figure out a way to organize meshes but it didn't really amount to anything

olive pond
#

I did find that we might have to figure out how to disable culling in the actual ps2 or intercept the console before it renders anything but that would involve reverse engineering the bios/games most likely

limpid flicker
spare dawn
#

Bloody Roar 3 kinda works as well as Pac-Man World Rally. Can’t capture a scene without it crashing though. Also unable to figure out the per game settings as mentioned on the GitHub. Maybe missing folder structure? Overall very promising.

shrewd hare
limpid flicker
#

But I do think with some work, this definitely could be viable.