• Content Count

  • Joined

  • Last visited

About stay

  • Rank

Contact Methods

  • Twitter

Recent Profile Visitors

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

  1. Unfortunately, no, I haven't tried to do any Xbox JS development lately, but I'm very interested in what you discover. Could you report back? Building a PWA for Xbox seems promising. I've read that getting a PWA in the Windows store is not super difficult. This article even mentions Xbox in passing. If I were to dive back into this, I'm sure I would look at PWA first. The thing I'm most worried about is that PWAs aren't fully embraced yet on some platforms, so how much respect will they get on Xbox? It would be nice to find out. -- Steve
  2. I've run into this scenario before, and I find it surprisingly difficult, especially if your frame rate varies at all. It gets worse the more dynamic and responsive the effect needs to be - e.g. if these trailing things are real game objects, not just effects, and they join and leave on the fly, and they need to stop when you stop, and if one leaves and another is expected to move up to take its place, etc. I think the approach you've started with (a recorded position array) is reasonable, and should work. I've done exactly that, and it worked out fine in my case. I admit I didn't care a lot about performance at the time, but I also didn't notice problems and didn't do any optimization. I can't think of any obvious reason the code you've presented would have performance problems. The one thing I was going to suggest right away was using a circular buffer, but you're already doing that. If the player can stop and you want the followers to stop, you can suppress adding new positions to the list until the hero has moved a minimum amount from their last position. For the sake of offering alternatives, a more complicated approach is to treat the trail like a spline (or something similar - even just some simple interpolation code from point to point). Track positions like you have, but each point in your list is a node in a spline. Then you just need to know a distance along the splice (maybe an interpolation value from 0 to 1) for each trailing object, and you can determine per frame exactly where each object needs to be. The downside is this is a lot of work, and fairly technical. And it may not do you any favors in terms of performance. The upside is that it's extremely flexible and dynamic. You change spacing between objects, remove one in the middle, etc. And everything can be ultra smooth, since you're using interpolated points on a spline. Another upside is you can make the array as long or short as you want, and collect points more infrequently. This is all probably not very useful if you really just want a visual effect and not gameplay objects. And if you find a better approach, I'd love to hear about it, since I keep running into this.
  3. Hmm... Working with that last case there, it may be a problem with how you're running from a locally hosted site, rather than including all your code and assets in VS. If your appxmanifest has a start page that's not like the default, e.g. if it's something like "ms-appx-web", then by default the Windows runtime API isn't available to your (external-to-VS) website. You have to explicitly enable it, through something like this: Sorry I didn't think of that earlier. My project is not like yours - I include my whole game in Visual Studio and use the standard setup.
  4. Ah, yeah, that code needs a little more checking. So, Window.whatever is only available when you're running in a real UWP (Windows or Xbox) App. So, you just need to check if it exists first. You only need that code inside a UWP anyway, so, something easy like: if (Windows) { Windows.UI.ViewManagement.ApplicationView.getForCurrentView() ... etc! } You could be more thorough and check that namespace all the way down, like: if (Windows && Windows.UI && Windows.UI.ViewManagement ... ) But if you've got the Windows global object, you should have the rest, especially in the work you're doing. So, in a normal browser environment, that Windows global won't exist, and you'll skip that code, which is what you want anyway. Note that in a UWP, it'll seem a lot like you're in an Edge environment (e.g. same navigator.userAgent value). So, that check for the Windows object is a good way to find out you're in a Windows/Xbox app environment, in case you want to do something special. WinJS is cool if you want to mess with traditional Windows application features like menus and whatnot, but for an Xbox game, you don't need to include WinJS in your project. I got pretty far without adding any extra libraries. At *some* point you'll theoretically need to enable Xbox Live features (evidently the Creators Program requires at least Sign In support), and that's harder, and requires more Visual Studio project changes. Pointing the VS start page to your locally hosted url is interesting and cool. Definitely easier to get started with. Eventually I expect you'll need to put everything in a Visual Studio project, though maybe that's not true if your ultimate user experience is *all* hosted online? It's a different approach I haven't messed with. In any case, I do 95% of my development outside VS as well. I just use VS to test actual Windows or Xbox functionality.
  5. Oh, my apologies! It goes in the actual JS code for your client-side app. Somewhere, anywhere, that gets called once. I don't know how your project is arranged, so I'm not sure how to recommend anything in particular, but if you started with the standard JavaScript Blank UWP app in Visual Studio, then it could go in main.js or default.js, maybe outside their placeholder code, or inside their app.onactivated function, but anywhere that eventually gets run should work! And no includes are needed. "navigator" is a global object and you can set that gamepadInputEmulation property (which is Xbox One specific anyway, I imagine) to whatever you want. Hopefully I still haven't missed your question. If you're using something like typescript that cares more about types and declarations, maybe this is trickier, but I'm just writing raw JavaScript and setting the value.
  6. Good to hear! Also note that having a debugger attached at all will have a surprising impact on frame rate on the Xbox One as well. If you ever worry about measuring frame rate, definitely test without the debugger attached. For mouse cursor stuff: navigator.gamepadInputEmulation = "gamepad"; is correct, and doesn't have any dependencies that I know of. I just set it directly, just like that, when my project first starts up (in my init code). (Actually, I set that value to "keyboard" for complicated reasons: It seems the B button by default suspends the app and goes back to the Xbox One Home screen, which is not what I wanted, but seemed to be committed to by the UWP host before I found out about the press through the gamepad API. If I set gamepadInputEmulation to "keyboard", then I also get keyboard events on gamepad button presses, which I can preventDefault() on, in order to suppress that. And the gamepadAPI still works in keyboard mode.) I also turn off scaling and overscan as they propose in the docs ( and ) though notice that sometimes the docs don't give you real JavaScript and you have to fix the case. For instance, that second one is really: var overscanDisabled = Windows.UI.ViewManagement.ApplicationView.getForCurrentView().setDesiredBoundsMode(Windows.UI.ViewManagement.ApplicationViewBoundsMode.useCoreWindow); Good luck!
  7. @mattstyles and @BobF At the risk of me looking dumb for asking, but sincerely for my own edification, can you clarify what part of Rojoss's sample is going to be doing more work than necessary every frame? For starters, I assume this code he's provided is being called once (e.g. in response to a resize event). Is there a reason to think this code is running every frame? The first of his two samples has a fancy transform expression - I expect that's evaluated every frame and bad. That one I can see being problematic (though it's his "good performance" example... ) But the second sample just calculates an x and y scale for the scene to use later. Is there a reason to think this calculation is happening more than once? Or is the concern that later he'll have to call context.scale(this.scene.scale.x, this.scene.scale.y) once at the start of each frame? Doesn't everyone use context.scale() at least once per frame in a real game? I'm not familiar with PixiJS, so my apologies if there's something more subtle here. Maybe this is all happening in WebGL anyway? Thanks!
  8. @Rojoss I've seen similar results, where fancy rendering (a lot of text, many sprites/particles, lots of transparency, etc.) to a large canvas (Your ideal display is 4K? dang...) is simply more expensive. In general, I've tried to pick a middle range where it looks good enough but isn't working on a huge canvas. E.g. both of your solutions combined: Internal scaling logic (your scene.scale.x) to scale to a reasonable-sized canvas, and then a CSS scale in addition to go up to the final display. For instance, on the Xbox One, I'm rendering to a 1280x720 canvas and then style-scaling up to 1920x1080. Beyond that, I just had to work to optimize my canvas rendering, which is a whole topic on its own, and I would expect PixiJS to be doing that work already. Another random thought: In some environments, using a spritesheet canvas above a certain size (2048x2048) crossed some internal browser threshold where suddenly performance went through the floor. It's been a while since I've dealt with that, so I don't know how common it is or if your environment is susceptible to that kind of thing.
  9. Hi jedimasta, Cool. I'm happy to try to answer any questions I can! I'm just going to spew some things that might be relevant. If you need more details in an area, let me know. Answering the last questions first: APIs to avoid: Nope, I didn't have any notable trouble with any of the usual browser-oriented APIs. In the last few days I've really been banging my head against the wall trying to get some Xbox-specific APIs (Xbox Live sign in) working, but that's a whole new layer on top of the core game. And some Xbox-specific APIs to control scale/overscan are not exactly as documented. A pain to import and convert the work you've done? In general, no. If you do things the way Visual Studio expects, it's really easy to import your whole existing JavaScript setup into VS and just run. Amazingly easy. What I mean is this: Visual Studio thinks it's the boss of your project, so it expects to live in the top folder, and to explicitly know about all your files. So generally you make a new VS project (JavaScript blank UWP app) at the top, add all your files (which you can do in large groups), and VS thinks it's in charge of them now. E.g. if you simply delete a file from VS, it deletes it from disk. So be careful. If you want, you can add things in a different way where VS is a lot less grabby, but it's more work. Let me know if you care and I can share details, or write another article or something... I would expect it to be pretty easy to get your project running inside Visual Studio, even using 3rd party engines or libraries. Also, I'd personally use VS 2017, though I doubt it'll matter much in this case. There's a lot to do after that if you want it to behave differently on the console (e.g. gamepad API, display differences, other xbox features...), but that's future stuff. Edge on the Xbox One. Hmm... yeah, if it's having trouble, I'd guess you'll run into the same trouble building in VS, since in my experience it's about the same - when I looked into what environment my game was running in (when I built it as a UWP in VS), it was reporting itself as the Edge browser. You have to start accessing some other global APIs (like Windows.whatever) to even detect that it's not a browser. So, that might be bad news. I think there's a good chance you'll run into the same issues when building an html5 UWP, though I can't say for sure. Is the game running OK on Edge on a PC, then? Is the frame rate of the game OK, but network traffic takes several seconds? I'm afraid I'm only doing a very small amount of network traffic in my game, and it's all outgoing, and not time sensitive. There are some notes on port ranges that are supported on the Xbox, but I would expect a problem there to reflect as the game not working at *all*, not slowly. I'm sorry I can't be of more specific help, though I'm happy to keep discussing all this. On a separate note, I like the sound of your game! Very cool use of the big screen. Edit: Another quick thought I had after skimming your separate post about the networking technology: The Xbox One does network throttling in some cases. I don't know what those cases are, but it's something to consider! Ideally your network code is written to be sending data only when needed, not constantly at full speed! That's the kind of thing I would expect to cause "chugging" on the Xbox. Random guess.
  10. I've been having some fun playing around with Xbox One HTML5 game development the last few days. Is anyone else doing this? I thought I'd share what I've experienced so far. * Setting up my retail xbox as a dev kit was not too bad. Following the online docs rather than the on-xbox prompts worked better. I already had a windows developer account. * I've signed up for the Xbox Creators Program, but that hasn't mattered so far - I think it'll only matter if (A) I want to access more xbox-specific APIs, and (B) if I want to release a game in the Xbox store. * Making a universal windows app out of an existing HTML5 project was OK - The way I like to arrange things means I have to wrestle with VS2017 a bit to keep it from thinking it is in charge of my project from now on, but actually getting the game running is straightforward. I found this to be true with Win8/Win10 html5 development as well. * With Windows app development these days, HTML5 and Javascript are first-class citizens. I can do anything I've needed to do, including all the regular HTML5 stuff I'm used to (fancy canvas stuff, gamepadAPI, etc.) as well as system-specific things like user account info. * After setting up the project, the process of launching on Xbox One was a little fiddly and flaky, but it's working well now. My game runs, displays everything correctly... * The development setup is actually pretty slick. You can point a browser at your newly enabled dev kit and get performance charts, memory usage, screen captures, etc. (It's a little inconsistent and not always functional, but when it works, it's neat). * I followed some documented instructions for turning off (in code) overscan and scaling, which was not as easy as expected (some API object names have different upper/lower case than documented), and I can run at 1920x1080. * I'm running at 60fps normally, though I found some cpu-intensive calculations slowed the system down to 10fps at one point. Everything looks smooth, though I'm suspicious of a tiny little hitch in one evaluation I did that seemed like it might be a regular garbage collection issue I used to see in some other Xbox-related work I did a while back. * I'm doing all this work in a custom engine of mine, and most of my engine is working great on the Xbox, including a ton of custom canvas stuff, audio, gamepadAPI, some server interaction with POST calls, and pretty much everything I expected to work. It's very much like an Edge-hosted web page, with some extra APIs. I'd love to compare notes with anyone else doing this! Lots more info on various pages connected to this page:
  11. This is cool. Simple and effective. You're right - sometimes you need to do this on the fly in your project, not in a separate tool. I recently ran into the case where I wanted the benefits of a packed spritesheet with images I was generating algorithmically, so a traditional standalone spritesheet tool (TexturePacker is my favorite) was not going to help. Thanks for sharing this!
  12. Makes sense. I confess that in some previous game work I used straight up as 0 degrees, which made more sense for the artists working on our games. They wanted to create art pointing up by default. Similarly, while the programmers used radians internally, we always supported degrees in game-designer-focused tools and data files, and carefully defined places where we'd convert from degrees to radians in the game engine. Since this is an html5-specific forum, I think Math and Canvas standards are particularly relevant, but I admit I'm doing all my coding directly to the canvas API and not using a popular engine. I don't know how other html5 engines approach this. At a quick glance, it looks like Phaser and Pixi both use +x, clockwise rotations, and radians, but I might have read this wrong.
  13. HTML5 Canvas uses the +x axis as 0 degrees/radians, with positive angles in the anticlockwise direction. That's also the standard in trigonometry: Using another standard means you'll have to convert frequently if you want to use standard routines like Math.atan2(), which are pretty dang useful. I recommend using +x.
  14. Fortunately, once you have a dynamic framerate system set up, there are usually just a few problem areas, like the physics update issue you mentioned, and there are usually some good known solutions for those. For instance, with collision you can run several short physics/collision cycles in one frame (as many as you need to match how much time has passed), and leave the rest of your logic based on a dynamic frame rate. As mattstyles says, hanging all your game timing off fps is not good. You'll eventually regret it - for one reason or another your game will be running faster or slower than you expected, and all the game timing will be wonky. Deltatime is golden. And once you have it, you can do cool things like artificially slow your calculated deltatime down for slow-motion effects, without rewriting any game logic. What goals are important to you? Ultra smooth animation and responsiveness all the time? Great. Target 60fps and make sacrifices elsewhere (in game logic and scene complexity). But if you're just trying to ship a fun game, I'd say don't lose too much sleep over it - plenty of games running at 30fps are perfectly playable! And it's just a target, anyway - since you can't generally control the hardware your game is run on, you can target 60fps all you want and you won't always get it, which is part of why you really need a system that can adapt to any frame rate the host device supports.
  15. Strongly agreed. As the stated objective is to work in the industry, I can confidently say you're better off only showing your best stuff, and not including lesser work at all. It just drags down a potential employer's overall impression of your abilities, even if you've improved since then. Even if you just have a couple of games as a result, if they're good, that's all you need. If you include unfinished (but non-crappy) stuff, explain why it's interesting - what cool thing did you explore or implement? Make sure everything is easy to play immediately or at least flip through screenshots. (Should be easy enough if you're doing html5 work!) Nobody wants to download/install a portfolio piece. Source: I hire programmers, designers, and artists as part of my job.