I want to learn Ocaml or Haskell and I want to do it by writing a simple game. Apparently, there's one small problem: nobody cares about Windows and I want to do it on Windows, natively.
Haskell has Cabal, which has SDL, but it doesn't build due to a trivial problem with no workarounds (order of parameters passed to gcc). Ocaml doesn't even have that, it's all in source packages, be it GLCaml or OcamlSDL or whatever.
Is there a place where I can get a working SDL for Haskell or Ocaml on Windows without fighting with a dozen versions of compilers?
The Haskell Platform comes with a binding to OpenGL which should work out of the box on Windows.
Concerning the SDL package on hackage, you can use cabal unpack SDL to get the source code and fix things yourself. To install the package with your changes, run cabal install in the unpacked directory. In any case, drop a line to the maintainer, I'm sure he'll help out.
It's not related to SDL, but you've mentioned OpenGL. There is LablGL binding for OpenGL in OCaml which works out of the box. Wiki example (http://en.wikipedia.org/wiki/Objective_Caml#Triangle_.28graphics.29) compiles and works just fine.
The best instructions I've found for getting SDL to work in windows with a the most recent Haskell platform can be found at this blog. I followed everything step-by-step and it worked perfectly, despite some configure error messages.
It isn't SDL but GLFW works on Windows with Haskell through Cabal.
My article High-fidelity graphics with OpenGL 2 (25th Feb 2008) explained how the GLCaml bindings can be used to write OpenGL-based applications in OCaml that use vertex and fragment shaders (a phong shader is given as an example). There are 9 articles in the OCaml Journal on OpenGL, albeit mostly using the older LablGL library for OpenGL 1.1.
I tried and failed to get OpenGL working from Haskell under Linux in 2007. The Haskell Platform may have changed that but I have neither had time to try it yet myself nor ever heard of anyone using it for this.
However, both OCaml and Haskell must rely upon fragile low-level bindings to OpenGL because they are standalone languages and nobody has ever managed to get any significant commercial software using them to work. As you're on Windows, F#+XNA is a far more logical choice because XNA is tried and tested and F# has a safe high-level interface to it. A Google fight gives you a good idea of what a pioneer you'll be: +haskell +opengl gives 437 hits on Google and +ocaml +opengl gives only 347 hits.
Related
Currently I'm doing some GLSL-stuff and to my surprise I cannot find a reasonable IDE for this (MacOS). Nothing to fancy, but just a way to change the code and see the results. I know of the Shadertoy-website, but I'm more interested in an offline solution.
So I came across the built-in OpenGL Shader Builder. According to Wikipedia, this is deprecated and superseded by GLSLEditorSample, which should still be available as an example project for XCode (of which I have version 7.3.1 installed). However, I basically cannot find anything about this, online nor on my computer. Therefor my question: Is this still relevant? If so, where is it located?
PS: if you know of any other GLSL IDEs, I'm open to that as well
Here they explain how to setup OpenGL on a MacOS on Xcode:
https://www.youtube.com/watch?v=Tz0dq2krCW8&list=PLRtjMdoYXLf6zUMDJVRZYV-6g6n62vet8
Everything I can find online about QtRuby uses Qt 4, but the current version of Qt is 5. Is this simply a matter of documentation not catching up with reality, where Qt 5 would work just fine with QtRuby?
If you assert that this is the case (that Qt5 is unsupported) then please backup your assertion with evidence.
QtRuby
Qtruby and korundum are not maintained for years now. To get a maintained version of qtruby, install qtbindings as ruby gem.
Qtbindings home page: https://github.com/ryanmelt/qtbindings/
Also see https://github.com/ryanmelt/qtbindings/issues/131 for a discussion about supporting Qt5.
Ruby-QML
Ruby-qml is a QML / Qt Quick wrapper for Ruby. It provides bindings between QML and Ruby and enables you to use Qt5 Quick-based GUI from Ruby.
The bindings provided by Ruby-QML are much leaner in comparison to QtRuby. In particular there is no direct access to the Qt classes' methods. That might first seem to be a a disadvantage when coming from QtRuby.
When learning to use use Ruby-QML, it turns out quickly that the advantages outweigh the limitations:
QML and JS greatly complement to describe and model the static and dynamic aspects of the UI
The user community of QML/JS is huge. It is so much easier to find examples or help to solve QML/JS issues, than it was within the tiny QT/Ruby community.
The examples on Ruby-qml are pretty much complete to demonstrate the constructs needed to get started.
JS may be used as flexible 'glue logic' between Ruby and Qt.
QtRuby only supports Qt 4 for the time being. Hopefully, it will change soon, but this seems to be the reality at the time of writing this.
The last release happened two and half a years ago as the time of writing this. That can be seen here:
http://rubyforge.org/projects/korundum/
As you can see, that is also a Qt 4 release as its name says: qt4-qtruby-2.2.0.
That information is also getting from their outdated KDE Wiki in here:
http://techbase.kde.org/Development/Languages/Ruby
If this is still not enough proof, you can look into the code yourself to see it is not actually binding Qt 5 classes added in that major Qt variant.
Here is a quick ls after decompressing the latest tarball:
lpapp ~/Downloads/qt4-qtruby-2.2.0/qtruby/src/lib $ ls
CMakeLists.txt Qt Qt.rb Qt3.rb Qt4.rb
I would like to build a GUI for an OCaml application I'm writing. My first idea was to use GTK+. I would like my application to run on Macs, Linux, Windows with a natural look and feel. I know that, while GTK+ uses X11 on the Mac by default (which looks awful), there is gtk-osx-application which uses quartz and looks natural and which I've just installed using macports.
I have three questions:
(1) Is it actually possible to use gtk-osx-application +quartz+no_x11 with OCaml? (My GODI installation which previously (with x11-based gtk2 in place) installed lablgtk2 with no problems, now (with gtk-osx-application +quartz+no_x11 and the previous x11-based gtk2 removed) is complaining about not finding /opt/local/lib/libgtk-x11-2.0.0.dylib, which is x11 related. But, as far as I know, there's no way to choose quartz over x11 when installing lablgtk2 through GODI.)
(2) If I develop my code on my Mac using the gtk-osx-application, can I use the code as is for compilation in other platforms which use different GTKs or can this bring problems?
(3) If it does bring problems, do you know of any other environment for developing GUIs in OCaml that may potentially be good regarding both look and feel and still be readily cross-used? (I am aware of labltk but I'd prefer something with more capabilities, for example, the ability to use notebooks, a.k.a tabbed panels, and being able to use Glade for rapid GUI design.)
Thanks for any help!
Cheers,
Surikator
Assuming you can get lablgtk to work, it is probably your best bet at present.
To get it working: have you tried rebuilding lablgtk after removing X11 GTK and installing Quartz GTK? A LablGTK built against X11 GTK naturally won't work on a Quartz GTK, as it will be linked against the wrong library, but a rebuild might be successful. It could also be that LablGTK won't correctly detect that X11 integration calls don't work and therefore fail to build, but I would expect that to be not-too-difficult to fix as LablGTK does support Windows.
If you develop code for GTK on Mac, it should work on other platforms just fine. You'll want to test it, of course, but it should work. Do be careful to use the GTK facilities to make things like dialog button order work properly.
I think there was at one time a set of OCaml bindings to wxWidgets, but they do not seem to be widely used and wx is painful to work with in my experience. There has also been some work on making Qt bindings, which would be awesome, but I don't think there are any projects with good headway on that front yet.
If the UI is a small-ish piece of your project, you could look at decoupling it from the backend and writing the UI in C++ with Qt, or writing platform-native UIs, and having the UI call out to OCaml code in an embedded runtime to get the real work done. But that is likely more work and may not give you much benefit, depending on your application.
So: GTK is your best option in the current landscape.
After a long evaluation period of mainstream toolkits Qt, WxWidget, GTK i came to the conclusion that it does not make sense to religiously equalize the different platform. Now more then ever before.
In the days before Java portability meant, that platform dependent code was located in known places and should be small but not none. No write once, run everywhere marketing.
Is there any GUI tookit - experimental or commerical (even outdated or dead projects) - that is going this way. It would need to give me native widgets of course. I would like to have a look at them before i start my own toolkit
If you think this is a stupid idea tell me why (cause everybody else is doing it differently there may be a reason i don't see)
As someone who zealously believes that GUIs should be drawn with native widgets, I must say I've been very impressed with wxWidgets, although you mention that at the beginning.
As far as I know, wxWidgets uses native widgets whenever possible, and indeed it does also include platform-specific features that are neither possible nor relevant on other platforms. A good example of this is how you can use the native Mac OS X menu, while on other systems it won't do squat. There are other and better examples.
I must mention wxPython in particular, in case you either don't want to or just don't have the time to write a C++ program. wxPython astonished me when I tried it out first, and I even managed to make a stand-alone .exe file from it that worked on a fresh install of Windows 2000 without any updates or particular runtime environments.
If wxWidgets doesn't suit your needs, I wonder what would. :) Hurray for wxWidgets!
AFAIK, wxWidgets uses the platform's native widgets whenever possible.
Have a look at SWT, it tries to use the widgets of the underlying platform as much as possible.
I thought this should be easy, but... geesh! A vendor gave me a fairly simple demo program meant to showcase some trivial icon animations. The target platform is an embedded system (MX51) with accelerated OpenGL ES 2.0/OpenVG and EGL support.
Unfortunately, the demo also has an annoying dependency on a few Qt utility classes (e.g., QImage). If not for this dependency, I would compile/run the thing on the target. But I don't relish the thought of cross-compiling Qt just to run this little demo---even if there were enough room for it on the embedded board.
I hoped I might be able to run the app on a standard(ish) Ubuntu 10.04 VM, and started following these directions to make it happen. And I actually managed---like, 10 hours later---to compile everything and get a runnable binary of the demo program. However, when I run it, I see the following error:
eglCreateWindowSurface: egl error "EGL_BAD_CONFIG" (0x3005)
Sigh. Not what I wanted to see after all that effort. This seems way more difficult than it should be.
Is the embedded GL landscape really such a ghetto that I have to run even trivial programs on the target using some vendor-supplied BSP? Judging from the lack of responses to this guy's question, I'm thinking the answer might be yes. But I don't even care about acceleration (yet). I just want to run the stupidest of OpenGL ES 2/OpenVG programs on a desktop PC and get an idea of how it looks. (It doesn't matter to me whether the PC is running Linux or Windows.) How do people do this sort of thing?
There are several OpenGL ES 2.0 emulators, such as:
For ARM Mali GPUs
For PowerVR GPUs
Also very recently, AMD has posted drivers that expose OpenGL ES 2.0 on desktop.
More recently, OpenGL 4.1 exposes the GL_ARB_ES2_compatibility extension, which makes OpenGL 4.1 drivers GL ES 2.0 compatible.
For OpenVG, you can use AmanithVG GLE.
Qualcomm's OpenGL ES emulator includes OpenVG support. You can download it from http://developer.qualcomm.com