jerrinx

Hey Phil,

 

Your damn right.

I could have just used placement on each element !!

I R IDIOT

 

Thanks for the link too !!

 

Regards,

Jerry

Hey guys,

 

Thanks for your replies.

 

@L. Spiro.

A *pArr = new (pMem) A[4]; is not casting operation. It goes through operator new[] overloaded function.

It is used when you want to initialize an array of elements (calling constructors) given pre-allocated memory.

 

@Martins

I agree that void* to A* will not change address.

If you notice the operator new[] is not changing the address. It is returned as such. Also in delete[] the value obtained is -4 of the address passed in (In other words the original address allocated). So the new[] operator is doing a +4 and delete is doing a -4. C++ is doing it !!

Try executing the code on your computer.

 

Also an update on my find:

I've tried the above code on a variety of different configurations. On Windows, On Unix and on A 64 Bit Application.

 

Here are my observations, when using In Place new[] operator overloading:

1. The memory returned from operator new[] is shifted forward by sizeof(size_t).

2. The memory passed as argument to delete[] is shifted back by sizeof(size_t).

3. The size argument to operator new [] will be equal to (sizeof(class) * numofArray) + sizeof(size_t).

4. The first size_t bytes of memory returned from new[] contains the number of elements allocated.

 

Also please note the above code needs to be changed to allocate +sizeof(size_t) memory to function without memory problems.

void *pMem = malloc(sizeof(BaseString) * 4 + sizeof(size_t));

 

I am wondering whether this is a C++ standard. If it is, I'd tweak the addresses myself and use it.

Managed to port glsl code to hlsl for FXAA.
Seems to work.

Attaching it for people who need it. It looks simpler than the Fxaa 3.11. I am guessing its the old version. But it performs better.
Tried with and without Luma. Works in both cases.

On DX9 you need to do color space conversion, in order to use it correctly.

I do something like this:

Stage 0
Render Main Scene to texture
- Texture Read convert - SRGB to Linear
- Texture Write convert - None

Stage 0.5 (Optional, if filling alpha with luma)
Render Texture to Texture
- Texture Read convert - None
- Texture Write convert - None

Stage 1
Render Texture to Monitor using FXAA
- Texture Read convert - None
- Texture Write convert - Linear to SRGB (as Monitor requires SRGB format)

Hopefully that clarifies some stuff.

For now this works.

@Dragon. Couldn't get the Fxaa 3.11 to work though. I rechecked all the variables, I am not sure whats the problem. if you find something wrong, please tell me. Attaching the updated old one again. Attaching some part of the code, if someone wants to see.

I have a question
FPS drops as follows (@1080p):
- Normal Render (1500 FPS)
- Render To Texture (1000 FPS)
- Texture To Scene with FXAA (500 FPS)
Is that normal ?

Jerry

Hey Thanks guys.

Like Hodgman said, My initial setting was 1/2 texel size off on DX9.
After fixing the issue the textures still renders the old jaggy pattern

Initially I noticed some difference in the image when rendering to texture vs normal rendering in the case of DX9.
Now, both look the same. I am assuming the 1/2 texel problem is accounted for.

@dragon.R
I used this article to understand the color space stuff
http://filmicgames.com/archives/299

Tried to use the color space as in the Fxaa_3.11 header. But still no dice.

Reattaching updated shaders.

lol... Maybe I should go for SMAA
https://vimeo.com/31247769
Fxaa3 (lower quality 0.62 ms) vs SMAA Tx2 (higher quality 1.32 ms)
Hard to decide

Thanks guys
Jerry

Cool thanks man.

Btw saw your game. It looks damn awesome