Me too! But then I re-establish contact with the reality of my actual abilities and create a button which, when pressed, prints "Hello, world!" to an alert window.
>The terrain is procedural, generated offline by a Delphi program (Delphi is a modern version of Pascal).
Nowadays I very rarely see new projects use Object Pascal or Delphi. This is somewhat disappointing since I think it really is a fine language that could be a viable alternative to C++ and Java due to its combination of high performance and clean syntax [1]. But then again, C# is very popular and it is pretty much the new Delphi.
Does anyone here use Object Pascal in their current projects?
[1] At least in theory. I'm not necessarily talking about the particulars of the Borland/CodeGear/Embarcadero implementation since Anders Hejlsberg left for Microsoft, which were not always perfect.
http://www.anadelta.com/index-en.php?s=exported
You may recognize the sky :)
So why not just use C? There were good reasons. In 1992 C/C++ compilers on the PC were slow -- pre-compiled headers were still mysterious -- and Delphi's handwritten compiler and integrated linker made the edit/compile/run cycle very very fast. It made small, fast, completely stand-alone (no MSVCRT.DLL or anything) binaries -- a feature which still supposedly makes it popular with malware authors.
The UI builder was excellent and perfect for knocking off one-off tools like the terrain generator described above. As long as you stuck to Windows, of course.
I don't know if I would necessarily go back though. While I sometimes miss some of Pascal's features like ranged types and sets (and bounds checking on arrays) the performance advantages of the specific Borland implementation have become less important, and there are other contenders that cover a bigger problem space than the delta between Pascal and C.
BTW, here's where Google Trends says Delphi is popular nowadays: http://www.google.com/trends/explore#q=delphi&cmpt=q
On the other hand, the object system has some nice features. I miss AfterConstruction and BeforeDestruction in other languages, and I like virtual constructors.
http://blogs.fsfe.org/thomaslocke/2013/02/10/using-the-ada-w...
It's as though you spent a month painstakingly mixing 64 channels of crystal clear audio, but, right at the end, threw your hands up and clipped the final mix into oblivion.
Q: OK, why not put them a bit lower than that, with some variety between peaks?
A: I already have. If you take a closer look, you will notice that there is another layer of flat surfaces, lower than the top.
Q: I'm not convinced. Why only two layers of 'flatness', one at the top, another a bit lower?
A: In the end, it's all about the dynamic range that you have to work with. When using a single byte, there are only 255 distinct height values. The key point is to understand that these values must not differ by much (i.e. they cannot be scaled by large values), since this will affect the appearance of the rest of the terrain (think very, very sharp, unnatural triangles everywhere). On the other hand, the scale factor must be large enough to allow for distinct terrain 'features', avoiding the appearance of a deflated terrain. Two layers of flatness, safely away from each other, was the best compromise.
Q: I'm still not convinced. Just vary the top layer by a small amount between peaks.
A: Using a small value wouldn't make much of a difference. If the amount was large enough, the distinction between the two 'flatness' layers would be lost and the terrain would lose that specific character that it currently has.
Going to two bytes per elevation (and thus be able to use a small scale factor) would allow me to keep the style intact (of some specific geological procedure that has formed the terrain), while varying the peaks and keep the rest of the terrain smooth.
I hope this made some sense. However you're right, it is noticeable! I just didn't think it detracts that much from the overall feel, while it still has advantages, so I went with it.
For example, I was working on creating a WebGL setup for playing around with the Oculus Rift and used three.js to create http://sxp.me/rift/. It's mostly three.js code, but I added a custom camera object which handles the offscreen rendering and distortion required for the Rift. It was much faster and easier than starting from scratch which was what I originally did before giving up.
1. As the demo stands, it doesn't really need a 3D engine. Including one (any one) wouldn't help with anything, except for maybe skipping some (miniscule) setup code. Surprising, but true. Things definitely change as soon as you wish to render a flying ship though.
2. Learning has been the main reason for this demo. There's no better way to learn than to take apart or build something from scratch. In fact, I've built a 3D engine as well during this time (not used in this demo at all), along with a 3D model viewer and an application I hope to turn into a start-up some day. If I've been developing a 3D game (for example), with the express purpose of releasing it as soon as possible, I'd certainly use Three.js!
And last but not least:
3. When I decided to get into web development, about one and a half years ago, I didn't know about Three.js! :) (I found out quite soon though)
I'm still waiting for someone to make a fully fledged game in WebGL because I can totally see it happening.
Very impressive!
A motocross would be slightly more difficult :)
Motocross suggestion seconded :)
[Edit:] And I see up to 13 fps if I fly away from the sun, the author seems to be right when he writes "Calculating sun visibility the geometric way (by casting rays through the terrain and the clouds) can be expensive if not done carefully."
$ uname -a Linux XX 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
The result is used for modulating the intensity of both the lens flares layer and the glare layer.
Nice article!
also, it would be awesome if you're able to implement highdpi mode http://www.khronos.org/webgl/wiki/HandlingHighDPI
wait, what? Lens flare is not common in photography.
The scaling in frame rate has to do with the amount of terrain patches that have to be displayed. You can see the same scaling by changing the frustum viewing angle (i.e. without resizing the browser window).
Thank you! :)
Don't get me wrong, that's pretty awesome in itself, I've done things like that myself. But I'd like to suggest (or perhaps inquire) why you wouldn't just overlay some html?
For learning, you can try game development sites, graphics programming books, online Geomipmapping tutorials (for terrain stuff), forum discussions when facing problems... However, the most important thing is general programming experience, I guess.
I remember though that Learning WebGL (http://learningwebgl.com/blog/) was very useful when I began learning things specifically for the web!
I can relate to your story of building the UI framework yourself. That's kinda what I ended up doing myself too, and I've learned a lot of fundamentals through that approach.
Is there a reason you decided to implement a WebGL UI, instead of using HTML for the user interface elements?
Is native browser compositing too slow with multiple HTML elements on top of the WebGL canvas?
Thanks for the kind words!
Can't say for sure, because I didn't make it all in one go. The first time I opened the browser with the intent of developing for the web was a year and a half ago. During that time, I've built some other things as well (a 3D graphics engine, a CAD-like 3D model viewer to test the engine with and an application I'd like to turn into a start-up someday :)).
If I had to guess, I'd say that the terrain took me 3 to 4 months, the GUI a bit more than that, plus two more for really polishing the demo. Hard to say though, since everything was done in parallel, with even a few dead periods in-between.
edit: 60.1 FPS at 2560x1440 on my desktop (KDE/KWin/Chrome Dev)
Would love to try with touch control enabled. Great work.
