I’ll look into it, thanks.
it’s enabled by default.
anyway, i’m just saying, exception-control-flow is surely silly but generally not a bad idea. the performance gain is usually very very little, but still … it’s good to be aware of. o/
Extra fuzz pollute registers, instruction cache, branch predicator table. Its also can ide the meaning of important code easily with only marginal gain by not making special case for edges. You are also calculating default value always and this calculation also contain memory read. This may or may not be optimized.
Found a perfectly fine looking rc boat. Opened it up and collected some parts.
I interviewed for an internship, and spent ~8 hours writing some Bukkit plugin stuff.
CopyableCougar4
A try block (in general) makes code harder to optimize as all possible paths must contain legal results. As an example any variable visible outside of the block must have the logically correct result at any point that an exception might occur…thus requiring more then minimally required stores to memory.
Got the terrain gen down to less than a second for 8192x8192 with 7 octaves (on my i7 4700MQ), interestingly enough it’s almost exactly 70M pixels/sec all the way from 256x256 (.94 ms) to the 8K (947 ms).
Memory usage is also quite low, and more importantly, constant during execution. No GC thrashing here!
Today I messed around with floatbuffers creating my own handling class which just makes the entire thing a lot more efficient and less bulky to handle.
Math.pow with integers…naughty. Math.pow with integer 2…very naughty. Don’t forget you need to insure you’re not in interpreted code for a meaning benchmark of something that’s going to happen frequently.
You should check what happens if you switch out all Math for FastMath. Usually that gives a free performance boost.
Mike
Learnt more about RESTful web services @ work, realized that was what my world server is doing @ home. All areas of the world are JSON documents on the end of simple URLs.
The only Math functions I’m using are min and abs, and neither of them are in the noise gen.
Also, Roquen, I fixed the naughty. Had forgotten about it in there.
You only need a touch of dithering to smooth out those gradients… right in your tone mapping shader, almost for free.
And what’s ‘up’ with the superfluous overdraw at the top of the cone? Doesn’t seem an easy fix, given the sheer amount of faces converging. Do you steadily reduce the tesselation towards the top?
@BurntPizza: I only skimmed…there’s some divides that can go away, but more importantly that XorShift can most likely be replaced with a well chosen constant LCG or even MLCG. Another option would be to use the first stage of MurmurHash2 (without the final cascade). Food for thought.
@Riven’s comment: yeah…kill all banding…it sticks out like a sore thumb.
Shadow mapping is slowly comming along, just gotta implement it into the light shader now!
[quote]Implode Balls
[/quote]
Phrasing!
I was planning on coding away today, but when I woke up I had 20 new backers for my Kickstarter which has been the biggest influx yet…
The very nice folks over at Phandroid did a nice little write up and article on the TyphonRT Video Suite:
So I have spent the last 4 hours trying to get some more momentum behind it… There is some activity on Reddit BTW if any of you use Reddit… “TyphonRT” may be a good search term… :
About coding though… I am close to getting a nice little repo up on Github with a very lightweight utility code to do modern OpenGL dev with Android.
The repo is located here and I hope to get things up in the coming days:
So hopefully back to hacking on the modern gl demos… I’ll be porting over the most excellent ray tracing demos posted on the LWJGL blog. Check it out… Good work Kai:
Shadow Mapping ( Finally )
