D3D/OpenGL shader thread. Reborn.

Place to talk about all that new hardware and decaying software you have.

Moderator: General Mods

mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

http://stashbox.org/1109222/toon.JPG

Was trying to come up with a watercolor method that does *not* suck and ended up with this.
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

Code: Select all

/* Default Vertex shader */
void main_vertex
(
   float4 position   : POSITION,
   float4 color   : COLOR,
   float2 texCoord : TEXCOORD0,
    uniform float4x4 modelViewProj,
   out float4 oPosition : POSITION,
   out float4 oColor    : COLOR,
   out float2 otexCoord : TEXCOORD
)
{
   oPosition = mul(modelViewProj, position);
   oColor = color;
   otexCoord = texCoord;
}


struct output
{
  float4 color    : COLOR;
};

struct input
{
   float2 video_size;
   float2 texture_size;
   float2 output_size;
};


static const float BlurWeights[13] =
{
    0.002216,
    0.008764,
    0.026995,
    0.064759,
    0.120985,
    0.176033,
    0.199471,
    0.176033,
    0.120985,
    0.064759,
    0.026995,
    0.008764,
    0.002216,
};

float edge_detect_sobel(sampler tex, float2 tc, float2 off)
{
    // sobel
    half4 g00 = tex2D(tex,    tc + half2(-off.x,    -off.y));   // Top Left
    half4 g01 = tex2D(tex,    tc + half2(  0,    -off.y));   // Up
    half4 g02 = tex2D(tex,    tc + half2( off.x,    -off.y));   // Top Right
    half4 g10 = tex2D(tex,    tc + half2(-off.x,      0));   // Left
    half4 g12 = tex2D(tex,    tc + half2( off.x,      0));   // Right
    half4 g20 = tex2D(tex,    tc + half2(-off.x,     off.y));   // Bottom Left
    half4 g21 = tex2D(tex,    tc + half2(  0,     off.y));   // Bottom
    half4 g22 = tex2D(tex,   tc + half2( off.x,     off.y));   // Bottom Right

    //compute luminance from sampled regions
    float3 rgb2lum = float3(0.3, 0.59, 0.11);
    g00 = dot(g00.rgb, rgb2lum);
    g01 = dot(g01.rgb, rgb2lum);
    g02 = dot(g02.rgb, rgb2lum);
    g10 = dot(g10.rgb, rgb2lum);
    g12 = dot(g12.rgb, rgb2lum);
    g20 = dot(g20.rgb, rgb2lum);
    g21 = dot(g21.rgb, rgb2lum);
    g22 = dot(g22.rgb, rgb2lum);
 
    //compute sobel mask
    half4 Gx = -(g00 + 2 * g10 + g20) + (g02 + 2 * g12 + g22);
    half4 Gy = -(g00 + 2 * g01 + g02) + (g20 + 2 * g21 + g22);
    half4 color = abs(Gx) +abs(Gy);
   return color;
}

output main_fragment( in float2 Tex : TEXCOORD0, uniform sampler2D s0 : TEXUNIT0,uniform input IN )
{
   float edgeColorAmount = 2; 
   float Detail = 1;

   float4 outcolor = {1.0f, 0.0f, 0.0f, 1.0f};
   float2 texelSize = 1.0 / IN.texture_size;
   float2 offset = { texelSize.x, texelSize.y };

   float gradient = edge_detect_sobel(s0, Tex, offset);
   gradient = saturate(gradient*0.2);

   float4 sum = 0;

    for (int i = 0; i < 13; i++) {
        sum += tex2D(s0, Tex.xy + (i-6) * offset.xy) * BlurWeights[i];
    }
    float4 pixelColor = tex2D(s0, Tex);
    outcolor = ( gradient*Detail*(1-edgeColorAmount) + gradient*Detail*pixelColor*edgeColorAmount + sum);


   output OUT;
   OUT.color.rgb= outcolor;
   return OUT;
}


Themaister's shader for waterpaint sux dix. Doesn't blend the colors, this does, is configurable.
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

Squarepusher
New Member
Posts: 8
Joined: Mon May 09, 2011 4:13 pm

Re: D3D/OpenGL shader thread. Reborn.

Post by Squarepusher »

