Jump to content

  • Log In with Google      Sign In   
  • Create Account

Karsten_

Member Since 19 Jul 2011
Offline Last Active Dec 11 2014 06:31 AM

#5166387 XNA vs Other

Posted by Karsten_ on 12 July 2014 - 05:25 AM

Microsoft used to come around University telling the students that XNA is deprecated in favour of MonoGame (an open-source XNA clone). The VisualStudio IDE used to crash every time they did a demonstration of the content pipeline with MonoGame biggrin.png

http://www.monogame.net

At risk of getting a lower grade because of minor differences between the two, I can't suggest that you use it. But you should probably evaluate it yourself and make the choice.

Your tutor might respect the fact that you are looking outside the box and towards solving issues of portability (a major topic within the game development industry).

If you are stuck with C#, an option that I would personally suggest is OpenTK. It is basically a very portable (and pretty thin) .NET binding around OpenGL, OpenAL etc. Anything you learn here will almost directly be translatable in later life to C, C++ or other languages using OpenGL. Including Javascript and WebGL (or preferably Emscripten).
For 2D you should find it pretty easy. For 3D naturally it becomes a more steep learning curve because you will be learning the fundamentals of modern 3D graphics programming rather than just scripting and automating products like Unity.

http://www.opentk.com


#5165511 DLL Import Failure

Posted by Karsten_ on 08 July 2014 - 04:40 AM

First of all, who ever said anything about Unity?  I never once mentioned it.

Heh, yeah, my bad. I kinda made the assumption that guys here using C# are probably using Unity. Much of my suggestions are C# issues in general than Unity so at least that cuts out licensing restrictions.

 

Now that you mention it though, it does require another DLL.  I don't remember whether I included that into the project as well.  Should I just include both of them and put both of them into the debug folder where the EXE is?

Normally just include them in the same folder as the .NET executable. However try compiling them in release mode. I think debug versions of the binaries could potentially cause issues.

 

If your .dll does come with a .lib file, then yeah it is likely to be a traditional native dll. So no problems here.




#5165288 DLL Import Failure

Posted by Karsten_ on 07 July 2014 - 10:38 AM

The .dll should be the correct one. .lib files are not used like that (On Linux you would use .so rather than .lib too).

However in Unity C# you do not seem to need to pass in the .dll suffix (may be optional). Perhaps try:

 

[DllImport("DllName")]

 

Have a look here: http://docs.unity3d.com/Manual/Plugins.html

 

Btw, this is a Unity Pro only feature so that could be your issue.

 

Perhaps also make sure you are not trying to compile for the Web Player. That has extra restrictions preventing native code for security sandboxing reasons.

 

