Lace

Lace

Been here way too long... From Lingerie, but also, like, fancy curtains
Joined
Last seen
Messages
3,052
Media
29
Reaction score
0

Profile posts Postings Media Albums About

  • Noxid
    If he's worth his salt, it might be fun to have someone else to talk turkey with :mahin:
    Noxid
    I know :s
    Where do they come from?
    Why all at once?
    This is Nicalis' fault, that's all I know.
    Noxid
    I have no way of knowing for sure, but I seem to recall seeing somewhere that it was using DirectDraw7, which in turn implies a DirectX version of 7
    Noxid
    Seeing as there isnt' hardly a single division operation and only a handful of imul, I'd say probably not very long :s
    Wedge of Cheese
    Well, I'm pretty sure that you can't do it any better than what I said before, simply because that's like the minimal amount of information you would need.
    Wedge of Cheese
    So it's really a programming problem rather than a math problem? How are you representing a function f(x) on a computer?

    And you should get your eyes checked, I clearly only posted once ;).
    Wedge of Cheese
    For a CS hack, I don't think it'd be really worth it. CS's physics are already pretty smooth and feel good. If it's not broken, don't fix it.

    And I don't really see what's so hard about that problem. Just look at the range of the function within each x interval. Am I missing something?
    Wedge of Cheese
    For a CS hack, I don't think it'd be really worth it. CS's physics are already pretty smooth and feel good. If it's not broken, don't fix it.

    And I don't really see what's so hard about that problem. Just look at the range of the function within each x interval. Am I missing something?
    Wedge of Cheese
    Worth it/implementation troubles would depend a lot on the type of game you're trying to make. Did you have anything specific in mind?

    And what's this math problem?
    Noxid
    Ugh I can't even see it being possible to feed it through allegro without doing EVERYTHING that way because how do I give it a DirectDraw surface? I'm pretty sure it can't use that.

    under the current DirectDraw driver of Allegro, most drawing functions need to lock a video bitmap before drawing to it. But doing this is very slow, so you will get much better performance if you acquire the screen just once at the start of your main redraw function, then call multiple drawing operations which need the bitmap locked, and only release it when done
    Click to expand...
    Possibly related to our issue?
    http://alleg.sourceforge.net/latestdocs/en/alleg009.html
    Noxid
    Do you mean
    004705C0 - Entity Solid Tile
    00470870 - Entity Tile Slope L1 Top
    00470970 - Entity Tile Slope L2 Top
    00470A70 - Entity Tile Slope R1 Top
    00470B70 - Entity Tile Slope R2 Top
    00470C70 - Entity Tile Slope L1 Bottom
    00470D80 - Entity Tile Slope L2 Bottom
    00470E90 - Entity Tile Slope R1 Bottom
    00470FA0 - Entity Tile Slope R2 Bottom
    004710B0 - Entity Water Tile
    00471160 - Entity Tile Collision Algorithms
    Click to expand...
    or for entity vs. bullet, which I don't think I have at the moment but should be somewhere in that general vicinity
    Noxid
    Idunno. Building a DLL to overtake graphics rendering functionality from CS will be no light undertaking, and if we go that far then why not go the whole 9 yards and use Allegro to provide PNG loading, or translucency? Why not just write the whole engine over?

    These are the questions that must be answered.
    Noxid
    http://www.mediafire.com/?cxl1f0subhdepkd

    Threw together a rudimentary particle class, on my crappy laptop it can handle upwards of 30k without any fuss. I've never made a DLL before though, so I must assert that this doesn't mean anything other than there should be no issue with this many renders
    Noxid
    I had an idea.
    It's kind of crazy though!
    What if we used a DLL to render the particles via a different method.. that was somehow faster? I might take a look at Allegro and see how many particles it can render at once...
    Noxid
    Still no significant difference; the process % remained in the 0-3 range from the beginning of the test to when the max # of unrendered particles was reached. I then turned on rendering and it immediately overtook the entirety of one of my cores. (It only will use one at a time)
    Noxid
    Without rendering there was no noticable slowdown when particles reached the upper limit of A00, even with collisions turned on.
  • Loading…
  • Loading…
  • Loading…
  • Loading…
Back
Top