• 8
  • 5
  • 2
  • 1
  • 8
  • 10
  • 5
  • 6
  • 32
  • 14
  • 27
  • 7
  • 7
  • 2
  • 7
  • 36
  • This topic is deleted!

    2
  • 5
  • 12
  • 3

Recent Posts

  • B
    Issue: auto-Applied HiDpi settings result in blurry images. When HiDpi is disabled, text is too small. Overriding system hidpi setting (ex:125%) to avoid blurry images can be done in Triplea code but only at startup before the GUI starts. Current dpi setting can be displayed (ex: in About... dialog). Changing font size is Look and Feel dependent and not straightforward.
    Nimbus does have a default Font Setting.
    In Substance, it seems you have to override individual font settings in code for each type of component (there are many of them). With this approach obscure options/workarounds are then sometimes required for the font setting to be applied (Metal JEditorPane, Nimbus Label ?), but overall it does work. An option could be added in engine Settings > ui > font custom scaling: 125%. It would be applied at next startup and would disable system HiDpi scaling at startup, no image scaling, custom scale applied to fonts.

    read more
  • @thedog said in TripleA 3.0 - Design Proposal & Discussion:

    From what little I know, the coders time could be better spent coding , than unpicking the old code, working around it and patching it up, putting patching on top of patching.

    That is kind of part and parcel to the task, it is somewhat intrinsic and describes what has been happening now for 15 years.

    A new XML structure format might be better in a later version say 3.5.

    Having new core data structures could be very important for re-arranging the code. Patching it together sounds much simpler than it will be. Removing all constraints of the existing design could prove to be very important lest the fire breaks will continue to have legacy design that has been holding us down.

    New code for the file saving format

    Almost all of the core data structures are tightly coupled to save game. A 'unit' and the concept of a 'unit type' cannot have any alterations because those code objects are encoded onto hard disk. We cannot change them in nearly any way without breaking save game. An overhaul of how the code is structured and data is required to enable a new save game format. Those same objects are mapped pretty directly to the XML, revisiting this from the ground up implies it all may change drastically.

    There is a lot of uncertainty here, though having a green light to make radical changes is a key component to 3.0. I'd rather release a 2.7 sooner. Though, we have been trying to rearrange and fix core code design for half a decade now, it does not seem to be effective enough to really be successful.

    read more
  • @butterw There are a couple built in look and feels, notably the 'metal' (which seemingly is just 'default OS'). I presume it is pretty heavily used.

    read more
  • @lafayette
    Might this approach work for v3

    Keep the current XML file structure as is A rewrite of the TripleA code (not from scratch), but taking code already written and rearranging it. Tempt past and present coders to stitch the code back together as they know they dont have to struggle/fight against the current structure. New code for the file saving format

    From what little I know, the coders time could be better spent coding , than unpicking the old code, working around it and patching it up, putting patching on top of patching.

    Yes the above will not have a working version for awhile, but hopefully it will be much leaner and cleaner.

    A new XML structure format might be better in a later version say 3.5.

    Just some thoughts from the side lines.

    read more