• 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.

MarlboroKing

Members
  • Content count

    42
  • Joined

  • Last visited

Community Reputation

252 Neutral

About MarlboroKing

  • Rank
    Member

Personal Information

  • Location
    United States
  1. I skimmed over it.. do you ever initialize "visible" anywhere in your sprite or GameObject? No? Then it's set to false, and your Sprite class is not drawing it due to the if conditional. Edit: Scratch that, I see you initialized it in your .h file (not used to that at all...) I'd have to add what has been said: you're going to have to use your debugger. Make sure all values are set correctly, then continue. As it stands, your code appears valid. Once you make sure EVERY piece of variables and objects have valid data, then please attach the rest of your code.
  2. C++ is a GREAT way to start coding. You learn about how a program behaves, instead of being stuck by rules. Once you understand how a program works, the rest is syntax. Sure, memory manipulation, stricter syntax, no safety nets, etc. But, it's best to learn WHY you need to do /that/ instead of being told "its bad". I always recommend starting with C or C++, then understanding the basics of x86/x64 Assembly. Seeing how a program works, is far better than being told "it works". Edit: To the OP. Have you done classes and inheritance? The cpp standard? STL? Win32/x11? There's far and far more to learn. Master what you know now, then move on. I highly recommend learning the cpp standard first. Then move on to the area you like (sound, opengl/directx, vulkan, etc), api programming, so forth). Learn to structure code throughout files. Can you write a number guess game via std::cout? Try that. Then move on.
  3. Unity

    You have your block struct, eg; struct Block { byte nSunlight; ulong nColor; EBlockType nType; } Then you have your array, int nCacheWidth = (nCacheRange * 2) + 1; int nCacheDepth = nCacheWidth; Block* pBlocks = new Block[nCacheWidth * nCacheDepth * nChunkHeight]; Now with the nType in the Block struct, specify AIR to 'delete' a block. nSunlight I used to use it as a value between 0-100, with 100 being brightest. nColor holds 4 bytes for each color (ARGB). Accessing each index would be, long tmpX = nCacheDepth * nChunkHeight; long tmpZ = nChunkHeight; long x = pos.x % nCacheWidth; long z = pos.z % nCacheDepth; long OFFSET = x * tmpX + z * tmpZ + pos.y; blocks[OFFSET].nType = EBlockType.AIR; I typed that from memory on my phone so excuse any errors. I also prefer this way as it makes it so much simpler if you/user wants bigger or smaller view/cache ranges (loading more chunks).
  4. Unity

    Constant allocation and deallocation is a big no, for something this big. It appears for every single block, you're new'ing and delete'ing. If you're aiming for world modification, shifting, etc. - create your initial data structure at once, then assign the block types. Yes, new'ing each block works, but if in one scene you have 8,000,000 blocks, that's a lot of allocation and deallocation. But 8,000,000 new operations, and, let's just say, 400,000 delete operations, it's just flat overkill. Eg; if( someCondition ) { blocks[myIndex].nType = BlockTypes.AIR; } Also, I'd say use a 1D array instead of a 3D array.
  5. In LibGDX, inheriting the GestureDetector class and implementing in to the InputMultiplexer, I am able to pan(move), zoom and pinch(zoom out) my mobile screen in my game (sort of, neither works too well!). The problem I'm facing is when I pinch or zoom, it'll call both Override methods "zoom" and "pinch", to be more precise it'll call "pinch" and then "zoom" directly right after each other.   I've read through the LibGDX documentation and spent hours on Google, have not really found a problem similar to mine. Did I miss a method or member? Here's some rough code; public class GameWorld implements GestureListener, InputProcessor { ..... public GameWorld() { .... InputMultiplexer im = new InputMultiplexer(); GestureDetector gd = new GestureDetector(this); im.addProcessor(gd); im.addProcessor(this); Gdx.input.setInputProcessor(im); .... } @Override public boolean zoom(float initialDistance, float distance) { m_Camera.OnZoom(initialDistance, distance); return false; } @Override public boolean pinch(Vector2 initialPointer1, Vector2 initialPointer2, Vector2 pointer1, Vector2 pointer2) { m_Camera.OnPinch(initialPointer1, initialPointer2, pointer1, pointer2); return false; } }
  6. Working with threads is really 3 things: Do I need a new thread? Writing Reading If you passed #1, #2 & #3 needs some form of locker. You can not write while reading and vice versa. This could be as: void Write( Obj o ) If not locked m_Locker.Lock(); ..... Else QueueIt(); void Read( Obj o ) If not locked m_Locker.Lock(); ...... Else ..... Or expand to something actually useful.
  7. Here's another approach: public String CharName { get; private set; } Which allows public return, but prohibits assigning outside the class. Get/Set is just a quick 'macro'. It basically points to a data type in a class/struct.
  8. Programming is logic. Period. Video games are logic. Mostly. You won't really touch integrated GUI's (eg Win32), you will create your own. Like I said, logic. That's all a GUI is in the core. For a button, you click, then an 'event' happens. As for visual, you'll need to understand OpenGL, it works like a pair in Java. You'll learn about buffers, memory management, textures/sprites, and let's not forget pulling hair out. To start, learn what versiom of OpenGL your system is running, then start on Google. Im sorry, but OpenGL likes to change drasticallt in each revision and much differs here and there.
  9. You won't be able to generate the array for your world, create the lighting and vbs ibs in one pass. Sure, you could, but don't. Nasty results. Generate and create obvious lighting first (eg --y and set sunlight to 0 if block is overhead) Then loop and run your lighting. Then throw away useless faces while creating your buffers. Create an initial section (eg 68 chunks) then light/create as you gain closer and remove as further. Ditch the heightmap if you want cliffs and overhangs. Slightly modify perlin as needed. This is the most difficult part of these games. Don't get discouraged, read and test. Split your world into 'chunks'. 1 draw call consisting of 300 16x128x16 chunk blocks is deadly. 300 * (16x128x16) draw calls is idiotic. Sorry, phone sucks for typing.
  10. Hidden RDTSC instruction - Awaits if a debugger is present. Basically is just a hidden windows timer, akin to GetTickCount, but screwed up in the byte code.     Runtime functions - Use VirtualProtect (or similar for your OS) and implement it. Is a lot of fun and you'll learn a lot.   Implement a random obfuscation virtualization environment. Hard, but not as hard as one would perceive. You'll just need to dive into the PE format (agian, for your OS, mine is Windows..), it's honestly quite intriguing.
  11. Alright, I see. If you're expecting your plain int has at least 32 bits of storage, however, the platform it's being deployed on creates only 16 bits of storage. So if you are performing a bit shift operation to take the last 16 bits out of the supposed 32 bits, bam.   Thanks!
  12. I see very little point of using the 'int32_t' compared to 'signed int'. The project irrLicht actually shows one valid example for it in .\irrTypes.h: #if defined(_MSC_VER) || ((__BORLANDC__ >= 0x530) && !defined(__STRICT_ANSI__)) typedef unsigned __int64 u64; #elif __GNUC__ #if __WORDSIZE == 64 typedef unsigned long int u64; #else __extension__ typedef unsigned long long u64; #endif #else typedef unsigned long long u64; #endif MSDN writes little about the 'fixed size' data types it supports, such as __int32: "The types __int8, __int16, and __int32 are synonyms for the ANSI types that have the same size, and are useful for writing portable code that behaves identically across multiple platforms" -- Great, it's "ANSI principle", I suppose.   I guess my point is; why does MSVC declare the data types prefixed with "__" a fixed size, yet \most\ other compilers determine the globally used "int"(etc.) as a fixed size? Is there any scenario that I should dread about a non-fixed size integer?   Edit: I am aware that 'int' on a x86 build is 32 bits, yet should be 64 bits on a x64 build.
  13. OpenGL

    TGrey, I wouldn't advise relying on frustrum culling. Every frame you would be doing that. So instead, take those faces out before hand instead of "taking those out every frame for 40,000 blocks". @kaptein, wonderful! Never thought of that!
  14. OpenGL

    I'm trying to stay away from octrees and similar, so I will semi-explain how my voxel game works: We have a block class (nType, nSun, color) This will be the main blocks such as grass or dirt. Obviously the best way to render and deal with this blocks is to split them up into "Chunks". Now we have a chunk class (vecIndex, vecPosition, nState) Did you notice we don't use blocks in this chunk class? Because constant allocation and deallocation is a big no. Instead of searching each chunk, create/destroy, etc., we see what our maximum cache distance is as for our BlockManager class And our BlockManager class (Block* pBlocks) I know, a single pointer-array. With this, we can index and grab quicker than an 3D array, and we won't have the overhead of new'ing or delete'ing a 16*128*16 array every time we go into a new chunk. I will post some code in a minute when my wonderful Pentium 4 finally boots up.   Edit: Here we go. This is just a sample that I ripped apart from several sources inside my game. Could be error prone, and defiantly needs some tidying up. #define CHUNK_WIDTH 16 #define CHUNK_HEIGHT 128 #define CHUNK_DEPTH 16 #define CHUNK_CACHE_RANGE 5 #define CHUNK_CACHE_VIEWRANGE 3 #define CHUNK_CACHESIZE_WIDTH ((CHUNK_CACHE_RANGE * 2) + 1) * CHUNK_WIDTH #define CHUNK_CACHESIZE_DEPTH ((CHUNK_CACHE_RANGE * 2) + 1) * CHUNK_DEPTH int MOD( int a, int b ) { return (a % b + b) % b; } int OFFSET( int x, int z ) { int nWrapX = MOD( x, CHUNK_CACHESIZE_WIDTH ); int nWrapZ = MOD( z, CHUNK_CACHESIZE_DEPTH ); if( nWrapX < 0 ) nWrapX += CHUNK_CACHESIZE_WIDTH; if( nWrapZ < 0 ) nWrapZ += CHUNK_CACHESIZE_DEPTH; return nWrapX * (CHUNK_CACHESIZE_WIDTH * CHUNK_HEIGHT) + nWrapZ * CHUNK_HEIGHT; } int OFFSET( int x, int y, int z ) { int nWrapX = MOD( x, CHUNK_CACHESIZE_WIDTH ); int nWrapZ = MOD( z, CHUNK_CACHESIZE_DEPTH ); if( nWrapX < 0 ) nWrapX += CHUNK_CACHESIZE_WIDTH; if( nWrapZ < 0 ) nWrapZ += CHUNK_CACHESIZE_DEPTH; return nWrapX * (CHUNK_CACHESIZE_WIDTH * CHUNK_HEIGHT) + nWrapZ * CHUNK_HEIGHT + y; } class BlockManager { public: Block* m_pBlocks; BlockManager() { int nSize = CHUNK_CACHESIZE_WIDTH * CHUNK_CACHESIZE_DEPTH * CHUNK_HEIGHT + 1; m_Blocks = new Block[nSize]; for( int i = 0; i < nSize; i++ ) m_Blocks[i] = Block(); } Block BlockAt( int x, int y, int z ) { if( !ChunkCache::IsInBounds( x, y, z ) ) return Block(); int nWrapX = MOD( x, CHUNK_CACHESIZE_WIDTH ); int nWrapZ = MOD( z, CHUNK_CACHESIZE_DEPTH ); if( nWrapX < 0 ) nWrapX += CHUNK_CACHESIZE_WIDTH; if( nWrapZ < 0 ) nWrapZ += CHUNK_CACHESIZE_DEPTH; int nOffset = nWrapX * (CHUNK_CACHESIZE_WIDTH * CHUNK_HEIGHT) + nWrapZ * CHUNK_HEIGHT; return m_Blocks[nOffset]; } };     Alright, now we can use a TerrainChunkGenerator, go from x = 0, y = 127, z = 0 and x++, y--, z++ Generate our chunks, and move to the LightingChunkGenerator. Perform some nasty recursive functions to spread out our light source from 16, and continue.   Now we are at VertexChunkGenerator. When creating the vertices, we check the current block's neighbors. So, if a block is above us, we don't create the top face. If a block is to its left but not to its right, don't create the left face and generate the right face. Now we have this chunk that will only have visible blocks vertices and indicies. We just gave our performance steroids.
  15. I'm in a similar boat, Zanman. Matrices, Quaternions, etc. scared me to death. Then it just clicked after a final look over. It took quite a bit, but it'll arrive when it's time.   See though, me personally, I prefer to do it myself instead of use a prebuilt library. I'm learning about the Linux system as I write my test-hobby game. Being open to use what I need to restricted to certain things, learning WTF X11 is talking about, switching from DX9 to OpenGL3, learning how to deploy on different platforms efficiently as I code, etc., yeah, not exactly fun at the moment. However, notice my mistake. I'm thinking because I have past history in Win32 & DirectX, I can just carry what I know in programming to a completely different OS and it'll work dandy. Well that's a big no.   I thought I could just jump into 3D games right away. Talk about falling on your face. Spending time in the 2D field, studying up on math, the API and what happens behind it as I continue to make simple games was, and I'll stand by it, the best option I and anyone else could've done.   Take steps, learn what you need to do first. Tackle it. Grab the next subject, take it down. Honestly though, time, patience, Google and creating test applications ARE your very best friend. I'd stick with C++ and OpenGL, they'll be more valuable to you, IMHO. As for your netsoccer idea, that's all you need. Well, graphics too. Trust me though the networking can and will get tricky.