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

scarypajamas

Members
  • Content count

    191
  • Joined

  • Last visited

Community Reputation

409 Neutral

About scarypajamas

  • Rank
    Member
  1. Based on these comments I'm going to attempt to implement an occlusion query design and benchmark it. Using portals would make things like lightmapping faster since I could eliminate lumels from sectors the light cannot see reducing the overall number of rayscasts. I could hook the occlusion query system into the lightmapper which might help. It seems like occlusion queries are a good general solution for polygon soup, but since the maps I'll be dealing with are more room oriented my gut still says portals might be more efficient. It also seems intuitively easier to me where portals should be placed (in doorways, hallway entrances) versus where an occluder should be placed. And for collision I'm thinking a BVH might be good enough.
  2. I have researched occlusion culling and I worry about the accuracy of a hardware solution since there will be latency between whats currently visible versus what was last reported visible by the GPU. The player might turn around quickly or teleport causing brief popping artifacts. A software solution might work. I also have to consider the visibility of the player from the perspective of the NPC's so this algorithm may run, not just for the players view frustum, but the NPC's as well. Lets say its a fast paced first-person stealth game with indoor environments connected by doorways and/or hallways. The levels are static and loaded once, they can be small or large. The world itself will be detailed by brushes and many low-poly model props. If an area is visible, then its content may also be visible. Based on these requirements I was leaning towards BSP's and portals, but before I go that route I want to be sure there isn't a more modern solution.
  3. I meant broadphase in the sense of narrowing down the number of solids needing to be checked for collision. In the Quake 3 BSP format that meant tracing down the BSP via hyperplanes until a leaf was reached. The leaf stores the possible brushes that can be collided against. Testing against that small set of brushes is the narrow phase. My question is not about frustum culling or GJK. Let me be more specific: I need a way of determining what parts of the world are visible without unnecessary overdraw. Quake did this with PVS and Doom 3 did it with portals (and I'm aware of how both of those algorithms function). I'm wondering, in 2017, if there is a better approach.
  4. I'm looking for a broad phase algorithm for brush-based worlds. I also need an algorithm for determining which areas of said world are visible from the view frustum. The Id tech engines in the 90's used BSP's for broad phase collision and PVS for visibility. Doom 3 in 2004 kept BSP's for collision but switched to portals for visibility. Its now 2017. I'm wonder what approach should be taken today?
  5. Thank you both for clearing up my confusion.  I'm trying to get a client/server architecture using UDP working.  The Quake 3 and ENet sources have been helpful for learning.  If you guys have any other reading material suggestions (source code, books, or otherwise) on the subject, then I'd appreciate it.  Thanks again!
  6. My understanding is that packets sent from computers behind the same router to an external address will have the same public IP address from the perspective of the external service being contacted. First question: I want to verify that although they share the same public IP, the port number attached to the public IP will be unique, correct?  Its by having a unique port that two computers behind a home router (sharing the same public IP) can connect to a game server and can be uniquely identified (via unique ports), correct? Second question: I was reading about how Quake did its networking and it appears old routers would sometimes change a computers public port mid-game causing clients to no longer match their port stored on the game server.  John Carmack ended up having to generate a "qport" (a random number at connection time) which would uniquely identify the client even if their real port changed.  Is this still necessary? TL;DR The ultimate point of this post is to verify that I can reliably use a clients IP address and port to uniquely identify them on the server.  I'm wanting to make sure two home computers sharing the same router (and thus same public IP) appear unique due to them each getting a unique public port.
  7. That's what I was afraid of :(   It sounds like I may need a different solution since I cannot express what I need with 4x4 matrices. My other idea involves using render targets for each widget.  Basically I would do the following: Start with the leaf widgets in the hierarchy and render them to a texture.  So in my example I would render the Cancel and OK buttons to their own separate textures.  When captured to a texture they must be positioned so the eye is looking directly at them. The dialog, along with its buttons, must be rendered to a texture. To render the dialog, first transform the buttons relative to it and render them using their render target captured in step #1. If the dialog itself needs to be transformed then apply said transformations to it and its children. This process needs to continue up the hierarchy until your done. This would mean every widget would need its own render target.  This would solve the problem, but I wonder if there is another way.  My experience with render targets is that they are rather slow and there could be many widgets on screen. Another problem is clipping: If the render target is not large enough, then it may not capture part of a really wide/tall widget.  That opens up the possibility of the widget looking cut-off if its positioned somewhere to show a part of it that the render target did not capture.
  8. The first gif of my previous post is already doing exactly as you describe.  I believe I've been incorrectly using the term "vanishing point" which is were the confusion may lie. When a widget renders on screen it needs to appear as though the eye was looking at its dead center.  When the parent transform is applied the perspective needs to be from an eye looking at said parents dead center.  And so on up the hierarchy. Take a look at the following two pictures.  The red line shows the vanishing point (I'm using the correct usage of the term now).  Notice how in the first picture the vanishing points of both buttons meet at the same point.  That not what I want.  I want the behavior in the 2nd screenshot.  Each widget needs to render as if the eye was looking at its dead center. [attachment=36036:vanishing_point.png]   So to be absolutely clear:  When the cancel button has its local transform applied, its pixels should be rendered from the perspective of an eye directly over its center.  The same is true for the OK button.  When the dialog transform is applied to both buttons, its pixels must be rendered from the perspective of an eye at the dead center of the dialog.  This behavior should continue up the hierarchy.
  9. Yup, your exactly right.  The problem is...if I omit step #5 and apply the parents transform, then the button will not have the vanishing point that I need. The gif below shows how the buttons would look if I omit step #5 and apply the parents transform.  Notice how the buttons vanishing point is the dead center of the screen?  That's not what I want.  I want each buttons vanishing point to be their dead center for their local rotation.  The 2nd gif shows how the buttons should look. [attachment=36034:buttons_bad.gif] I can get the correct vanishing point by performing step #5, but then I don't get the parents transform.  That's what the following gif shows: The buttons with the correct perspective / vanishing point, but they do not account for the parents transform at all. [attachment=36035:buttons_good.gif] I need a solution that lets me achieve both: Account for the parents transform and keep the vanishing point at the buttons dead center.  Right now I'm only able to achieve one or the other. So, for clarification, the buttons need a vanishing point at their dead center for their local rotation.  When applying the parent transform, the vanishing point should move to the parents dead center.  And so on up the hierarchy.  The problem is a standard perspective matrix applies the same vanishing point to all geometry.  Its almost like the perspective somehow needs to be intermixed during the model matrix transforms.
  10. I'm trying to create a GUI system inspired by Apples UIView architecture.  For those unfamiliar with it, a "UIView" is Apples version of a widget.  Each widget can be transformed with a 4x4 matrix.  Its transformation effects its children, its children's children, and so on down the hierarchy. The problem I'm running into is a perspective problem: Each widget must transform with a vanishing point located at its center. The following two gifs show what I mean. [table] [tr] [th]Incorrect[/th] [th]Correct[/th] [/tr] [tr] [td]The buttons in this gif use the center of the screen as their vanishing point.[/td] [td]The buttons in this gif use their own center as the vanishing point (this is the expected behavior).[/td] [/tr] [tr] [td][attachment=36013:buttons_bad.gif][/td] [td][attachment=36015:buttons_good.gif][/td] [/tr] [/table] Here is how I'm moving the vanishing point now:Start with an upright button whose vertices are centered around the origin.Apply a rotation matrix to them.Apply a translation matrix to move them forward so they are centered in front of the eye.Apply a perspective matrix to transform them to clipspace.Translate the X,Y clipspace coordinates moving the button to the lower-right corner of the dialog box.The problem with this solution is it doesn't account for the parents transformation.  In my gif examples the dialog box is the parent of the buttons. [table] [tr] [td]The following gif shows the expected behavior of a rotation applied exclusively to the dialog box.[/td] [td]Now imagine the dialog rotating, but this time with the buttons transformed and in the perspective depicted below. That's the behavior I need.[/td] [/tr] [tr] [td][attachment=36014:dialog_good.gif][/td] [td][attachment=36016:rotation.png][/td] [/tr] [/table]
  11. I am fairly certain you can do that by applying the translation of card after the projection matrix. Just insert the projection matrix between step 3 and 4 in your previously "incorrect" list: Start with vertices comprising an upright card centered around the origin. Apply a rotation matrix to rotate the card. Apply a translation matrix moving the card forward so its dead center in front of the eye. Apply projection matrix here. Apply another translation matrix moving the card so its in the lower-right corner of the screen. The amount to translate in step 5 is left as an exercise to the reader (i.e., too lazy to check myself) but I believe it has to be done in normalised device units. That is, a translation of 0.5 would translate the card by half the size of the window (or rather the viewport, but I assume you're not changing the viewport in this approach and the viewport is the full size of the window). That actually works!  I feel so silly for not thinking of this before.  This solution is far better than changing the viewport; not only is it simpler but it avoids viewport clipping issues as well.  Thank you for your help!
  12. I see now what you intend to do. If you consider the view of a single card as its own viewport then what you describe here is precisely what glViewport is for; you define the region of the window where you want the scene (your single card) to be drawn. Thanks Brother Bob that's good to hear.  I apologize for any confusion.  It looks like GL_ARB_viewport_array supports a unique scissor rectangle per viewport so I'm in luck.  I'm planning to use that extension so I can batch render the sprites. I asked about the stencil buffer because I may need card-like transformations for widgets as part of the GUI.  Since parent widgets clip their children I was thinking about using the stencil buffer to make sure children get masked away. I'm still wondering if there is some "matrix transformation magic" that exists as an alternative solution to the problem.  Some kind of ortho/perspective hybrid maybe?  I'd love to hear alternative solutions to this problem.  Thanks again.
  13.   What kind of projection are you using ? Perspective projection.  I'm not using orthogonal projection at all.     Any reasons for this ? Just because you use a perspective to render flat things and you "disable" the perspective transformation. So what left for the perspective ? If you have other models needing perspective, then you can simply render your cards on top of them by using a simple orthogonal projection. Well I just want to know why you use a perspective here, maybe that could help me understand things I currently have no idea yet :) There may be a gap in my knowledge, but I don't know how to 3D transform (in this case, flip) a sprite without the perspective matrix.  Can this be done with an orthogonal matrix?
  14.   What kind of projection are you using ? Perspective projection.  I'm not using orthogonal projection at all. Here is how the "correct" card flip is done: Start with vertices comprising an upright card centered around the origin. Apply a rotation matrix to rotate the card. Apply a translation matrix moving the card forward so its dead center in front of the eye. Before rendering, use glViewport to translate the card anywhere on screen. Here is how the "incorrect" card flip is done (step #4 is the only step that's different): Start with vertices comprising an upright card centered around the origin. Apply a rotation matrix to rotate the card. Apply a translation matrix moving the card forward so its dead center in front of the eye. Apply another translation matrix moving the card so its in the lower-right corner of the screen.
  15. Good to hear. Just as I thought. I'm not flipping the card using the viewport, I'm flipping it using a rotation matrix.  The purpose of changing the viewports x,y parameters is to translate the card.  I could use a translation matrix to translate the card, but then its perspective would not be its dead center. Observe the following gif.  The bottom card shows the incorrect behavior and the top card shows the correct behavior.  Both cards use a rotation matrix to flip them.  The difference is in how they are translated.  The bottom card uses a translation matrix to put the card in the lower-right corner of the screen.  The top card renders the card at the dead center of the screen and then uses the viewport to put it in the right place.  The latter ensures that the eye is dead center on the card when the rotation is performed thus it looks correct regardless of its final screen position. [attachment=35974:card.gif]     Thanks for the reply.  I typed out my recent post before seeing yours.  Could you elaborate more on this?