GSdx
(01-18-2014, 01:10 AM)Asmodean Wrote: tsunami2311: They're not supposed to update the options you've selected inside the GSdx dialog. They're for toggling on and off on the fly, while the emu is running. Use the option checkboxes for permanent settings.

Edit: now that I think about it. maybe it would actually make more sense to have them update the ini options? lol. I dunno, it's not really that big of a deal though, is it.

no biggy it just kind confused me how the menu said they where off, yet the log window said they where on, so figure it might be bugish in general I just setting it to 1 for FXAA (in past) now i just gona set ShaderFX to 1 in ini and leaving it be.
Reply

Sponsored links

The toggles are how they should be now:
Permanent if you tick them in the GUI, hotkeys for toggling ingame (and disabling when leaving the game).
This is consistent with most other hotkeys so all is well Smile
Reply
build removed, to avoid confusion.

Updated the testing build above. Some small changes/finished the description etc.

I'll do the dx9 code for it tomorrow, along with trying out some halftexel stuff.
Reply
Managed to find a CRC hack for Nocturne that gets rid of shadows, which resolves that really annoying shadow issue (where you can see the character's shadow through their model) Smile
I've only tested for the NTSC-U version, so I'm not sure if it'll work in other versions - might need to be tested some more cause it might have other issues as well. About to start a play through of the game so I'll post if I find any issues with this hack

Can one of the main devs merge this GSState.cpp file with their own?


Attached Files
.cpp   GSState.cpp (Size: 137,1 KB / Downloads: 212)
Reply
Nice, I was playing SMT:Nocturne just the other week and was annoyed by the shadow thing.
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
Reply
I'm trying to fix the slowdown issue with Shadow Hearts in HW rendering mode

I know what the problem is, I'm just having trouble trying to figure out how to deal with it

essentially, the problem stems from having backgrounds which are sprites
the game splits the screen into 40x38 (or something like that) blocks and then loads an individual object for each

The problem is, each of these sprite objects are of the same background image, which is something like 1536x1920 pixels and each of the objects selects a small sub-area of that image. The problem with this is that you're loading the same 1536x1920 image 1520 times for each frame which is what causes the tremendous frame rate loss

There's then a few possible solutions;
1. find some way to render the full image with a much smaller number of objects (ie. 40 sprites with each sprite being 1920 pixels across instead of 1520 sprites)
or
2. Cut the original image up earlier so you're not loading the full 1536x1920 image every time
3. Convert the sprites into triangles (polygons) like in the FF12 hack (this is probably the one I'm going to try and figure out how to do)

These are the possible solutions but I don't know how to implement them; any ideas from the devs who are more familiar with the code?
Reply
interesting description @htb123.

i guess this' a "scrolling tiles" background. a technique similar to the gba. it's pretty tough for gsdx. the problem perhaps is that it's uploading the border fragments in rows or columns at the edges. in the memory it looks even more wierd cause the rendered offset is different then the memory. it's scrolling. i guess the style of loading is not texture cache firendly.

whether you gotta make it a complete and seperate flux texture surface and use subrect uploads. or throw the cache technique over and do that with smaller fragments instead of transfer like texture surfaces. i dunno if this is controllable tho.

the easiest to check is if it's using a texture format that needs to be "converted" to render. i tought something was in gsdx too. in that case you'd need a routine that does that per 16x16 fragmented style, not the whole texture page.
Reply
Got the AF working on Dx9. It was a bigger pain to get working for d3d9, than it was for d3d11, as per usual.

I'll upload a build in a bit. I'll up a patch and source when I'm finished working on it.
Reply
(01-18-2014, 08:04 PM)Asmodean Wrote: Got the AF working on Dx9. It was a bigger pain to get working for d3d9, than it was for d3d11, as per usual.

I'll upload a build in a bit. I'll up a patch and source when I'm finished working on it.

DX9 is that for sure, its one rendering system that should be put out to paster. Sadly even with consoles now be-able to be DX11 I dont see this happen anytime soon (lazy devs porting to to PC, that and to many people still have DX9 only cards. Even more people by brand new 500$ laptops and think it will run this emulator but whole other issue lol

None the less kudus on AF implantation
Reply
Finished the AF. Link to test build, Plus patch & source below;

Final updated test build & a few screens here

Patch & Source;

.zip   GSdx_AnisotropicFiltering.zip (Size: 1,04 MB / Downloads: 392)

I also added the post processing init functions to dx9. To see if it sorts the vs 2010 bs, for the time being.
Reply




Users browsing this thread: 10 Guest(s)