[Working with artists who don't own Leadwerks]

I feel like everyone is missing the point, but the question has been answered. Thank you for your time.

[Working with artists who don't own Leadwerks]

First, thanks to everyone that's offered advice on this.

 

@Azazel226: There's an easy solution: buy a LE license for all members of the game project. It's the only right choice to do anyway, and Josh gives often decent discounts when you explain the situation to him. If your game makes any profit, you will get easily your money back, plus maybe even more since you can finish your project faster and easier. Each day of game sales means money, so the faster your game is on the steamshelves, the more money you will get.

 

 

In the case where it's me working as the programmer and a steady, solid member of my project working as the artist, of course buying an additional license would be the right thing to do. Most bedroom programmers though don't have access to a dedicated artist however, and thus commission/buy work as they can and from whom they can. I think we can both agree that buying a license for every artist you could potentially contract or commission to generate art for your project is unrealistic in this situation.

 

If you want to make your own model viewer for your artists to use, that is fine. The SDK tools are part of the SDK, and are only for use by licensed developer. The Leadwerks Engine SDK is a product for both programmers and artists, so owning a license doesn't allow you to give away the SDK to artists.

 

If they're just making models or textures, they may not even need to do anything special for the engine, if they can send you a .psd or .max file.

 

Thank you for clarifying this issue for me. I suppose when I boil it down, what I was expecting is a freely available, simple method for any artist out there with an asset to be able to visually verify that their artwork is indeed Leadwerks compatible and engine/game ready.

 

In most engines I've dealt with, the content import process is always hampered by some "gotchas" and format/engine oddity that need to be taken into account, least problems arise. In those instances, it's nice to have a simple viewing program to verify the model/material/etc is indeed working properly, animates properly and looks as intended.

 

Accepting the files and doing this step myself of course is always an option. I believe that's what most people do now. I suppose I don't see why more people haven't raised this issue to simplify the process and allow a more streamlined system to positively impact the pipeline. Perhaps I've personally had too many conversion/format/incompatibility headaches to think about this objectively.

 

In any event, I apologize if I appear argumentative. That's not my intention. Thank you for your time.

Dell

 

P.S: An example of what I'm trying to convey is here: Verify that this model pack functions and looks correct in Unity

[Working with artists who don't own Leadwerks]

Thank you both for your input. I honestly didn't expect this to be much of an issue, but apparently it can be. I've been trolling around the boards for a while now, and I understand that the primary Leadwerks developer is working on the next major release, and is also drumming up ideas/interests on how to improve the product and worthwhile features. Has this topic come up? It seems pretty backwards to be honest to have to worry about breaking the agreement just because you want to be able to outsource artwork that can be independently verified without buying copies of the engine for all would-be contractors.

 

I appreciate the input and guidance given,

Dell

[Working with artists who don't own Leadwerks]

Thanks for the replies. It seems you both are suggesting the option B approach; which is to write my own asset viewer/verifier(s) to send out to hired artistic help so as to adhere to the agreement.

 

Not the end of the world by any means, but it seems pretty lame to have to rewrite existing, fairly basic tools that would serve the purpose just fine if 3rd parties could utilize them for the purposes of checking and verifying media in Leadwerks.

 

Thanks for the help,

Dell

[Working with artists who don't own Leadwerks]

Hi,

 

I was wondering how you would go about approaching asset creation/assessment for the Leadwerks engine utilizing artists who are not licensees.

 

There are tools available to help assist an artist in visualizing what their work would look like in the engine in the /tools/ directory, but the license agreement explicitly forbids handing these tools over to anyone.

 

This SOFTWARE PRODUCT is for personal use only and may be installed and used by on only one computer. Its component parts may not be separated for use on more than one computer. SOFTWARE PRODUCT may be accessed through a network only after obtaining a site license. All components accompanying the software are copyrighted by LEADWERKS CORPORATION and may not be taken apart, modified, used or published with other software or means except with the SOFTWARE PRODUCT software and may not be distributed or copied in any manner.

 

At any rate, I'm merely curious as to how people solve this problem. I wouldn't want to have to babysit an artist I commission through the entire creation/verification process to ensure that their work is solid and usable in the engine, but it also seems a bit of a waste to write my own asset viewers when this functionality already exists for the most part. Am I missing something?

 

Thanks for any clarity you can provide,

Dell

[CreateWindow() class function conflicts with CreateWindowA()?]

Right, but does that mean you can never have a class function called CreateWindow???

 

 

Greetings,

 

This appears to be a common issue. Here's a quote from http://www.winvistatips.com/opos-so-linedisplay-createwindow-problem-t194728.html

 

The reason is a "misunderstanding" between the Class Wizard and the MSVC system headers. In the system headers the name CreateWindow and DestroyWindow are used as macro definitions and they are mapped to DestroyWindowA and CreateWindowA in the ANSI version. Microsoft uses this macro-replacing -mechanism to allow ANSI and UNICODE compiling. However, if you have C++ classes with a method using a "reserved" word the compiler will generate errors. In general: you should not use method names which are already used in the Window API. This is not a restriction of the language C++ but of the MSVC compiler.

 

Later on in the thread the author got around this problem by doing a #undef on the CreateWindow macro.

 

Problem solved!

 

In translation unit that #includes compiler generated header which

has

CreateWindow hassle (#included windows.h):

-#include windows.h

-#undef CreateWindow

-#include compiler generated header

 

 

 

Oh yeah, first post, and hello