Jump to content
  • Advertisement

Steven Ford

Member
  • Content Count

    57
  • Joined

  • Last visited

Community Reputation

145 Neutral

About Steven Ford

  • Rank
    Member

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi guys, I've got a little problem which is irritating me as there must be a simple solution but Google isn't necessarily being my friend right now. In my new game, I've got a set of projectiles for which I need to check for collisions with typically rectangular shapes (but which aren't axis aligned). My general approach is to create an axis aligned bounding box for both the projectile's movement and the target object. If there's a match on the broad phase, then I want to check whether the projectile collides with any of the edges of the collision and then report the first collision (i.e. if the projectile would have gone through multiple lines then I want to know the first collision so I can display the explosion animation in the right place). I represent my shapes as a series of line segments (there's a future question about colliding with semi-circles and circles, but that's later). Can anyone 'refresh my memory' on being able to test for the interaction of line segments? Thanks Steve
  2. Echoing @Finalspace's suggestion of Tiled (although admittedly I did get bored and wrote my own subsequently for other reasons), it's brilliant for being able to knock up 2D maps really quite quickly. The file format is simple to interpret in your own tooling subsequently. What I did was use Tiled to create the initial map, and then have a resource generation step (a custom MSBuild task) which loaded up the file, created the appropriate sprite sheets etc. and then outputted a file which could easily be consumed by my C++ layer. In my case, I had 2 layers: Pure background tiles Foreground tiles (Game Objects were handled separately) These tile layers were then stored in a simple array (offset = (y*width)+x) with zero meaning no tile, any other value being the tile id. At rendering time, I simply had 2 for loops (x and y) and wrote any tile to screen (the loop ranges were based off what was visible on screen) using the DirectX Toolkit. As @Finalspace says, get it working first, then worry about doing speed ups if you have to. Clearly you can pre-generate the DX11 command list etc. if you need to, but cross that bridge when you come to it. Note that on my tiles / sprite sheets, I made the conscious decision to handle overlays in the tooling and output a fresh sprite sheet each resource build. Depending on how much you share the sprites with other items in your games you may or may not want to do this. Either way, the principle holds true, you just store multiple values for each tile to allow for overlays etc. (or multiple layers)
  3. Steven Ford

    i need directions

    If you're interested in low level C++, then one thing which make the learning process simpler was to use the DirectX Toolkit as it provides easy ways to render 2D sprites. Once you're comfortable with that / how the GPU works, then you can do more experimental things. If you combine this with the templates here then you'll be fairly quick able to access a loop where you get given an instance of ID3D11DeviceContext* (which can be passed in to the DX Toolkit's SpriteBatch object) and then you're all set.
  4. Steven Ford

    New 2D Renderer d3d11 or d3d12

    Hi @Quat, my understanding is that you'll be able to get better potential performance using DX12 but you're also given enough rope to hang yourself / can get lower performance if you're not careful. Unless you truly need the power of DX12, then I'd be inclined to stay with DX11 for sheer simplicity's sake if nothing else.
  5. You could have something which created a map between the name of the object and a function which returned an object, i.e. std::map<std::wstring,std::function<std::shared_ptr<IGameObject>(myNode&)>> gameObjectProviders; and then populate this with functions which create and populate fresh instances. It's not quite as nice as reflection, but it's going to at least avoid lots of if statements - and the creation items can be more easily tested. In my games, I have an intermediate step in C# (as an MSBuild task) which takes my level files and then outputs binary files which contain something along the lines of: - number of gameObjects - gameObjectType ID - binary format for each game object So the C++ layer doesn't have to know anything about the name of the properties, it just reads from a byte stream. The main advantage is that I can then apply whatever rules to my game objects I like in the tooling layer so I pick up any errors at resource generation time rather than having to load the level in the game engine.
  6. Just in case anyone else comes across this issue. Effectively, my takeaway is that this doesn't work if you're using VS2017 / toolset 141. Presumably it does with v140 (VS2015), but I didn't want to roll back that much. My solution was to go back to C++/CX and then it all worked. "£$"$%^% £$%^£$%^ "$%^ - what a waste of time! And breathe out again Steve
  7. I've hit a similar issue in my game, it's a puzzle solver where visibility of the whole puzzle is useful and the level designer has assumed that it's a 1920x1080 screen with 64x64 blocks. For the other resolutions, typically lower spec PCs, the choices as mentioned above: 1. Draw to an off-screen texture at 1920x1080 resolution and then scale on screen (maybe with the text overlays rendered at the native resolution for simplicity) 2. Draw directly to the scaled ratio The advantage of #1 is that it's the simplest (I do this for my UWP version so users can resize the window without killing my puzzle aspect). The disadvantage is that you're burning compute cycles to do so. Whether this is important depends on the rest of the load on your GPU. For me, it appears to be irrelevant though. #2 allows a much greater flexibility, but does require greater resources (i.e. those for 32x32, those for 64x64 etc.) Along with probably slightly more complicated rendering logic. Reading your post more though, you talk about a strategy game - and hence I'm assuming that being able to see as much of the battle field as you like is important. I'd almost argue that users would expect to be able to zoom in / out regardless of screen resolution, so I'd be inclined to go for option #2. You could do as @Zakwayda points out and use standard mip-maps and if you're allowing zooming to be done dynamically, I'd go down this route. Otherwise, you could do this in the resource generation stage of your pipeline, so you only ever load in a single resource set rather than loading multiple and subsequently deciding which texture set to use per frame. Also, for the aspect ratio, for my game (puzzle in a space station), if a user resizes to a weird ratio, I just add black bars on the appropriate side. Again, for a strategy game, I'd be inclined to let them play with whatever ratio they have.
  8. Hi, I've set up a UK limited company in order to release my game. I've registered with Steam and now I need to fill in the tax details but the form itself is quite confusing. I was wondering if anyone had been through this / knew of any good resources (blogs?) with walk throughs? Specifically, I'd have thought that there would have been an EU entity which would have acted as my company's contact point for the simplification of taxation etc. rather than having to deal with US entities and all the hassles that that involves. Any assistance gratefully received Regards Steve
  9. Anyone? Does anyone have any experience in making C++ header files using cppwinrt for this library? I'm guessing that's the usual approach for handling .winmd files, but I'm not having much luck. What I'm currently trying to do is: 1. Navigate to E:\Spacegirl\packages\Microsoft.Xbox.Live.SDK.WinRT.UWP.Native.Release.2018.6.20180914.1\build\native\lib\x64\v140\Release 2. Run cppwinrt: cppwinrt -in Microsoft.Xbox.Services.winmd -out E:\temp The Microsoft.Xbox.Services.Achievements projection is incomplete. A required reference may be missing. The Microsoft.Xbox.Services projection is incomplete. A required reference may be missing. The Microsoft.Xbox.Services.ContextualSearch projection is incomplete. A required reference may be missing. The Microsoft.Xbox.Services.Events projection is incomplete. A required reference may be missing. The Microsoft.Xbox.Services.Leaderboard projection is incomplete. A required reference may be missing. error 0x80004005: Unknown namespace: Windows.Foundation The Microsoft.Xbox.Services.Multiplayer.Manager projection is incomplete. A required reference may be missing. I'm not an expert on C++ / winrt so apologies if these appear stupid questions to anyone, any help gratefully received.
  10. I'm using the following link from MSDN. This seems to imply that the CPP version is for C++/CX and not for standard CPP. Which kind of leads me to using the Microsoft.Xbox.Live.SDK.WinRT.UWP version. So when I do that and add the following: #define XBOX_LIVE_CREATORS_SDK #include "xsapi\services.h" I get an error about not being able to find the file. Looking at the directories which have been added, then I don't see any file named that, but I do see files along the lines of (within Microsoft.Xbox.Live.SDK.WinRT.UWP.Native.Release.2018.6.20180914.1): build\native\lib\x64\v140\Release\cpprest140_uwp_2_9.dll build\native\lib\x64\v140\Release\cpprest140_uwp_2_9.lib build\native\lib\x64\v140\Release\cpprest140_uwp_2_9.pdb build\native\lib\x64\v140\Release\Microsoft.Xbox.Services.dll build\native\lib\x64\v140\Release\Microsoft.Xbox.Services.pdb build\native\lib\x64\v140\Release\Microsoft.Xbox.Services.winmd build\native\Microsoft.Xbox.Live.SDK.WinRT.UWP.Native.Release.targets I was, maybe naively, expecting to be able to then have everything work out of the box. This was the case when I used the initial 'cppwinrt' Nuget package. What steps need to be done in order to use this in order to be able to sign into Xbox Live?
  11. Thanks @Lactose; that probably sums up my week! ;-( The correct links (hopefully): Microsoft.Xbox.Live.SDK.Cpp.UWP Microsoft.Xbox.Live.SDK.WinRT.UWP I'm using CPP winrt, so it's really not clear which one would be appropriate for me
  12. Hi all, I was wondering if someone could put me out of my misery. As part of releasing a game for the creators collection on X1, I have to add support for Xbox Live (this game doesn't need any actual features from it, merely the ability to log in, but hey, those are the rules it seems). As part of doing this, I was expecting to simply: 1. Add a reference to the appropriate nuget package 2. Set the appropriate constant / add the header file Unfortunately, I seem to be struggling with something which would appear to be simple. I'm using the cppwinrt templates - Nuget package - cppwinrt. My questions are: 1. What's the difference between - Microsoft.Xbox.Live.SDK.WinRT.UWP (Nuget) and Microsoft.Xbox.Live.SDK.WinRT.UWP (Nuget). There doesn't appear to be any useful information in the Nuget pages describing what the differences are or which I should use in preference 2. I'm assuming that people have gotten this successfully to work, are there any steps other than the ones above? Any help gratefully received. This is literally the only thing left before I can submit the game Thanks Steve
  13. Just adding a code snippet of how this [handling of keyboard inputs] was done in case it's useful to anyone else (and me for later reference 🙂 ). Look at the following Forum Post ( @Endurion 's one) to see a subset of the possible inputs. To do these in C++/winrt; the following syntax can be used // SetWindow from templates // Window = CoreWindow // Tokens which can be used to remove the event listeners later winrt::event_token _keyDownToken, _keyUpToken; _keyDownToken = window.KeyDown([this](auto&& /*sender*/, auto&& args) { int keyCode = (int)args.VirtualKey(); args.Handled(this->handleKeyDown(keyCode)); }); _keyUpToken = window.KeyUp([this](auto&& /*sender*/, auto&& args) { int keyCode = (int)args.VirtualKey(); args.Handled(this->handleKeyUp(keyCode)); });
  14. @wedouglas Depending on your actual requirements, this sounds like a look candidate for a cloud based set up, although the complexity would be how to get a GPU enabled worker to pick up the message request off the queue. I can see 3 models: 1. You spawn up a GPU enabled worker each time you need something processed. 2. You leave one permanently running 3. You use 'serverless' computing - although I've never seen that available with access to a GPU. Problem with any of these is that #1 requires more orchestration (maybe the serverless component could enable that machine) , #2 requires a fairly expensive VM to run, #3 - don't have a clue if anyone offers this. Sorry to not be more helpful. One thing which might work, I have no idea about the use of 3dsmax, is having that on your cloud machine if you can write a macro for it? Might work.
  15. Hi all, I'm hitting a frustrating problem with trying to add Xbox Live support to my UWP application under the creators collection. I've followed the instructions in this MSDN post (I'm using the templates for C++/WinRT, hence not using the WinRT.UWP variants as used in the article). I've added the suggested lines in my code of: #define XBOX_LIVE_CREATORS_SDK #include "xsapi\services.h" And when I go to compile the code, I get the following compilation issue: spacegirl\packages\microsoft.xbox.live.sdk.cpp.uwp.2018.6.20180914.1\build\native\include\cpprest\asyncrt_utils.h(503): error C4596: 'system_type_to_datetime': illegal qualified name in member declaration spacegirl\packages\microsoft.xbox.live.sdk.cpp.uwp.2018.6.20180914.1\build\native\include\cpprest\streams.h(900): error C7510: 'int_type': use of dependent type name must be prefixed with 'typename' spacegirl\packages\microsoft.xbox.live.sdk.cpp.uwp.2018.6.20180914.1\build\native\include\cpprest\streams.h(1133): note: see reference to class template instantiation 'Concurrency::streams::basic_istream<_CharType>' being compiled spacegirl\packages\microsoft.xbox.live.sdk.cpp.uwp.2018.6.20180914.1\build\native\include\xsapi\types.h(156): error C3083: 'System': the symbol to the left of a '::' must be a type spacegirl\packages\microsoft.xbox.live.sdk.cpp.uwp.2018.6.20180914.1\build\native\include\xsapi\types.h(156): error C2039: 'User': is not a member of 'Windows' 1>c:\program files (x86)\windows kits\10\include\10.0.16299.0\winrt\roerrorapi.h(170): note: see declaration of 'Windows' I've checked on my build tools and they're set to 'Visual Studio 2017 (v141)' and I have version 15.7.5 installed of VS Community 2017. I'm going to update to 15.8.5 to see if that solves it, but who knows. Any suggestions? Thanks Steve
  • 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!