Jump to content
  • Advertisement

GuyWithBeard

Member
  • Content count

    527
  • Joined

  • Last visited

Community Reputation

1911 Excellent

3 Followers

About GuyWithBeard

  • Rank
    Advanced Member

Personal Information

  • Role
    3D Artist
    Level Designer
    Programmer
  • Interests
    Art
    Design
    Programming

Recent Profile Visitors

12947 profile views
  1. Now that Apple platforms have semi-official support for Vulkan it makes Vulkan the graphics API to target if cross-platform support is important for you. It is still not supported on all platforms (eg. Xboxes still support only DX and Sony has their own APIs too) but porting from Vulkan to another low-level API is actually not that difficult as opposed to porting from, say, OpenGL to DX11. Another option would be to look at a library like LLGL which abstracts away most (but not all) of the API differences and gives you a somewhat unified API to work with.
  2. GuyWithBeard

    Targeting both Win32 and UWP

    Excellent, yeah it seems like it was added in 2015. There is no such project type in VS 2013. Thanks for your help, I have some stuff to try out now
  3. GuyWithBeard

    Targeting both Win32 and UWP

    Sounds like something I should look into. Is this a scenario VS supports directly? Eg. what kind of project is the shared code project? Do you have to make it an actual C++ project (and if so, what kind?) and then just skip building it when building the solution or is there a special project type for these kinds of things? Thanks!
  4. GuyWithBeard

    Targeting both Win32 and UWP

    Interesting. Does the shared project produce a library which is then consumed by the other projects, or is it just a container for the shared code in VS?
  5. Hey folks! I have a question about how I should organize my Visual Studio project and/or solution to allow targeting both Win32 and UWP with as little resistance as possible. Currently my project consists of a game exe project and a few dll projects, all sitting under the same solution, and all targeting plain old Win32 with Visual Studio 2013. I have been thinking about porting the project to UWP for some time now, mainly to be able to run on the Xbox, but there are some things I haven't wrapped my head around, mainly how to organize the projects in Visual Studio. As far as I know, to build for UWP I would need to update to VS2015 and I would need to make the project an "app container" project. Codewise there shouldn't be that much to do, except change the main loop to work through the CoreApplication system as well as remove some uses of LoadLibrary() etc. However, it seems that if I change the project to an "app container" project I loose the ability to build for Win32. I was hoping I could simply add a new UWP configuration to the solution which would make all projects build "app container" targets, but that does not seem to be possible. Creating a new empty UWP project in VS and opening the vcxproj file up in a text editor reveals things like this in the "Globals" property group: <AppContainerApplication>true</AppContainerApplication> <ApplicationType>Windows Store</ApplicationType> <WindowsTargetPlatformVersion>10.0.14393.0</WindowsTargetPlatformVersion> <WindowsTargetPlatformMinVersion>10.0.10586.0</WindowsTargetPlatformMinVersion> <ApplicationTypeRevision>10.0</ApplicationTypeRevision> Namely, they are not part of a configuration, but instead make the whole project an "app container" project. What I would like to do is have one project (eg. the exe of the game) where I could flip between Win32 and UWP easily through configurations, using #defines to enable/disable parts of the code that does not apply to the current configuration. Is there a way to do this? One way I have been thinking about is having the Win32 project be the "main" project and have a UWP project which simply includes links to each and every source file in the Win32 project. This sounds cumbersome and error prone and I would like to avoid it if possible. Another way would be to autogenerate both projects with something like CMake, SharpMake or premake, but I would not want to get into that either right now. Any other options? Cheers!
  6. GuyWithBeard

    Networked Physics sanity check

    Seems like a solid version of the Quake networking model. We do something similar, except we keep the server ahead of the clients, ie. we never extrapolate on the clients, only interpolate. One thing missing from your description is lag compensation. Depending on the gameplay this may or may not be needed, but if you have hit-scan weapons you might want to have the server doing some kind of lag compensation, to counter the fact that the client and server are on different timelines.
  7. GuyWithBeard

    DirectX - Vulkan clip space

    I tried out the parameter last night and it does what it says on the can, so that's probably the easiest way to fix it up without having to flip the coordinate manually in the shader code. Not related to this, but I had some very strange issues with glslangvalidator 1.1.73.0 generating sub-optimal SPIR-V, almost as if the spirv-opt step that's supposed to be built into the LunarG version of the program was not run. Anyway, I had to revert to 1.1.70.0, but as it turned out the invert-y parameter is available with that version too :)
  8. GuyWithBeard

    DirectX - Vulkan clip space

    After updating to the LunarG SDK version 1.1.73.0 I noticed that glslangvalidator has gained this parameter: --invert-y | --iy invert position.Y output in vertex shader Sounds like exactly what we need. I haven't tried it out yet though.
  9. I don't know if this is something you can use but maybe it will give you some ideas. I wrote a preprocessor that is run before the actual shader compilation is performed. I let the preprocessor generate all the bindings for all shader inputs, according to some rules I have set up. This system is completely deterministic and I can decide exactly what I want and where it goes. I compile HLSL to both DX bytecode for DX11/12 and to SPIR-V for Vulkan. I might have something like this: #autobind Texture2D gTexture; #autobind cbuffer gConstantBuffer #autobind sampler gSampler; where #autobind is a preprocessor directive that gets expanded to something like this: layout(set=0,binding=0) Texture2D gTexture : register(t0); layout(set=0,binding=1) cbuffer gConstantBuffer : register(b0) layout(set=0,binding=2) sampler gSampler : register(s0); Using this system I have full control over where my inputs get bound, eg. I can always bind shadow map inputs to certain slots etc. I then use D3DReflect() on DX and SPIRV-cross on Vulkan to verify that the compiler generated what I want. Eg. in certain cases the compiler optimizes away an input in DXBC but not in SPIR-V or vice versa. This does not let you "re-bind" stuff in the already generated SPIR-V but it does let you decide where they are put in the first place.
  10. GuyWithBeard

    Send one color per surface to shader?

    Not sure what the "best practice" is in this fairly simple case, but using vertex colors like you do now is not "bad practice". Another way to do it (and I am sure there are more still) is to set up a constant buffer with a single color value and use that, but it seems silly to have to create, update and bind a CB just for one color value. In the end it is all about what you are trying to do and what your data looks like. Eg. if you have hundreds of thousands of vertices, then you could be saving a bit by not having the color be a part of the vertex, but if there are fewer vertices it won't be a problem.
  11. How is game_pVertexShader created? Normally you call CreateVertexShader() on the device to create a vertex shader. The first parameter to that function is the shader byte code.
  12. GuyWithBeard

    D3DReflect unrsolved external symbol

    You also need to link against dxguid.lib. Try adding #pragma comment(lib, "dxguid.lib") to your code. I don't know why the docs don't mention this.
  13. GuyWithBeard

    Tips on porting to Apple platforms

    Don't know how I missed your response, only saw your message now. Anyway, thanks! Yes, it seems like the safest way to go with Apple platforms (and probably most power-aware platforms, ie. mobile) is to have the OS update the app rather than doing it yourself. Luckily I planned for this some years ago when setting up my engine base and the engine lets the application take care of the main loop however it wants as long as it calls certain things in a certain order during one update. I found this (http://floooh.github.io/2016/01/15/oryol-metal-tour.html) article which suggests doing the same, ie. hook the update into the draw callback of MTKView, which is probably what I am going to do. However, after spending years developing only on MSVC it will take some time still before I can even build the core engine library on clang, so it will be some time before I get to implement this. But it's all good, the codebase becomes more mature through all this. I have also found some subtle bugs and some questionable code that MSVC has (erronously) swallowed without a warning.
  14. GuyWithBeard

    Gameplay in C++

    In my experience, the most common reason to write gameplay code in C++ is that you already have an engine or base framework in C++ and don't want to deal with another language. Even if you have a well-working scripting layer, there is power and convenience in being able to write and debug the whole game from top to bottom using just a C++ IDE. This is of course not just the case with C++ but with any language.
  15. GuyWithBeard

    Tips on porting to Apple platforms

    Really? No-one knows? This seems like a fairly typical scenario to me, iOS being as popular as it is. Anyway, I took the sword as it is dangerous to go alone, and started porting my core library. For now I am going with a Cocoa Touch Shared Library, as it seems to be the closest to what I have on Windows. Apparently iOS supports loading shared libraries since iOS 8 so I should be good regarding that. It seems like this produces a "framework" which is a bundle containing the dylib file + headers and resources, which is cool I guess. Still not sure if I actually need that or not. For the plugins I am thinking about having straight dylib files but I am still unsure if I need resources to create a .nib file or whatever the windowing resources are called nowadays, in which case a framework would be better. Seems like I should be able to drive the update/render logic the way I normally do but it remains to be seen if that is a good idea or not. Seems like the CADisplayLink is the preferred way to render, so I might want to add support for that later. It will be a while before I have even the core lib compiling on clang, so I don't have to worry about that right now. Thoughts?
  • 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!