Search Results

Search found 4 results on 1 pages for 'luken'.

Page 1/1 | 1 

  • Prototype experience: Unity3D vs UDK

    - by LukeN
    Has anyone yet prototyped a game in both Unity3D and UDK? If so, which features made prototyping the game easier or more difficult in each toolkit? Was one prototype demonstrably better than the other (given the same starting assets)? I'm looking for specific answers with regard to using the toolkit features, not a comparison of available features. E.g. Destructable terrain is easier in toolkit X for reasons Y and Z. I can code, so the limitations of the inbuilt scripting languages are not a problem.

    Read the article

  • C strange array behaviour

    - by LukeN
    After learning that both strncmp is not what it seems to be and strlcpy not being available on my operating system (Linux), I figured I could try and write it myself. I found a quote from Ulrich Drepper, the libc maintainer, who posted an alternative to strlcpy using mempcpy. I don't have mempcpy either, but it's behaviour was easy to replicate. First of, this is the testcase I have #include <stdio.h> #include <string.h> #define BSIZE 10 void insp(const char* s, int n) { int i; for (i = 0; i < n; i++) printf("%c ", s[i]); printf("\n"); for (i = 0; i < n; i++) printf("%02X ", s[i]); printf("\n"); return; } int copy_string(char *dest, const char *src, int n) { int r = strlen(memcpy(dest, src, n-1)); dest[r] = 0; return r; } int main() { char b[BSIZE]; memset(b, 0, BSIZE); printf("Buffer size is %d", BSIZE); insp(b, BSIZE); printf("\nFirst copy:\n"); copy_string(b, "First", BSIZE); insp(b, BSIZE); printf("b = '%s'\n", b); printf("\nSecond copy:\n"); copy_string(b, "Second", BSIZE); insp(b, BSIZE); printf("b = '%s'\n", b); return 0; } And this is its result: Buffer size is 10 00 00 00 00 00 00 00 00 00 00 First copy: F i r s t b = 46 69 72 73 74 00 62 20 3D 00 b = 'First' Second copy: S e c o n d 53 65 63 6F 6E 64 00 00 01 00 b = 'Second' You can see in the internal representation (the lines insp() created) that there's some noise mixed in, like the printf() format string in the inspection after the first copy, and a foreign 0x01 in the second copy. The strings are copied intact and it correctly handles too long source strings (let's ignore the possible issue with passing 0 as length to copy_string for now, I'll fix that later). But why are there foreign array contents (from the format string) inside my destination? It's as if the destination was actually RESIZED to match the new length.

    Read the article

  • C++ class derivation and superconstructor confusion

    - by LukeN
    Hey, in a tutorial C++ code, I found this particular piece of confusion: PlasmaTutorial1::PlasmaTutorial1(QObject *parent, const QVariantList &args) : Plasma::Applet(parent, args), // <- Okay, Plasma = namespace, Applet = class m_svg(this), // <- A member function of class "Applet"? m_icon("document") // <- ditto? { m_svg.setImagePath("widgets/background"); // this will get us the standard applet background, for free! setBackgroundHints(DefaultBackground); resize(200, 200); } I'm not new to object oriented programming, so class derivation and super-classes are nothing complicated, but this syntax here got me confused. The header file defines the class like this: class PlasmaTutorial1 : public Plasma::Applet { Similar to above, namespace Plasma and class Applet. But what's the public doing there? I fear that I already know the concept but don't grasp the C++ syntax/way of doing it. In this question I picked up that these are called "superconstructors", at least that's what stuck in my memory, but I don't get this to the full extend. If we glance back at the first snippet, we see Constructor::Class(...) : NS::SuperClass(...), all fine 'till here. But what are m_svg(this), m_icon("document") doing there? Is this some kind of method to make these particular functions known to the derivated class? Is this part of C++ basics or more immediate? While I'm not completly lost in C++, I feel much more at home in C :) Most of the OOP I have done so far was done in D, Ruby or Python. For example in D I would just define class MyClass : MySuperClass, override what I needed to and call the super class' constructor if I'd need to.

    Read the article

  • Plugin architecture in C using libdl

    - by LukeN
    I've been toying around, writing a small IRC framework in C that I'm now going to expand with some core functionality - but beyond that, I'd like it to be extensible with plugins! Up until now, whenever I wrote something IRC related (and I wrote a lot, in about 6 different languages now... I'm on fire!) and actually went ahead to implement a plugin architecture, it was inside an interpreted language that had facilities for doing (read: abusing) so, like jamming a whole script file trough eval in Ruby (bad!). Now I want to abuse something in C! Basically there's three things I could do define a simple script language inside of my program use an existing one, embedding an interpreter use libdl to load *.so modules on runtime I'm fond of the third one and raather avoid the other two options if possible. Maybe I'm a masochist of some sort, but I think it could be both fun and useful for learning purposes. Logically thinking, the obvious "pain-chain" would be (lowest to highest) 2 - 1 - 3, for the simple reason that libdl is dealing with raw code that can (and will) explode in my face more often than not. So this question goes out to you, fellow users of stackoverflow, do you think libdl is up to this task, or even a realistic thought?

    Read the article

1