Jump to content
  • Advertisement
Sign in to follow this  
stellar

Building in a OS that you don't have (Cross-platform 2D engine)

This topic is 809 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello guys,

 

I currently started working on a simple 2D engine to apply my OpenGL knowledge and learn about building and stuff.

I have a Mac and a Linux, therefore I can easily test building and configure CMake settings for these operating systems. However I also wanna build on Windows, and yesterday I got some trouble trying to achieve that:

 

- I installed a Windows 7 virtual machine

- Configured everything and installed GLFW, GLEW

- Run cmake, tweaked configuration, run make and everything went fine, no single error.

- So when I tried to run the .exe program it crashed with no obvious reason.

 

Now I don't know if the problem is with my code or with the VM. I did a research and apparently OpenGL can run normally on a VM. I also installed VirtualBox Guest Additions but nothing changed.

 

After some time I realized that my Windows 7 had OpenGL 2.1, and I was using 3.3 functionality. However this would throw me an error on Linux or Mac and not simply crash.

 

Now I ask: Is it common for developers to build their projects in Virtual Machines or do I have to own physical Machines? Is there any other alternative for using VMs?

 

Here's the early code for my 2D engine. Currently it only displays a triangle on screen, but I want to make sure it works in all three major platforms in order to advance.

 

I would change CMakeLists.txt to this so you don't have to worry about SOIL library as the project isn't using it just yet:

cmake_minimum_required(VERSION 3.0)
project(stella)

file(GLOB_RECURSE SOURCE ${PROJECT_SOURCE_DIR}/src/*.cpp)

set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)

find_package(OpenGL REQUIRED)

find_package(PkgConfig REQUIRED)
pkg_search_module(GLFW REQUIRED glfw3)
include_directories(${GLFW_INCLUDE_DIRS})

find_package(GLEW REQUIRED)
include_directories(${GLEW_INCLUDE_DIRS})

# Not using SOIL yet
# find_package(SOIL REQUIRED)
# include_directories(${SOIL_INCLUDE_DIRS})

add_executable(stella game.cpp ${SOURCE})

if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU" OR
    "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang" OR
    "${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang")
  set(CXX_COMPILE_FLAGS "-std=c++11 -Wall")
endif()

if (UNIX AND NOT APPLE)
  set (LINUX TRUE)
endif()

if (LINUX)
  set(CXX_LINK_FLAGS "-lX11 -lpthread -lXrandr -lXi -lGL")
elseif(APPLE)
  set(CXX_LINK_FLAGS "-framework Cocoa -framework OpenGL -framework IOKit -framework CoreVideo -framework Carbon")
  set(GLFW_LIBRARIES "glfw3")
elseif(WIN32)
  set(CXX_LINK_FLAGS "-lopengl32")
endif()

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CXX_COMPILE_FLAGS}")
target_link_libraries(stella ${CXX_LINK_FLAGS} ${GLEW_LIBRARIES} ${GLFW_LIBRARIES})

Share this post


Link to post
Share on other sites
Advertisement


Now I ask: Is it common for developers to build their projects in Virtual Machines or do I have to own physical Machines? Is there any other alternative for using VMs?

 

No, it is not common.  Most if not all of the developers I know have physical machines for testing.  Testing in a virtual machine is risky for many reasons; especially since a majority of your end users will not be running the build from within a virtual machine.  If you are going to build for Windows, have a native Windows machine with at least your bare minimum target hardware.

Share this post


Link to post
Share on other sites

Thanks ByteTroll, appreciate your help.

Well, it seems I don't have another alternative than dual booting.

Share this post


Link to post
Share on other sites

I would actually disagree with ByteTroll to a certain level.  We use continuous integration and everything is built using VM's and in a lot of cases our automated tests run within the VM's also.  So long as that process completes, we hand the builds to QA and they test on real hardware.  Additionally, when working on a Mac, I tend to run a Windows VM for testing reasons until I switch back to a real Windows box.  So, I use VM's quite a bit for both building and running.  Is this common?  I'd actually say it is for folks doing a lot of cross platform work.

Share this post


Link to post
Share on other sites

I would actually disagree with ByteTroll to a certain level.  We use continuous integration and everything is built using VM's and in a lot of cases our automated tests run within the VM's also.  So long as that process completes, we hand the builds to QA and they test on real hardware.  Additionally, when working on a Mac, I tend to run a Windows VM for testing reasons until I switch back to a real Windows box.  So, I use VM's quite a bit for both building and running.  Is this common?  I'd actually say it is for folks doing a lot of cross platform work.

 

Interesting. I was also using a Mac to run the VM.

Could you give me some specifications of the VM you were using?

Share this post


Link to post
Share on other sites

Literally everyone I can think of builds on multiple platforms via CI in a VM farm. You can also run as many of your automated tests as possible as part of your CI. You're not going to give each of your developers one of each of the possible 10+ platforms* you might be targeting and expect them to manually build and test in each before committing any change. That would be pure idiocy.

 

That's not a replacement for full testing and release validation of course, which I think is maybe what ByteTroll was really talking about?

 

You can setup a small cluster of VMs or use some hosted services like TravisCI and AppVeyor or VSO to do your CI for you. You'll need your own in-house CI system with physical access to consoles to run most automated tests, of course, but you can still make your builds on regular ol' VMs, so at least manual testing is as easy as deploying a build, so non-engineers can do the testing.

 

*PC, Linux, Mac, iOS, Android, XBone, PS4, WiiU, HTML5, XB360, PS3, 3DS, NX, WP8, UWP, and probably some more that I missed.

Share this post


Link to post
Share on other sites

I generally use VMware Fusion running Windows 7 or 10.  It can support running DX 10 I believe and GL 4.0 so it does pretty well for our needs.

Share this post


Link to post
Share on other sites

Wine is fine for testing unless you're using Direct3D (or is this better now?).
Dual booting ReactOS might also be worth looking into - it's an open-source binary-compatible implementation of Windows XP. But this had severe issues when I tried it out about 5 years ago and considering how often it BSOD'd back then it's probably still not great.

Edited by nfries88

Share this post


Link to post
Share on other sites


Now I ask: Is it common for developers to build their projects in Virtual Machines or do I have to own physical Machines? Is there any other alternative for using VMs?

 

Many developers use virtual machines over the course of development, but generally there is at least one step where actual devices are used.

 

An exception is for systems where deployment is going to also be on virtual environments, such as back-ends for databases or server clusters. In that case the virtual environment is also the real environment, so they are still running and testing on the system they are going to use.

 

In your case you are planning on targeting Windows, MacOS, and Linux.  If you are serious about the development, you will eventually need a box (probably plural) with each system on it.

 

If you are less serious about it, or it is a hobby project, you can say that you believe it runs runs on the platform or otherwise suggest that they can probably run it just fine,  but I'd be wary of saying it is fully supported. If you haven't run it on actual devices running the system, you don't know for certain it actually runs on them.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!