X3 Reunion graphics again. This time raytraced.

[citystate]

performance dropped slightly with this new build (less than a 10% hit though) and CPU usage was pretty much consistant regardless of which res I uesd (95+)

1 30
2 54
3 80
4 120
5 180
6 291
7 1073

[Hades]

@THCM, Derek, citystate

Many thanks, that was very helpful!

@THCM, Derek

Here I'm getting always the same numbers +-2ms at most. It's probably just the timer that works different on Intel CPU's. I'll fix that.

100% usage is great, and your timings (kind of) reflect that. So this is just an issue with vsync and my thread sync between frames. At least thats an easier fix than most other reasons I thought of.

The C2D is now closer to the speed I expected, and what's better: the scaling from dual core at 1,86GHz to quad core @2,4GHz is like 100%. Wow!

My memory usage is very excessive right now. I'll fix that, too.


@citystate

I'm surprised about that speed drop. On the other hand... those timings are still better than I expected from a Celeron. Even at 3,33GHz.
But I think I know what caused the speed drop. Should be better in my next (real) demo.




Now I've got some work to do...

Cheers,

Hades


Edit: Issues (hopefully) fixed. New exe

[dige]

Hmm, I see only a white screen and in the upper left corner a frame
counter: 180ms

Used System: AMD Athlon 64 FX-53, XP SP2, GeForce Ti4600

[Derek]

Faster again, now down to

12
22
33
50
77
130
493

[citystate]

this version seems better

1 26
2 49
3 71
4 106
5 159
6 258
7 936

[Hades]

@dige

Thanks for that report. It sounds like you have an old OpenGL version that doesn't support non power of two textures (OpenGL 1.1 from Microsoft?). Somehow I forgot to about that.
I will try to code a workaround.


@Derek, citystate

Thanks! No further problems?




Edit: New exe. Edit2: Replaced by the right exe.

OpenGL non power of two texture problem solved.
.ini file added to...
-support windowed mode
-change screen/window resolution

[Derek]

The good news, it's a lot faster,

8,15,24,35,54,88,333 so that's about half as fast again.

The bad news, it's all in red. No detail at all, just shaded red.

[Hades]

Oh no.

Sounds like I've packed the wrong exe. That's probably a shader that encodes the distance to the hit as a color.
I'm at work now, so it'll take some time to verify that.

On the other hand... now you've got an impression how much time is spent for lighting and texturing.
But that part still unoptimized PureBasic code, so there's still some room for improovement.

[Derek]

Plenty of scope for improvement then if that is unoptimised, on what is already blistering fast code considering what it is doing.

Look forward to the next exe.

[Hades]

Confirmed. Somehow I grabbed an exe with the distance shader enabled.

Originally I didn't want to optimize that other shader (from the other exe's) at all, because it isn't really useful for anything. But now that your asking for it...

[Hades]

The shader still isn't fully optimized.

Instead I've added shadows, and the light moves now.
There are also some keys with added functionality.

Esc : quit
1-7 : raytracing resolution
F : toggle Fullscreen / windowed
L : toggle Light movement
Q : toggle shader Quality
V : reset View
WSADEC / Numpad 854693 : move
cursor-keys : rotate view


>>Full demo<<


Have fun,

Hades

[Derek]

Really, really good. When are you going to make a game out of it, would be really good.

[Hades]

As soon as octo cores get common, or I am getting a mysterious performance breakthrough.

[Derek]

By the time octo cores are common I expect you'll have it optimised down to a couple of msec's

[Hi-Toro]

That's excellent performance for a raytracer... nice work.