Can you make sure your .dll does not require any other dlls? Usually if they require more .dlls then it could fail to load. There are tools on Windows that should help you find out (perhaps try depends (http://www.dependencywalker.com)).

 

Perhaps also make sure that you have built a native .dll. It is quite likely that you already know this but if you generated a .NET dll using Microsoft C++/clr:safe or pure, it will not work when loaded in like this.

 

Finally, I once noticed that when I made a Unity plugin with wxWidgets, it actually had to have the wxWidgets dll in the same directory as Unity.exe. Perhaps try this if none of the other suggestions work.




#5158233 After learning basics of C++

Posted by Karsten_ on 04 June 2014 - 04:07 PM

and i saw that none of mobile platforms support C++

They do not advertise very well that they support C++ but the fact of the matter is that they all have to support C++ because they were largely all written in C or C++.

 

So with Android, have a look at using the NDK (https://developer.android.com/tools/sdk/ndk/index.html). The examples are great and you can generally get started (with OpenGL) directly from the hello-gl2 example project.

If you do not want to use *any* Java in your application, then look towards using the NativeActivity. Personally I much prefer using this simple event driven system rather than all the object-orientated fluff required by typical Android development.

 

With iOS, you will be using Objective-C++. Most of the documentation is about Objective-C (i.e https://developer.apple.com/library/mac/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html) but frankly it is quite straight forward to apply your C++ knowledge to extend it to Objective-C++. One of the main tricky bits is getting the automatic memory management (RAII) provided by C++ to play nicely with the automatic memory management (Reference counting) provided by Objective-C.

 

With WP8 / Metro you will be using C++/cx (http://developer.nokia.com/community/wiki/C++_support_from_Windows_Phone_8). This language is very similar to Microsoft's C++/clr compiler and is basically an extension to pure C++ (i.e it also provides ^ and % in place of * and & for managed or WinRuntime references).

 

Blackberry primarily uses C/C++ anyway (have a look at http://developer.blackberry.com/native/documentation/cascades/getting_started/first_app/create_your_first_core_app.html). I enjoy blackberry development. I found its API to be really clean and well documented. It is really noticable that the API is designed with C++ in mind as being its main applications language. Shame Blackberry is no longer "cool" :/.

 

Tizen is apparently programmable with both Javascript and C/C++ but I dont know too much about it. Not yet had a project involving it (some docs: https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.apireference/group__Cplusplus.html).

 

You may also want a look at Marmalade (https://www.madewithmarmalade.com/) which not only provides the C++ SDK but also an abstraction layer to help write cross platform code for many platforms.

 

Finally, and I probably do not advise this but you can also use Microsoft C++/clr to script more hobbyist tools like Unity. If you make sure to use the /clr:safe flag, it even works in the restricted WebPlayer environment (Though you also lose a lot of the power and benefits of C++ too).




#5158085 Language Choice

Posted by Karsten_ on 04 June 2014 - 07:14 AM

Well, I should mention that now both Unreal Engine 4 and CryENGINE are cheaper than most commercial game engines (Better than Unity Pro's 30,000 dollars)

 

Agreed. Epic Games in particular has done a very impressive thing by opening up their Unreal engine to the masses. Frankly I am very happy to pay their subscription costs more as a donation and pledge of support even if I am not currently using their engine for a recent project.

 

Last time I looked at CryENGINE however, it required me to log onto their servers in order to use the main tool. This is called DRM and for this reason, it should not get our support. Similar to why Unity should not get our support.

 

I really am hoping that Epic Games benefits from their decision. They really deserve it. I am also noticing a massive improvement in portability to platforms like Emscripten, Linux and even BSD because of this so again, great job!




#5157305 What to use for an OpenGL-based game engine.

Posted by Karsten_ on 01 June 2014 - 05:14 AM

I personally use wxWidgets for tooling (since I never liked the way that Qt advocates using non standard C++).
It is portable to pretty much any OS people run productivity software on.

The exact widget I use is called wxGLCanvas.

You can read more about it and it's usage here: http://wiki.wxwidgets.org/WxGLCanvas

Most people's gripe with it is that much of the old documentation talks about things like DECLARE_EVENT_TABLE() because it used to use this system back when MFC was "cool", however this is very out of date and you should use connect() instead. Have a read of: http://wiki.wxwidgets.org/Example_Of_Using_Connect_For_Events
Not many developers know this unless they have actually used wxWidgets before so unfortunately this misinformation still spreads.

For the games themselves, I really suggest grabbing a rendering context from some library (Glut will do on desktop, GLSurfaceView will do on Android) and then create your own GUI widgets in OpenGL.


#5155837 Language Choice

Posted by Karsten_ on 25 May 2014 - 05:12 AM

In the professional world of interactive media and games, C/C++ are the main choice.

However for indie game development, you are very much constrained to what your tool of choice uses. For example with Unity you are going to be looking at .NET languages (C#, UnityScript, Boo). Likewise, the "Indie" version of UDK 3.x would require UnrealScript.

Many of the more open-source engines and tools allow you to use C++ (as well as other languages with bindings) including the very latest UDK 4.x (if you subscribe for source access).

So the question really is. Out of all the engines you have had a play with. Which do you prefer? Then pretty much go with whatever language it best supports.


#5153604 How do I add librarys in visual studio 10?

Posted by Karsten_ on 14 May 2014 - 11:06 AM

My favorite method is by using the #pragma comment, ex:

 

#pragma comment(lib, "LibraryName.lib")    

 

I do like the idea of the #pragma solution since for example if you use the GLUT_STATIC or GLEW_STATIC define then the #pragma can be put in the correct #ifdef and link against the static version of the library (glut_static.lib) rather than the dynamic version. This means that you do not need to worry about the linker and build system becoming unsynced with the code.

 

However since I always try to write the most portable code I can, I guess I will never use it until 99% of compilers (especially on UNIX) support this type of linking ;)




#5151722 Visual Studio 2012 Command Line Building Woes

Posted by Karsten_ on 05 May 2014 - 04:55 PM

Microsoft's C++ compiler has a flag that specifies whether to use the static runtime (/MT) or the dynamic runtime (/MD).
 
Issues arrise when different libraries / programs use different versions of the runtime (error messages about conflicting symbols as you saw). There seems to be no "standard" on this so you need to be weary which libraries you use because by default they might use the wrong one.

Since it is probably easier for you to just use whichever runtime SDL uses rather than recompile SDL to match your program we are going to have to add this flag to the Makefile.
 
So again, either before or after the /link flag (I think it is after because it seems to be a linker option, but not 100% sure), you need to add either /MT or /MD depending on what SDL uses.
You should also remove the NODEFAULTLIB:msvcrt.lib flag since it should hopefully be using the same runtime now smile.png


#5150818 Game creation for Android

Posted by Karsten_ on 01 May 2014 - 04:19 PM

I had a quick look through the Construct 2 docs. There is a lot of mention of plugins (including Windows 8, keyboard, etc...). https://www.scirra.com/manual/145/windows-8. Am I correct in thinking it is possible to develop your own plugins to Construct 2?

 

If the game runs on the Fire TV, then you are 99% the way there. If you invest a little bit of time learning how to create a plugin to bind the underlying gamepad API to the rest of the platform, you should be able to avoid having to reimplement your game in an entirely different platform.

 

If it is anything like the Ouya, then it is as simple as adding an additional jar, tweaking the manifest and mashing in some extra lines of java into the activity class. Perhaps you can do this by modifying an existing Android plugin for Construct.




#5150769 Visual Studio 2012 Command Line Building Woes

Posted by Karsten_ on 01 May 2014 - 12:08 PM

After you have called vcvarsall.bat, you should only have to call cl.exe rather than the full path since your path env variable has now been extended to include the VC/bin directory.

 

The error you are getting is because it is not finding either the main or winmain functions.

As I recall, SDL is a little bit screwy on Windows so I think it needs /SUBSYSTEM:CONSOLE to be defined as a compiler flag.

 

Perhaps try putting that either before or after the /link argument.




#5149240 Basic OpenGL / SDL 2 app - Source

Posted by Karsten_ on 24 April 2014 - 05:16 PM

This is a nice example which is not bogged down with any OOP. I will likely refer people to this when they are starting out with SDL2 and GL. Thanks smile.png

 

A small question..

 

Inside main cpp (OLD and NEW) you have the define

#define nullptr nullptr

Is there a reason for this?




#5143493 Linux development...

Posted by Karsten_ on 31 March 2014 - 09:21 AM

A few tips that might help.

1) Like any new platform, start simple. Use a plain text editor and compile from the console until you understand what the IDEs are "meant" to be doing for you.

2) Are you new to C/C++ development too? If so, perhaps learn this on the platform you currently use so you are not in a completely foreign environment.

3) With Linux, in exactly the same way as OSX and Windows. If you have hardware that the OS does not support, swap out the hardware with something that does. In your case, a graphics card is quite an easy thing to replace. However, I would be suprised if your card was not supported. Perhaps try running glxgears or a 3D linux game (i.e OpenArena) to see if it is working.

What issues were you experiencing with Irrlicht? Did you install it from the package manager (# apt-get libirrlicht-dev) or manually from a source archive? If you specify the error you are having, I might be able to help solve it with you. In most cases you can compile code like:

$ g++ MyCode.cpp -lIrrlicht
Linux is trivial to develop for so once you get over these initial hurdles, you will find it extremely straightforward from then on.


#5142912 Browser-Based Game: Best Language?

Posted by Karsten_ on 28 March 2014 - 01:11 PM

There are many Javascript tutorials around the internet because it is quite popular (Perhaps due to the flux of web developers flooding out of universites between 2008-2011). So I am sure you can find some quite easily via google.
The only additional tips I can offer is to be weary of w3schools which traditionally has been infamous for bad habits (though it might be better now).
You will also come across many examples pushing JQuery. I would keep well away from this because it is not standard Javascript and it is not always very interoperable with other libraries.

A site that does look quite useful is Mozilla's developer site. It doesn't look browser specific either which is obviously important.
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Canvas_tutorial




#5142815 Browser-Based Game: Best Language?

Posted by Karsten_ on 28 March 2014 - 05:32 AM

There is currently a catch with the following technologies:

 

Java

C# (Unity 3D)

C# (Silverlight)

AS3 (Flash)

 

They require your users to have a plugin (of the correct version) installed. This also means that your software will only work in specific browsers on a limited number of operating systems (that supports the plugin). Tablets in particular will not load them in their web browsers.

Plugins are a legacy technology that are slowly and surely moving over to Javascript / asm.js. Unity is making good progress at porting their plugin to pure Javascript via Emscripten, Unreal engine has done the same. Adobe have also stated that they are going to be migrating their tools and language over to HTML5. Unfortunately none of these are quite ready yet.

 

So instead, since you are starting from scratch anyway, I recommend the following choices.

 

Javascript (+ Canvas) - For 2D web games

Javascript (+ WebGL) - For 3D web games (perhaps using three.js to help)

HaXe / Typescript etc. export to JS too so these kind of things might suffice if you really dislike Javascript.

 

If you or anyone else in your team is interested in getting into programming in a big way, then this opens you guys up to Emscripten (C++ -> Javascript compiler) which is becoming very popular now with larger companies and native developers but also allows you to utilize a massive back catalogue of traditional C and C++ libraries to help you develop your game (rather than reinvent the wheel).






PARTNERS