Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Dec 2013
Offline Last Active Today, 03:43 PM

#5184908 Is 3D game development easier with an engine?

Posted by Jan2go on 04 October 2014 - 02:27 AM

As Hodgman said, making development easier is the reason why they exist.

Off the top of my head I can only think of a few reason why one would build their own engine, e.g. to learn how they work internally or because you need some super special features that you cannot get from an existing engine. Or, obiviously, if you're getting paid for it. biggrin.png

#5184861 What version of MonoGame should I use ?

Posted by Jan2go on 03 October 2014 - 06:05 PM

A quick Google search came up with OpenGL 1.4 being the latest that is supported by your hardware. As MonoGame 3 uses OpenGL 2 this explains why it doesn't work for you. The older 2.5.1 release might indeed work better for as it supports OpenGL 1.1.

#5184742 Help! I cannot run makefiles with commands D:!

Posted by Jan2go on 03 October 2014 - 04:17 AM

Strange. On my machine it compiles without any problems. What distribution of MinGW do you use? The "/usr/bin/sh" part looks like Cygwin to me. If it is I can't really help you as I never used it before.

#5184658 Help! I cannot run makefiles with commands D:!

Posted by Jan2go on 02 October 2014 - 04:41 PM

You need to run make (or mingw32-make as it is called in the MinGW destribution I use) in the directory that contains the Makefile. In this case this would be the "lua-5.2.3" folder (for some reason you have 2 or these, there should be only one after unzipping the archive).


btw: make mingw tells make to build a target called "mingw" so that's not going to work. ;) Lua actually has a "mingw" target, so forget about this line.

#5177282 glut glew freeglut, what is diffrence?

Posted by Jan2go on 31 August 2014 - 03:50 PM

now i read some articles that i have to add glew_static but i dont know what it is. can you please help me.

It's GLEW_STATIC (case is important) and you need to add it to your preprocessor definitins (Project Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions), but only if you are linking against the static version of GLEW (i.e. one the glew32s.lib files).

what does it mean that to use which library? i pasted the library to programefiles86/ microsftsdks/windows/7.0/lib and include  
are there diffrent kind of files there with same name?

