[java`s revenge]

Dit is waar het pijn doet. Sorry Nederlanders (grapje tussendoor) maar je moet eerst het volgende lezen. Slechts browse door ze, Ik zal m`n best doen om alles weer uit te leggen.

(picture heavy )

Terug in 2007 toen SH4 uitkwam, Zamboni schreef deze tutorial. Je zult het
niet geloven, maar het werkt nog steeds
http://www.subsim.com/radioroom/showthread.php?t=111832"

Het nam 2 en een half jaar in beslag om iemand (ik!) om uit te vogelen hoe de naar
de resolutie te schalen.:

http://www.subsim.com/radioroom/show...28&postcount=7

Als je één van de oude garde bent is er niets nieuw dat ik je kan vertellen en het zal je slechts
een paar minuten kosten om de interface en de editor uit te vogelen. ( het nam mij 1 minuut
in beslag).

Alles is hetzelfde. En dat is een zeer goede zaak. Je ziet, zelfs honderden items in NOTEPAD
maakte nut in SH. De werkstroom was traag maar als je het begrepen had HOE, het was enkel
een zaak van tijd en geduld.

Introductie

Terug in SH3, we zaten we vast aan de 1024x768 resolutie. Dit maakte het modden nogal gemakkelijk als ieder positie van het item aanwezig was als een verschuiving naar zijn "parent",
in pixels. Maar items precies positioneren en uitlijnen was pijnlijk. Bij voorbeeld:

[G01 I1]
Name=Page shell
Type=1027;Menu page
ItemID=0x1000000
ParentID=0x0
Pos=0,0,0,0

[G01 I3]
Name=SShell
Type=1030;Static bmp
ItemID=0x1000004
ParentID=0x1000000
Pos=146,685,28,33

Het 0x0 item was de "Root". Het hoofd scherm. Het was 1024 pixels breed en 768 pixels hoog
dus het vulde het scherm op. Het kon niet verplaatst worden, het kon niet
toegankelijk zijn. Het "startte" van de linkerboven hoek van het scherm.
Het 0x1000000 item daar is het eerste menu "page". Het is een "child" van het 0x0 item (ParentID=0x0). Het is 0 pixels breed door 0 pixels high(Pos=0,0,0,0).Maar
waar is het geplaatst? Elk item positie is wel degelijk een positie gegeven vanuit zijn LINKERBOVEN
HOEK.

Enig "child" van dat item zal dan verwant naar de item's (de "parent") verplaatsen, door een
verschuiving in pixels. Dit verspreid naar de hierarchy dus heeft in feite nooit de echte positie op het scherm. Je moest stapsgewijs te werk gaan, van "parent" naar "child", met ieder stap
een verschuiving maken, In ons geval, de "Page" heeft een verschuiving van

0 pixels op horizontaal en 0 pixels op verticaal (Pos=0,0,0,0). In ander woorden, Het is precies op 0 0 coordinates (in de linkerboven hoek van het scherm).

De bitmap object object 0x1000004 is een "child" van de "page"(ParentID=0x1000000). Het heeft een breedte van 28, een hoogte van 33 en zijn linkerboven hoek is verschoven naar de "parent`s"
linkerboven hoek door 146 pixels naar rechts en 685 pixels op(Pos=146,685,28,33).

In andere woorden, de Pos lijn is:
Pos=X, Y, WIDTH, LENGTH waar X en Y de eerste verhoudingsgewijs naar de eerste onmiddelijke "parent" is gegeven.

Denk je dat dit ingewikkeld was? Doe een snelle blik op de SH4 positie lijn:

Zone= 545 396 80 24 0 1 0x28190001 1 -0.5 0x28190003 0 0.5 3 0

Maak je niet druk, het zal alles nuttig maken. We zullen zien hoe de Menu Editor echt dit monster
produceert en waarom het belangrijk is om de tijd te nemen en het te begrijpen.

The Menu Editor is een prachtige tool maar je moet eerst veel vooruit denken, en hier is waarom.

Toen SH4 uitkwam, bracht het meerdere resoluties en, natuurlijk, meerdere verhoudings a aspecten (1024x768 en 1600x1200 zijn 4:3 resoluties terwijl 1920x1200 is een 16:10 resolutie,
of zoals het wordt genoemd, breedbeeld).
Dus hoe maakten ze de ze de inferface naar iedere resolutie/aspect om het hele scherm op te vulllen?

Meerdere interfaces voor iedere resolutie? Magie? Geheime tools? De zoon van Einstein? Neee.
Eigenlijk programmeerden ze de gehele interface als een 1024x768 scherm en rekten het
"achter de schermen"!!! En raadt wat......je zult hetzelfde in SH5 nodig hebben
Omdat de Menu Editor je slechts een 1024x768 scherm laat zien. En als je ongeveer de imba
interface creëert voor iedereen afvraagt, je moet begrijpen hoe het "schalen" werkt om vooruit
te plannen.
Anders, je zult niet weten wat je geraakt hebt.

Scherm Resolutie versus Editor resolutie, relatief versus absoluut

Voor al mijn volgende voorbeelden zal ik slechts 2 resoluties als refentie gebruiken:
1024x768 (normaal 4:3 aspect) en 1920x1200 (16:10 aspect).
1024x768 is de meest belangrijke resolutie omdat het de resolutie is in welke je de de priview
van de resultaten zult zien.
Als je interface van het object correct zijn geplaatst en geschaald in de Editor, zullen ze in het
spel ook zo goed eruit zien. Maar op één of andere manier moet je iets doen om het goed te laten
uitzien op alle resoluties en de relatieve positie of instelling van het scherm.

Dus je moet vooruit denken hoe je items op het scherm wilt hebben. Hier is wat je in je
achterhoofd moet houden;

ABSOLUTE SIZE: als je je item altijd X pixels breed en Y pixels hoog wilt hebben, de item zal "krimpen" als je de schermresolutie hoger zet:



ABSOLUTE POSITION: als je je item altijd X pixels links en Y pixels onder van de linkerboven hoek van je scherm wilt hebben , de positie zal veranderen als de resolutie toeneemt.




RELATIEVE MAAT:

Er hebben al heel wat mensen geklaagd over de recognition manual dat het te klein is.
Het is niet zo klein op 1024x768, maar het wordt kleiner en kleiner als de resolutie toeneemt.
Dit heeft betrekking op 90% van de game`s interface. Het is goed voor enige items, maar
slecht voor het meeste. Dat wat we willen is voor een item zijn relatieve maat op het scherm
blijft houden. Als de resolutie verdubbeld, willen we de de maat van het item verdubbeld hebben.
Maar hier is wat er gebeurd als je de aspect ratios schakeld:



Waarom? Omdat wanneer de resolutie van 1024x768 naar 1920x1200 toeneemt, de schembreedte
is toegenomen met een factor van StretchX=1.6 (als in 1920/1024) terwijl de schermhoogte is
toegenomen met een factor van StretchY=1.5625 (als in 1200/768). Dus ons item is toegenomen met de maten 1.6 horizontaal en 1.5625 verticaal. Dit creëert het oprekken. Dus wat als we het niet willen oprekken?

In deze kwestie moet je KIEZEN hoe jouw item moet ingesteld worden.

Het spel biedt veel flexibiliteit hier:

- "none": neemt de maat helemaal niet toe. Het resultaat: de items worden kleiner en kleiner.
- "no constraint": De breedte neemt toe door StretchX en hoogte door StretchY. Resulaat: de items worden groter maar hey wordt gerekt of samengedrukt tot enig non 4:3 aspect ratio.
- "horizontallyOnly": zal slechts de horizontale maat toenemen door StretchY. Resultaat: de items zal ZEERRR breed worden terwijl gelijkertijd kleiner wordt in hoogte. Zeer goed voor zaken als "long bars".
- "verticallyOnly" : Zal slechts de verticale maat toenemen door StretchX. Resultaat: hetzelfde als hiervoor maar dan verticaal.
- "constantAspectRatioHorizontal": Zal beide horizontale en verticale maten toenemen door StretchX. Resultaat: de items worden groter zonder gerekt te worden. Dit is
de beste methode voor achtergronden omdat ze het scherm opvullen. Echter, het zal
hun "top" en "bottom margins" verkorten.
- "constantAspectRatioVertical": Zal beide horizontale en verticale maten toenemen door y StretchY. Resultaat: de items worden groter zonder gerekt te worden. Dit is niet goed voor de achtergronden omdat het lege banden links en rechts zal laten.
- "constantAspectRatioMin" en "constantAspectRatioMax": Dit zal
overtollig klinken, zoals alle monitoren een "Width>Heigth" maar daar zullen mensen zijn die het leuk vinden om hun monitor te draaien. Dit zorgt voor rare resoluties zoals 1200x1600 en 1200x1920.



Met het risico van "slechts teveel zeggen", ik wil erop wijzen omdat 1024*768 is een 4:3 resolutie,
al de "constantAspectRatio resizing" methoden zal hetzelfde verschijnen als je een 4:3 monitor bezit. Als je het doet, en je wilt een interface creëren is het belangrijk dit te onthouden omdat
je voorzichtig moet zijn als je items herschaalt, simpel omdat je niet in staat zult zijn om het
op een wijde resolutie uit te testen. Het zal er goed uitzien voor je, maar een persoon met een
verschillend "aspect ratio" zal fouten zien als je niet voorzichtig bent. Als een vuistregel,
is het slechts op 2 resoluties nodig om je creaties uit te testen: 1024*768, en de maxium breedte
resolutie dat je computer toestaat. Als het op deze er goed uitziet, zal het op ieder monitor er
goed uit zien.

Heeft het slechts op images betrekking? Nee. ik gebruikte alleen het plaatje van de grootste held van alle tijden om te laten zien "stretching" wanneer "resizing".

Het heeft eigenlijk betrekking tot alle items ongeacht of ze images hebben of ontzichtbaar zijn:
menu pages, groups, alles. We rekken geen images, we veranderen (resizing) afmetingen. Bijvoorbeeld, zeg dat je een menu group wilt hebben dat het hele scherm moet opvullen op
elke resolutie. Wat zal je doen?

1. Je "vult op" het scherm tot 1024x768, met de bedoeling dat je een item creëert met de maat 1024x768 en je plaatst het in de linkerbovenhoek op het scherm.
2. je wijst het toe tot "resize method" van "geen beperking". Op deze manier zal het altijd het scherm opvullen.

Waarom wil je onzichtbare objecten "resizen"? Hier volgt waarom:

RELATIEVE POSITIE:

Neem een blik terug naar de image met absolute positie. Je plaats het item in de "dead center" van het scherm en je wilt dat het daar in elke resolutie blijft. Als je zegt "wel, mijn resolutie is
1024x768 dus ik start vanaf de linkerbovenhoek van het scherm en schuift het item juist door 512 pixels en neer door 384" zeker, het zal goed lijken bij 1024*768, MAAR het zal niet langer in
het midden bij 192x1200 staan, omdat het midden bij zo`n scherm is 860 per 600 (als in de image).

Wat je moet doen is zoals dit:

"Ok, Ik heb een "parent" (Het scherm in dit voorbeeld). Het heeft Breedte en Hoogte en ze variëren in resolutie. Dus als ik een nieuw "child item"wil maken dat in het midden van de "parent" scherm blijft, moet ik de positie uitdrukken van de "child" als gerelativeerd tot de
BREEDTE en HOOGTE van de "parent". In andere woorden, om een knop te maken dat is
geplakt aan de rechter zijde van het scherm, begin je van de linker bovenhoek van de "parent", zoals in SH3, en dan de horizontale positie verrekenen door de volle BREEDTE van
de "parent". Als je jouw item in het midden van het scherm wilt houden, begin je van de bovenhoek van het scherm en dan verschuif je jouw item rechts door 0.5 * BREEDTE en dan verschuif het naar beneden door 0.5 * HOOGTE.

Relatieve positie werkt zoals dit:
1. Je start van de positie van de "parent"
2. Je verschuift dmv een aantal relatief tot de "parent's" afmetingen.
3. Je verschuift dan een aantal relatief tot de "item's" afmetingen.
4. Je verschuift dan dmv een bepaald nummer van pixels.

Ik zal voorbeelden laten zien waarom iedere stap nuttig is.

Zo, dit is wat het spel doet wanneer je items rekt. Zelfs door je "pages" en "items" kan slechts een maximum maat van 1024*768 in de editor hebben, wanneer je het spel laad, de "engine" zal de breedte en de hoogte van alle items achter de "scene" toenemen. Zoals gezegd te hebben door de "resizing" methode. Dit zal effect hebben op alle posities van de "children".

Ik hoop echt dat het nu zin heeft omdat ik het niet beter uitleggen kan dan dit.


SH4 & SH5 Zone Lijn

Gebaseerd op wat je zover hebt gezien, het is nu tijd de echte variabelen vast te leggen dat
de positie van de TOP LEFT hoek van elk item opmaakt. (niet het midden):



ID - Het ID van de item
AnchorID - de "positioning" parent: Voor relatieve posities kan je elk item in dezelfde groep selecteren (inclusief de "group" op zichzelf, welke de echte "parent" is) of, voor absolute posities, helemaal geen item.

X - Absolute Horizontale positie op het scherm: 0 betekend LINKS scherm rand .. 1024 betekend RECHTS scherm rand.

Y - Absolute verticale positie op het scherm: 0 betekent ONDERSTE schermrand ...768 betekent
BOVENSTE scherm rand.

In relatieve modus, zijn ze beiden automatisch bijgewerkt op basis van de andere waarde.
Ze controleren eigenlijk niet de positie, ze zijn gewoon voor de show.
In Absolute modus

Echter in Absolute Modus, controleren ze de positie.

Resize - de grootte van de methode voor het item.
DX - Breedte van het item in pixels
DY - Hoogte van het item in pixels

1. We gaan uit van het anker de linkerbovenhoek en verschuiven op basis van de afmetingen van het anker.

ARX - Achor Ratio X: ARX * (Achor's width) = het aantal pixels waarmee het item wordt verplaatst naar links of rechts van het anker X.

ARY - Achor Ratio Y: ARY* (Achor's height) = het aantal pixels waarmee het item omhoog of omlaag verplaatst van het anker van Y.

2.
Dan verschuiven we weer, maar deze keer gebaseerd op de afmetingen van het object.

DRX - Post Ratio X: DRX * DX = het aantal pixels waarmee het item wordt verplaatst naar links of rechts uit de vorige stap.
DRY - Post Ratio Y: DROOG * DY = het aantal pixels waarmee het item wordt verplaatst naar boven of beneden van de vorige stap.

3. Dan, als het nodig is verschuiven we dan door een specifieke offset (meestal het beste alleen al vanwege schalingsproblemen links)

Uit x - Offset X: horizontale afstand in pixels
Uit Y - Offset Y: horizontale afstand in pixels

Geen idee of deze ook worden aangetast door de grootte en de resolutie scaling of eenvoudigweg toegevoegd / substracted als ze zijn opgenomen.

Laten we eens kijken naar de gevreesde zone line:

Zone= 545 396 80 24 0 1 0x28190001 1 -0.5 0x28190003 0 0.5 3 0
Zone= X Y DX DY Resize ? AnchorID ARX ARY ItemID DRX DRY OffX OffY

Het "?" item is altijd 1, wanneer de Editor gebruikt wordt en niet veranderd kan
worden. Ik heb een theorie over wat het doet, maar zelfs na het maken van 300 items in hetzelfde scherm heb ik nog nooit een nuttigheid gevonden.

Genoeg theorie, laten we wat voorbeelden doen.