Jump to content

Sonarpulse

Community Members
  • Posts

    166
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Sonarpulse

  1. how much data is outside public.zip?

    Yeah, as soon as I read that headers cause such problems, even with known compression algorithms, I was worried. Hopefully zsync can be upgraded someday. It could be extraordinarily usefully combined with a package manager.

  2. Particle systems have a fixed emitter

    What about Projectiles, like in that catapult video in the alpha 9 preview thread?

    Anyways since wakes are the interference of many waves, I think it would look good boats spawned static particles behind them. Those particles would be animated "sprites", i guess, of the two wakes moving perpendicular to the boat's velocity at the time & place the particle was spawned. Hopes that makes some sense.

  3. Nice work! Is this is based around premake or something else? I think your current method is good, but I would rename some folders so as other platforms, package managers, etc are support, stuff still makes sense. (I put those other features in the hierarchy too, not saying you should add them now)


    Prerequisites
    \-- Source
    \-- Include
    \-- just library headers (of course)
    \-- Dynamic Lib
    \-- android arm (windows 8)
    \-- osx x86_64
    \-- osx x86_32
    \-- iOS arm (windows 8)
    \-- windows x86_64
    \-- windows x86_32
    \-- windows arm (windows 8)
    \-- Static Lib
    \-- android arm (windows 8)
    \-- osx x86_64
    \-- osx x86_32
    \-- iOS arm (windows 8)
    \-- windows x86_64
    \-- windows x86_32
    \-- current contents of libraries
    \-- windows arm (windows 8)

  4. Hmm, I don't think you guys should scrap the slow, physics & collisions method of calculating trajectories and damage. Ideally I would make it so players can select that method, or the proposed speedier one before a match.

    Also I think that height really should be taken into account for ranged projectiles, and that it wouldn't be too hard either:

    700px-Ideal_projectile_motion_for_different_angles.svg.png

    1. Imagine all the other parabolas
    2. Take the union of them all
    3. Make a function that describes the border of the region, f(y)=x. I bet it might be a simple polynomial too, or a hyperbola.

    Now when checking if a target in range, there is two more steps: get the height difference between the target and archer, and plug that in. If the function is too slow/complicated, make a table. Using a table also means that drag, etc, can be accounted for with no performance penalty.

    Doubt this is any faster, but the shape can be spun around the z axis to create a 3d shape which can be placed over the archer (not rendered of course), and then intersected with the hieghtmap to create a bordered region. Game then checks if unit is within that region.

    ---------------------------------

    On an somewhat unrelated note, I was thinking if a bunch of ranged units are selected and told to attack (maybe just attack ground), the mouse wheel (with a hotkey I guess) could be used to adjust how much spread they should aim for. the area to be targeted could either correspond to the formation of the archers, or simply be a circle or rectangle. That way if the enemy is a swarm of units you can just rain down arrows, but if the enemy is some big powerful unit that moves slowly (the king in), you can have them all target the same spot

  5. To clarify my current interest in this: I don't care about making a proper playable game on Android, and I'm not intending to spend any time trying to achieve that. I'm just personally interested in learning about the technical aspects of the platform, and porting the game engine as a tech demo seems a better approach than spending the time on some throwaway toy project instead, since it encounters more interesting issues and produces a more impressive result, and it also indirectly helps the game on the proper desktop platforms (by cleaning up some of the rendering code (avoiding global GL state), and by adding GLSL support which will simplify new graphical features and may improve performance or driver compatibility, and by dealing with some portability problems, etc).

    Read this again guys. The porting that is going on right now is NOT about making a playable spinoff game, or anything about that. it is about cleaning up the Code. These days, as standardization is better than before, porting doesn't necessitate having to separate code trees, or quick hacks. If one does it right, (which these guys are), it means one's code will "play by the rules" better than ever, be "properly modular" (all the somewhat unsystematic #ifdef's are just an intermediary step).

    Then you guys might say, "well if the point is just cleaning up the code, isn't this an inefficient, roundabout way to that? Well if one could consistently visualize every issue that would arise porting a program, then one's code wouldn't need to be cleaned up in the first place.

  6. It's not possible to incrementally update the installer .exe files (or equivalents on other platforms) - they're compressed so their content becomes completely different whenever a single byte is changed. Any kind of patching system would need to be slightly more integrated with the post-installation game, so it can use the old installed public.zip as the base for the new version.

    see: http://zsync.moria.org.uk/

    zsync has special handling for gzipped files, which enables update transfers of files which are distributed in compressed form.

    Don't winzip and gzip use the same underlying compression algorithm? I'd hope that zsync's logic would work on that algorithm alone and not be hung up on the differences between *.tar and winzip's built in archive method

  7. Yes, that might have been a more sensible approach. I guess git-svn converts the svn revision history to git. Anyhow - in the meantime, it completed.

    Well, a git checkout downloads all history too, so you probably wouldn't have saved on download times. Just make sure the conversion didn't get rid of .svn (or can git update+convert too?) and if you "push --force" to your forked repo on github it might be able to make some sense of it. Good luck!

  8. I don;t know about git svn clone, but that sounds like a git to svn converter. I would

    1. git clone your fork
    2. copy past the svn over the git,
    3. add .svn/* and .svn to .gitignore (one per line)
    4. try pushing to git hub.

    Then copy in your android hacks+commit. whether you want to pop 'em all in, or make a "fake history" and commit in changes is up to you. If SVN adds anything else besides ".svn/*", I would copy that too.

  9. You could configure git to ignore ".svn/*" (very easy, just dump that in a text file called .gitignore). Then you can continue to use svn to update if the official repositories get out of sync, without confusing git. in addition, because of git's hashed based versioning, if both git repositories endup with the same version separately, git should take note.

  10. pathfinder8.4.thumb.jpg

    Shouldn't the red zones not be so angular at this point? at the corners of the fence, building, and coast, shouldn't the impassible-navcell shape resemble an arc? I think it could be an issue: for example if the fence was a bit closer, the unit with this clearance radius wouldn't be allowed to go between the fence and the coast, even though it really wouldn't fit. I think the "blur filter" method used for terrain passibility would solve this problem, is it too intensive? The cells, as you say, are supposed to be a conservative measure of what is passable, and this method makes them over constrictive at the corners.

    Alternatively, I guess you could also do 2 sets of nav cells: "Potentially/indeterminately passable" and "definitely impassible". If the fastest route was definitely passable, Great! If the route has "indeterminately passable" bits, more rough paths are queued until a fail safe is found, and then the precise/slow pathfinder (or whatever it's called) checks all the risky bits of the queued paths.

  11. Built in update systems are cumbersome and usually platform specific. But something I that would be nice is to use jigdo or zsync to allow users to quickly update their installers. In addition, once either of those programs make a new "base", the actually updating can be cancelled, and the incomplete download can be used with BitTorrent. That combination is a very efficient way to roll out an update for alphas or releases, and requires no upstream changes.

  12. Actually the one wraitii complied was great, but since MegaUpload has been closed, you can't get it.

    I just tweaked it with some extra maps and AI and the icon. You can download it here. (~360 MB ZIP)

    The app is located in

     0 A.D./data/

    If you need to configure screen resolution, etc, open

    data/config/default.cfg

    Sweet, I don't have a mac, but I know people who do and would want to play this but cant be arsed to compile anything.

  13. Sonarpulse my profile is the only one on this computer and it's set as administrator

    Oh, your on XP. Then it probably won't, if you were on Vista or 7 there is a difference.

    How? :P

    Well, I think I was thinking more "Acess denied", whoops. But I think I read there might actually be some subtle differences in the way windows handles memory based on whether the program is run with administrator privilages.

×
×
  • Create New...