• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

__SKYe

Members
  • Content count

    176
  • Joined

  • Last visited

Community Reputation

1784 Excellent

About __SKYe

  • Rank
    Member

Personal Information

  • Location
    Portugal
  1. Ah okay, I apologize. I thought you were doubtful about the packing of the individual textures rather than the colors that bleed onto the other textures.
  2. I want to start by saying I've never used UE4, but this seems to be a texture atlas. Basically, instead of having 6 separate textures, they are all packed in a single one (the so called texture atlas). The advantage being that you can draw all those different textures, only having to bind it once (intead of having to bound each separate texture). The separated textures would look something like this (I put them in spoiler tags, so as not to flood the post): Perhaps the most confusing part about that texture, is that the separate textures seem to bleed onto each other, but when they're rendered (by setting the appropriate texture coordinates), the extra pixels won't be visible. When rendering, the actual texture area used would be something like this (delimited by the red lines): Just as a quick note, this kind of atlas is a packed atlas (were each texture is packed as tightly as possible, or thereabouts). Another common texture atlas type, is to put each texture on a grid, with each of them having the same dimensions (a typical example would be a tileset, very common in 2D games). There's plenty of topics on texture atlases on the web, so you can read about them a bit more, if you're interested. Anyway, hope it helps.
  3. The others have pretty much said it all, but I'll just add one thing. Be careful of using (or when implementing) the AppData or SavedGames folder as a fallback, if the user doesn't have the necessary rights to write to the executable directory (if the EXE is in ProgramFiles, and the user doesn't run the program as an administrator). If the user runs the game as admin, then their save will go into the EXE folder (again, probably ProgramFiles), but if they later run it without admin rights, then you must ensure that your game still loads the correct save, otherwise it may just look in the fallback folder (AppData or SavedGames), and will not find it.   I only wanted to post this, because I've had this happen to me in a couple games (whose titles I can't recall right now).
  4. You may probably know this already, and I haven't used MSVC 2015 in some time, but there are 2 versions (for desktop applications) of MSVC Express 2015, the desktop version and the windows 10 version.   The Windows 10 version uses UWP (Universal Windows Platform), and can only be used to build applications for Windowd 10 (and perhaps 8.1, but I'm not sure).   The Desktop version is the "standard" one, which can be used to build applications to previous versions of Windows.   Again, you may already know this, and I'm not sure this is your problem, as I never used the Win7 SDK before, but you never know.       In my opinion, you should definitely keep supporting WIndows 7. Like you said, many users don't have Win 8.1/10, and the only actual reason to use the Win 10 version of MSVC (that I know of), is to develop your application for both Windows 10 desktop and mobile.
  5. Your question is kinda hard to understand.   Are you asking if rendering to a screen with an aspect ratio of 1 (width = height) will be faster than rendering to one with a different aspect ratio (4/3, 16/9, etc)?   In an embedded system without GPU, the rendering responsibility will fall upon the CPU, so the only thing that should make a difference is the amount of pixels rendered, not the aspect ratio of the screen.   Or you mean that your game's supposed to support several different resolutions?   In that case, in my opinions, and given the scarce resources you have to work with, perhaps it would be better to develop a specific version of your game for each resolution you intend to support. Not the entire game, but rather the rendering part, so that you don't have to spend extra CPU time converting from a generalized game resolution, to the actual, physical screen resolution, at run time (ie. Having your game output a "fixed" 256x256 resolution, and adjusting to each different screen resolution (320x240, 240x260, etc) at runtime).   Or is your question something else?
  6. Here's a nice post that lists (and reviews) a few websites that offer graphics for games.   I know you requested free graphics, but, since this is your first game, and you probably won't sell it, you could use sprites ripped from commercial games. Yes, they are indeed copyrighted by whatever company created them, but for a learning project (or fan games, for that matter), they are very much suitable.   By the way, you can also find free sound clips, music, 3D models, etc, online. Just to a quick search for "free *insert type here*" on Google, and you should find them quite easily.   Anyway, good luck, and welcome to Gamedev.
  7.   Sorry but I'm a bit confused. Do you throw a bullet or a block? Or do you mean you throw a bullet, that lands on a block, and then the player teleports to that block?   Either way, you need to reduce the number of objects you test for collision.   Physics/Collision libs usually have two phases for testing collisions: the broad phase and the narrow phase.   The broad phase is responsible for finding object pairs that are potentially colliding, and discarding the ones that are not. This phase usually uses some form of spatial subdivision for the world (quadtrees, octrees, etc) and also tests for potential collisions between objects by using simple bounding volumes (like AABBs or OBBs) instead of the actual object's collision model (which can be much more expensive to test).   The narrow phase is where you check if two objects are actually colliding, using their actual bounding volumes (like you are doing in your code).   Summing it up, the broad phase very quickly and roughly discards non colliding object pairs, and the narrow phase performs the actual test to see if two objects are colliding.   This is much better explained in this article, that I came across a while ago. It is a 3 part article that also contains physics and constraints, so give it a read if you're interested.   Anyway, hope it helps.
  8.   Yeah, but you can't really help that, if you view such a small graphic zoomed out, stuff like this will happen. Have you tried mipmaps? You might get a better result with them.       This, I can't really help, except you could enforce sizes for the viewport zooming, instead of allowing arbitrary zooming amounts. What I mean is, allow zooming, but in 50% increments (or something along those lines), so that you can ensure it doesn't break the alignment.   Obviously, depending on what you're trying to do, this may not be possible (or wanted), but it's a thought.   Anyway, good luck.
  9. The color change may happen due to the linear filtering, because by using linear filtering, you're averaging between the 4 closest texels, and, since most of the texture is blueish, the resulting color will also be blueish.   The odd line position thing, may also be somehow related to this (though I can't properly explain it).   Have you tried setting the minification filtering to nearest instead of linear, to see if the results improve? You could keep the magnification filter linear, so that, if you zoom in, the result will be linearly filtered.   Anyway, I'm not sure this is the case, but I hope it helps.
  10. I'm not really familiar with SFML but, it appear that "SFML/OpenGL.hpp" is trying to include "gl/gl.h" and you don't have that file. Have you checked if you have a "gl" folder in your include directory with the "gl.h" file in it?   The reason your app compiles without the including OpenGL.hpp may be because you don't make any calls to OpenGL in your application. But, I fear that when you do, it will stop compiling.   Again, not sure if that's the case, but it's worth a shot.   Hope it helps.
  11. Well, first of all OpenGL and openGL ES are pretty much the same thing, with the exception that OpenGL ES is targeted at mobile devices (ES stands for Embedded Systems).   Now for choosing between OpenGL and Vulkan.   OpenGL is very popular,and has been around for a long time now, so you won't have much of a problem finding resources about how to use it.   Vulkan however, if I may put it this way, is the future of OpenGL (and, perhaps, of graphics API in general). This means, however, that it not only has fewer resources available (since it is pretty recent), but also that it is harder to program, because, unlike other APIs (OpenGL or DirectX), you have (mostly) full responsability of ensuring that everything works correctly (whereas other APIs are more lenient, in that they will not only manage graphics memory for you, but also ensure that your graphics card never crashes your application, etc).   I like to think of the difference between the two as somewhat like a managed language (say, C#) and C++. C++ will allow you to do pretty much anything you want, even if it is detrimental/dangerous/etc to your application, whereas C# (or other similar managed languages) will be safer to program in, at the expense of limiting what you can do.   So, in my opinion, I'd advise you to learn OpenGL first, again, mainly because it has the most resources available, and also because it is the easier of the two to learn.   Do note that, regardless of what API you choose, most of the things you'll learn will still apply to the other APIs, so it's not time wasted by any means.   Now for resources.   For Vulkan, right here on GameDev you have a topic about Vulkan resources. You can find it here. There's also a pretty nice article, also right here on GameDev. You can find it here.   For OpenGL, here's a few:   http://learnopengl.com/ http://www.opengl-tutorial.org http://ogldev.atspace.co.uk   And of course, you can find many helpful stuff right here on GameDev, both in the forums and in the articles section. You can also find tons of OpenGL tutorials on Google, so if you get a bit more curious, try it. These are a nice start though.   Well, as a last thing, though somewhat unrelated to your question, there's this. GPU Gems are books that were published back in the day, and are now free to read on NVIDIAs website.  I know that it doesn't quite relate to your question about APIs (or OpenGL/Vulkan specifically, for that matter), but I just thought I'd share it, because it contains many awesome techniques/stuff about graphics rendering, many of them used in actual commercial games. Even if you won't need it for your project, it's always a nice read, and a good way to learn about rendering in general (and not-so-general) so, if you get curious, give it a try.   Hope it helps.
  12.     One way you can deal with this, is to use Composition instead of Inheritance.   If you abstract the type of the objects (Player, Enemy, etc), then the collision code doesn't have to know the object type, only the collision polygon/surface.     For the collision checks, in my opinion, it is fine, and simpler, to overload the same function.   But again, if you abstract the collision surface from the game Object (Player, Enemy, etc), then your collision functions only need to know the type of collision surface, which would, in turn, simplify them even more.   So, instead of  check_collision( RAY_AABB, Object& obj, Player& player ) check_collision( SPHERE_AABB, Object& obj, Player& player ) check_collision( SPHERE_RAY, Object& obj, Player& player ) you'd have check_collision( Coll_AABB &aabb, Coll_Sphere &sphere ) check_collision( Coll_AABB &aabb, Coll_Ray &ray) check_collision( Coll_Sphere &sphere , Coll_Ray &ray )  The object types are stripped away, and only the collision models/surfaces remain.   It's just an idea, though. If implementing it will cost you more (in programming time) than what it will bring, just update what you have.   Hope it helps.
  13. Ok, just by glancing at it, you have GL_TEXTURE_2D enabled. Call glDisable(GL_TEXTURE_2D) before you draw non-textured polygons.       Both work. You can put glColor*() calls both outside or inside glBegin() glEnd() calls.   I usually put it outside if using a single color for the whole polygon, and inside if using per vertex color (when I use old fixed function OpenGL anyway).
  14.   Yes, i thought that too, but if i recall correctly, having texturing enabled without specifying a texture ( with an ID of 0) will prevent any non-textured objects to appear at all.   The lighting could also be a problem, but even if he had light enabled by mistake, the objects should appear black (or grey?) if he didn't specify a light color/position.   And he would also have to enable texturing and lighting, because they're disabled by default.   I might be wrong though.     Yeah, or the whole code, if possible.
  15. Ok, first things first.   Calling glClear(GL_COLOR_BUFFER_BIT) will clear the color buffer (ie. the screen) with the color you specify with glClearColor(). You also only need to set the clear color once, so call glClearColor() once when you initialize your program, and then, you only need to call glClear() at the start of every frame to clear the color buffer (instead of calling both everytime, like you do on your clear function).   Next, in order for transparency to work, you need to enable blending.   To do this, call //Enable alpha blending glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); glEnable(GL_BLEND); You also only need to do this once, when you initialize your program, just like glClearColor().   Now, inspecting your rendering code and your screen shot, it appear that the text's background box is not being drawn at all, and that every subsequent draw uses that first box' color (red).   Honestly I can't really see what's causing the problem. Can you post you're entire code? If so I'll be able to test it in my computer, and I'll be able to help you more.