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

Thread: PGDmC - Unknown Name

  1. #11
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    @Nuno: Although I don't want to admit it with the lack of stuff that I can check as finalized, coding started on day 3 so its well underway (clocking 1.2k lines or so now in total - 3k if you include Prometheus and other libs). Now its content generation, content format standardization and the player interface that just need to be finalized before I can call it a game. The menu system gave me a few nasty aches but its all but done at last. The beta will most likely be Monday and then its the content content content sprint till the 8th where its beta 2 - any killer bugs I missed, fix and upload...

    @Ingemar: Screenshots was going to happen, but due to the themes of each section being on the abstract side, I thought against it (shame TBH). Reminds me: I've alwaya wanted to have a hack at the particle system and improve rotation for particles. Maybe if have a bit of time tonight.

    @General Public: Since Prometheus is a gaming library, the custom version I've been rocking for my game devs will be released as version 1.0 along with 100% completed docs for that version around the 28th - about time right? Well, at last it seems to be bug free as tested by games, fast as tested by games, cross platform and once X11, WIN32 spec code is in place you get another 10% speed increase whene it goes bare gl for video. Audio will be late july hopefully once codec wars end. The target min spec for prometheus is 3.1mb ram, 22mhz cpu, 16mb HDD and Opengl > 2.0 with 'legacy' support via 1.x extensions: gma 945 crowd, that is you so yay. Active OSes are Win32, Win64, Lin32, Lin64 on X86 (and yes ARM 7/9 is under the feasibility test). Chances are it works on OS X but its never been tested although chances with SDL powered revisions are quite strong.

    Oh and for those that like more control, I am looking into a function based language that shares the prometheus codebase so instead of image.rotate(x) you can dest := rotateimage(image, x)... And its all inter-operable! YAA!

    Of course, for bare bones performance go ZenGl, but I am looking into the performance gap and have a few tests getting close to the theoretical max speeds of my HW (OK, it chows up 1.1ghz cpu and 300mb ram ATM, but the concept delivery 80% of it can be crammed in 8mb ram and 200mhz cpu) with leaps there along with a new data type for dealing with VERY large images: compress the text data with bzip or similar and decompress areas needed on the fly... Slow but faster than page file
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  2. #12
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Progress News at last:

    With 10 days to go, my project has been shortened by 641 lines (or pretty much everything)... I got all the code I needed for a messy, unexpandeable, slow game. So now its time to ditch bad program architecture for a new and more experimental one relying less on threads and instead kernel run levels in an array of procedural pointers... Sounds fancy, runs good and best of all - its clean.

    The idea is simaple:
    Any kernel may launch another via RunKernel(@KernelToRun) which registers it, ups the run level etc... If the kernel to be run is the same as the one that ran the procedure sending the request, the kernel sending the request is asked to terminate and hand control of the app back while shifting the runlevel back by 1. It sounds complex, but its easy, fast and clean - nice. Finally a public beta may be made available, I compile for Windows x86, ubuntu x86 and ubuntu x86_64...
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  3. #13
    Quote Originally Posted by code_glitch View Post
    I hope so too... My first 'issue' is the fact my game and attacks heavily rely on a particle effect system. Now how do you check whether 5,000 particles are hitting each player every frame... Hmm. I'm thinking of filtering it by angle then distance instead of re-calculating particle positions and then trying to match them.
    You could use a spatial collision algorithm - put each particle into a 2d grid 'slot' by it's location, and then when you check the player, see which 2d slots the player is covering and only look in those slots for particle collisions.

    This will speed things up lots!!

    cheers,
    Paul

  4. #14
    Quote Originally Posted by paul_nicholls View Post
    You could use a spatial collision algorithm - put each particle into a 2d grid 'slot' by it's location, and then when you check the player, see which 2d slots the player is covering and only look in those slots for particle collisions.

    This will speed things up lots!!
    I agree. You can use a regular grid, or a quadtree/octree, or an axis aligned BSP tree. Any of them will help. If the distribution is fairly regular, if you know that the density is at some level, then a regular is a quick and easy solution.

  5. #15
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    I found a novel solution now: particle are based on threthings; time, angle and speed. All I need is starting coords + (Time * Speed) and see if that is in the player area twice. One for the upper limit the other for lower. Then just use an if to check each particle in that range. Easy as 1, 2, 3 and so far seems fast enough (checking 1,000 particles every frame @ 55fps eats around 150-200mhz ) although speed tweaks are on the way to use those other cores more efficiently...

    Also looking into using the power of OpenGl HW and textures with some colour values and framebufferobjects to do some HW acc detection: at the power usage of 50,000 pixels/sec is not much right? Although since its POC code I doubt it will be part of the final entry TBH
    Last edited by code_glitch; 08-07-2011 at 10:20 PM.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  6. #16
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    This new architecture is super awesome - in 180 lines I have ported 350 lines of the old beta with a 40% performance boost (mem + cpu)... Now tweaking some physics and playability, drafting the AI and writing the threaded input control system Should be 1 map playable once I get a basic tileset etc done. I lovez this new gamedev approach
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  7. #17
    40% performance boost is quite significant. Sounds like good work!

  8. #18
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Looking like an excellent new architecture yieleding a lot of progress.... Newfound performance and customizeability comes at a small price: you may need around 100Mb of ram to run at peak times and at least 600mhz cpu (preferably dual core or better) with OpenGl 2.1

    Doesn't look like much trouble - vmware can run it at just over 18 fps (just playable) on one core, 256mb ram with xp sp2 and no hw accel

    Finally got the maps up correctly and currently re-writing player input threads and reading up on some TCP/IP goodness. Shame I have almost nothing on Prometheus_net so I'll probaly use some FCL stuff or sdl_net.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

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
  •  
Comodo SSL