Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: Cave flying technique

  1. #11
    No shaders needed, i expect all my games to work on wide variety of computers and graphics cards. So pixel shaders would be going out from that, limited to only new cards.

    But as far as efficiency goes i can think of ways to improve it even further. For example i'm using glBegin(GL_POINTS),glVertex,glEnd sequence which could be replaced with vertex array. Each individual pixel call would add to array stack and once operations are done or pixel tool changes, or stack goes full, it would draw all at once. But as the drawing part is still very fast i don't think there's need to, yet.

  2. #12
    Quote Originally Posted by User137 View Post
    No shaders needed, i expect all my games to work on wide variety of computers and graphics cards. So pixel shaders would be going out from that, limited to only new cards.
    I would call them fragment shaders since we are talking about OpenGL. Anyway, if you support computers without shaders, you are going way back. Is it important to support computers from 2003? (It is good from an environmental perspective but I am not sure it will affect your sales.) Of course, if we also include hand-held equipment the picture changes quite a bit.

    But as far as efficiency goes i can think of ways to improve it even further. For example i'm using glBegin(GL_POINTS),glVertex,glEnd sequence which could be replaced with vertex array. Each individual pixel call would add to array stack and once operations are done or pixel tool changes, or stack goes full, it would draw all at once. But as the drawing part is still very fast i don't think there's need to, yet.
    Immediate mode is indeed slow. Just moving to glDrawElements speed things up a lot (by an order of magnitude for a complex scene), and VBOs will improve things further. It depends on how much geometry there is. If the polygon count is low it doesn't matter.

  3. #13
    I did a major change to the water system in preparation to make Pixelcolony (project name) to more like a game. Earlier the water particles didn't move and had a density. It was fun for "scientific" study but not really as efficient as it can be.

    But now the system fits better for games. Water particles don't have density anymore and they fully move themselves to either down, left or right. This means that i was able to remove watermap index array and reduce code and memory use by alot. The water itself of course acts slightly sharper because every particle is either on or off, not between. Animation became faster, water stabilizes faster, no gaps are left anywhere and that causes solidifying to be more efficient. Where old code had particles remaining in thousands when "stable", it is now reduced to ~10-50 which is the absolute water surface only. Also because indexarray was removed, it would now be easier to increase the max amount of moving water.

    It's not very different visually so don't really need a screenshot, although animation sure is different and better. One difference is almost lifelike "bubbles" that come to surface when explode there. But i'll drop this topic because i really might flesh that into a game, and release more info then. The current issues to come lie in basic ship tools, computer controlled bots, cave generation and overall map that looks attractive. I'm a fan of old, now buried, game Fuse. It was similar pixelmap game which added elements from Command and conquer. Harvestable resources, structures, infantry units, turrets and all kinds of things. But will see what comes of this I will definitely add sand too.
    Last edited by User137; 03-09-2011 at 03:09 PM.

  4. #14
    Nice work! did you update the download file in the first post with the latest version?

    cheers,
    Paul

  5. #15
    I had a look into your code and maybe there is a little failure on

    // Move and collide players
    for p:=0 to 0 do
    with pl[i] do begin
    iy:=iy+5*lag/1000; // gravity

    "with pl[i] do begin" must be "with pl[p] do begin"?

    Thomas

  6. #16
    Thanks KidPaddle, failure is fixed Luckily variable "i" just earlier went through for 0 to 0 so it worked.

    And paul, i just now added zip to first post. There is also new keys to use, Numpad + and - to change zoom level (1x-6x).

    What i last added yesterday was that when water detaches it takes parameter on which direction it will start heading into. Like, if a water particle collides it from right, it will start moving left rightaway, if it can't go down or once it falls down. I think this chain reaction was part of making it faster fluid.

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •