I am quite happy with the response. I have tried using alpha5 and the app keeps crashing (but I have already tried to fix all the floats, dunno where is the problem) and I don't know how to fix it at the moment. Could somebody have a look to it (but I am referring only to the 'engines' part) and check if the 'f' suffix is present for all the floats? It would great to have a corrected copy to see if it works then.Maybe there's another quicker solution, but is there?

Starmute

@Starmute

great job bermarte, I will check it out soon!

Btw, is there any way you might add a way to block clients that are not running genuine mandelbulber (i.e. do not send anything if the client improperly identifies itself?)

The invalid client is actually preventing one of my good clients from rendering (it takes up a spot).

Sebastian Jennen

@zebastian

@Starmute having friends in romania? :-D https://www.abuseipdb.com/check/89.165.252.68In general mandelbulber is meant to be used in LANs, since it has no security considerations whatsoever.Yet still strange, how the client managed to establish the connection (what is he scanning for on this port?) I will file an issue on github, but this has a low prio,For the mean time you can prevent the traffic on another level (prevent the incoming traffic on your server machine or better even on your router)

Sebastian Jennen

@zebastian

most consumer routers have a security area on their web admin page. For me it is:Menu > Advanced > Security > Ip and Port filterJust add the IP to block for all ports, this should do the trick

Starmute

@Starmute

hello!

tried compiling mandelbulber with the changes bermarte recommended, but still getting an error:

@Starmute that problem was fixed with this commitbuddhi1980/mandelbulber2@72d8cc9

bermarte

@bermarte

Did you build the app yourself or did you use the .dmg file? Maybe it is an include problem, check if opencl_algebra.h file is present .

bermarte

@bermarte

Package "qt5-default" and "qttools5-dev" have been removed in Zesty, so installation for Ubuntu would not work out of the box.

Krzysztof Marczak

@buddhi1980

thanks for info. I will check it and correct readme files.

Krzysztof Marczak

@buddhi1980

I have just switched to Qt 5.9.1. Everything works properly.

_

Krzysztof Marczak

@buddhi1980

With Qt 5.9.1 my gamepad works! So I will be able to improve and finish development of gamepad control.

Krzysztof Marczak

@buddhi1980

There is one problem with Qt 5.9.1. qDebug() doesn't output anything. This needs investigation.

Krzysztof Marczak

@buddhi1980

I have solved problem qith missing qDebug() output. I was system configuration problem. It returned working when I deleted /etc/xdg/QtProject/qtlogging.ini

Sebastian Jennen

@zebastian

Thats good news. The debug channel is probably deactivated by default, since it is only to meant to be used by developers, i guess.

Krzysztof Marczak

@buddhi1980

Probably you are right. qWarning() and qCritical() worked properly.

Sebastian Jennen

@zebastian

hmm, what about qInfo()?

Krzysztof Marczak

@buddhi1980

We need to change all temporary qDebug() outputs to WriteLog()

I haven't tested qInfo

Sebastian Jennen

@zebastian

The problem about qInfo was that in old versions of qt it did not work properly

At least that is what i remember

Anyway it would be rasonable to have one "consistent" logging mechanism, best to use our own WriteLog

BTW: What are the next steps you want to do in the project?

Krzysztof Marczak

@buddhi1980

I think it's good time to start cleaning up the code. DOF effects are almost done.

We need to add more error checking to the code to make all more robust

Sebastian Jennen

@zebastian

Yes, i also encountered some crashes and shutdowns, mostly some race conditions about new opencl code.

I will try to find a way to reproduce and investigate with debugger whats wrong.

Krzysztof Marczak

@buddhi1980

One actual issue is to use GPU for rendering DOF and SAAO using GPU. On most of GFX cards it's only possible to allocate 512MB per memory block. When image resolution is high (like 6400x4800) rendering of DOF fails.

Sebastian Jennen

@zebastian

I also could reproduce the problem with julia vector copy: buddhi1980/mandelbulber2#352 but i could not identify the error

Krzysztof Marczak

@buddhi1980

I'm going to predict memory usage and switch to CPU rendering when would be not possible with GPU

Sebastian Jennen

@zebastian

how much of a pixel range do you need to calculate these effects? maybe its possible to make these effects tile based to save memory. That would maybe only require little overhead of copying overlapping areas

Krzysztof Marczak

@buddhi1980

i will look at issue #352. It's also reproducible for me

these effects have to have access to full image, so it's not possible to divide image

Sebastian Jennen

@zebastian

#352 is probably a use after free, maybe the parameter stuff interferes with the preview below the julia parameters...

Krzysztof Marczak

@buddhi1980

So as you see now we should focus on debugging and cleaning up. Actual state of development is enough for new release. Most of effects and fractal calculations already works. More will came in v.2.13

Preparation for release will take probably more than month, because there was a lot of major changes. We need to check all old functions (like calculation of fractal formulas, which are now 4D), bring back compatibility with older versions, and make application more stable.

Sebastian Jennen

@zebastian

we will also need to test that queue / cli / netrender is working as expected with and without opencl (at least not crash, when opencl in not yet supported).