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

freakchild

Members
  • Content count

    234
  • Joined

  • Last visited

Community Reputation

572 Good

About freakchild

  • Rank
    Member
  1. This is about a year old and I haven't used it in a while (so the NDK may have changed to the point where this could be a little out of date) but this is how I built a shared library that also includes prebuilt static one.   LOCAL_STATIC_LIBRARIES := nameofprebuiltstaticlibrary ... include $(BUILD_SHARED_LIBRARY) ... $(call import-module,nameofprebuiltstaticlibrary)   But for some source includes (and some commented out lines which I'll cover below) these are the only locations in my Android.mk that specifically mention the library I'm trying to include.   You look to include your pre-built static as a shared: LOCAL_SHARED_LIBRARIES := foo-prebuilt   ...and I'm not sure what the result of that would be but it looks a little dodgy given it's a static.   Before the above, this is what I used to do. include $(CLEAR_VARS) LOCAL_MODULE := library_pre LOCAL_PATH := $(TARGET_OUT) LOCAL_PATH := $(EORBRANCH_FS)/obj/prebuilt/$(TARGET_ARCH_ABI) LOCAL_MODULE_FILENAME := libprebuit LOCAL_SRC_FILES := libprebuilt.a include $(PREBUILT_STATIC_LIBRARY) $(call import-module,prebuilt)    I list that because I note you have something similar too.  In my case, this is how it was and it is now commented out and I rely on the first code box above.  I mention it because for me to not be using this/this being my old method - you may be mixing two methods.  The google make files offer more than one way to cook the egg and as I recall mixing them is easy to do.   I would post my files but once upon a time another engineer hacked them up to customize.  Not sure exactly what they had in mind here because it was working well already and they eventually stopped trying as they realized the google system worked well enough.  In the process they really messed up the clarity on offer though (it was once much clearer from just looking at the file), hence why it's best for me to post the intact snippets and the commented parts.
  2. Try removing the static keyword from static int rb_down = No; and the equivalent in your lb function.   Looks to me like it gets the touches regardless of whether any are down or not, so 'if (touches)' is always true which prevents the alternative 'else rb_down = No' from executing.  If the touch is outside the radius the subsequent setting of rb_down to Yes is missed.  While that wouldn't matter (given it sets to Yes', the point is that nothing is setting it to anything in that circumstance...and thus it will remain as 'Yes' from when the touch was within radius.   The problem is that there is basically nothing that sets this to 'No' after the first initialization to that with the static keyword.  Once it goes to yes, it stays yes...unless you lift all fingers up, in which case your 'if( touch_count != 0 )' triggered ZeroMemory call does the work, or you lift the finger in question (triggering touchesEnded, which will also do it).
  3. 2c...   I started in this industry at a time where most people had no degree...either from just not bothering or 'dropping out'.  Degrees became a little more the norm over time and as such there came to be a point along my path where most people new to the industry did have a degree and I was largely surrounded by quite a lot of 'qualified competition'.   i.e. I've been through this.   As a result, I spent many a year around that time wondering whether to get a degree or not.  I never did take the leap and nowadays I’m glad about that, as the time would have been wasted.  The only thing that really mattered was that I was always able to do the work and after years of doing that, the relevance of a degree that I might have taken time to earn 10, 15 or 20 years ago is just obsolete.  Nobody really cares nowadays and for the most part never legitimately did, either I just have much more experience than most people around me which nullifies their issue or, they have enough experience in addition to their degree to now understand it doesn’t matter.  Stick with it and you will find yourself in the same position.   People can be a judgmental as they wish but if you can do the work they will never have a legitimate complaint so please bear in mind that this speaks more of them, than any failure of your own.   Thus, I agree…if you do get it, do so because it adds to your skillset and not to get a +1 in the eyes of your shallow colleagues.   I would also add, the best +1 you’ll get is working with them and holding your own, especially if they ever struggle on something and you can help them out.  This will serve as experience on their part and help them overcome their issue.  Resist the old ‘well, look where your fancy bit of paper got you’ dance either way because that will just distract such people from appreciating your own efforts.
  4. jsbsim @ http://jsbsim.sourceforge.net/ is a fairly common choice.
  5. Paul Nettle's reference [url="http://www.paulnettle.com/pub/FluidStudios/CollisionDetection/Fluid_Studios_Generic_Collision_Detection_for_Games_Using_Ellipsoids.pdf"]here[/url] explains a theory of how to do this. While the result is focused on 3D and ellipsoids, it does lead up to that by describing the method as it applies to 2D and circles. The section on sliding applies to things other than spheres either way and demonstrates how to get the sliding vector from the direction vector and obstacle plane.
  6. You want advice? Well, if after all that you've decided to get on with life and are going to U of U, it looks to me like you're already rebuilding things positively. Just get on with things as you are. You will never shake this off (you already know this) but don't fear it too much because the impact it has will lessen over time. In deciding what you want to do and just getting on with it you're accepting the thorn in your side that it is. It's better you try this, than write yourself off as a career criminal and don't try...or worse. It will become a much smaller thorn quite quickly if you stay on the straight and narrow, perhaps even set an example for others. Doing well at school, will put it one step behind you and potential employers will have something both more recent and positive to focus on in hiring you. Do well at your first employment and I think other potential employers will trust that you're not the kid who made a mistake, but a potential employee. Although you might find some places that won't employ you, I'm sure you will find many who will overlook it especially for something done as a minor. When it comes to applying for jobs, be up front about it but personally I would say 'not so up front'. Putting this in your initial application is probably not a good idea, but I would say that if you're invited for interviews you need to start thinking about talking at that point to their HR. In this industry, usually there are phone interviews and I would consider speaking about it at that point and possibly follow up with an email to the hiring manager or HR. In both cases, explain that you have a history, aren't hiding it but wanted to get chance to speak first and you were always going to be 'up front'. If you are following up with something in writing after a call, then point out you were up front in the call, backing up the idea you were up front at the most appropriate point. Get references, including those of the character kind along the way. College professors will be quite ideal for this because what they think will be respected. Get a job while you are at college too, for the same reasons - effectively showing that you are a reliable employee. Be careful what you get up to for the next few years and if you're ever in a place where you could be in trouble with the police even just by association, think about not staying there. Party with weed about...consider going home. At a bar...don't get too drunk, avoid getting into fights, etc. You don't have to be an angel by any means, just don't take risks. Do remember that we all have skeletons in the closet one way or the other. Incidentally, do bear in mind the above 'do computer science over game design' is common advice around here and with very good reason. If you are intent on programming and can change that over, I would.
  7. OpenGL

    Okay, so I did mean the code that sets up the projection matrix - just looking to make sure it maps to your depth range of 0.0 to 1.0, but if that's always worked and you're confident in it. I mean set gl_FragDepth to 0 in the fragment shader, but certainly you could also try fiddling with gl_Position (although with w as 1) to try and beat other oddities to the surface. Really these won't solve anything, they'll just allow you to spot inconsistencies and maybe pickup a clue nugget.
  8. OpenGL

    A case where everything is rendered when depth is disabled, but nothing when enabled is suggestive to me, as in Kaptein's case that the pixels are being rejected because the depth test is working and either the depth testing setup is wrong, or you're getting the wrong output because of either the wrong input or some meddling going on between (your depth value is not what you are expecting, or is not within the range you've configured to expect). I notice you haven't set your depthrange...nothing wrong with that, it just means that you're expecting the default of between 0.0 and 1.0. Is either your projection not set up to deliver a value in this range, or are you doing something else in the shader that might overwrite or otherwise corrupt the depth output to be not within this? It might be a good idea to post your projection matrix code and your shaders, then people can look how your projection is set up and confirm that's okay and nothing is meddling with the expected result in the shader. I would also look at your depth output by putting it into the shader output rgb and therefore viewing it (depth tests disabled to make sure the results aren't rejected). Make sure you're not always writing 1.0 or something, or at least it's always as you expect showing a depth between 0.0 and 1.0. Another test you can do is force the depth output to 0.0...which if the depth testing is on should see everything pass. This will not solve the problem, but would at least add more weight to the idea the depth testing is working even if the result is correct. I would do this before the above actually. Don't be worried about the value of doing tests like this, sometimes you have to beat all the info to the surface before the problem/solution is obvious. With that in mind, also have a look at [url="http://www.mvps.org/directx/articles/linear_z/linearz.htm"]http://www.mvps.org/...r_z/linearz.htm[/url]...it's not a solution for your problems but there is a discussion in there on z and w values...some knowledge of what they are and how they relate should also allow you to force them to other specific values and undertake more specific tests, making sure that you always get the expected results. There is also some knowledge in there that might otherwise highlight an error.
  9. OpenGL

    Just to make sure, but you are also clearing the depthbuffer too...including at the appropriate points in your chain? A long shot also, but is there anything in your shader taking an early out so the pixel is not written, based on depth or not? Given that you also have a long chain of swapping in/out targets, have you spent any time looking at interim results to see if they are as you expect, which if not might provide further clues?
  10. OpenGL

    [quote name='Kaptein' timestamp='1352233331' post='4998187'] It doesn't matter if I add a renderbuffer or not, as long as I have a depth-texture target the screen is black If I don't have depth-texture target it draws fine, just without depth-testing anymore [/quote] So, with no test it works but with a test it fails. It sounds like the test may be wrong or at least not configured how you expect it to be. At least make sure glDepthMask, glDepthRange and glDepthFunc are set as you expect them to be, personally it sounds like your fragment output is rejected due to depth working but not as you expect. It's probably also worth reviewing (googling) the concept of 'framebuffer completeness' to be more certain about what you understand a framebuffer can/can't do. That will cover the necessary minimum and clarify what attachments need to be in place. Checking for framebuffer completeness via glCheckFramebuffer status is a good idea and may help to debug any obvious errors you might have. You will find the concept of rendering to a depth buffer alone is considered 'incomplete' which is possibly where your actual problem might be. This might be specific to GL ES, but is worth checking anyway. Specifically, what you might be witnessing above is a misconfiguration of depth parameters when you do have a renderbuffer and when you don't (if I'm reading your 'chain' correctly), you may have a framebuffer incomplete problem.
  11. Not sure I understand you fully, or at least the subject text reads a little bit of a different problem to the body. Assuming for the body though... Rotate the first object and translate it into position. For the second object, rotate it around it's local origin (no translation) first then rotate the position and the offset translation (not the object itself, but the (x+2,y+3)) and then apply the result of that to the second object as a translation.
  12. [quote name='EngineProgrammer' timestamp='1349707579' post='4988005'] An allocator is an allocator so why don't they just write 1 struct: Allocator. and use it for everything. I don't get it why they uses so many structs. So if someone could explain this for me, thank you! [/quote] Each allocator likely has a mix of common and unique/specific needs based on a unique purpose or scenario. This probably means the structs have slightly differing members based around that need, which likely means the structs have varying sizes. If you packed all structs into one you'd be stuck with the same size struct all the time and the size would always be equivalent to the largest of them all, also always the worst case scenario. Structs in memory management are often used as headers for blocks of allocations (or sometimes with each allocation) so this would mean that every time you deploy the header it will use the same memory as this worst case scenario, regardless of the other memory you're looking to allocate. If you are using one of the smaller structs that uses only a subset of the members, needing only to occupy just a few bytes then you are wasting memory. While there are other ways to boil this egg, using different structs allows you to more easily access only the members you need and only use only the memory those members require.
  13. [quote name='EpicWally' timestamp='1349385023' post='4986902'] 1.) Is TDD applicable to game development? I'm guessing the answer is yes for large projects/teams, but I don't know about small project games like what I've mentioned I've done/am working on. [/quote] It's applicable to development, so game development would not be ruled out...but it is something that you'll find is practiced more widely outside of games than in, although there is no particular reason for that. It can apply to small projects just as appropriately as it can to large projects. Larger projects are in some ways more difficult if the entire team is not using the technique, because other team members might break your tests or you'll keep the tests very small and based around what you author only, possibly at the sub-feature level. But do remember there is more than one way to boil an egg. Some people get similar benefits by doing other things and some people just frankly have a preference for one thing over another. There is no single correct methodology and if there is a best one, it's often a mixture of things anyway. [quote name='EpicWally' timestamp='1349385023' post='4986902'] 2.) If it is, what kinds of tests would one run? [/quote] A test, which will likely be a set of smaller tests but collectively considered that validates whatever feature you're implementing. These will be tests that confirm you get an expected output for the given input, Fake and mock tests that simulate real use of the code, either in full or in part and so on. A test that takes you through the entire 'use case' of the feature or code, possibly from initialization, gathering the results/output and validating them as being valid and/or within certain constraints and testing even the destruction of the system to finish. The general idea is that the tests also define your requirements, so TDD is often considered efficient because you're not authoring a whole lot of imaginary requirements or documents elsewhere, you're doing the requirements, the tests and the code pretty much all in the same place which many people consider is productive. Also, it can also include tests that test memory and performance impact...particularly if you have specific requirements there. If you are working on an object, you might run a test every once in a while to make sure the object is in a correct state at any one time, sometimes people try and keep an object in what is known as a class invariant state for example which basically means it's never broken between operations, or at least that kept to a minimum. I used to work at place where as part of their coding standard, each object had an 'invariant' function that would be asserted to be true at various points. Such a function can play a role in these tests. Basically...whatever tests you want, but enough so to validate against your requirements. Anything less is not really TDD, although that doesn't necessarily mean less is not still valuable. [quote]Is it a good idea/worth learning? etc[/quote] It's a good idea, but like many good ideas they often represent more of a personal preference and/or is going to be based on your own personal situation, the sort of code your are authoring and so on. Some people take to concepts like this well and others just feel it gets in the way, or they might not benefit from it much so it's nothing but overhead. It's productive and productivity is a good thing, but you need to figure out whether the productivity it offers you is valuable and/or enough to justify it. Start small, definitely more at the class unit test level rather than testing higher level features and the entire output of a program or specific feature. This will let you dabble in it without diving in head first. i.e. if you're interested, do enough to figure out how much personal value this is to you and whether or not you want to spend more time on it. Try and figure out whether it'll be productive for you at both the small and large scales i.e. at class level,more of at the class unit test level or at the feature level...or both (again thinking in terms of many small results sum to a big result). You'll have to also maintain, develop and iterate the tests you author so you need to understand whether that's overhead for you or not. Ultimately, you need to determine that you can accept the overhead and consider it tolerable, understanding whether the net result of all the work still yields productivity or some other benefit that has value to you. You might actually suffer a productivity loss from any concept such as this, but consider that to be okay given the quality of code coming out of the other end. Again, that's a very personal decision and assessment. Programming is all about making trade offs and not all have black and white results. Bear in mind that it can help to put together an extensive framework to run these tests. I don't recommend doing that initially, but there is a point where if you take this on running many little tests all the time by hand becomes cumbersome so do consider that if you run with this, it is quite inevitable you'll spend time automating the entire process. That will payoff in the long run, but there'll be a period in time where you're not working on new code and putting together a framework and build system.
  14. [quote name='___' timestamp='1349357244' post='4986754'] i have alieron center position not in 0,0,0 but in x,y,z and if i want to rotate(glrotate)it by X,0,0 or 0,Y,0 0,0,Z axises i just need to transalte it to 0,0,0 point ( -x,-y,-z) [/quote] Yes, that sounds right. Translate by (-x,-y,-z) and then do the rotations you need, then translate by (x,y,z) in order to put it back in place. [quote name='___' timestamp='1349357244' post='4986754'] and second question: you have told me that i need to rotate it by local axis then just multiple matrices [ alieron with airplane modelview (simple glMultMatrixf) ] right? this should do the work? [/quote] glMultMatrix along with glRotate, glTranslate and so on, operating on the modelview matrix can work yes but do bear in mind that all these functions apply operations to the 'current' matrix, which will be determined by glMatrixMode and whatever you initially loaded by glLoadMatrix. While that version of the API has handy functions like glPush/PopMatrix which can help too it can get a little cumbersome and difficult to debug, especially if you're new. As an alternative many people do author or use a matrix library, working outside of opengl first and then submitting the final results to the GL_MODELVIEW matrix via LoadMatrix. This can offer a little more flexibility as far as manipulating matrices goes and can help in understanding things.
  15. [quote name='ISDCaptain01' timestamp='1349226910' post='4986241']Its been my dream to make a crappy hobbyist quality 3d engine, but if i need to know a truckload of math that would be a hearbreaker =([/quote] Bear in mind that a lot of the knowledge you need to do this to the level you mention is actually what you can pick up from DirectX tutorials and books, which you'll have to do anyway if you're new to DirectX. A couple of people have commented on that sort of thing as a possibility and/or whether or not it's a good idea, but I would classify it as giving it as go or 'making headway' as GeneralQuery mentioned. I think the advantage of doing that is that you'll learn more about your own limitations during the process, including understanding whether you need to pick up a little more math knowledge. If you already know calc 1 then do consider that through practice and application, the fuzzyness you describe will disappear and you are somewhat already set up to be filling in blanks from other math topics. Also bear in mind that there are many 'graphics programmers' out there who don't necessarily operate at the cutting edge of R&D and are quite often following others. Really, the idea these same people are top math students or not is more a measurement of how much more easily they'll be able to devour white papers to follow new research but even the lack of an ability to do that does not preclude a lot of people from developing 3D engines. For many, it just means they're devouring knowledge at a different (higher) level, perhaps after others have turned said white papers into tutorials and pseudo code, in other cases it's often using libraries developed by others and gradually picking up the knowledge that is initially quite alien.