Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 2019-06-15 in all areas

  1. fluffy north african forests
    10 points
  2. Great video from @ValihrAnt
    5 points
  3. got one more to polish and then an entity template to make screenie showing just what I mean, new oaks on the left, holly oaks on the right, and easily double the number of the old oaks on top perhaps wood counts should reflect the poly weight?
    4 points
  4. I still have lots to learn when it comes to creating trees, but here are some holm oaks I made. (436 tris)
    3 points
  5. I appreciate the critique as it helps me to improve. Hopefully you don't have to wait to long!
    2 points
  6. No offense to bigtiger. He has some awesome stuff in his mod. He's done some pretty cool things with decals, for instance, which should be merged with core game, and I like the dead trees and fallen trees, which should also be merged. But LordGood's trees are actually better. At least, from what I see so far! Oh, and BigTiger's bushes should be merged too. Very nice. I think LordGood's oaks there finally have the "layering" effect right, to cast some nice self-shadowing and give that fullness expected from a mature set of trees. It's one of the things I like about the "old" Carobs.
    2 points
  7. @Bigtiger might have some stuff to show soon
    2 points
  8. Thanks for the report, this is fixed by https://code.wildfiregames.com/D1975.
    2 points
  9. These trees look amazing! Good job! Since they seem a lot more higher poly than the existing trees, could one have an option to toggle between these new trees and the okd ones? That way weaker computers would just use the old trees if they have performance problems.
    2 points
  10. Oh man, these look a lot nicer than some of your others! They fit quite well with LordGood's. My main critique of some of your other deciduous trees is that their foliage is very thin. I imagine you partially do that for performance, but the fact still remains. I do like how tall some of your trees are. Sometimes 0 A.D.'s trees seem a tad too small.
    1 point
  11. They will be committed. I'm waiting for his last map
    1 point
  12. I think that's fixed with D1969. That's not bugged actually... That's just 0 A.D. 's correct behaviour. I'm not sure how svn used to behave there though. D1970 fixes this issue for good by changing how fleeing works. Noticed that, needs to be fixed in unitAI, should be trivial. Likewise I think D1969 fixes that. -- BTW the animal roaming issue is fixed in D1980.
    1 point
  13. If you are banned and create an account right away, this will increase your ban. At least that's what happened to me. I get 7 days if I remembered. eae farmelius
    1 point
  14. I have opened the door of the ship. If I don't, please tell me how to open the door of the ship.
    1 point
  15. I decided to open a thread about this topic because I think we need to collect the available information somewhere. There are different people who already worked on improvements of Mac support, but we're not yet where we want to be and there are still some missing bits before we can put everything together. This involves different aspects and we will only be successful if we cover all of them or at least the important ones. First let's give an overview for those who didn't look at our build-system in detail: The basics: update-workspaces.sh / update-workspaces.bat: The sh-script on Linux/*nix/OSX runs the compilation of some external dependencies and also premake. On Windows the batchfile only executes premake because most of the dependencies are precompiled. Premake: Premake creates our workspaces (also called solutions or projects) for the different platforms. Currently we support Makefiles, VisualStudio (2005, 2008, 2010), Xcode3, Codeblocks. Workspaces: The workspaces are used for building the code on different platform and also for development with different programs (IDE's). Deployment: For (alpha-)releases we make a special deployment for various reasons. The main reason is that we want to make it easier and more convenient for the user. Everything is precompiled and distributed in appropriate containers for the different operating systems and platforms (e.g. .deb files for debian based linux systems and .exe files for windows etc.). I don't know who exactly does that for which system. OK now our current status: XCode support: Currently we have support for XCode3 but It's not particularly useful as far as I can tell and XCode 4 is already out quite a while. The most current version of premake (4.4beta) supports XCode4, but we don't yet know how well. Premake: We are using premake4.3 with quite a lot of customizations. Upgrading is a lot easier than from premake 3.x to 4.3, but I requires some efforts to reimplement the customizations that are still needed and to test everything. Here's a list I made in a few minutes... but It's probably not complete. General: Customizations for using nasm assembler. It's not needed anymore, but the customizations are still in our code... General: PCHHeader as „path“ instead of „string“ in api.lua Windows: trimmprefix for removing the „source“-prefix Makefiles: Fix for parallel builds Makefiles: Test generation Linux+Makefiles, Codeblocks: --start-group and –end-group to work around circular referencing Codeblocks: Fix Codeblocks not relinking after static libraries change (changeset 10814) Workaround some linking problems for ActorEditor, ArchiveViewer and FileConverter (changeset 10749) ... maybe forgot some Build-process on the Mac: The build-process used during development generally works. There's one little problem because both the Makefiles and XCode generate a .app bundle that does not work. You have to copy the binary inside the app-bundle to /binaries/system before it can be executed properly. Deployment process on the Mac: We currently don't have one. We just link to the development build-instructions and sometimes there are people on the forums who create a .app bundle. Tickets: There are currently at least two open tickets about this topic: #947 1073 The patches in both tickets don't offer completed solutions yet. Next steps / open questions XCode support: I think we must still stick to premake and should not use manually created XCode projects. Changing one workspace manually is error-prone and time-consuming. I've created a quick-and-dirty integration of the premake4.4beta and sent it to historic_bruno because he has XCode4 and knows what to check. He will test if it's worth the efforts of upgrading. Build-process on the Mac: Changing the kind of our WindowedApp-Projects to "ConsoleApp" in premake4.lua causes XCode and the Makefiles to generated simple binaries instead of the broken .app bundles on OSX. That's a quick fix and we just need to test if we can change this settings on all environments or if we should do it just for the Mac. Deployment process on the Mac: I've discussed this with historic_bruno and we both think that we should seperate the deployment from the build-system. It's something that should come after everything is build and the build-process should stay as it is for development. I've red some documentation about .app bundles and started creating a shell-script to but one together. We aren't sure if we should put everything into a single .app bundle or if we should use more advanced packaging tools. I think we have to do the .app bundle anyway, because those packages seem to be just some kind of container. If there are no important downsides of "simple" .app bundles, we should avoid the additional complexity added by the packager. One important question that could make a decision obsolete is where we want to put the different resources like the data-directory. We know about two potentially suitable locations: 1. The Resources directory of the .app bundle 2. Library/Application Support/0AD/ I tend to the first because of two reasons: 1. According to the Bundle Programming Guide a bundle should contain all resources required to run propperly. 2. Having anything outside the bundle forces us to use the packager. Code for resource-paths: We definitely have to make some changes to source/ps/GameSetup/Paths.cpp about the location where it tries to find the data-directory and other directories. Echelon9 proposed something about that in his patch. I think we should do something like that for the default behaviour on the Mac (either for Library/Application Support/0AD/ or the bundle's Resources-folder) and in addition add some possibilities to override the default behaviour by command-line parameters or environment variables. Prebuilt libraries: I don't know which libraries need to be prebuilt yet and it will require more work and more testing. One important thing is that the libraries should be compatible for different versions of OSX (which?) and 32 and 64 bit. The Bundle Programming Guide states I'm not sure if that's something that can be done with the bundles or if it just means using universal binaries. What do you think? Probably that's a topic we could also discuss on our team-meeting.
    1 point
×
×
  • Create New...