• Content count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About AlexKay

  • Rank

Personal Information

  • Interests
  1. In your first post you have this function: /*picking function*/ bool picking(int x,int y) { int mouse_to_image_x, mouse_to_image_y;//get mouse position in the image mouse_to_image_x = 30 - x; mouse_to_image_y = 30 - y; if((mouse_to_image_x < 0 && mouse_to_image_x > 7) && (mouse_to_image_y < 0 && mouse_to_image_y > 7))return false;//mouse is not in the image for(int i = 0; i < 7 * 7; i++) { if(pixel_alpha[mouse_to_image_x][mouse_to_image_y] == 255)return true;//in the image and alpha channel is 255 } return false; } and this data structure BYTE pixel_alpha[7][7];//save alpha channel matrix If you have gone to the trouble to store hittable bits in your own data structure wouldn't you be better of just looking up the alpha value at a given location instead of iterating in a for loop searching for it // something like this? lookup_x = mouse_click_x - location_of_object_x; lookup_y = mouse_click_y - location_of_object_y; if( (lookup_x < 0 || lookup_x > 7) || (lookup_y < 0 || lookup_y > 7)) { // WAS: OOPS had && but can't be less than 0 and greater than 7 // NOW: changed to || return 0;//mouse is not in the image } hit = pixel_alpha[lookup_x][lookup_y]; return hit; Say mouse_x is at 355 and object corner is at 351 you need to lookup 355-351 = 4 and a similar thing for y. Also you are storing value 255 in a BYTE, I presume a BYTE is 8 bits, so it'll cost 8 bits for each texture bit. Wouldn't you be better off using 1 bit per bit (hope that makes sense). Sorry I can't be more specific since I'm not sure what you're trying to do, these days I would use modern OpenGL and vector graphics and I'd render to an off-screen frame-buffer, each object in its own color with unhittable objects left as black then I'd use glGetPixels to decide what was hit. So called "Color-Based Mouse Picking" ... It requires a lot more code than this - but it gets to run on a "hardware" accelerated board so probably worth it? Cheers.
  2. Let's say you have a texture which is an image of a button or something - and now you want 15 buttons. And another texture - a kitten - so you have 20 "Entities". One way to do all this is to have a struct or Entity class which has it's own bottom left x,y and top right x, y to form a bounding box, yes, a good old fashioned rectangle. Not buttons, not kittens but rectangles. Now you would have an array or list of all such Entities, each with their own x, y locations. So you can go through your master list which has all the Entities - if the mouse x, y is not even in the bounding box of an Entity then it can quickly and easily be eliminated. There is no point in drilling down into the details of each kitten pixel if you aren't even in the same ball park as the bound box rectangle. Right? For these "broad phase" collision tests you can use other simple shapes as well:- like circles, spheres, cylinders or whatever. The concept is the same. Back in the day I was an avid arcade game player and could've sworn they were doing pixel perfect collision detection. Years later I heard the actual author say it was just a bounding box or circle test. Had me fooled. Yes you can drill down and "sample" the RGBA of a texture but I'd get the bigger picture as described above sorted out first. And if you have many thousand objects then you would benefit from partitioning space. A simple Grid with Cells or Quadtree for 2D, Octree for 3D will help you reduce the master list, you'd have a sub-list which only contains Entities in that neighbourhood ... (At any rate I would not create my own data structure containing just the alpha channel bits. That's all on the CPU with regular system memory, you'd want more OpenGL and hardware acceleration help).
  3. “Where to start” is a great question - and there have been some great answers which I wholeheartedly agree with. Especially about starting small! I know the temptation is to go all-in with all guns blazing but that'll lead to nowhere but frustration. I strongly recommend that you really understand how something like Space Invaders or any other 2D arcade game with sprites works. Then you will understand how thousands of games work! I reckon C with K&R is great and well worth the read (and re-read). OpenGL is written is C, SDL is written in C, GLSL is "C like", we have C++, C#, Objective-C ... You can do C++ without first learning C but I'm glad I did C first. At least I understand what has no become some sort of secret - memory is not infinite and must be managed. The memory fairies won't be able to sprinkle fairy dust and make all the problems go way. Chances of going astray with C are pretty low. You could then get SDL which is an OpenGL library and learn the examples it comes with like fireworks.c - then modify and build from there. Or you could start with Lua - a C like language which is used a fair bit in the gaming industry. If C++ is king then Lua might be a prince? There are many engines like Corona Labs which run Lua. The App Store must have thousands upon thousands of games built with it. You can find many small game examples to get you started. C++ ? Hmm, I fear you might get distracted and roam around the wilderness a few years! It is a big language used in so many different ways in so many different arenas - it does not all translate well to game programming! Often the opposite of what you need!. I am not rubbishing the "GOF" Pattern Book, it has some deep insights and knowledge. But evidently too deep for most people: It says "favor object composition over class inheritance" (page 20), but what does the world do? The exact opposite! Deep and wide hierachies everywhere. This is only completely different, 180 degree, PI over 2, boolean negation operator, opposite! Went left - should've gone right. WOW. And then there's STL, Boost, Templates, Multiple Inheritance and whatever else. Again these are not without merit (STL and Boost saved C++ IMHO) but for gaming they can all be a big problem - falling into a pit or three is almost assured. Anyway I reckon finish C with K&R and either get SDL and examples which run with SDL. Or go to LUA. Either way learn what a game loop is ... Once you understand games and have built a few small ones then you might go to C++ - at least then you will be anchored on what is necessary for gaming.
  4. Your example will probably run at 500+ FPS so efficiency is not an issue at this stage. Far from it. Checkout the site it goes through everything step by step. Forget efficiency for the moment - you'll want to texture the cube, then move the cube around, read an OBJ file to move beyond cubes and then render that model, maybe a few instances of it, a camera, matrix transforms, basic lighting .... that or similar is the usual order of things. Do work out how to calculate FPS and display it in the Window.title bar or Console - that way you'll know where you really stand as far as efficiency goes and if / when you need to do something about it. Meantime over thinking it all will just cripple your progress. (Sooner or later google "bunny.obj", download it, read it into as a mesh and render that ...) my 2 cents worth.
  5. I definitely agree you should start with 2D, get things going make something small to learn from then you can expand from there. SDL is very good, it is used in a lot of small and heavy duty games. But I did found it hard to find good material so I had to expand my horizons and look at the other OpenGL tool kits like:- glfw, SFML, LWJGL/Java and WebGL. Under the hood they all use OpenGL - so it all helped. I wanted example projects bigger than HelloTriangle and smaller than Doom3 - could not find much in-between. BTW of all of the OpenGL tool kits SDL is my favourite because it does mobile and it just works! Anyway have a look at: 1. The example apps that come with SDL (or SFML, LWJGL or whatever). 2. - shows you how to setup on Windows, Mac, Linux, with and without mobile. There is no great architecture here, just example by example - but then you can take that knowledge and use it in your games. 3. as mentioned here already. Uses glfw not SDL but it is a good site and there's a free book you can download. 4. (WebGL yes I know ... but still it is OpenGL under the hood and you can quick learn from those guys. Lots of stuff on YouTube but many of them take 100 videos just to make the most primitive game - it should only take about 10 vids not 100. Everything is easy once you know how. If you learn how one sprite based game works (like Space Invaders) you will realise they are all more or less the same. Good luck.
  6. Welcome theelephant, (I'm new here too but been doing game dev a good while now). Definitely, absolutely and make no mistake about it - start with something small. An arcade 2D game like space invaders is the way to go. Forget 3D for now. There is no best engine, they all have fans, so yes you'll hear conflicting stories. But people are all different so you have to find what works for you. At this stage the best engine is the one you learn most from! And I definitely wouldn't be paying for an engine at this stage (I did in the past but never mind that ...) - there are now so many great free choices. Corona Labs have a Lua based 2D engine. It was subscription based but now I believe it is free. Lots of examples, tutorials, vibrant community, remember learning is the big deal at this stage. Angry Birds is Lua based, I unpackaged the original iPhone version, I can see Lua guts but can neither confirm nor deny the rumour it was actually done in Corona? Still plenty of real games done in Lua. Love2d is yet another Lua engine with real fans and games. Godot - seems to be very good but they use their own custom scripting language. I've only tinkered with Godot but I got it up and running within minutes and the demos all worked flawlessly. A pretty polished open source engine. Apple's SpriteKit - if you decide to get into programming more? It is pretty easy to use, I made a game in about a week or two (but I've been programming a long time). It has a thriving community with plenty of examples and tutorials. Unity 3D is bigger than the above and pretty good - but it seems to me there is a reason it's called Unity 3D - it feels like 2D was an after thought. Anyway it starts free but sooner or later you feel the urge to start buying stuff from their store ... Unreal Engine is even bigger and definitely the real deal - but you need beefy hardware and again it's really a 3D engine pretending to be a 2D one. Maybe SDL, it is C based but it can work with Python or Lua... Again that's if you get into programming more. But SDL very good. I suppose I should mention Java with LWJGL. Not my first choice of language or environment but apparently you can make popular games with it as in Minecraft. You run but not hide from programming and maths - either you will have to do it or beg/pay someone else to do it for you so the more you know the better. And you might discover you really like it. Sorry I don't have a simple and clear answer - it depends on you - but have a look at Corona Labs and Lua see if you can sink your teeth into that. Meantime learning is the answer. And game design is more important than which engine. Hope that helps.
  7. 3D Do models go inside a BSP?

    Just to clarify I wasn't advocating BSP Trees as the be-all-and-end-all of game related tree structures. But the OP did say 'starting to think about BSP Trees", and rightly or wrongly, I jumped back in time to when I started with them. I bought a dozen books and read everything on the Internet on the subject but frankly the signal to noise ratio was and still is pathetic. Sad rubbish. I only made real progress and got all my questions answered after I somehow cobbled a version together and played with the code. I guess I was channeling my university professor who said to me "yes I can give you all the answers but that'll be like reading a book on How To Swim! You can read and think until the cows come home but you have to write code then you'll truly understand..." So I stand by what I said "if you have great information and source code for Octrees or Bounding Volume Hierarchies (BVH) then by all means go with them first". And I don't treat code as so precious that it cannot be changed, tweaked, improved and thrown out. Master whatever tree you can and keep moving. Have a nice day, Thanks.
  8. 3D Do models go inside a BSP?

    Sorry, late reply and most points have already been answered but I really like BSP Trees so why not ... and they're actually good questions.
 If your engine is mainly about outdoor scenes then you will not benefit from a BSP Tree or any other tree. BSP Tree's are predominantly about indoor scenes. To build a BSP Tree you feed it all the static polygons of the world. Dynamic ones are not included at all, they come later. You have an empty world with walls, ceilings, floors, steps and any other static objects you want to "bake" into the map. You need a way to specify all this. Sure you can build a world in Blender or Maya but then you need a way to flag what polys are walls, which are floors, which are ceilings. Most game engines don't use Blender or the like for world creation, only for models. For levels or worlds Doom had doom-ed, Quake had quake-ed, Unreal has it's own built in world editor... You can just create a simple text based map file, similar in nature to OBJ files but for maps. You specify walls, floors, ceilings and refer to OBJ files for static objects. After reading this file you can create the specified wall, floor and ceiling polygons and OBJ derived static meshes which are of course just more polygons - feed them all into a BSP Tree, partition along walls and you're ready. Once a tree is built and the game is up and running - then dynamic models come into play, they can quickly determine what can be seen from any given room - but it's not just about visibility - the BSP Tree lets you test for collisions, you obviously don't want to walk through walls or fall through floors. For dynamic to dynamic model collisions the BSP Tree cannot be used, they aren't even in there, you probably need an additional scheme. I'm just using a grid based division for this, there is no point checking for collisions with other dynamic objects across the world, only check within neighbouring cells. Apart from BSP Tree's there are other partitioning schemes but if you're anything like me the only way to truly answer all the questions is to build one and play with it. It's a case of build first, ask questions later. Once you master one scheme you can quickly and easily bridge over to others. Sure if you have great information and source code for Octrees or Bounding Volume Hierarchies (BVH) then by all means go with them first - but for me the Michael Abrash Black Book and associated code was a deciding factor. It's not really a book, it's a collection of articles so you don't have to read it all. I find most of the information about game programming "out there" to be rubbish - but Abrash worked with John Carmack on Quake so this is the real deal and he has code examples. Thanks Michael, thanks John.] (Spoiler alert - for Quake which has polygon based dynamic models they ended up using z-buffers after all but only in a limited way and just for mixing dynamic and static polygon models. Now we have z-buffers handed to us on a silver platter, just enable GL_DEPTH_TEST and let OpenGL do its magic). Hope that helps.