This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 »
31
General ENIGMA / Re: Lateral GM question
« on: October 01, 2014, 10:15:36 pm »
ENIGMA is a plugin to LateralGM. LGM loads the game file and passes that information on to ENIGMA, which then does its own thing.
Robert did some work on getting it to compile from the command line; I don't recall how much of LGM he used or if it still works: http://enigma-dev.org/forums/index.php?topic=2047
Robert did some work on getting it to compile from the command line; I don't recall how much of LGM he used or if it still works: http://enigma-dev.org/forums/index.php?topic=2047
32
Off-Topic / Re: Windows 10
« on: October 01, 2014, 05:45:21 pm »
Windows, including the start menu, looks way better than Gnome, IMO. Gnome overdoes gradients and rounding, and makes everything slightly too big. It is a little odd that Modern apps would have a different title bar, though.
34
Off-Topic / Re: Good places to learn OpenGL
« on: September 30, 2014, 07:57:41 pm »
No, there is a consistent, standard OpenGL API. It just doesn't include context creation or backbuffer swapping. The only thing you need wrappers for is initializing a window with a GL context and calling some sort of SwapBuffers() once per frame.
35
Off-Topic / Re: Good places to learn OpenGL
« on: September 30, 2014, 11:42:59 am »
To add to that, the reason for the wrappers is that every platform has a different way to get an OpenGL context and to actually put things on the screen- Windows uses wgl and Win32 functions, Linux uses glX and X11 functions, etc.
GLFW is probably the lightest wrapper there is- it lets you just create a window without dealing with platform-specific APIs. Probably a good place to start if you just want to #include a few headers, make a window, and start making GL calls.
You'll also need GLEW whichever window/context library you use, to load GL extensions (which is a euphemism for "almost all the modern API"). But it's pretty simple too- just #include a header and call a function to initialize everything.
A couple of other good tutorials: http://www.opengl-tutorial.org/ https://open.gl/
GLFW is probably the lightest wrapper there is- it lets you just create a window without dealing with platform-specific APIs. Probably a good place to start if you just want to #include a few headers, make a window, and start making GL calls.
You'll also need GLEW whichever window/context library you use, to load GL extensions (which is a euphemism for "almost all the modern API"). But it's pretty simple too- just #include a header and call a function to initialize everything.
A couple of other good tutorials: http://www.opengl-tutorial.org/ https://open.gl/
36
Off-Topic / Re: Restructuring the Community
« on: September 25, 2014, 08:46:14 pm »* Rusky braces for the 10-page Darkstar2 post "refuting" that this forum is full of misinformation
37
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: September 25, 2014, 06:49:31 pm »
Robert- You should be able to get a list of users from Git itself then, if GitHub won't show unknown emails.
38
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: September 25, 2014, 05:45:42 pm »
Depending on how accurate the repo is, you could just look at this: https://github.com/enigma-dev/enigma-dev/graphs/contributors
39
Developing ENIGMA / Re: The benefits of Visual Studio's compiler?
« on: September 07, 2014, 09:39:56 pm »
Yep, .NET works the same way and is huge, but it's entirely unrelated to this thread.
40
Developing ENIGMA / Re: The benefits of Visual Studio's compiler?
« on: September 07, 2014, 04:18:47 pm »
To answer Josh's question, MSVC appears to be able to build OpenAL, ALURE, DUMB, OGG Vorbis, zlib, and libffi, out of the box, as they all have Visual Studio build instructions online. After fixing any potential issues with gnu extensions, it would likely be a matter of just switching the prebuilt library formats from .a to .lib, and switching the command lines in the Makefiles.
41
Developing ENIGMA / Re: The benefits of Visual Studio's compiler?
« on: September 07, 2014, 04:10:24 pm »
Y'all have no idea what you're talking about. Let me demonstrate; you can follow along if you like:
I just created a new console application in Visual Studio 2013. In release mode, it is 7Kb, and dynamically linked. It does not run on any of the Windows 7 PCs around here, because they do not have the 2013 Redistributable installed.
Now, in the project properties > Configuration Properties > C/C++ > Code Generation, I switch the Runtime Library option from /MD (DLL) to /MT (statically linked), and rebuild. The executable jumps to 68Kb and now runs on everything with no dependencies.
This is the exact same behavior as GCC, except if you do decide to go with the DLL, it's more likely to be installed on your target and easier to get if it's not. My Windows 8.1 install came with 2005, 2010, and 2012 by default, and the 2013 installer is only 7Mb and required for a lot of other things anyway.
Further, you can get Visual Studio to use older libraries if you have the SDK installed by going to Configuration Properties > General and changing the Platform Toolset option.
Finally, none of this has anything to do with .NET- it's all the C and C++ runtime libraries. Robert's correct that it's not backwards compatible, but with all the old versions factory installed with a total combined size around 13Mb, who cares?
I just created a new console application in Visual Studio 2013. In release mode, it is 7Kb, and dynamically linked. It does not run on any of the Windows 7 PCs around here, because they do not have the 2013 Redistributable installed.
Now, in the project properties > Configuration Properties > C/C++ > Code Generation, I switch the Runtime Library option from /MD (DLL) to /MT (statically linked), and rebuild. The executable jumps to 68Kb and now runs on everything with no dependencies.
This is the exact same behavior as GCC, except if you do decide to go with the DLL, it's more likely to be installed on your target and easier to get if it's not. My Windows 8.1 install came with 2005, 2010, and 2012 by default, and the 2013 installer is only 7Mb and required for a lot of other things anyway.
Further, you can get Visual Studio to use older libraries if you have the SDK installed by going to Configuration Properties > General and changing the Platform Toolset option.
Finally, none of this has anything to do with .NET- it's all the C and C++ runtime libraries. Robert's correct that it's not backwards compatible, but with all the old versions factory installed with a total combined size around 13Mb, who cares?
42
Developing ENIGMA / Re: The benefits of Visual Studio's compiler?
« on: September 07, 2014, 10:10:51 am »
Where are you getting the idea that VS outputs bloated executables? GCC also requires a separate standard library, unless (in both VS and GCC) you statically link it. Visual Studio's is about 6Mb, which is actually around the same size as what GCC adds when you statically link. However, it's installed by default on newer Windows installs, so you can use an older version and not depend on anything.
I'm not advocating either compiler in particular, but the reasons you're citing against VS are not all true. VS on Windows works much more smoothly and integrates better than MinGW- there's a reason people use it there.
I'm not advocating either compiler in particular, but the reasons you're citing against VS are not all true. VS on Windows works much more smoothly and integrates better than MinGW- there's a reason people use it there.
43
Developing ENIGMA / Re: The benefits of Visual Studio's compiler?
« on: September 05, 2014, 08:30:42 pm »
Darkstar2, why are you qualified to have an opinion on the effect of using VC++ over GCC? Have you run any tests? Just googling that, I see both compilers beating each other in different situations, with much wider variation just from the optimization flags used than from the compiler. MSVC and GCC are both high-quality compilers, and MinGW is just a Windows port of GCC- it's exactly the same program.
The biggest reason by far to use Visual Studio and/or its compiler on Windows is library and tool support. Visual Studio is a fantastic IDE with a fantastic debugger; all Windows SDKs are supported primarily (and often only) on MSVC; MSVC is guaranteed to be compatible with Windows. For example, rc files on Windows are a huge pain point in ENIGMA's build process because MinGW's windres.exe is perpetually broken. Further, Visual Studio's Express Edition has no restrictions on what you use it for. The only restrictions are some of the more advanced features that would be almost useless in porting ENIGMA.
Games probably wouldn't change noticeably by switching compilers. Some would maybe gain, some would maybe lose, there might be some rare pathological cases where one or the other compiler is way slower or faster. You can develop Windows App Store games with MinGW anyway, so it wouldn't make a difference there either.
The biggest reason by far to use Visual Studio and/or its compiler on Windows is library and tool support. Visual Studio is a fantastic IDE with a fantastic debugger; all Windows SDKs are supported primarily (and often only) on MSVC; MSVC is guaranteed to be compatible with Windows. For example, rc files on Windows are a huge pain point in ENIGMA's build process because MinGW's windres.exe is perpetually broken. Further, Visual Studio's Express Edition has no restrictions on what you use it for. The only restrictions are some of the more advanced features that would be almost useless in porting ENIGMA.
Games probably wouldn't change noticeably by switching compilers. Some would maybe gain, some would maybe lose, there might be some rare pathological cases where one or the other compiler is way slower or faster. You can develop Windows App Store games with MinGW anyway, so it wouldn't make a difference there either.
44
Developing ENIGMA / Re: Android
« on: September 02, 2014, 09:05:52 am »
I'd double check the file types. .eobjs is highly unlikely to be a problem, but missing dynamic library flags, bad file types for the exe or object files, or not having enough information in the exe to link with anything could all be issues as well.
45
Off-Topic / Re: I love Linux
« on: August 28, 2014, 05:50:46 pm »
Debian Testing is actually pretty up to date and nearly as stable. Debian Stable releases are more for super-critical applications that don't care about up to date stuff.
Arch Linux
Arch Linux