Jump to content
  • Advertisement

Nytegard

Member
  • Content count

    1825
  • Joined

  • Last visited

Community Reputation

841 Good

About Nytegard

  • Rank
    GDNet+

Personal Information

  • Role
    Programmer
  • Interests
    Art
    Programming

Recent Profile Visitors

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

  1. The problem was, while my explosion displays at a 1:1 ratio, internally, it's being calculated @ 16/9:1. This is mainly an issue for tunneling. Squish the coordinates to 1:1, and voila, you have a circle again. The other stupid improvement I forgot is that you can precalculate when the missiles are going to blow up to avoid unnecessary calculations in the hit detection. The instant you fire, you know when and where your missiles are going to explode, and thus have all the necessary information to determine all known future hits of enemy missiles/crafts/bombs. An enemy missile lasts past time t? Explode at X(t), Y(t), rather than tons of continuous hit detection checks. Just simple stuff like this that I didn't think of during the initial creation. I mean, my game works, but there are so many more optimizations that could be added that would require a rewrite of the logic.
  2. The problem was, while my explosion displays at a 1:1 ratio, internally, it's being calculated @ 16/9:1. This is mainly an issue for tunneling. Squish the coordinates to 1:1, and voila, you have a circle again. The other stupid improvement I forgot is that you can precalculate when the missiles are going to blow up to avoid unnecessary calculations in the hit detection. The instant you fire, you know when and where your missiles are going to explode, and thus have all the necessary information to determine all known future hits of enemy missiles/crafts/bombs. An enemy missile lasts past time t? Explode at X(t), Y(t), rather than tons of continuous hit detection checks. Just simple stuff like this that I didn't think of during the initial creation. I mean, my game works, but there are so many more optimizations that could be added that would require a rewrite of the logic.
  3. It's all a learning experience. I made the mistake of starting backwards, and having no plan for the actual game. By the time I got to the actual game portion, I came to realize my mistake. But it's all good. Fortunately, the resolution itself can easily be changed, but I found a cheap and easy solution for my problems, though it is a hack. Just scale everything to 1:1 for hit detection, and easier hit detection for fast moving objects as I have a circle. (Not that anyone would ever really need to worry about that scenario, but bug free is still better than a bug that exists even if no one will ever see it.) I'd like to think of this more as a starting point for a complete rewrite.
  4. It's all a learning experience. I made the mistake of starting backwards, and having no plan for the actual game. By the time I got to the actual game portion, I came to realize my mistake. But it's all good. Fortunately, the resolution itself can easily be changed, but I found a cheap and easy solution for my problems, though it is a hack. Just scale everything to 1:1 for hit detection, and easier hit detection for fast moving objects as I have a circle. (Not that anyone would ever really need to worry about that scenario, but bug free is still better than a bug that exists even if no one will ever see it.) I'd like to think of this more as a starting point for a complete rewrite.
  5. Since I finally have/had a few days to work on something of my own, why not this? It's the most barebones version of any submitted, and I'm still trying to track down bugs before I focus on adding any features. Still trying to track down a few memory management bugs. Built in Visual Studio 2017, source included. It's a Win 10 64-bit application. Requires Direct2D. Use 1, 2, 3 to fire, and arrow keys to move. Escape for menu and Enter for confirm. http://www.behindtimes.com/nytegard/media/d2dtest.zip
  6. Since I finally have/had a few days to work on something of my own, why not this? It's the most barebones version of any submitted, and I'm still trying to track down bugs before I focus on adding any features. Still trying to track down a few memory management bugs. Built in Visual Studio 2017, source included. It's a Win 10 64-bit application. Requires Direct2D. Use 1, 2, 3 to fire, and arrow keys to move. Escape for menu and Enter for confirm. http://www.behindtimes.com/nytegard/media/d2dtest.zip
  7. It's been awhile since I've been on this site. Been busy at work, but as with all contracting, sometimes work gets light, which is the case as of the new year. So I saw this challenge, and thought it might be fun to brush up on my skills. I've been working mainly with embedded systems and C#, so I haven't touched C++ in awhile, and when I have, it's been with an old compiler, that's not even C++11 compliant. So, I installed Visual Studio 2017, and decided to make the best use of this. Time is short, and I don't exactly have media to use, so I decided to just go out and start to learn Direct2D. I have little experience with any modern form of C++, and zero experience with Direct2D and XAudio. Whereas I didn't mind learning Direct2D, I fully admit XAudio presented a bit of problems. In the end, I blatantly stole Microsoft's tutorial and have a barebones sound system working. And unlike the Direct2D part, I didn't bother to spend much time learning what it does, so it's still a mystery to me. I'm not entirely sure I released everything correctly. The documentation said releasing IXAudio2 would release objects, and when I tried to manually delete buffers, things blew up, so I just let it be. There are most likely memory leaks there. As you can plainly tell, this is by far the worst entry in the challenge. This is as much of a learning experience as an attempt to get something out the door. I figured, if I couldn't be anything close to modern, at least be efficient. And I failed at that miserably. Originally I wrote this in C. Excluding the audio files, it came out to a whopping 16 KB in size, and memory usage was roughly 6 MB. And then I decided to start to clean up my spaghetti code (I said start, never said I finished), and every time I thought I was getting more clever, the program grew in size and memory usage. As of right now, it's 99 KB and takes up roughly 30 MB RAM on 720p resolution. I haven't really checked for memory leaks yet, and I'm sure they exist (beyond just the audio). In reality, I'd prefer to clean up a lot of the code. (And I found a few errors with memory management, so I need to track down where I went wrong. I removed allocating memory for the time being and pushed everything onto the stack.) The other thing is, this code is ugly. Towards the end, I just started taking a patchwork approach rather than keeping it clean. I was originally hoping for modularity, but that got destroyed later on. And I'd love to replace the pointers that are thrown liberally throughout the code with smart pointers. Unlike the other entries, I only have missiles for the gameplay. I didn't include UFOs, airplanes, smart bombs, nor warheads. I just don't feel I had enough time. Yes, there's still a couple weeks to go, but I'd prefer to cleanup what I have than add new features. And unfortunately, I was a bit shortsighted, which caused problems later on. There are multiple places where the code is far more verbose than it needs to be, because I wasn't properly focused on the correct areas. I wanted to make it scalable, and I focused making the game a 1:1 ratio internally, yet displayed 16:9 to the user, which caused massive problems later on. I ended up having to do math on pretty much every piece of graphics and game logic whereas if I had just displayed it as 1:1, or handled the internals in 16:9, I could have shaved off a thousand lines of code. And it also caused problems with hit detection, which is another reason I didn't bother adding in anything but missiles. The hit detection was a mess. I had everything mapped out. The game was going to work whether a missile went 1 pixel a second, or 1000 pixels a nanosecond. Calculating moving objects and collision with circles or boxes is easy. Unfortunately, I was using ellipses. And while there are formulas for that, I'll admit my eyes started to glaze over at the amount of math that would be required. In the end, I decided to leave it buggy, and only detect if it was currently in a static ellipse, which is easy and fast enough to calculate. I mean, I guess if the program freezes up, the user was going to lose a city/silo anyway, or lose it if the missile was traveling at light speed, but it's still a bug, and still annoys me, especially since everything else was calculated regardless of what the user sees. (*EDIT* Thinking about this more, the solution was right in front of me the entire time. Just squish the world back to 1:1 and do the hit detection that way). Controls: 1,2, and 3 control the missiles, and the arrow keys control the cursor. Escape for the menu, and Enter for selection. I've only tested this on Windows 10, as I'm pretty sure it requires those libraries. It's a 64-bit executable.
  • 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!