Mirror of forum.nim-lang.org

2448 :: questions about nim capabilities

• bkerin (orginal) [2016-08-07T22:46:13+02:00] view original

  I'm considering nim for a new project. I'm interested largely because of compile to C or JavaScript. It's an OpenGL app really. Some questions:

  • How much hassle to target both OpenGL on desktop and WebGL? Can nim help target both in any way or is going through WebGL going to negate all advantages of being able to target both C and JS?
  • Are there any features to help with database-backed (persistent) objects, or can nim macros help with this? I'm glancing at http://nim-by-example.github.io/oop_macro/ and guessing yes but I haven't studied in detail yet.

  Thanks, Britton

---

• Krux02 (orginal) [2016-08-08T00:34:39+02:00] view original

  If you want to hear my personal thoughts on the JavaScript backend, I hope that WebAssembly will make the need for a JavaScript backend completely irreleval at some point in time in the future, but I do not know when that will be the case. But that's more a hope than knowing anything. To answer your questions.

  • The current OpenGL wrapper is a pure wrapper around the C bindings. I think you would at least need to put in some work, to make the wrapper work with webgl, if not write an entirely new wrapper, in case you are on the webgl platform.
  • Macros are very powerful, and they will devinitively allow you smooth out the database integration. It all depends on how much intelligence you want to put in there.

  And then the question you did not ask: Do you think it is a good idea to compile an OpenGL application to JavaScript?

  • Generally, no. The problem with OpenGl application, or at least Games, is that they are real time applications, and you really do not want to miss frames. The problem with JavaScript, and all other gc languages is, that garbage collection freezes the application depending on how much memory you have. You might miss frames, and you won't be able to do anything about it. Smaller heaps can solve the problem, but that's something you do not have control over. In short the javascript version of the game will behave differently in respect to performance optimizations compared to the c version. Also the JavaScript version will consume a big amount of memory more than the C version, just because of the nature of Javascript, that everything is a reference type. This can all be a non-issue for you depending on the complexity of your app.

---

• Demos (orginal) [2016-08-08T00:44:41+02:00] view original

  I don't see a problem with compiling an OGL app to javascript. Games are soft real time, it's not like a GC hitch will kill someone. So that really depends on the complexity of your game.

  For the database thing I managed to cook up a primitive ORMish thing in a weekend (it works kinda like SqlAlchemy's core module). What I did was made an untyped macro that would parse a statement such as: select(col: seq[string], another: int) from table_name and generate a real sql query and the appropriate tuple type to return.

---

• yglukhov (orginal) [2016-08-08T21:50:13+02:00] view original

  How much hassle to target both OpenGL on desktop and WebGL? Can nim help target both in any way or is going through WebGL going to negate all advantages of being able to target both C and JS?

  That is exactly what nimx does. There's a tiny porting layer in portable_gl.nim. Truth be told though that asm.js is a better alternative for heavier apps, and that is why nimx supports emscripten target as well.

---