kosmon_x

Members
  • Content count

    197
  • Joined

  • Last visited

Community Reputation

205 Neutral

About kosmon_x

  • Rank
    Member
  1. Knight of the Living Dead: XNA game

    Awesome! Are you guys going to add multiplayer support?
  2. Special-Chess AI

    Quote:Original post by alvaro I should mention that a lot of the top chess programs don't use a bitboard representation. The algorithms you use are way more important than the board representation. If you don't want to loop through a lot of empty squares trying to find your pieces when you are generating moves, keep a list of pieces. Most state-of-the-art chess AI now uses bitboards, and if they don't, they should ;) It's simply more efficient. Harder to read and debug? Yes... but a much more efficient use of pipelining/caching/registers. Just a more efficient use of computer architecture overall. Several years ago they weren't as widely used, but that is largely untrue today with 64 bit machines. Quote:Original post by alvaro The algorithms you use are way more important than the board representation. I disagree - I think they are both vitally important. If I'm using an array[][] and I have to do a multiply + add to access any position and I'm doing lots of for loops with conditional branches, I'm going to get much less done than someone else using a bitboard who can execute multiple queries simultaneously thanks to pipelining. Quote:Original post by alvaro If you don't want to loop through a lot of empty squares trying to find your pieces when you are generating moves, keep a list of pieces. Bitboards are used precisely because there is no looping to find where pieces are, where collisions are, etc. They are highly optimized for generating moves, far more efficient than the offset method. Here are some interesting papers by Bob Hyatt (Crafty) http://www.cis.uab.edu/hyatt/boardrep.html http://www.cis.uab.edu/hyatt/pubs.html The articles were written a few years ago before 64 bit machines were widely available, so the preference for bitboards has increased even more since then. As for the Op post... I don't know. A simple array will probably do the job. Bitboards are so convenient for 'regular' chess because a 64-bit unsigned integer perfectly accommodates an 8x8 chessboard. If you are doing 22x22 or something odd like that, it's probably more work than its worth to use a more complex bitboard setup (unless this is a very hardcore project). It's complex enough for an 8x8 chessboard... EDIT: Also, Sjeng does use bitboards... as of 5 years ago. I also would not be surprised if REBEL doesn't use them since it stopped being developed in 2004. [Edited by - kosmon_x on April 30, 2007 6:23:00 PM]
  3. [java] Is Java Dead on Internet ?

    Runescape uses Java, and as far as I know they have one of the largest player bases of any MMO right now (9 million active free players and 850,000 active paying players - from wikipedia). I'm not sure if it's Java Webstart, an Applet, or both. It does run directly in the browser, however it also asks for permission to run (signed app), therefore it does not run in the basic applet sandbox.
  4. Generating Area in Space

    Quote:Original post by Dasubermechen Agony, Your first part helps answers my question rather well, but the next two parts add a new level of confusion. But this is why im a designer and not a programer haha. Could you explain further, I dont quite understand why distance would complicate things so much, expecaly if it is blank. Also if you could, what would be the largest area of space you could harness, if you could give me an example or referance (e.g. the entior diameter of our solar system or no bigger than a bread box)? This might be difficult to understand if you aren't a programmer. Basically, you don't store space. You store objects that reside in space. All game worlds are 'infinite.' Now lets say you add an object, a town. The town's center resides at location 0,0,0 within this infinite space of your game. Let's pretend the town stretches out 100 units in every direction. The 'space' of your game is still infinite, but now you have an object at location 0,0,0. Now, to further the simulation, the player is restricted to moving only within 100 units from location 0,0,0 -- ie, he can't go outside of the town. To the player, your game world is small -- they can walk around the inside of town but can't leave it. To the programmer, the game world is still infinite. If the programmer wanted to, they could add a 'planet object' at location 5000,5000,5000. Now your game data has two objects, one at location 0,0,0, and one at 5000,5000,5000. The 'space' is just a coordinate system -- you don't store a coordinate system. All you store are objects within that coordinate system. Your game is defined by the data -- the game objects -- located in relation to the coordinate system. Agony is saying that you can run into problems if you have game objects that are oriented very far away from one another in this coordinate system.
  5. AMD Athlon XP running at 2.1 ghz 1024MB DDR RAM 256MB Sapphire ATI 9800 Pro Soundblaster Live! 5.1 Windows XP Home SP1
  6. Fog Question

    I'm having the opposite problem with my fog... If I specify the start/end from the range 0.0f - 1.0f, it works, but I get terrible resolution (if I want it out in the distance, I have to do start: 0.99f, end: 1.0f... I don't get much control over it). When I try to enter the start/end in world coordinates, I simply get no fog at all. Does anyone know how to get the world coordinate fog working? I've tried literally everything =\ My perspective matrix IS Eye-W compliant (or whatever) as I'm using the D3DX function to generate it. Are there some presentation parameters or SOMETHING that I could be missing? Here's the code I'm using: pd3dDevice->SetRenderState( D3DRS_FOGTABLEMODE, D3DFOG_LINEAR ); pd3dDevice->SetRenderState( D3DRS_FOGSTART, FtoDW( 0.99f ) ); pd3dDevice->SetRenderState( D3DRS_FOGEND, FtoDW( 1.0f ) ); pd3dDevice->SetRenderState( D3DRS_FOGENABLE, true ); Thanks
  7. Billboarding and Euler Angles!

    Thanks for the link to that thread -- I was able to get it working based on what you posted :) Thanks again!
  8. Hey guys -- this one has me a bit stumped: I'm trying to calculate the set of Euler angles needed to rotate vector V0 so that it's orientation is identical to vector V1. In other words, I'm trying to make a billboard! (If I can figure out the rotations needed to make the billboard normal equal to the vector pointing to the camera's position, I'm set) Is this a simple problem to solve? I can't seem to figure it out! It seems like I'll run into divide by zero cases when V0 and V1 are orthogonal... Any help would be appreciated!
  9. Bump. Anyone been able to get pixel fog working using world coordinates?
  10. I'm having a bit of trouble getting the fixed function pipeline fog to work correctly.. I heard that you can specify the linear fog start/end using world coordinates, however I have been unable to do this! right now my fog code looks like: pd3dDevice->SetRenderState( D3DRS_FOGCOLOR, D3DXCOLOR( 1.0f, 1.0f, 1.0f, 1.0f ) ); pd3dDevice->SetRenderState( D3DRS_FOGTABLEMODE, D3DFOG_LINEAR ); pd3dDevice->SetRenderState( D3DRS_FOGSTART, FtoDW( 0.99f ) ); pd3dDevice->SetRenderState( D3DRS_FOGEND, FtoDW( 1.0f ) ); pd3dDevice->SetRenderState( D3DRS_FOGENABLE, true ); So I have to specify 0.99 - 1.0f to get the fog to appear off in the distance. This doesn't give much control at all and forces me to move the near plane further away to get any sort of far away fog. What I want to do is specify the start/end in world coordinates, but it isn't working! My projection matrix SHOULD be Eye-W compliant (or whatever) as I'm using D3DXMatrixPerspectiveFovLH() to generate it... Has anyone been able to get their linear fog to work using world coordinates? Any thoughts on what I could be doing wrong? [Edited by - kosmon_x on September 2, 2005 7:06:38 PM]
  11. Quote:Original post by WolfZen After many failed attempts on creating games with other programmers, it seems the best way to get anything done is to do it yourself. (when you don't have a budget) So anyway, here is the request. I need a short project idea which is of appropriate scope for one person to do all of the needed programming in a 2-4 month time period as a solo developer. I will be putting about 15-20 hours per week into this project. I will most likely be using free models/artwork. I have 5 years of c/c++ experience and quite a bit of experience with opengl, although I don't have a huge amount of experience game developing. I have made a few 2D games, and would like to move into the realm of 3D, if it is feasible. If anyone has some idea of what would possibly be a good, "completable"(coding wise) project in my time frame, it would be appreciated. ===== WARNING: long post (sorry) ===== Ok, I'm going to give you my personal opinion on how to approach this. You say you're trying to move into the realm of 3D -- well, this isn't such a menial task. There is a lot of trivial (and even more non-trivial) learning that will need to be done. As I've come to learn through experience, working on a game while learning all of the concepts needed for the game lengthens the timeline tremendously. It usually ends up in a cancellation of the project due to many new insights gained while learning, coming to a realization that I had been approaching the entire project incorrectly, or realizing that I had a better idea of what I could / couldn't do, and generally just wasting much more time than necessary. In other words, if you plan on a 2-4 month 3D project and have no 3D experience, it's going to end up taking a lot longer than 2-4 months. Instead, why not try this: Learn 3D programming using an incremental approach and then put it all together into a game project at the end -- it will go *much* faster / easier this way. Allow me to explain with an example: Come up with a -very- rough (and easy) game concept of something that you would eventually like to make. The tech specs should be kept to a minimum since you are just starting to learn 3D. Something ambitious might sound like this: a flight-combat sim where the user can control a spaceship/aircraft and fly over some terrain while shooting a few different weapons (maybe against AI opponents, maybe not). Ok so now figure out what techniques and skills you are going to need to complete this project. First, you're going to need to learn the basics of 3D such as basic vector / matrix math, coordinate space transformations (model to world to view to projection to screen space, etc). A camera will be needed to look around the world, so learning how a simple camera works is in order. You'll also need to load the spaceship / missile models (using static models will help since animation is a more advanced topic). So, loading and texturing models is on the list. You'll need to be able to generate some terrain, possibly from a heightmap. You'll need to be able to texture that terrain, maybe with texture splatting, maybe not. Some sort of sky will be needed, so you'll need to look into skyboxes or the slightly more advanced sky domes / sky planes. You'll also need some very simple physics and collision detection for the spaceship and missiles. You might also want a simple particle system to spew some fire / smoke particles from the missiles. Maybe you want some spacial partitioning in the form of a quad tree, maybe you don't -- you can always decide to learn it later on if you feel comfortable with the material. And finally, if you are up for it, you will need to learn some basic AI to get a few enemy ships flying around. So now you have a pretty good understanding of what you're going to need to know to complete the project. The next step is to go out and learn it! Create small projects in which you fully explore each aspect of one of those requirements. Create a project in which you do nothing but load a mesh and texture it. Modify that same project so that you can move around the mesh using a camera. Then, start a completely new project in which you learn how to load a heightmap from a file and generate some terrain from it. Paste in or re-write your camera code so you can fly around the terrain. Start a new project in which you create a functioning particle engine. You get the idea -- the point is to create small projects that fully explore each topic. After you have learned all of the techniques that you'll need to create the game, you'll find that you've also learned -much- more about how to approach coding the actual game itself. Data structures and code organization will become much clearer as you will have a much better grasp of what you will be working with. After you complete the projects, coding the game will be a breeze. You can transfer code directly out of your previous projects and into the appropriate sections of your game (cleaning up the code, of course ;) Starting 3D from scratch (and possibly with a good book), I think that you could get through all of the above topics in 2-3 months. Putting it all together into a game might take you 1 month. Of course, it's just an example, and a less ambitious first 3D project will go by much faster. Imagine a 3D tetris game -- you will need the 3D math primer (vectors, coordinate spaces, etc), loading / texturing models (bricks), display some text (the score), maybe a camera to give different angles of the game, and maybe that's it. It's really up to you. Anyway, sorry for the long post -- it is basically my methodology for approaching new topics and thus far I have found it extremely useful. The best part is, you decide when to stop learning new material and when to start putting it together into a game. If you feel that after loading some models and creating a camera that you want to make a game with it, you can. If you want to go on to learn one more shadowing technique, that's fine too. But once you dive head-first and under-prepared into a game project, it's much harder to make these decisions and a lot more time and effort will be wasted in the process!
  12. Hey, Ok, so I've created a quadtree and have split up my terrain into chunks which are each then assigned to a unique leaf node in the quadtree. Each chunk is simply a unique set of indices that operate on the same full set of vertices. Now, I want to make the terrain "looping," so that if the player moves off the edge of the terrain, he will pop back to the other side. I can change his position accordingly, this is no problem. However, as the player approaches the edge of the terrain, they see the 'edge of the world' right up until they are popped back to the other side -- not a very convincing illusion. So, I need some way to detect that the viewing frustum is viewing off past the edge of the terrain, and render the appropriate amount of nodes from the other side of the terrain to fill it up. Maybe these pictures will clarify a little: In the image to the left, you can see that as the player approaches the left side of the terrain, most of his viewing frustum is seeing nothing -- the player sees the edge of the world. In the image to the right, nodes 3 and 4 are drawn again infront of the player to give the illusion of looping terrain. Once the player hits the edge of the "actual" nodes, they will seamlessly pop back to the other side. So, my problem: I'm unsure of a clean algorithm to do this, or if this is even the best way... Has anyone ever attempted something like this? Is there a good way to organize my quadtree-scene graph to set something like this up?
  13. Height Map from Mesh

    double post