Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

291 Neutral

About bladerunner627

  • Rank
  1. bladerunner627


    Yeah, I'm still alive. Schools wrapping up, got finals starting next week so hopefully I'll be getting more done on Quadrion Engine after that. Speaking of Quadrion Engine, it's a large endeavor that Shawn Simonson, Renato Ciuffo, Kieran Culliton, and I have been working on for a few years granted my input has been a bit variable. Lately we've been making immense amount of progress as Shawn has implemented a dynamic lighting system which uses a defered approach. What follows is a video showing off the SSAO and dynamic lighting working simultaneously. On my 'acceptable' GeForce 9500M (mobile) 512MB I get about 45fps on average which is damn good considering you could conceivably have an unlimited amount of dynamic lights on the screen and not have much of a performance hit (if at all) though I'm not sure about overdraw. Anyways, enough of that here's the video WATCH IN HD, it's set to Synchronicity 2 by The Police =D. CLICK HERE FOR VIDEO ;) Also, don't forget to check out Moogen Studios which is our development blog. I believe Shawn's going to be make some video blogs in the very near future, so those that are interested in some technical details and theory you'll soon find yourself indulged; he's a great speaker. Peace
  2. bladerunner627

    Group blog

    I finally convinced my close friend Shawn Simonson to create a blog for his work on Quadrion Engine and other miscellaneous technical endeavors. He has a way with words; I'm sure that anyone who even bothers to peek at my blog will find themselves quite a bit more indulged with what he has to say. I might start mirroring the posts from there due to my sheer lack of content. Check it out http://quadrionengine.blogspot.com/ :)
  3. bladerunner627

    Easy Usage

    So with the little time I have to code, I've managed to get a little bit done on the engine. One thing that's always bugged me when creating game/render windows is picking the 'right' resolution by default for the user. To combat this issue I wrote a window creation function that does just that. int OpenQuickWindow(bool fullscreen) is the prototype for it. Basically, when the method is called it grabs a list of available video modes and removes the video modes with the lowest RGB bit values. If true is passed to it then we assume the user wants the highest resolution video-mode available from the list for full-screen, otherwise we pick a lower resolution mode (but not the lowest) that way windowed mode isn't taking up his/her entire screen. It's probably not the best routine but it works. My only concern is when you're dealing with weird aspect ratios, like mine for example (16:9) which has 1366 x 768 AND 1365 x 768. Right now it's picking 800x600 for windowed mode on my system which is perfect, I need to test it on other systems before I get too excited.
  4. bladerunner627

    Microsoft's STL implementation slow?

    Those tests were done in Release mode.
  5. Thanks everyone, I've received a lot of helpful comments and I was able to solve the problem. Apparently, regardless of whether you're in release mode or not, Microsoft's vectors do some 'other' stuff in the background. So, in order to fix this issue you have to use these pre-processor definitions: #define _CRT_SECURE_NO_WARNINGS #define _SCL_SECURE_NO_WARNINGS #define _SECURE_SCL 0 #define _HAS_ITERATOR_DEBUGGING 0 I still think it's a bit silly that they assume you want iterator checking, etc on but w/e.
  6. bladerunner627

    My dumb programming idea

    The only problem with it is standardization and getting all these developers to follow it. Other than that I believe it's extremely elegant.
  7. bladerunner627

    Perlin Ants

    Oooohh, these two screenshots remind me of plasma pong. This looks like an effective terrain generation routine, the pronounced and slightly varied lines at a single edge give it a really 'natural' feel. Nice work.
  8. bladerunner627

    Microsoft's STL implementation slow?

    Yeah, I dunno :P. When I made my claim before the test I got this kind of response "BULLSHIT ALERT! Did you just say the STL is slow? Are you freaking kidding me? You switched out a trusted, well-implemented dynamic array for a hand-written dynamic array, and you noticed 300% - 400% speed increases?" I noticed the slowness when using vectors to store all IBSP map data (this is before I started using vertex and index buffers) so you can see WHY it would make a significant difference, I was hitting these things SEVERAL times a frame.
  9. bladerunner627

    Escape II path nodes

    Hah, I love that wobble on the laser dot, seems like the sniper doesn't have a steady hand at first.
  10. bladerunner627

    Microsoft's STL implementation slow?

    Is it me or does Microsoft's implementation of vectors in the STL seem oddly slow? This question came about after my past experiences and now recently a debate on a different forum. Anyways, to investigate this I wrote a small program to test the speed of populating and fetching data to/from regular 'ol malloc'd...dynamically allocated arrays and std::vector's... respectively. While the test isn't extremely extensive, I believe it's sufficient. Either way, the results are...disturbing to say in the least. This is with the \O2 'Full Speed' optimization flag on MSVC 2008: Starting first test: Populating Speed... Populating dynamically allocated array... Populating vector... The dynamically allocated array took 0.0176ms to populate. The vector took 0.0396698ms to populate. A 2.25397 ratio difference in speed. Starting second test: Fetch Speed... Fetching data from dynamically allocated array. Fetching data from vector. The dynamically allocated array took: 0.00195556ms to fetch data. The vector took: 0.0312889ms to fetch data. A 16 ratio difference in speed. This makes me want to reinvent the wheel... I thought it might have been my code but when I asked a friend to test it on his GCC setup his results were drastically different... while I don't have his exact results he said "I compiled this on GCC and get slightly better results with the vector at -O2, populating on GCC 4.3.2 (-O2) was slightly slower, but fetching was faster. It might be interesting to figure out what is causing the issue." I'm posting the full source code here in attempt to get a broader range of results from various platforms. So far it seems like it's a Microsoft specific issue. Here's the source code: VecTest.zip If someone knows of something I don't know, please let me know. I'm interested in seeing your results.
  11. bladerunner627

    GPU Terrain generation, cell noise, rivers, crater

    Amazing stuff, it's not often you see 3d renderings as sexy as these. The amount of detail you put into this is mind blowing.
  12. bladerunner627

    Angel Script

    Yeah, wow, college is definitely eating up the majority of my free time. So what's been up? Nothing other than drowning in homework. When I do get to code it's mainly just been refactoring old code though recently I've been dabbling around with implementing Angel Script into Odorless Engine. Angel Script is really neat, the syntax and usage is nearly identical to C++ except for a few minor things like the primitive types. I haven't done any performance tests with it but it seems stable and fast. My only gripe, though it does support classes :), is that it doesn't support inheritance (yet). Hey, it has interfaces! So yeah, if you guys are looking for a scripting language for your games and want something with syntax nearly identical to C++, then I recommend checking out Angel Script. People would argue that Lua is better but honestly I don't like the syntax of Lua.
  13. bladerunner627


    Sweet, stuff. Show us some videos once you've got the merging implemented :).
  14. bladerunner627

    Visibility implemented

    Visibility is in which is a huge milestone for me. Not much else to say so here's a video: Yay!
  15. bladerunner627

    "Impossible," said Mr Impossible

    Unless I'm thinking of something else but aren't Hammer's texture coords always defaulted to like [1,1] UV's when you apply a texture to any face?
  • Advertisement

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!