That directory is for Microsoft's Windows SDK. You don't want to put your files in there. You can place them wherever you want, but don't put them into into the folder of another SDK. You could for example create a dedicated SDK directory next to the projects folder you mentioned earlier. Then you add the directory where you placed your SDK to the linker directories (Project Properties -> Linker -> General -> Additional Library Directories) and the libary's name to the dependency list ((Project Properties -> Linker -> Input -> Additional Dependencies).

#5177170 glut glew freeglut, what is diffrence?

Posted by Jan2go on 31 August 2014 - 03:42 AM

FreeGLUT is an open-source alternative to GLUT. As the latest version of GLUT was released in 1998 you should probably use FreeGLUT if you decide to use one of them. They provide functionality for window creation, input handling an some other things
GLEW on the other hand has a different functionality. It loads the function pointers that you need to write modern OpenGL code.
You should be able to use GLEW with FreeGLUT but you cannot use GLUT and FreeGLUT at the same time.

For more detailed information you should check the documentations of FreeGLUT and GLEW.

#5175508 Efficient way to read .obj files in Visual Studio 2013

Posted by Jan2go on 22 August 2014 - 10:34 AM

What are those "libraries"? Where do I find them? And most important can I use them for my own purposes?


As no one aswered to this part yet, I guess I'll have to do it. :D


Of course there are libraries available allow you to load OBJs (and lots of other formats as well). Assimp and the FBX SDK just to name a few.

You still have to create your buffers but these libraries allow you to easily access the vertex data.

#5170376 Make file unreadable by an external program

Posted by Jan2go on 30 July 2014 - 10:24 AM

As soon, as the game has loaded, literally all I need to do is Alt-Tab out to Pix/gDebugger/ApiTrace/... select the texture and click "Save As...".

I'm did not understand this line, could you tell me more about it please ? If you agree ^^

Tools like Pix (for DirectX) or gDEBugger/CodeXL (for OpenGL) are used for graphics debugging. Among others things, they can show you all textures that are loaded by the program that you are debugging.
Even if these tools may not necessarily provide an export functionality, it's still not that hard to save your textures.

#5170083 I'm A Programmer, Not An Artist

Posted by Jan2go on 29 July 2014 - 09:45 AM

You can always use placeholders while developing. For 2D you could draw stuff on paper and scan it in order to use it for your prototypes. For 3D you can stick with very basic meshes like boxes and capsules.
Once your game has reached a state where you can show something interesting you can still look for an artist to help you out with the graphics (e.g. at the Classifieds).

#5169769 Make file unreadable by an external program

Posted by Jan2go on 28 July 2014 - 08:44 AM

XNBs are simply files that are generated by the XNA Content Pipeline. They are not encrypted in any way, you can write yourself a viewer without much trouble using XNA or Monogame.

The easiest way that I can think of to "protect" your assets would be to store them in one or multiple archive (7z, zip, ...) and use a custom extension. Then, you change the the archive header so that the files cannot be opened without knowing how to reconstruct the original header.

Somehow I wonder what kind of assets you have that no one must be able to see them. biggrin.png

#5163206 Vector Efficiency question

Posted by Jan2go on 27 June 2014 - 05:18 AM

If you always search for objects by name, you could use std::map to get the right one. That way the lookup is only O(log n) instead of O(n); you won't see a difference with your 4 objects, but once you add more objects you will see the difference. When using std::map, you might also take a look at hashing to avoid string compares when looking for the data, as string compares can be quite expensive compared to integer compares.

#5157940 unresolved external symbol problem

Posted by Jan2go on 03 June 2014 - 03:13 PM

1. You still have "glew32.lib" listed under "C/C++ > General > Additional Include Directories". This field is not meant for libraries or even files. In there you put, directories (not files!) where the compiler should look for files to #include in addition to the default ones (i.e. the place where Microsoft C++ implementation is and the folder of your own code).

2. Under "Linker > General > Additional Library Directories" you have also listed "glew32.lib". Again, this field is not for files. In there you put the directories (not files!) where the linker should look for the libraries (which you specify under "Linker > Input > Additional Dependencies").


So, if you remove the entry from "C/C++ > General > Additional Include Directories" and change the one in "Linker > General > Additional Library Directories" to the path to your glew32.lib (without filename) it should work.

#5157918 unresolved external symbol problem

Posted by Jan2go on 03 June 2014 - 01:24 PM

Another thing that I noticed when I opened the project file in Notepad++. It seems like you have copied GLEW (at least the glew.h) into Visual Studio installation directory. I strongly recommend you to not copy any file into these folders, they are meant for Microsoft's C++ implementation. Put your files into some other folder (C:\Programming Stuff\... or so) or, if we're talking about small libraries like GLEW even inside your project folder.


Are you sure that the paths you entered are correct? You might want to upload the updated project (after you moved GLEW out of the VS directory :)) again.

#5157910 unresolved external symbol problem

Posted by Jan2go on 03 June 2014 - 12:59 PM

No, I haven't even tried to compile it as I have neither GLUT nor GLEW libraries on my computer. You might want to add the path to the glew32 lib unter "Linker\General\Additional Libary Directories". Forgot to mention that one in my last post.

#5157899 unresolved external symbol problem

Posted by Jan2go on 03 June 2014 - 12:24 PM

You have specified the "glew32.lib glew32s.lib" under "Additional Include Directories". First, that is the place where you put the paths where the compiler should look for  #include "..." files. Libraries need to go into "Linker\Input\Additional Dependencies". Second, you can't put two libraries, paths, etc. in the same line; use one line per entry or separate the entries with a semicolon.

Also, you should only link glew32.lib or glew32s.lib, not both of them. glew32.lib is for dynamic linking (requires glew32.dll at runtime), glew32s.lib is for static linking (no dll required). If you go for static linking you need to #define GLEW_STATIC before you #include <glew.h>.