• Content count

  • Joined

  • Last visited

Community Reputation

2456 Excellent

About Satharis

  • Rank
    Advanced Member

Personal Information

  • Interests
  1. Unless you're a wizard, using images from a texture atlas would either require uniformly sized images or a file describing the locations of each sub-image. So yes, normally it should come with something. If no such file exists then you have little option besides figuring out the coordinates manually.
  2. Keep in mind that a lot of things you learn coding apply to all languages, or at least most of them. Even if they don't for whatever reason, the experience still helps you learn much faster. It would be easy to argue that if you say, were very advanced in C++ then picking up Java or C# would be much less confusing than starting from scratch would be. That said, it is of course good to experience a few languages, as there tend to be commonalities between certain languages.
  3. Where to start… MMO to single player

    I'm honestly rather confused what the OP is even interested in doing. What defines turning an MMO into a single player game? Wouldn't that just be an RPG?
  4. How to learn from Quake source code

    I'm not sure why you think older game engines or games are "simple". Most of them use old fashioned techniques of doing things, or things that applied to the kind of environment and software that was around at the time, they're often extremely cryptic as well. If you think you'll be remaking the quake engine by yourself then moving on to make a later game engine or something, don't bother, you'll spend your entire life trying to recreate engines made by dozens of people over multiple years. Although old software, the man hours invested in older games and engines is not trivial, they worked just as hard as people do now.
  5. That's a bit of an oversimplification. Practically speaking there isn't a difference between stack and heap memory, they are both just RAM. The major advantage to the stack is that it is designed to grow in a contiguous block of memory up to a predetermined size, meaning it is both fast to add and remove from it, and it tends to keep related data you might work with in one cache line. The heap is slow because of how it is allocated(which you can control somewhat). If you say, allocate three different game objects with new, and then you create an array of pointers to each of those game objects, when you allocated each object they were probably placed arbitrarily far apart in memory. So now if you want to iterate over the array and interact with each object, you get a cache miss every time it has to jump out to the objects. The heap is slow to allocate because it has to locate a suitable block of memory that is large enough for what you are asking for. The heap could be slower to access than the stack, or about the same, depending on if you had it allocate a large block of memory and your code is working in that single block, vs having to jump out to separate allocations that could be all over the place. This is where cache misses become a problem. Freeing memory on the heap can still be more expensive both because of locality, and the fact that the heap essentially has to be thread safe. A final point that was mentioned a little in my last bullet is that every program thread has its own stack, and doesn't have to be locked for multi-threading concerns. The heap on the other hand, is generally shared and operations may have to lock in order to allocate or de-allocate memory. In general you can see the point that the heap will basically never be BETTER than the stack but it can be similar in performance while also allowing arbitrarily sized allocations.
  6. The boiled down point of what frob is saying (as far as I see) isn't necessarily that it is inherently wrong for things to draw themselves, but that they have serious performance issues on modern hardware. Draw calls can be a big bottleneck with tiles because from the perspective of the software, draw calls are designed to be called to essentially render a ton of stuff. For instance, Unreal in most cases uses one draw call per material on an object, so if you have a 20k triangle weapon with two materials, that is barely 2 draw calls. Flipping that around, when a sprite(a tile maybe) is drawing itself, it is essentially using one draw call per tile, which can easily end up in the thousands of draw calls range, per frame, just to render a tile map. Of course that is assuming you are doing everything the extremely primitive way, you could certainly create objects that draw themselves, but batch more content into the draw calls, in that case you would gain significant performance without changing the architecture of the system. But in general, if objects draw themselves, they are operating in a bubble, they draw like they are the only thing that exists in the system. That's why it helps to have a middleman object that actually handles sorting information on what needs to be rendered during the frame, so it can make more intelligent decisions. You definitely CAN make a game of relative complexity with objects drawing themselves, but you're going to hit performance issues eventually, it doesn't scale well, and you'll essentially be adding patchy changes to make it work whenever you hit a performance wall. So the issue isn't that you are somehow violating a law of the architecture police, but that the system isn't conducive to knowing the information it needs to intelligently render things.
  7. Any advice?

    I would either pick up a game engine like Unreal Engine 4 or Unity and start messing with it to learn what aspects go into games, or I would start making things in C++. Both are useful really, existing engines are useful for showing you how things are separated and glued together while hiding the actual implementation details, but I wouldn't jump into using C++ in say Unreal, unless you already know it quite well. If you want to learn C++ then just read a tutorial and make something, the important part is to set a goal to make something and continue to challenge yourself a bit more each time. Make hangman, make a text adventure, make something 2d. You learn a bit from everything.
  8. C++ Text Adventure Design

    Though it's hard to give advice without more specific questions you can think of two major strategies for figuring out how to design code things. First off, examine what it is your code needs to do, forget about the code itself and focus on the action. In your case you need to display a list of things that you can do when you enter a room, then you need to respond to input based on that list. Second, look at what things have in common between them, that's an often not well explained thing in coding is that data driven behavior is all about -similar- behavior. In your case each rooms needs an action. Well what do actions have in common? They have a number for their action in the list, they have text that describes what they do, and then they have a function that they call when you select them. Looking at it that way, you could make a structure or class that represents an action, and have rooms contain a list of actions, then when you enter a room you can have a function that simply prints them. Since the input also needs to deal with actions you might make part of the action data include a function to call to handle them when they are selected, or something. The details don't matter, the point is to think of it as an abstraction, you are trying to allow yourself to add an arbitrary amount of things that all do similar behavior, that one bundle of code can work with.
  9. What code is the best for game development?

    If you've never used a programming language before then learning any of them will teach you a lot, though I would agree with C# being a nice option for learning. You can of course start with something like C++ but it forces a lot more on you to learn early on, such as dealing with pointers. C# is a bit more modern and more friendly to pick up one could argue, but is quite similar to C++ and Java in syntax and style.
  10. Blank Programmer.

    The important thing is to keep challenging yourself. Whether using an existing engine or making something from scratch, you're always learning things that make you a better programmer. There isn't some "course" or specific set of tools that will teach you everything, you absorb little bits of information every time you try something.
  11. Missile Command - Part 2 - Independent Missiles

    Yes, and I specified that you could use erase, or something like swap and pop if he didn't want to use an iterator. Which is why I rewrote it using the same method he was using. The iterator method is also a waste of time if you already have the index of what you want to get rid of, in this case it is fine since he is examining the entire container, but yeah. EDIT: More specifically in situations where performance is a concern erase is actually slower than swap and pop anyway since it shifts the elements back and ends up being O(n).
  12. Missile Command - Part 2 - Independent Missiles

    Well no, you are right, it does go out of scope, then you only have the vector pointer referring to the missile object. I only really pointed that out to make it clear that they were pointers and where they were going. Thing to remember about pointers is that they are just variables themselves so you can delete the memory they point to even while they're still in the vector, they just will be pointing to unallocated memory if you try to use them after that. if( missileVec[i]->destroyNow) { auto size = missileVec.size(); auto lastIndex = size - 1; if(size > 1 && i != lastIndex) { Missile* swap = missileVec[lastIndex]; missileVec[lastIndex] = missileVec[i]; missileVec[i] = swap; --i; } delete missileVec[lastIndex]; missileVec.pop_back(); } Something like this would work for deleting.. though I probably did something stupid in it, but you get the idea. Alternative is to use a smart pointer in the container, then it just deletes it when you pop it off.
  13. Missile Command - Part 2 - Independent Missiles

    Missile* newMissile = new Missile(renderer, cannon->x, cannon->y, clickedX, clickedY); missileVec.push_back(newMissile); If it isn't clear what you are doing here, you are essentially creating a pointer named newMissile, which then has its value set to point to the memory that is allocated by using new, so now only newMissile refers to that memory. Then you use push_back on it, which copies the value of the pointer into the vector, so now we have two things pointing at that memory. for( int i = 0; i < missileVec.size(); i++ ) { float targetX = missileVec[i]->endX - missileVec[i]->x; float targetY = missileVec[i]->endY - missileVec[i]->y; missileVec[i]->angle = SetMissileAngle(targetX,targetY); missileVec[i]->Update(delta); if( missileVec[i]->destroyNow == true ) { missileVec.pop_back(); } } Now this part is an issue, basically you're iterating over each pointer to a missile. The problem is that presumably the first missile in the container will be the earliest fired one, and likely to explode the first. What happens when it explodes? it sets destroynow to true, and then the next time the loop runs the first missile it sees is one that is destroyed. Problem is push_back and pop_back do exactly what they say, they push or pop the element on the back. So now when your first missile explodes, whether you have 1 missile or 10, it removes the last one. Then it goes to the next ones, they may not be destroyed yet, so it exits the loop. But what happens the next update loop? It checks the first missile, sees it is destroyed, and pops the back again. Basically you're going to infinitely pop off all of your missiles. In addition, you are popping the missile pointers off without ever calling delete on them to free the memory they point to. There's a few methods you could use to remove elements in a vector like this. If you use an iterator(missileVec::iterator) then you can use erase when you get to a missile you want gone. Erase will remove that element and shift the other elements back to fill in the space. Another method is swap and pop, essentially if there are more than two elements in the vector you take the last element and swap it with the one you want to erase, then pop it off the back. Just make sure to delete these missiles, or use a smart pointer like unique_ptr, which is vector safe. EDIT: Managing memory and ownership like this is a pretty big part of any program, especially stuff like this for games. It might be worthwhile for you to research your options a bit and understand some of the various ways you can store things and pass ownership or references around.
  14. Making Breakout - Code Structure help requested

    Which is fine, I experiment with ideas myself on a regular basis, the problem is it becomes easy for you to start doing that for everything. Particularly when it is that, experimenting, you can quickly get in over your head and make the code a mess of things you aren't sure are good architecture, and dig yourself into a corner that it feels frustrating to get out of. Sometimes it might be better to experiment on standalone tech demos and things, or to save writing something complex like that until you actually need it. That's a bit of an unspoken rule that people don't often actually explain, software only gets complicated because it needs to. If you could write the next Battlefield game just by making a function that loads all the game data at the start and not bother with subsystems dedicated to managing things, then they probably would. You might want to consider that the faster you finish a game the faster you get to try another project as well, and possibly explore more concepts or have more challenging rules to write for.
  15. Making Breakout - Code Structure help requested

    A classic issue for a lot of people (myself included) is the tendency to over engineer things. Frankly the best way to learn what you need is to just make something and set small goals, milestones if you will. I used to create these really complicated classes before even knowing what I needed, but often it either got thrown away or simply went unused or the architecture changed somewhat so I had to rewrite it anyway. For example, since you're making a breakout game you might just want to start simple, "well I need a game loop and a window, now I need to draw something onscreen, now I need to make a ball, okay now the ball needs to bounce against the edges of the screen and re-spawn." The first two things you mentioned are fine, for the texture manager I would question if you even need one. Is the game complex enough that sprites require managing? Honestly in most arcade games that isn't the case, sprites may be used only once and the entire game contains a small enough number of them for you to simply load them all in some function and pass them around. Important questions are things like -when- to load them too, if you can you might as well load them all at the start. Frankly unless you KNOW for a fact that you need something to be complex, it is almost always better to start off simple and build up from there.