Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

150 Neutral

About JHL

  • Rank
  1. JHL

    Bomb Squad Thwarts Aqua Teen Hunger Force

    Only an idiot would think these pieces of cardboard with lights on them were bombs. I sure that the cops could tell that from 30 feet away but once the idiots in charge and the ignorant media get started they refuse to admit their wrong. The worse thing is adult swim applogised they didn't do anything wrong. They should have went with a tackful defense of their actions. I'm sure the guy who got arrested will be less ready to submit once his lawyers get involved. Hopefully there will be come cosmic vengence now and the ATHF movie will be a block buster.
  2. I'm certain that the clip planes are post divide at least on my computer. orignally I assumed they had to be before that at first too to make sense. But I ran tests like with planes like (-1,0,0,D) where D grandually changed from 0.0 to 1.0 and half the screen gradually was cut off. I hope its not some kind of difference in hardware implimentations cause that makes these even less usefull. I have a geforce 6200.
  3. That doesn't make any sense to me the perspective divide squeezes things farther away closer together meaning that plane curves towards the clip space origin as it gets farther away from the origin in clip space.
  4. The z buffer trick would have worked for some of what I wanted to do but not all of it. The my land scape is very dynamic I have parts of the water 'grid' this is not visable but can't be easly not rendered so I wanted to sink them below the visible water level and then clip them off with a clip plane. I also found that dx plane tranform function but with out knowing what it did it didn't help me any I use a custom math library. Mathematicly a world space plane doesn't equal a plane in clip space. That said though I've some how managed to make them work, at least so far. I'm using them to clip the reflections and the scene below the water (which I also render to texture) as well as the thing I mentioned at the top. I simply took 3 points on the world space plane and simply transformed them in to clip space and then used those 3 points to create a plane in clip space. I think whats going on is under certain conditions the error between the two planes isn't noticable. What those conditions are I'm not exactly sure but a few things may or may not be involved. For one I'm making an rts so your normally looking down at the water not across the water. Second I render the map in square chunks of geometry (the view is normally about 2 1/2 chunks wide). And the 3 points I use are 3 corners of a chunk at the height of the water in that chunk. And I recalculate the plane for each chunk. I think this else helps to minimize the error. Because of the way I render this theres no opertunity for z fighting really here either.
  5. In canada theres Telefilm nationally and OCMD (or OMCD not sure) for ontario. My company got telefilm quite a bit of money but got turned down for OCMD. I'm american but my bussiness partner is canadian.
  6. That seems to use xna functions to transform the plane that doesn't tell me a whole lot. But I was able to just take 3 points on the plane transform them into clip space and rebuild the plane from that and it seems to work although I'm not sure how exactly.
  7. Has any one used clip planes for their water in any modern system that uses vertex shaders? Up till now my water has been using the texkill instruction to clip the reflected and the below water scene. But its slow so I thought I would switch to clip planes now that support for them is more wide spread. I did some research and found you have to specify your clip planes in 'clip space' not sure exactly what that ment I did some tests and found its the space after the perspective divide. My understanding is this poses a really obnoxious problem because (as far as I can tell) a flat plane in world space is not a flat plane in clip space the perspective divid in fact curves it. This makes it impossible to clip something to a certain height. Any one know if I'm right about this? or has any advice on how this could work?
  8. 2005 uses unicode (2 byte char's) by default this will screw all kinds of things up if you program was designed with the normal ANSI 1 byte charactors in mind. As I've learn from personal experience. In the project properties under "Configuration Properties"->"General" it has the option "Charactor Set" make sure its set to "Use Multi-Byte Charactor Set" and not "Use Unicode Charactor Set". **edit** after reading more not so sure this is your issue but its a good thing to check.
  9. It gonna be a problem it seems if your game is coming out at a time when vista just coming out and being adopted but xp is still a huge part of the market share. You wanna take advantage of DX10 features but have no easy way to downgrade for DX9 cards with out a writing two seperate apps. Thats why I'm gonna use opengl I think.
  10. JHL

    Advanced C++

    Ha I'm not sure thats cumilitive like that
  11. JHL

    Advanced C++

    Quote:Original post by JasonBlochowiak Yeah - "up to a point" usually includes speedups of 100x to 1000x for algorithmic improvements. As opposed to those massive 2x to 10x type speedups that are more typical of alignment or cache-aware optimizations. Ahem. ... Oh, and read that article that Zahlman linked. Your statement and the article are right but they don't make my point any less valid. 1000x is much more impressive then 10x but if you need every cycle you can get then that minor boost is still extremely important. Quote: I'm not saying that during optimization you shouldn't pay attention to alignment and cache line aware issues, I'm just saying you shouldn't generally be thinking about that, unless you're targeting ancient hardware. Thats not true. These things are becoming more neccessary rather then less unfortinatly as CPU's start using things other then raw hertz to up their power. The 64 bit age will usurp 32bit soon and that will bring more issues. Still its not something you need to care about the overwelming chunk of your time. Most of your coding in a game will not need this at all. But say your writing a software renderer (they still have modern uses) a cutting edge physic engine, a neural networked AI you gonna want every little bit you can get. And thats Advanced Baby
  12. JHL

    Black Holes

    Quote:Original post by Damon Shamkite "Our hyperspace drive creates a pocket in subspace and is powered by a microsingularity / quantum singularity / zero-point-energy / dilithium matrix (choose one)". Don't blame the scifi writers for all this these are all ideas physists actually had regardless of how beyond pratical they are. Except for dilithium matrix that one is completely made up but if you had said matter/anti-matter reactor then it would fit in with the rest.
  13. JHL

    Advanced C++

    Quote:Original post by jpetrie Quote: but can start to see there is a whole nother level ( namely a much lower level ) that is very important in C++ programing. Understanding more advanced parts of the language. How certain C syntax actually compiles down to machine code. This sort of low level thinking is rapidly becoming less and less important, and less and less worthwhile. That kind of thinking bugs me alot and leads to sloppy slow code in my opinion. As some one has said in this post already algorithimic optimization will always produce the greatest results but that only works up to a point. And new arcitecture is making this more relevent not less. Memory alignment, Memory lantancy, Multi core proccessors these things make understanding how c++ turns into machine code instructions all the more important. I'm not suggesting that you should break out the asm but knowing (or at least having an idea) how the compile turns c++ into asm helps you write code the that compilers can optimize better.
  14. I would say if you never have to reallocate it just use a regular array. Thats my policy. But if your access to the array is rare just during load times for example the overhead is very minimal. Another minor note is I think an std::vector class its self has a slightly larger size then an allocated array which is just a 4 byte pointer. Its a few additional bytes that means nothing unless you have many thousands of these arrays. Allocated arrays are marginally more efficent in my opinions. But you should use what ever your more comfortable with. Theres no reason to use C's malloc though use new and delete if you go that route. **edit** I see your other post now, I would try your auto_array thing if you extremely worried about performance here.
  15. Your gonna have to be more specific do you mean register a c++ function so you can use it in lua then no there isn't.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!