Hi there mudlord,

I really liked your shader - in combination with other shaders (like 4xSoft-HD-1344x752.cg) it really looks terrific - so I took the liberty of adding it to SNES9x PS3/VBA PS3/Genesis Plus GX PS3/FCEU PS3. I hope this is alright with you - shader is called waterpaint-mudlord. Chrono Trigger with 4xSoft-HD-1344x752 almost looks like Saga Frontier 2 - that's the closest comparison I could think of.

I posted some raw screendumps from my PS3 here:

http://psx-scene.com/forums/f190/new-sh ... post813835

BTW, I really need to talk to you about VBA - perhaps we can do this over PM (as to not derail the thread). I am still heavily reliant on a profiler that has to wade through the code first and detect any possible stuff that can be further optimized away. The graphics code is just a branch nightmare - hopefully you know GBA.cpp/Mode 0/Mode 1/Mode 2/Mode 3/Mode 4/Mode 5 source files well enough so we can take some stabs at better optimizing this thing for systems where branches are expensive (as in - PS3/Wii).

And believe me, performance in VBA PS3 is heavenly compared to VBA Wii - the latter is even far worse, and has to resort to frameskipping to run anything decently. The only reason the PS3 port runs as well as it does right now is because Lantus made some speedhacks here and there and kindly contributed them (it's from his VBA 360 port). And it still doesnt' run well enough for my taste - I can visibly tell every time an additional sprite gets added to the screen - Level 1-2 in Super Mario Advance 2 is a good case in point example with the 7/8 Koopas on the platform - you will notice some framerate hiccups because of the massive amounts of sprites and because gfxDrawSprites is just a total branch clustertrainwreck - that stuff really hurts the PS3 PPU's poor feelings - as it does the little Broadway CPU in the Wii. No point in even thinking about making this a target for vectorization at some point since the SPUs (which are meant to do that) don't have branch prediction - so you're really left with Altivec as a last resort. Ideally, all of the gfxDraw* functions should have as little amount of branches as possible - so we have something to work with.

But I'm hoping there's more stuff that can be optimized that doesn't require going with a total core rewrite - like VBA-2 (if that thing still exists).
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

I think honestly thats the best way to do it :(
A rewrite with consoles in mind.
Spacy is busy with university (last time I heard from him, he has been tinkering with....Java, so that makes that PS3 stuff impossible), so VBA2 for him is on hold.

Sprite caching might help, I know Exophase has some ideas about that...

Is there any good resources for console coding? Like some guidelines? I currently don't have any console to try shit on, let alone a PC thats old enough for good speed testing. I am stuck with...a hex core, 8GB RAM, and a gtx460 I'm afraid....

And yes, that shader can be bundled with those emulators, as long as its not bundled with any bsnes shit.
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

Sorry about speed with my shader.
I tried the Robert's Cross algorithm for edge detection...didn't work out quite as planned, so stuck with Sobel. Prewitt would have been worse as thats 1 extra texture lookup.
Squarepusher
New Member
Posts: 8
Joined: Mon May 09, 2011 4:13 pm

Re: D3D/OpenGL shader thread. Reborn.

Post by Squarepusher »

In-order PowerPC development (especially on consoles) is an exercise in sadomachosism - especially when you're an 'unauthorized' developer lacking a true 'debug unit' so nice stuff such as remote debugging, Tuner and stuff like that is mostly out of your reach - well, at least that is the situation with PS3 so far. Programming for PS3 is like going back to the '80s/'90s in terms of programming methodology.

I've got a few nice blog posts from experienced devs (they all work for a company of some sort that makes games) that can give you a snapshot of what to expect -

http://cbloomrants.blogspot.com/2010/07 ... uxors.html

http://cellperformance.beyond3d.com/articles/

http://macton.smugmug.com/gallery/89367 ... 6709_ZX4pZ

(Mike Acton is one of the coding gurus at Insomniac Games and is a card-carrying member of the 'Data-Oriented Design' club. Some of his pals include guys from Q-Games and other mainstream commercial devs - they're being surprisingly open about their development work and publishing much stuff - including PS3 SPU sourcecode).

Basically, write very conservative C++ code (C is preferable) - avoid virtuals like the plague (yes, I'm currently ripping out all class inheritance and virtual functions in VBA right now - Multi_Buffer - Stereo_Buffer - Effects_Buffer - and so on) - make sure that your code blocks are big so that the code can be better pipelined - identify cold-hot code and deal with it - avoid Load-Hit stores - avoid L2 cache misses (this seems to be the biggest offender so far ) - avoid branches because these give you pipeline stalls (luckily for us eh that VBA is absolute branch hell eh? :)). Don't rely on the compiler to inline stuff for you - the compiler is very dumb in PS3's case (GCC 4.1.1 and/or SNC - they have built-in inlining limits, they pull in a lot of headers from the big 'S' that do all sorts of funky shit that increases the possibility of you running into the limits of those built-in inlining limits - increasing inlining limits has done nothing but produce slower code - so the best rule of thumb here is according to professional PS3/360 devs - the compiler is dumb, the code generation is bad, so coax it into producing better code) - ghetto inline functions or just try to do as little function calls as possible.

I think the biggest speed boost could be if we rewrote the graphics code to be a target for vectorization (in the PS3's case - that could be done using either Altivec or the SPUs). For that to be possible, we really need to cut down massively on the branches - we can make most of it branchless with a software implementation of isel, but far better to just eliminate them altogether instead of making the 'branches' branchless.

Knowing where to prefetch stuff into the cache is likely to pay off big as well. Making sure structs are well padded out.

You can check out some of the stuff I've done to the core so far -

https://github.com/squarepusher/VBA-PS3

It's mostly me just randomly throwing shit on the wall right now and seeing what sticks or actually results in a speed boost. That being said, I have managed to clean up VBA a bit already - it must be said that there's a lot of questionable stuff in there that barely even does anything - or I fail to see the need for it - such as this thing I found in all of the Mode files that allowed you to set a different color for the color 'black' in the background - that really took me back as being particularly unnecessary - indeed even costly - when having to deal with branches for that stuff every frame - and then that's for every graphics mode as well.

BTW - me ripping out the SFML code entirely resulted in Sonic Advance 1/2 working again. Just so you know in case you were not aware of this.

Just for the record - games that have proven to be particularly CPU-intensive so far on PS3/360 - Final Fantasy 5 - Final Fantasy 6 - Sega Rally - Doom. The 360 port (Lantus) right now runs a bit better than the PS3 because he can just use OpenMP on the other two PPE cores (PS3 is totally reliant on its 6 SPUs in that regard) - but even the 360 port can't handle these games at fullspeed.
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

Wow...Thanks for the notes! Do appreciate them. I'll keep them in mind while I do this next emulator (no ETA at all, and development on shit of mine has been fragmented enough as is)..
Shame that even Blargg's APU code is bad D: I seriously thought that even his code would be fine for speed. I am astounded honestly that its not. Sony's crap is really *THAT* bad???

BTW - me ripping out the SFML code entirely resulted in Sonic Advance 1/2 working again. Just so you know in case you were not aware of this.


Hearing that made me rofl. SFML is just for linking anyway with Dolphin as a form of emulator interop iirc. Your end users might not want that...:P
vigi_lante
Rookie
Posts: 37
Joined: Mon Nov 15, 2004 5:05 am

Re: D3D/OpenGL shader thread. Reborn.

Post by vigi_lante »

Thanks Squarepusher. Very good read. Do you think we can also expect to see sound interpolation in the PS3 version of VBA?
adventure_of_link
Locksmith of Hyrule
Posts: 3634
Joined: Sun Aug 08, 2004 7:49 am
Location: 255.255.255.255
Contact:

Re: D3D/OpenGL shader thread. Reborn.

Post by adventure_of_link »

mudlord88 wrote:Sony's crap is really *THAT* bad???

after the recent games with the PSN and such, I believe Sony just went from bad to worse..
Image
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

byuu is pissing me off.

http://stashbox.org/1112972/fuckbyuu.JPG

The shader is not public because its broken because of byuu. (it needs some outside changing variables for it to work)

As a result, my noise is not dynamic. Because of his fucking reluctance to implement a framecounter because he feels its a hack etc.
I NEED a framecounter! If you want good shaders, IMPLEMENT A TIMER OR SOMETHING!!!
Squarepusher
New Member
Posts: 8
Joined: Mon May 09, 2011 4:13 pm

Re: D3D/OpenGL shader thread. Reborn.

Post by Squarepusher »

Alright guys - are there any more fluff things in VBA that I could safely comment out? AGB Print I also ripped out just for the sake of it, though it didn't do much if anything for performance - at least it shrunk filesize down.

Also - what's with all the dead fluff loops in the original codebase that serve no purpose? Also, the overabundance of switches poses another problem for PS3/360/Wii - I saw a lot of opportunities to eliminate the switches altogether - that would be the best way to go about it.

Here are some technical details about switches and why they're a performance hazard in general -

http://cmpmedia.vo.llnwd.net/o1/vault/g ... 4428i1.pdf

Virtual function calls and switches

Since their introduction, virtual function calls have proven to be an extremely
useful tool for abstracting class behaviour.

However, this comes at a terrible price.

A virtual function call has to fetch the address from memory, often invalidating
the dcache, and then make an indirect call which invalidates the icache.
In very cold code this will introduce over a thousand cycles of latency.

So it is best not to use virtual functions to fetch variables from classes;
reserve them for very high level functions.

The same applies to switch statements that may use indirect branches also.
Be careful to group case values so they are sequential, otherwise the switch
will have to be broken into a tree of branches.

Some compilers use the convention that the first case label is executed most
frequently which can be used to hint to the compiler. It may be worth
maintaining this convention until we fully support it.


It would be helpful if someone like Exophase could chime in and give me a rundown on what parts of VBA are the worst bottlenecks and the parts that would require the most editing to speed it up. Lacking a hardware Tuner and any kind of useful debugging, it's kinda hard to tell.

Can something like gfxClearArray be done with Altivec? We seemed to give it a try at one point and it proved to be a deadend. Perhaps we're doing it wrong.
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

oh, themaister came to the rescue and implemented the counter \0/, all is well in Cg land :D
as for VBA: yeah, a lot of shit needs to be redone. So much in fact that I really think that fixing it for consoles, means rewriting the damn thing.

Sorta like why BSNES on consoles fails.
Squarepusher
New Member
Posts: 8
Joined: Mon May 09, 2011 4:13 pm

Re: D3D/OpenGL shader thread. Reborn.

Post by Squarepusher »

Haha, bSNES on PS3 - now that was a funny story. After news broke out that SNES9x had been ported to PS3 (by an initial porter other than me - I took it over after that - the initial port wasn't even that good to be honest) - byuu really wanted to see bSNES on PS3. He used to bash the Wii for its performance and said that PS3, on the other hand, would be the ideal target for bSNES.

That's how Themaister got involved with me in the first place.

Byuu was totally convinced it was going to run Compatibility core at over 60fps on PS3 - he was like - oh my Atom runs Performance core at 190fps - the 3.2GHz Cell CPU should eat it up - and when he learned I was doing work on SNES9x PS3 - he at first tried to setup some dialogue between me and him. I didn't know enough about bSNES at the time though to do it - so Themaister became involved and he ported SSNES (bSNES) to PS3 - but it ran at 40fps max - 50fps now probably with Super Mario World - and that's with Performance core.

Anyway, byuu found this hard to believe - that his code ran like shit. And I guess he simply walked away from it frustrated by feigning he didn't care and just saying - meh, PS3 sucks - they're lying their ass off about the core speed - they're doing their engineering wrong - and so on. He even made some analogies that the PS3 would have been better if they just stuck an Atom in it - Exophase straightened him out on that by basically saying that you have to program with the architecture in mind (as in - using the SPUs and not only the PPU) and that a quad-core Atom console would be the laughing stock of the console world. Then came the straight comparisons between the Apple G4/G5 and the PS3 which according to many people I talked to (Halsafar, Lantus) were totally ridiculous comparisons.

Personally, I think he still feels bad about this - that SNES9x PS3 vs. SSNES PS3 actually confirmed that there is still a huge performance gulf between the two emus. Personally, my opinion - his insistence on cutting-edge C++ is what is absolutely killing performance on in-order consoles. And to be honest, it doesn't make much sense to me that he's going with C++0x when that standard has not even been 'standardized' - whether he wants to acknowledge it or not, he is actively marginalizing bSNES by going with C++0x - because that will exclude a lot of platforms that don't even have a C++0x-compatible compiler.

All in all, I think bSNES would actually perform a hell of a lot better if he would refrain from doing so much homespun stuff and just sticked to what's already available instead - no libco, no Ruby, no Phoenix, no libnall, no 'lib-whatever', no overabundance of virtuals, no quadrillion classes, and so on.

Really, the sourcecode itself is not all that important - it exists to be hacked up, and to be made as fast as possible. When users run a program, nobody gives a damn what the source looks like - what they care about are the end results - how it runs. I feel he should be a lot more pragmatic about this - it doesn't mean making the source a complete mess like I'm known for doing - but there has to be some middleground between wanting to do things nice and doing things with speed-efficiency in mind.
Squarepusher
New Member
Posts: 8
Joined: Mon May 09, 2011 4:13 pm

Re: D3D/OpenGL shader thread. Reborn.

Post by Squarepusher »

mudlord88 wrote:oh, themaister came to the rescue and implemented the counter \0/, all is well in Cg land :D
as for VBA: yeah, a lot of shit needs to be redone. So much in fact that I really think that fixing it for consoles, means rewriting the damn thing.

Sorta like why BSNES on consoles fails.


I've seen you say in the past that the Forgotten VBA codebase is an absolute disaster - I'd say that is pretty much an understatement - it's a disaster from a performance perspective. There's so much redundant waste in there it feels like a wasteland. I wonder if the C/C++ code is actually a port from Assembler - because a lot of this stuff just doesn't make any sense to lay it out like this - it's like there's an actual conspiracy involved to have the compiler create shoddy code gen when it has to run its teeth through this code.

To be honest, I'm astonished the VBA-M team has not bothered cleaning up or rewriting some of the core stuff - there's a lot of stuff that just sticks out like a sore thumb that could be very easily replaced and would probably gain you some better performance on nearly all platforms. Are they just afraid they might break some stuff in the process and would have to put some time and research in to fix it? Because, as they say, you can't make an omellete without breaking a few eggs.

Even stranger is why things such as Sonic Advance 1/2 incompatibility has still not been fixed due to an insistence on having GBALink in there - I mean, if linkup code is going to break game compatibility, there should be at least an option to toggle it on/off. Perhaps I'm missing something here, but like I mentioned, I had to comment all that stuff out altogether manually to get those games to work again. That to me seems like a serious oversight on the part of whomever implemented that GBALink code.

At least lag went way down on VBA PS3 by commenting out a large chunk of stuff that wasn't even necessary.
Last edited by Squarepusher on Sat May 14, 2011 12:35 pm, edited 1 time in total.
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

To be honest, I'm astonished the VBA-M team has not bothered cleaning up or rewriting some of the core stuff - there's a lot of stuff that just sticks out like a sore thumb that could be very easily replaced and would probably gain you some better performance on nearly all platforms. Are they just afraid they might break some stuff in the process and would have to put some time and research in to fix it? Because, as they say, you can't break an omellete without breaking a few eggs.


Thats mainly it, laziness, and that since the code is such a mess to read, wouldnt want to break shit. I'm currently doing some GB stuff atm from scratch, which should not have those issues. And as well as being in pure C.

Even stranger is why things such as Sonic Advance 1/2 incompatibility has still not been fixed due to an insistence on having GBALink in there - I mean, if linkup code is going to break game compatibility, there should be at least an option to toggle it on/off. Perhaps I'm missing something here, but like I mentioned, I had to comment all that stuff out altogether manually to get those games to work again. That to me seems like a serious oversight on the part of whomever implemented that GBALink code.


The outsider who did it did it for Dolphin <> VBA-M compatibility for 1-2 games. Since said outsider is a idiot, will most likely remove that code at some stage.
I.S.T.
Zealot
Posts: 1325
Joined: Tue Nov 27, 2007 7:03 am

Re: D3D/OpenGL shader thread. Reborn.

Post by I.S.T. »

I would say that byuu is too clever for his own good. That and a stubborn insistence on not listening to what others say unless he already has respect for them.
grinvader
ZSNES Shake Shake Prinny
Posts: 5626
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Re: D3D/OpenGL shader thread. Reborn.

Post by grinvader »

I.S.T. wrote:I would say that byuu is too clever for his own good. That and a stubborn insistence on not listening to what others say unless he already has respect for them.

And quickly losing respect for anyone that doesn't think like him/go along with his latest coding mood swing.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
I.S.T.
Zealot
Posts: 1325
Joined: Tue Nov 27, 2007 7:03 am

Re: D3D/OpenGL shader thread. Reborn.

Post by I.S.T. »

grinvader wrote:
I.S.T. wrote:I would say that byuu is too clever for his own good. That and a stubborn insistence on not listening to what others say unless he already has respect for them.

And quickly losing respect for anyone that doesn't think like him/go along with his latest coding mood swing.


That's like saying water is wet.
Squarepusher
New Member
Posts: 8
Joined: Mon May 09, 2011 4:13 pm

Re: D3D/OpenGL shader thread. Reborn.

Post by Squarepusher »

Hey Mudlord - another excellent shader (the Noise one). Definitely keep them coming. By all means do keep mentioning when/if you're feeling limited by the shader specs again - because so far, the results have been top notch.
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

Hi,

I am currently porting a FB2K DSP set I made to SSNES.

Code: Select all

#include "ssnes_dsp.h"
#include <string.h>
#include <stdio.h>
#include "phaser.h"

static float buf[1024];
Phaser echo_dsp;
static void* dsp_init(const ssnes_dsp_info_t *info)
{
   echo_dsp.SetDepth(100);
   echo_dsp.SetDryWet(128);
   echo_dsp.SetFeedback(0);
   echo_dsp.SetLFOFreq(0.4);
   echo_dsp.SetLFOStartPhase(0);
   echo_dsp.SetStages(2);
   echo_dsp.init(info->input_rate);
    fprintf(stderr, "DSP_INIT\n");
    (void)info;
    return (void*)-1;
}

static void dsp_process(void *data, ssnes_dsp_output_t *output,
      const ssnes_dsp_input_t *input)
{
   fprintf(stderr, "DSP_PROCESS\n");
   (void)data;
   output->samples = buf;
   int num_samples = input->frames * 2;
   for (int i = 0; i<num_samples; i++)
   {
      buf[i] = echo_dsp.Process(input->samples[i]);
   }
   output->frames = input->frames;
   output->should_resample = SSNES_TRUE;
}

static void dsp_free(void *data)
{
   fprintf(stderr, "DSP_FREE\n");
   (void)data;
}

static const ssnes_dsp_plugin_t dsp_plug = {
   dsp_init,
   dsp_process,
   dsp_free,
   SSNES_API_VERSION
};

const ssnes_dsp_plugin_t* ssnes_dsp_plugin_init(void)
{
   return &dsp_plug;
}


Some reason, the audio works fine after a while and goes kaput (some buffer might be starved?).
DLL is here: http://www.sendspace.com/file/z5g3aj
Same goes for the DSP example you posted...so I dunno at all what the issue is.
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

http://www.youtube.com/watch?v=S_42K9IJhMg

Sound gets messed after 15 seconds due to above sample buffer issue.

Concept of cross platform reverb+echo...
Themaister
Rookie
Posts: 13
Joined: Wed Mar 30, 2011 10:57 am

Re: D3D/OpenGL shader thread. Reborn.

Post by Themaister »

I think I see an issue.
You're using the debug messages fprintf(stderr, "DSP_PROCESS\n"); etc. When SSNES is started from the GUI, it will pass stderr to a GUI texbuffer, which gets filled quickly if spammed to, and after a while it performs like shit (crackles, etc since it can't keep up with 60 fps, lol). Tried to remove those? Forgot to remove them from the example code it seems :P
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

Silly me, that fixed it entirely.

Now to add a config and crap....
mudlord88
Lurker
Posts: 115
Joined: Sat Nov 20, 2010 12:43 am

Re: D3D/OpenGL shader thread. Reborn.

Post by mudlord88 »

Working:
http://www.youtube.com/watch?v=kax73ALOdIc

Is it possible to extend the API to allow dialogs or something? And a human readable ID of the DSP plugin?
Post Reply