Jump to content

Imarok

WFG Programming Team
  • Posts

    992
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Imarok

  1. 4 hours ago, aeonios said:

    Thinking about openGL in terms of version numbers isn't really useful. People seem to have this idea that higher numbers are better, but that's not how openGL works. Really we should be using the lowest version number that has features that are highly useful to improving the performance and/or appearance of the game. Using a version higher than that doesn't actually do anything besides preventing people with older cards (like me) from playing. That said, I think 3.3 is a good idea, and there are some major performance and quality enhancements that could be had by upgrading. However there's also GLES to consider which I'm not actually certain about. We should really look into the consequences before making any major changes like that.

    Honestly we keep going around in circles with this. It'd be good to make a decision sooner rather than later. Technically only model and particle drawing would need to be changed, I'm pretty sure. Upgrading to openGL3 doesn't mean that every shader would need to change, only the ones that would need to handle instancing and depth readback for soft particles would need to be updated. That and the model drawing code would need to be updated to use real instancing. It's less of the engine than you might imagine (although if we decided to throw out arb or ffp that'd be a lot of cleanup).

    Hmm. That could actually be done. It's certainly worth testing though.

    Would it be possible to use opengl 3.3 features only when the graphics card supports it? So that too old cards can still run the game, but won't profit from 3.3 features?

  2. 8 minutes ago, Exodarion said:

    I am not sure if I have the authority to make tickets, but if so, in which category would you like me to put it?

    Everyone can create tickets.

    Wrt category: just do it as you think. If it's wrong someone will correct it after you created the ticket.

  3. 15 hours ago, Exodarion said:

    Just as a bit of extra info. The only thing I did is writing a few functions that uses the vanilla 0ad garrison functionality.
    This issue by itself has nothing to do with the code, but with the garrison system as a whole.
    If I were to remove all my garrison code, play the faction myself and garrison the units manually in the Hydrophant, the issue will remain the same.
    I am not expecting a fix to this anytime soon and also don't expect you to fix this for Hyrule Conquest specifically.

    However, I am almost 100% sure that this problem also exist in the vanilla game. Therefore, it would benefit 0ad in general if someone from the dev team would look into this problem at some point in time.

    If it is a bug in 0ad, a ticket (trac.wildfiregames.com) would be nice.

  4. 1 hour ago, l2edVipel2 said:

    Really? Whenever I tried it popped a message about adjusting firewall or doing something with a port (20590? Don't remember the exact number). I turned my firewall off with no success but can take a closer look tonight when I get home.

    It only works inside the lobby

  5. 4 hours ago, The Undying Nephalim said:

    I've got a question and I'm curious, is it possible to make it so that certain factions are only selectable in certain modes? For example a faction that only appears on naval maps and not land maps, and vice versa?

    You can change that in gamesetup.js

  6. 36 minutes ago, aeonios said:

    Horrible hacks are possible. We don't necessarily need super-realistic clouds, just a reasonable approximation. For example we could just have all cloud particles below a certain height be considered shadowed.

    Do I assume correctly, all this only works with a newer OpenGL version? If so shouldn't we/you first make 0ad ready for the newer version and then discuss about how to use the new possibilities?

  7. 47 minutes ago, s0600204 said:

    May I ping you? :P

    Looks like it'll still happen in A23. Looking at gamesetup.js, the code that assigns a random civ to a player starts by making a list of available "cultures" (filtering out unplayable civs so as not to add their "culture" to the list (unless they happen to share it with a playable civ)), then randomly chooses a civ from a randomly selected culture - but does not check if the civs it's selecting from are all playable. In other words, SelectableInGameSetup needs to be checked on line 2182.

    So... do you want to fix it, or shall I?

    Done.

    See D1455

    • Like 1
    • Thanks 1
  8. 23 hours ago, The Undying Nephalim said:

    Do you have your opponent set up to Random? If so sometimes the AI it will spawn as Lon Lon Ranch, which is supposed to be a non-AI map specific faction that's only on Hyrule Field. It's trying to load the AI and apply it to Lon Lon Ranch but they don't have the necessary buildings for the AI and that's why it freaks out. For some reason 0AD sometimes picks non playable factions when you select Random. I think they fixed it in the upcoming 0.23.

    Have you marked it in some way as unplayable?

×
×
  • Create New...