LÖVE

raidho36 wrote:Don't know why'd you think it wouldn't

Well to be honest GLSL is not the most reliable programming language, it would've been a mistake not to try, truly. The 'problem' I have with your solution is because although the mengersponge function doesn't use a loop anymore everything else still does (Raymarch and Radiance) so why wouldn't those loops cause a problem when eventually calling the uniforms(through the mengersponge function)? I just don't understand why that particular unrolling fixes everything ?

raidho36 wrote:Also you threw away free camera

I didn't throw away anything! I just didn't add your camera yet .

raidho36 wrote:your travel is limited to the horizontal plane

This is not true ?

GijsB wrote: This is not true ?

It is! The camera is axially locked and cannot fluently rotate from any position to any other position, most notably it couldn't do 360 loops. You're always acutely aware of this when moving up or down at extreme angles because of increasingly strong motion distortion and crippling loss of control due to onsetting gimbal locking. You will find yourself simply avoiding these angles and even strongly oblique ones, effectively limiting movement to horizontal plane only. With freely rotating camera there's nothing to cause any such problems.

This loop causes errors because it uses uniforms in it, other loops do not. Props to modern nVidia cards for not crashing on it but there is substantial portion of GPUs out there what will crash on this code. I guess this has to do with nVidia cards being less of a vector processors and more of general purpose processors, thus being able to handle more flexible computations? Who knows but there you have it, uniform anywhere near a loop is a recipe for disaster.

raidho36 wrote:

GijsB wrote: This is not true ?

It is! The camera is axially locked and cannot fluently rotate from any position to any other position, most notably it couldn't do 360 loops. You're always acutely aware of this when moving up or down at extreme angles because of increasingly strong motion distortion and crippling loss of control due to onsetting gimbal locking. You will find yourself simply avoiding these angles and even strongly oblique ones, effectively limiting movement to horizontal plane only. With freely rotating camera there's nothing to cause any such problems.

This loop causes errors because it uses uniforms in it, other loops do not. Props to modern nVidia cards for not crashing on it but there is substantial portion of GPUs out there what will crash on this code. I guess this has to do with nVidia cards being less of a vector processors and more of general purpose processors, thus being able to handle more flexible computations? Who knows but there you have it, uniform anywhere near a loop is a recipe for disaster.

Well the camera direction was indeed locked to the horizon, thought you meant that the camera's position was locked to a horizontal plane, my fault.

Implemented more of your code btw

Debian Linux (Testing) x64, NVidia GT430 (128Bit 1024Mb), alternative drivers ver. 352

4aiman wrote:Debian Linux (Testing) x64, NVidia GT430 (128Bit 1024Mb), alternative drivers ver. 352

Hmm that's rather odd, does this one work for you?

Hmm... nope

Do I have to use Love2d ver 0.10.2 or 0.10.0 should (but for me it somehow doesn't) suffice?
I was able to run Mandelbrot GLSL.love, though.

GijsB wrote:

4aiman wrote:Debian Linux (Testing) x64, NVidia GT430 (128Bit 1024Mb), alternative drivers ver. 352

Hmm that's rather odd, does this one work for you?

neither work on win8 + GTX 970 latest too by the way. It was an easy fix but I deleted the files from last time I did though.

4aiman wrote:Hmm... nope

Do I have to use Love2d ver 0.10.2 or 0.10.0 should (but for me it somehow doesn't) suffice?
I was able to run Mandelbrot GLSL.love, though.

s-ol wrote: neither work on win8 + GTX 970 latest too by the way. It was an easy fix but I deleted the files from last time I did though.

Floats do get send correctly so this should work

Can I request you use [wiki]Scancode[/wiki]s instead of simple keys, I cannot find some of the mentioned keys in a spanish keyboard

It works for me on an Intel Graphics 5500

Positive07 wrote:Can I request you use [wiki]Scancode[/wiki]s instead of simple keys, I cannot find some of the mentioned keys in a spanish keyboard

You can try the version I uploaded, it's slightly old but otherwise identical functionality-wise.