Jump to content
  • Advertisement

TayZrain

Member
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

122 Neutral

About TayZrain

  • Rank
    Newbie
  1. TayZrain

    Fast hittest w/ Python & OpenGL

    despite my lack of background with this aspect of graphical programing, I would think a BSP Tree Quad Tree or Oct Tree would help considerably with this. By dividing the information into nodes layed out according to region, you can brake down an x^n operation by ruling out data residing outside of the sub region your testing within. that is to say, we can take the click location and figure out that it only resides within one node, so we only need to test data within that node.
  2. I am having an issue with my shaders where world space, object space, and tangent space is getting lost in the shuffle. I transplanted most of the stuff I'm working with from various sources, in fact ALOT of sources, so needless to say duck tape bubble gum and a lot of reworking went into getting them to mesh up, so this was expected and I'm now going back and cleaning things up, however I think a reworking is in order. my question is this, is there a good way/practice of standardizing a shader such that world space, object space, bone space, tangent space all lay out in sync. further more what level of organization go's into this at an application level, since at present I pass almost all my matrix's to the shader. at present the engine I have built from the ground up deals with models by loading them into an object issuing an handle that stores there world orientation and various other data. a game entity then requests a link to that handle and keeps it for its own use. The entity in fact loads the models information upon requesting the handle (and yes it handles redundant meshes just fine), The issue however is when I get down into things at the HLSL level. Ive been having the full gamut of issues where lighting will rotate with the object, the eyes world position wont rotate/translate correctly with the models position...in another words its a bit of a clusterf**k as far as how the math is handled. The effects are stored in its own object witch registers itself with a list and pass's its pointer to the model object, in case any one was wondering how that was handled. so again, how would you layout a system to achieve this (and I'm I thinking about this correctly)... - Translate/Rotate Object into world space and then clip space Then take the world space data as from the perspective of object space from there I need to, - rotate vertex's to correct bone space, and do the same to texture space from there.... - Rotate world space to bone space to texture space. From there I would write a pixel shader that deals with these vertex inputs... Texture space light direction Texture space eye position. Texture space normal. thats all well and good and working.
  3. I am still reading this post, and I have no background with multi thread programing. but I can say this much. the talk about synchronizing multi thread operations sounds a little bit silly to me when you consider the principle of multi thread programing. We program games to work like scripted plays, or planed dances. everything happens in order and data is handled one at a time, an operations stack is build and then resolved. The result is that two workers can not make one job go faster. However, when we stop treating the game as a scripted event and more like a physical world, we can consider the possibility of letting one core handle the graphical interpretations of what the game has stored in memory, while letting another core handle the act of ruining that world. The result is binding the games functionality to the memory fields.
  4. TayZrain

    RTS object-oriented problem

    Quote:Original post by gamecoder86 Quote:Original post by Kylotan In games I have always had 2 parallel types of data in this situation, one for types, one for instances. Typically many instances will share a reference to their type. Thanks a lot all. The flyweight pattern sounds like something that would be a great help. I think I'm going to go with what Kylotan said with having two parallel types: one type for each of the actual objects on the map and then another type that stores all their shared properties and data. If my understanding is right this is pretty much the basic idea of the flyweight pattern. Yea, the key to repetitive graphical reuse is knowing whats different in a system and what remains the same across all instances of seed object. so if rotation, position, scaling are the only things different between say 4 trees, don't even bother loading the other information more then once. best way to split this is to have a class or even structure deadicated to position and orientation, and have it link to a graphical structure or class that handels the actual graphical data.
  5. most common model to the hole physics conundrum is this. "Why do the same math twice, and why do the same math for people who dont care" the only thing the client needs to know is where something is, not how It got there. however at the same rate, the last thing the server needs to be doing is trying to figure out how something happened as well. so a split system is not uncommon where the server just keeps track of where things are, and the clients decide where to put them, a parent child system usually pops up where this logic is taken on. simply put a player is married to the physics that effects his actions and his player. his client dose all HIS collision detection, while the server handles all world entity's. in other words the client broadcasts his position and his actions, while the server just keeps track, then when something happens that requires the attention of all clients involved (big explosions for example) the server handles the physics. again the idea is to avoid redundant math at the server level. another approach is to leave all the physics to the clients, and the server just relays all the events, and lets the clients handle the math. this can cause bottle necks with items such as grenades and the like, as its no one systems entity to control however the server needs to be posted with its position and direction and what not, as such you have 5 clients sending the server redundant information, thus a parent child setup is some times adapted, but this is week to client side lag.
  6. I would like some thoughts on this, as its a project I'm considering. I have been toying with the idea of starting an Open Source open access game engine that is angled at professional level use, yet with the strength of an open source community to back it up. theres a heap of issues that arise with an idea like this, but a whole world of possibility opened up as a result. as of now the best games on the market are all privately developed closed source projects who all have there own methods to implementing there content. groups such as EPIC sell there technology to smaller game developers to produce there own games. while these games are top notch cutting edge solid works of entertainment, we cannot help but notice that every one is trying to reinvent the wheel, when in fact the industry would rather work on whats inside the cart, that the wheel is attached to. I once Heard a ruff statistic stating that almost 2/3ds of all web servers are powered by Apache web server, an open source project that produced amazing stability and favorable operating platform for customization and solid security. its highly bug resilient and constantly getting updated and fixed by hundreds of programmers tracking down bugs and issues that relate to there applications and then passing off the information to better help the community. Where I am going with this is simple, why should 3d gaming suffer at the hands of cathedral style development and be held at the mercy of the private developers when the ability to construct the strongest tool is in the hands of the public. I don't pretend to be or am ignorant to the fact that there are many open source projects. http://irrlicht.sourceforge.net/ and http://www.ogre3d.org/ being the primary two hits on Google when you search the subject mater. however theres a commonality with both these software packages, crippling complexity, and limited applications in regards to the implantation of content. Game engines are complex! however game developers like to keep life simple, so when the source code that controls what you see is so complicated it just about blows the mind of a GAME programmer, your going to see little in the way of progress for packages like this. the truth is, game developers like to stick to the half-life 1 SDK model of moding, "Give me a working world, with full control of its user/entity mechanics, and a solid base of file formats to work with". and for the most part Open source projects do there best to cater to this need. HOWEVER Whats is needed is a dedicated project who's goal is to make a tool who covers both the development side and the end user side. where building a game is as easy as building a map, making some models, and setting some game rules. An almost "Industry standard", at present Direct X is doing just that, taking care of all the hard stuff and letting game programmers get back to what they do best, making games. the next logical step is an truly open game development community that works with the same tools and helps advance each other. GameDev.net is such a PLACE, but what about the solid stuff, the real CODE, they say the prof is in the pudding, well wheres the next Halo/Gears of War/GTAIV/Crysis gonna be on? a privately developed engine? or a publicly available open source core level engine? - Complications - In this multi player world of FPS's MMO's and the like, game integrity is a must, and open source counters that very concept. however theres a difference between a brick and a building, and that is architecture. a open project like this could require projects using its software to publish any technology updates, while letting them keep there creative property private. further more this works as a two way street as if an issue arises that needs public addressing, the team can always publish a mini project that includes what would be needed to test the bug and the necessary code to let the eyes of the public solve the problem without "giving away" the game itself. theres again piles of problems that can arise by having this type of code public for cathedral style game development, but in the end I feel the advantages to something like this is astronomical. again we wouldn't have games like counter-strike if valve didn't make the actual game DLL an open source offering.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!