• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

124 Neutral

About AlabamaCajun

  • Rank
  1. Opinions on processors

    Unless you are going for a quad, I would go with the Regor 250 at 3.0G and 2x1M cache. http://www.newegg.com/Product/Product.aspx?Item=N82E16819103681 Those big 1meg caches vs the 512K in all the Phenom line amounts to a nice boost to what we do. Compile, Game, rip etc.
  2. Artificial Neural Networks

    Table driven state engines probably still provide the best bang for the buck. Most Neural Networks or just adaptive approximation trees. Neurons and the networks of axons and dendrites in a brain can only be simulated to a tiny fraction of the biological systems capacity to reason. In most cases a lot of processing time is eaten up attempting to calculate synapse threshold potentials. Factor in attempts to build the cerebral reflector clusters and you end up with huge amounts of code that eat up tones of processing time. I don't want to discourage development of neural algorithms because there is a lot to be learned about it. Here is one thought that will put the brain into perspective. "Tip of the tongue". I know it but I just can't quite remember it. Only in a brain can this anomaly occur. Reason is the highly associative nature of the cerebral cortex allows this to happen. A single though is not just a few synapses causing a few neurons to fire into axons triggering a response. I actually involves millions of neurons firing sequences of pulses in a collective manor that allows the thought to come into play. Micro processors just don't have the capability to make it work in todays instruction sets. For us in games it can evoke great ideas of how to mimic these actions and potentially start using multicore processors to our advantage.
  3. Qt for Making Games?

    From experiance I would go with SFML and other libraries. A theme park project used QT and very few people can build the project. On the Highrise developer project we used SFML and CEQUI for dialogs. Once we got the works in place we just got down to writing game material. Took no one more than 15 mins after checking out the source to having a built project. The Mac version may have been a few minutes longer to build a new Xproj project. One what BrainyDextor said, I agree keep the libraries under wraps so you can swap them out later. Same for QT, it you decide to use it, use standard libraries for your core and only expose the UI layer to QT (or any libraries).
  4. Game programming and raytracing

    There are multiple uses for RT. Use it full force to create realistic backdrops to replace far rendering. Use ray casting where only samples are traced to locate light source, objects and reflections real-time to use in normal polygon rendering, lighting, shadows and reflection. As for full blown realtime, we will have to wait a little longer for that kind of procssing power. My current ray tracer first used on the Amiga in 1988 ran in a little over 20 seconds to render 3 reflective spheres and a tile floor at 320x200. It now runs in a little over 1 sec with 2 cores at 1024x1280. This is simple sphere collision with recursion pegged at 3 to eliminate wasted time bouncing between the spheres.
  5. The posts about using refs where you have to have valid pointer and pointers for the possiblity of null is a correct answer. You can choose to be as flexible as you want but try to stay with a rule or style to avoid confusion. Ask the question, is it an abstract collection or concrete instances. I use refs when passing a helper or adaptor class to a new class instance or function. I use Pointers when working with collections or where the object is not always instantiated.
  6. GoTo: is it really evil?

    "I find the G-word offensive in programming, Is there a filter to block me from see it!" To me, using them in programming is akin to running RingSeal oil in a race car engine. Using a chainsaw to cut studs to build a house. A doctor using an xato knife to do surgery. ... Jumps and branches are used in assembler as that is the way asm code works. Why the G-word has not been depricated from C and Cobol is beyond me. In 25 years I've not used one in either of those languages. I have been forced to used the wretched things in VB6 for on error blocks but thanks to DotNet i'm ripping them out this month and using real try blocks. Later we will port that code to CSharp.
  7. Global pointers to objects?

    A global pointer is a pointer declared outside a structure, class or function. CPlayer *pPlayerA; CPlayer *GetMainPlayer() { return pPlayerA; } struct Legion { CPlayer *pPlayerB; ... }; void foo( void ) { pPlayer *pPlayerC = GetMainPlayer(); ... } Player A is the only global pointer in this exe or dll. Player B is in a structure and would have to be referenced through an instance of Legion. Player C is in a function and would only referenced in foo and valid until foo exited. GetMainPlayer is a function wrapper where is allows you access to PlayerA by returning a pointer to Player A. Example of a wrapper on CodeProject. http://www.codeproject.com/cpp/Functor.asp?print=true Search for more information "wrapper pointer C++".
  8. I finally found my March issue to read this artical. It brought back bad memories and sparked imagination into improving functionality implementation. First the bad: I once worked with about 40 developers on a project that was an aggregated properties based system built on a set out about 235 specialized objects types. While the project succeded in programmer expectation it failed to meet it's operational objective. The code was a mass of blobs with multiple dynamic aggregate property collections. Functionality was implemented right into the Inheritance. Execution would take over an hour to achieve it's task where the program(s) it replaced took about 5 mins. To be fair, about half of the time wasted was spent in poorly written code for what was the "physics" engine of the app. A major amount of time was spent in the data set querying the properties. Could the same thing happen to a lot of projects should functionality implementation now be aggregated? The author does the right thing of metioning a migration path which allows you to move over with encapsulated sections to be able to work out problems avoid the doom of a failed project. IMO, One of the aspects realized by the project is that code got refactored by necessity during transition in order accept the new methodology. Cross "pollenating" pointers to brige to functionality sounds like an area for improvement. Not to bash the author but I've spent decades trying to convince progammers not to use GOTOs (another four letter word) in new code. The "physics" engine I mentioned earlier was infested with a massive amount of pointers. The point is, map out what objects are doing to avoid having to pass addresses all over the place. If one point gets mangled and passed along then trying to debug may be a nightmare when the knight passes the sword to the alien BSODs your workstation. Now the good: Building componants bases on lightweight objects with some aggregation of functionaliy can be the winning approach. What I'm proposing is breaking up the objects into smaller functional pieces. The tree would grow a little but the lightweight objects are specialized to a particular function(s). Just for thought and discussion: Take the basic bowmans arrow, I'll trace it's cycle. The componant manager produces the arrow in the fletchers hut(Class Factory). The arrow is the some of a few parts (Feather, shaft and blade). These could be just part of the CArrow object or aggregated parts depending on what you want from it. The arrow gets basic fuctionality, render, position etc. Launch and flight functionality I would assume are added then the archer uses it. When it lands flight is taken away and damage is added. The archer could also add fire to the tip (another function) before letting the arrow fly. Using this same arrow object let's say we send a couple of surfs out to dig man traps (pits). They collect spent arrows from the battlefield and shove them into the bottom of the pit business side up. Or componet manager now has the duty of adding the impale function to these arrows. Owwch! While this is wild bunny chase, it covers a lifecycle of a simple object. How we implement this into the component model is the question. I will be looking into this and more for how not to create overhead and extra pointers.
  9. 1) Assuming a base class of your objects has a SustainDamge( float fForce ) method and a float GetDamage() method then a simple call should to these publics would give you the access. Each object maintains it's damage matrix or level. This puts the object in the position of updating the vertex matrix to alter the rendering or change the texture tiling. 2) The simplest methed is to factory load them to the manager but you may find it necessary to sort them in some cases. The manager in my previous reply is the parent object. At some point a topmost parent would be managed by a scene segment or animated object. The best way to work this out is take one of your simple empty world scenes and add the truck with wheels. Build the objects and implement the functions. This will get you on the path to building the tree. Once you work out methods to move the truck object around the scene you can clone and produce more trucks with this model with added colors and textures etc. reusing this one truck class. Now assuming the flying object and running collision detection you get to the scene segment of the truck. When you call getNextObject() returns a pObject. Using pObject you call gets for collision detection and strike pObject then just call pObject->SustainDamage( DamageAmount ). At this point the projectile is not concerned what it hit but pObject knows it's been hit and responds. I can get tricky if the truck is moved by force from one scene segment to another. In that case it would have to be removed from one segement and added to another. It's also good to get the address of the parent should the child have to call the parent. I realize this is mid to high level but it's a lot of code at the lower level to discuss. To simplify things at first, you may want to use a single global manager to hold the scene and main object list to get started. Later you will have to start being concerned with LOD, multiple scenes, and dealing with child passing and collateral damage (objects impacting other objects.
  10. Quote:Original post by snk_kid Right it's easy to get carried away by the hype and become a little ignorant without realizing it, i think just about everyone is a crime of it from time to time. Whats funny is that the functional paradigm isn't new, it's older than both structured and OO paradigms and OOP was probably being done in one of the daddy functional languages i.e lisp before anyone knew what OOP was or made it an explicit paradigm/practice. Absolutly right :thup: (thumps up). I can definitelty rememeber working in assembler with a intel 8085 processor and Z80 Disk controller where both needed to run parallel. OSs not do this although it's more of task switching act than a single programme! Interesting thought pops into mind: With micro controllers a sort of component functionality is being implimented. Each controller is programmed as a Functor and has a specialized purpose with any number of sensors and/or output responsed. It's also a study on neural netting where the conrollers are both parallel and interconnected. This enforces strict class obedience since one controller can't get to the other controllers privates:blush:
  11. [Quote] by snk_kid] ~ Actually the future is more likely in hybrid functional languages ~ Point well taken on the matter of going foward with programming techology. I think we tend to attempt to solve problems with time tested principles and forget that newer methodologies could better solve the problem. As for acedemia when I colleged in the early 80s RPG and Cobol were the staples in business principles. One procedural and the other event driven. Mentors kept us from using gotos and enforced structured programming. I do agree that the hybid languages will better serve as RAD tools, I have strong beliefs that OO will handle parallel just as easy. It's all in how the model is developed. Attempting to reach equlibrium with core usage will be the challange. We already use objects to run the shader(s) and the principal proves itself. I do realize that shaders are nothing more than Functors which are objects that are defined by their properties and a single method. OO is not just a class but a discipline of logical thinking and realworld modeling.
  12. You will assume the DOFs are all part of a higher DOF. Basically collections to the parent. If every object in the tree is a collection of aggregates(inherited from a common base class). All parts added to each objects collection become that objects child. This is where UML shines by allowing you to define relationships, collections, actors, entities etc. The base clase should also have an overable pure virtual function to identify the object via two methods. One static and one dynamic. The static defines the concrete form of the class such as Wheel. The dynamic one is the dynamic property such as "Truck Wheel", "Bicycle Wheel". From these methods the classes can be persisted with the named parent to rebuild the tree on load. You may want to store movable objects as loose collections with the position and state of the object. Store the world and it's objects states in another. This avoids unnecessary complexity of the storage model. Your truck justs owns four wheels, if it looses one then one is removed from the list and cardinality reduces to 3. By calling Truck->AddWheel( pWheel) the parent will call Identify() for that wheel and if it is not a truck wheel then reject it else add it to it's tree. It's up to the parent node to call it's children to render, evolve, rotate, update state, force state etc. Remember the tree is a dynamic entity. Where each child is a branch with children unless it is a leaf node. This is why you have to know what the child is for when you persist the tree are need to query the objects for specific objects. A query may occur then the game requires confiscation such as take away all the matches or check all wheels for grease. This subject gets more involved with all the available patterns which takes time to learn and master.
  13. Not to thread rip but I just wanted to pass along some ideas of how to refactor code for faster compile and run. I changed tolerance to const in the example but if you intend to adjust it during gameplay then it would be a non-const member var. void SpaceObject::TurnToPos(const D3DXVECTOR3 &dPos) { const int tolerance = 0.001; //turning tolerance | const is initialized at compile time. //Get the global difference coordinates D3DXVECTOR3 r( dPos - pos ); // instanciate vs assign. D3DXVECTOR3 u; //Convert the global coordinates to local coordinates u.x = r.x*cos(-rotation)+r.y*sin(-rotation); u.y = -r.x*sin(-rotation)+r.y*cos(-rotation); u.z = 0; //never a z-component //Normalize the local coordinates D3DXVec3Normalize(&u,&u); //If x is negative move to the left //If x is positive move to the right int dir = (u.x < -tolerance) ? -1 : 1; // declare and assign in one line //Turn the ship Rotate(dir); } Note variable declaration in the middle of a function is the same to the compiler and early declaration. It only affects scope as the stack space is reserved with the function and held until the function exits. These techniques also reduce optimization cycles by reducing the amount of instance tracking that the optmizer has to look at.
  14. Great to see this kind of discussion finally happening. I'm noob on this board but have been in the software business for 20+ years. OO took too long to catch on in the real world. We started with structured programming in the 80s until C/C++ took hold in the 90s but top-down was still being taught in the schools. We talked about parallel arch in the 90s before multicores became a pipe dream and finally reality last year. Adopting OOD and OOP principals is the key to going to parallel arch and multicore. Component basing should improve the organization of objects forcing tighter rules and looser object coupling. Too often as some of you have said, getting Is-a'ed out forces programming to tightly couple class building to rigid forms and robs attention from techniques such as mix-ins and more generic classing. Patterns have evolved to address a path to object hormony resolving most of the issues of dealing with what-is and what-has and how implementation should play in. Looking at the facets example, you can see that collections play more of a role than inheritance.Beeing able to assemble a collection of objects that work in unison is the key to succesfull object interaction. Like a shop full of tools, a bandsaw is not the only tool as inheritance is not the only method of class construction. Inheritance, Is-a and Has-a is important to maintaining object purity. If you later find a Is-a/Has-a violation then refactoring a well developed set of objects should not be difficult. Refactoring from procedural to OO is the nightmare :eek:. Take the bullet example: The bullet is not velocity but has velocity once fired until is encounters flesh, wall or ground then it "is" shrapnel. (Ok that ended in a morph). Being able to provide the physics without a tight couple is-s relation is the key since this object can do many things and morph into a differnt object in the end and be used again. CBullet is fired from a gun, has velocity for 2 seconds and strikes a brick in a wall. It shrooms into the brick, breaks in two and half falls to the ground. Bird sees the fellen shrapnel and takes it way. A once pure class has been striped back to abstract, reformed as two objects and now has pieces of CBrick attached. Also CBird has a piece of the action now also. I can see a lot of use for components in the future of development since we already use them with current 3rd party products. I currently use components to seperate the object collections(world and stuff) from physics and rendering. Using Visitor and Adaptor patterns I have enough flexibility to allow using these same engines elsewhere. This thread hits on the next step of my componentizing effort. I have started collections of objects that I intend to integrate into the main mesh of the world and define these components by their physical makeup. Take the woodcutters shed used in a lot of games. If it gets trashed it becomes scenic material and you can't reuse it. If the shed were a composite made of other objects, boards then you could reuses parts. Say the shed is razed and the enemy is killed. Provided they did not torch it the boards should be still there. A couple of surfs could take theboards back to the stockpile and reused. This does require more work and billboarding this in LOD gets difficult but it's possible. "Long live OO"
  15. Building a SimTower / Yoot Tower Clone

    I saw this project from a Google Search and signed up here just to be a part of it. I considered doing this project being a Sim fan for 15 years. Outline of the approach I would take: -------------------------------------- CRealEstate Collection (your buildings). Base Class CBuilding to derive Tower, Homes, Shopping malls etc from. Class CTower ...CFloor collection ......Has collections of Tennants and properties defining usable space, usage (considering sky lobbies etc). ...CElevator collection ......Has poperties defining size, texture, load, speed, schedules etc. ...CTennant has Occupants, Contents, space rented, lease price, color, texture, type etc. ...CServices, security, janitorial, etc. -------------------------------------- Consider the visitor pattern approach to collect rent, animate occupants, time management etc. A visitor only knows it's own business and what the host class provides is a loose coupling with functionality. A visitor enters the class through a provided virtual function that the class can choose to override or leave as default. Example: CRentCollector as a visitor will call .PayRent() once a month to all floor tennants. An office class would override the .PayRent() function to pay whereas the SkyLobby would not. This way only floors space that us actually rented will see the RentCollector. Using Anonamous's approch to define properties create a resource file to set what object properties are available. At some point you have to limit abstract and require concrete parameters. The open format just makes it much more expandable. These are just some ideas, feedback is appreciated even if you don't aggree.
  • Advertisement