Hello,I’m a graduate student specialising in game design and environments,and wondering if Kdb+ or Kx has ever been applied to opengl?I usually program in c++ but I heard from a friend that Kx/Kdb+ ismore efficient and requires less lines of code but after much googlingI haven’t been able to find any information on how it can be used indesign environments.Thank you so much!
Return-Path: rohit.tripathi@capgemini.com
I think its not a question of just opengl alone but compiled vs. interprete=
d languages. You can always write a shared library which is loaded by q and=
interfaces with opengl (for each platform)
q/kdb+ can be used for generating precomputed data/models (e.g. in Quake 3D=
) which can then be loaded by compiled code which actually runs on the cons=
ole or PC. Maya and 3DS are used quite heavily in game development so an in=
terface with them will be very useful. They already have C++ APIs…but the=
n you also have licensing issues to take care of.
Hope this helps. This graphics thing is on my secret wishlist.
-----Original Message-----
From: personal-kdbplus@googlegroups.com [mailto:personal-kdbplus@googlegrou=
ps.com] On Behalf Of milkred
Sent: Monday, September 05, 2011 11:34 AM
To: Kdb+ Personal Developers
Subject: [personal kdb+] Kdb+ and opengl
Hello,
I’m a graduate student specialising in game design and environments,
and wondering if Kdb+ or Kx has ever been applied to opengl?
I usually program in c++ but I heard from a friend that Kx/Kdb+ is
more efficient and requires less lines of code but after much googling
I haven’t been able to find any information on how it can be used in
design environments.
Thank you so much!
–=20
Submitted via Google Groups
Kdb+ is great for a lot of things, and is my favorite tool, but game programming is not one of them:
- Scalar operations are better (read: faster) in C/C++ because kdb+ has to do type checks on the vast majority operators. When we need to manipulate a lot of scalars we usually do so with C or C++ code and load it into kdb+.
- Writing a main loop for a game will starve q because data will not be able to come in over a socket due to the interpreter executing the while loop. Unless you write socket code in C, say good bye to multiplayer games. Want to tap into q’s main loop to avoid this? You can only do so with a socket. You could technically work this way, but then you’d be an interpreter within an interpreter.
- Because CPU speeds aren’t scaling at the speeds they used to we have gone multi-core and modern games are written to take advantage of this. Kdb+ is mainly single threaded. Yes, we can use peach, but that isn’t enough. We need a thread to run the game, one to preload resources, maybe one to calculate physics (if you’re not using a GPU for this) and one to handle sound perhaps.
- There are limitations on kdb+ in terms of the maximum number of constants (literals) and variables in a function. In a well written program one may not run into this, but it happens from time to time.
- No object oriented programming. Everything must be procedural. This is okay, but if you need to create a class the closest thing you have is a namespace which doesn’t cut it. I imagine within q that’s a double hash look up (assuming the proper attrib on the dict) every time you touch the “class.”
The previous version of kdb+ has a GUI built in. Kx removed it because it was becoming a pain to maintain and the GUI code was larger in size than the core of kdb+. I’m sure efficiency was also another reason: why would you want GUI code slowing down your calculations? GUI and Graphics will (as far as I could say) never make it back into kdb+.
I’m sure there are more reasons I’m just not thinking of. Just stick with C/C++.?