Second part in a two part mix, see “Argon” for part 1.
What I have tried to do with these two mixes is present two sorts of music that are really floating my boat at the moment. This second part is a heavyer than the first, encompassing trance, electro and progressive.
01. Arty & Matt Zo – Rebound
02. Marco V – Unprepared (Recharged Mix)
03. Sander Van Doorn – Renegade
04. Arnej – Dust In The Wind
05. Sander Can Doorn Feat. Carol Lee – Love is Darkness
06. Jochen Miller – Brace Yourself (Extended Mix)
07. Cold Blue – Lucidity
08. Cramp – Prelude (Extended Mix)
09. Mord Fustang – Lick The Rainbow
10. Spenser & Hill Feat. Lil Jon – Less Go! (Porter Robinson Mix)
11. Axwell – Heart Is King
First part in a two part mix, see “Iridium” for part 2.
What I have tried to do with these two mixes is present two sorts of music that are really floating my boat at the moment. This first part is a much lighter, techhyer, houseyer affair than its counterpart, hence the noble gas Argon.
01. Nathan Fake – The Sky Was Pink (James Holden Remix)
02. Petter – Everyday Balloon
03. Delavari & Rouzbeh – LaLaLa (Ozgur Can Remix)
04. Who’s Who – Klack (Inpetto Remix)
05. Matt Lange – Bad Year Blimp
06. Gui Boratto – No Turning Back
07. Second Left – Traffic Lights
08. Butch – Amelie
09. Deadmau5 & Kaskade – I Remember
Following on from my previous experiments into the world of haXe and HTML5 I have been playing around again with trying to get as many 2D sprites on screen as I can.
I started by reading some posts by google on how to render things fast in HTML5, and it got me thinking. Where I was likely going wrong with my HaXe + Three.js experiments was that I was making a separate draw call to WebGL for each and every crawler. Draw calls are expensive and hence I was reaching the draw call bottleneck at just 2000 sprites being rendered at once.
What I needed to do was batch the draw calls together and render them at once. I knew from my work on XNA you could group sprite render calls together quite nicely. So I started off coding up a WebGL equivillant of SpriteBatch from XNA. I managed to get it kind-of working but as is often the way another thought struck my brain, and I decided to tackle that instead.
The great thing about point sprites is that I only use one draw call per frame and the GPU is very good at rendering them. The only bottleneck really is the number of pixels you need to draw. With that in mind if you drop the size of the point sprite down to 1×1 you can render a very large (5million) points at interactive framerates (18fps):
I added a “dont use texture” option just out of interest to see how expensive the texture lookup in the fragment shader was, it didnt seem have much of an effect.
There are a few caveats to using point sprites:
Firstly in WebGL has a limit on how large you can make them currently it differs between graphics cards and browsers, a safe minimum is 64×64 so this means you cant have them and bigger and still want it to work in all situations.
Secondly, and this one is more important I cheated to get the numbers above. In my other experiments with haXe and WebGL I was using the CPU to update the positions of the crawlers each frame, having them bounce off the screen edges. In this point sprites demo however I have the points flowing out of a fountain, the simulation of which is entirely calculated on the GPU. The reason for this I talked about in a paper I wrote for a university project 4 years ago:
So I kind of cheated. The fountain simulation on the GPU isn’t the same as my other examples. The crawlers don’t bounce off the side of the screen. To make that that happen each crawler needs to somehow preserve its state between frames.
Currently each crawler’s position is calculated in the vertex shader each frame like so: