Jump to content
Sign in to follow this  
  • entries
    31
  • comments
    4
  • views
    2849

It's magic!

GameDev2017

1060 views

The first time writing code in C++ and, indeed, the door opens! 
We develop in C++ mixed with Blueprints but, in the beginning, we mainly work in the 3D Editor and push the polygons later to UE4.
Writing code will increase when the character will finally act and play.

 

 



0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By phil67rpg
      well I am able to get my sprites to rotate and move in all directions, I have drawn two plane sprites, I am also able to shoot a bullet in the up direction, I want to shoot bullets in all directions just like my plane rotates, I just need a hint on how to proceed, go easy on me this is new stuff to me. However I am making progress.
    • By Shaarigan
      Hey,
      I'm currently starting next iteration on my engine project and have some points I'm completely fine with and some other points and/or code parts that need refactoring so this is a refactoring step before starting to add new features. As I want my code to be modular to have features optional installed for certain projects while others have to stay out of sight, I designed a framework that starting from a core component or module, spreads features to several project files that are merged together to a single project solution (in Visual Studio) by our tooling.
      This works great for some parts of the code, naming the Crypto or Input module for example but other parts seem to be at the wrong place and need to be moved. Some features are in the core component that may belong into an own module while I feel uncomfortable splitting those parts and determine what stays in core and what should get it's own module. An example is Math stuff. When using the framework to write a game (engine), I need access to algebra like Vector, Quaternion and Matrix objects but when writing some kind of match-making server, I wouldn't need it so put it into an own module with own directory, build script and package description or just stay in core and take the size and ammount of files as a treat in this case?
      What about naimng? When cleaning the folder structure I want to collect some files together that stay seperated currently. This files are foir example basic type definitions, utility macros and parts of my Reflection/RTTI/Meta system (which is intended to get ipartially t's own module as well because I just need it for editor code currently but supports conditional building to some kind of C# like attributes also).
      I already looked at several projects and they seem to don't care that much about that but growing the code means also grow breaking changes when refactoring in the future. So what are your suggestions/ oppinions to this topic? Do I overcomplicate things and overengeneer modularity or could it even be more modular? Where is the line between usefull and chaotic?
      Thanks in advance!
    • By jonwil
      We have an engine based on Direct3D11 that uses ID3D11Device::CreateTexture2D to create its textures passing in whatever format we read from the dds file header.
      We also have a previous version of our engine that uses the DX9 fixed function bump map feature for bump maps. This feature takes bump map textures in U8V8 format as input but it also takes textures in DXT5 and A8R8G8B8 and converts them into U8V8 using D3DXCreateTextureFromFileInMemoryEx in d3dx9).
      Our current D3D11 engine handles the U8V8 textures just fine (I think it feeds it to CreateTexture2D as DXGI_FORMAT_R8G8_TYPELESS) and has some shader code that emulates the fixed function bump map feature without problems. But now we want to add support for the DXT5 and A8R8G8B8 bump maps.
      Does anyone know where I can find code for Direct3D11 (or just plain code with no dependence on specific graphics APIs) that can convert the DXT5 or A8R8G8B8 texture data into U8V8 data in the same way as D3DXCreateTextureFromFileInMemoryEx and the other D3DX9 functions would do? (Someone out there must have written some code to convert between different texture formats I am sure, I just can't find it)
    • By PlanetExp
      I've been trying to organise a small-medium sized toy game project to supports macOS, iOS and Windows simultaneously in a clean way. But I always get stuck when I cross over to the target platform. I'll try to explain,
      I have organised my project in modules like so:
       
      1. core c++ engine, platform agnostic, has a public c++ api
      2. c api bindings for the c++ api, also platform agnostic, this is actually part of 1 because its such a small project
      3. target platform bindings, on iOS and macOS this is in swift. Basically wraps the c api
      4. target platform code. This part just calls the api. Also in swift.
       
      So in all I have 4 modules going simultaneously, all compiled into a separate static libraries and imported into the next phase/layer. Am I even remotely close to something functional? I seem to getting stuck somewhere between 2 and 3 when I cross over to the target platform. In theory I would just need to call the game loop, but I always end up writing some logic up there anyway.
       
    • By SmilingDerek
      I've decided to branch out from Java and try learning C++ with Vulkan because it sounded like fun, but I've had a lot of trouble linking the libraries for GLFW and Vulkan. I'm following a tutorial on vulkan-tutorial.com which uses Visual Studio for the project. I've tried Visual Studio, Eclipse CDT, Code::Blocks, and command line compilation using MinGW G++, but every single method complains about undefined references to GLFW and Vulkan members. Here's the code in main.cpp:
         
      #define GLFW_INCLUDE_VULKAN #include <GLFW/glfw3.h> #define GLM_FORCE_RADIANS #define GLM_FORCE_DEPTH_ZERO_TO_ONE #include <glm/vec4.hpp> #include <glm/mat4x4.hpp> #include <iostream> int main() { glfwInit(); glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API); GLFWwindow* window = glfwCreateWindow(800, 600, "Vulkan window", nullptr, nullptr); uint32_t extensionCount = 0; vkEnumerateInstanceExtensionProperties(nullptr, &extensionCount, nullptr); std::cout << extensionCount << " extensions supported\n"; glm::mat4 matrix; glm::vec4 vec; auto test = matrix * vec; while(!glfwWindowShouldClose(window)) { glfwPollEvents(); } glfwDestroyWindow(window); glfwTerminate(); return 0; } Here are the commands being used to compile the code:
         
      g++ -std=c++11 -fexceptions -g -IC:/glfw-3.2.1/include -IC:/glm-0.9.9.1/glm -IC:/VulkanSDK/1.1.82.1/Include -c "src/main.cpp" g++ -LC:/glfw-3.2.1/lib-mingw-w64 -LC:/VulkanSDK/1.1.82.1/Lib -o VulkanTest.exe main.o -lglfw3 -lvulkan-1 The first command compiles the .cpp into a .o successfully, but the second command gives me errors from the linker. Every single reference I made to a member from Vulkan or GLFW is undefined. (Path has been shortened for easier reading)
      [omitted]/src/main.cpp:12: undefined reference to `glfwInit' [omitted]/src/main.cpp:14: undefined reference to `glfwWindowHint' [omitted]/src/main.cpp:15: undefined reference to `glfwCreateWindow' [omitted]/src/main.cpp:18: undefined reference to `vkEnumerateInstanceExtensionProperties@12' [omitted]/src/main.cpp:26: undefined reference to `glfwWindowShouldClose' [omitted]/src/main.cpp:27: undefined reference to `glfwPollEvents' [omitted]/src/main.cpp:30: undefined reference to `glfwDestroyWindow' [omitted]/src/main.cpp:32: undefined reference to `glfwTerminate' It seems like the linker can't find the library files I provided with -L and -l, but if I change -lglfw3 to -llibglfw3.a or -lglwf3.dll, I get this:
         
      [omitted]/mingw32/bin/ld.exe: cannot find -llibglfw3.a
      or
      [omitted]/mingw32/bin/ld.exe: cannot find -lglfw3.dll Leading me to think that the linker DID find the libraries at first, since it didn't complain about being unable to find the library - but why can't it find sources for the references to GLFW / Vulkan functions? I have no idea what's happening. Is it finding the library files?
      I'm using GLFW 3.2.1, Vulkan SDK 1.1.82.1, MingW GCC version 6.3.0, and I'm running on Windows 10 Pro 64-bit.
×

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!