Quale sistema di coordinate utilizzare per gestire l'interfaccia utente 2D?


20

In seguito alla domanda sulle proporzioni , sono interessato a sapere cosa stanno usando le altre persone quando lavorano su sistemi di interfaccia utente 2D (molto probabilmente le loro soluzioni di produzione propria). In particolare, come gestite i sistemi di coordinate. Secondo me ci sono tre opzioni:

  1. Coordinate codificate (ad es. 0 -> 720, 0 -> 576)
  2. Coordinate normalizzate (0,0 -> 1,0, 0,0 -> 1,0), mappate in coordinate reali prima del rendering
  3. Coordinate virtuali (ad es .: 0 -> 1600, 0 -> 1000), mappate in coordinate reali prima del rendering

L'hard-coded è ovviamente utile solo se si è su una piattaforma fissa e si conoscono in anticipo le coordinate dello spazio dello schermo o se si è pronti a creare layout dello schermo per ogni possibile set di dimensioni dello schermo.

Le coordinate normalizzate sono belle, ma soffrono di ambiguità quando le proporzioni dello schermo non sono fisse (ad es. 0,75 mappe su coordinate fisiche diverse quando si esegue in widescreen rispetto a 4: 3). Inoltre, per gli autori, è davvero controintuitivo dichiarare un elemento dell'interfaccia utente (0,2 x 0,2), solo per scoprire che in realtà non è quadrato quando viene eseguito il rendering.

Le coordinate virtuali sono inequivocabili, ma soffrono degli stessi problemi delle coordinate normalizzate nella fase di rimappatura: una piccola discrepanza decimale può comportare errori off-by-one, il che significa che gli elementi dell'interfaccia utente che dovrebbero affiancare ora hanno una cucitura tra di loro.

Allo stesso modo, quando si dispone di uno schermo a risoluzione fissa, sia le coordinate normalizzate che quelle virtuali indicano che è molto difficile garantire una mappatura 1: 1 tra i pixel finemente elaborati dell'artista nell'immagine dell'interfaccia utente e i pixel sullo schermo, il che significa che si corre il rischio di cattivi artefatti di ridimensionamento (supponendo che tu stia eseguendo il rendering come quad strutturati sullo schermo).

Abbiamo scelto l'approccio coordinato virtuale, in particolare per evitare ambiguità sulle proporzioni. Quindi, quando si esegue il rendering su uno schermo 16:10, lo spazio dell'interfaccia utente è (0,0) -> (1600,1000), ma quando si esegue il rendering su 4: 3, lo spazio utilizzabile dell'interfaccia utente è effettivamente (133,0) -> (1467 , 0).

Esistono soluzioni migliori di cui non sono a conoscenza? Esistono buone strategie per ridurre al minimo i problemi di questi 3 approcci?

Risposte:


5

Penso di essere d'accordo sul fatto che le coordinate normalizzate non si associano davvero bene alle cose dell'interfaccia utente.

Quello che faccio di solito per i layout 2D, è fondamentalmente il tuo spazio di coordinate "virtuale", ma scelgo uno spazio che mappa 1: 1 con la mia risoluzione target preferita (1280x720, ad esempio). Non è riparato, ma è intuitivo da gestire e so che nel 90% dei casi sembrerà giusto. Ovviamente è importante non essere compiacenti e controllare spesso diverse risoluzioni.

Per una maggiore nitidezza nel rimappare le risoluzioni, prenderei in prestito alcuni suggerimenti dal rendering dei caratteri e fornirò informazioni di suggerimento. Quindi assicurati che le cose che devono essere continue siano etichettate in qualche modo, eseguendo anche l'arrotondamento per ottenere pixel esatti dove è necessario un allineamento nitido.

Forse considera anche di rendere le cose più relative. Quindi, piuttosto che tutto ciò che è "posiziona l'oggetto 1 in assoluto X, Y", puoi specificare "posizione in basso a sinistra dell'oggetto 2 in corrispondenza di un certo offset in basso a destra dell'oggetto 1". È più facile quindi ridimensionare e / o spostare le cose, senza perdere relazioni importanti.


5

Il sistema di coordinate di CEGUI sembra davvero ben pensato. Il suo sistema di coordinate unificato unisce il posizionamento assoluto con il posizionamento relativo. Puoi specificare posizioni come:

  • nel mezzo dello schermo
    UDim(0.5,0)
  • cinque pixel a sinistra del bordo destro
    UDim(1.0,-5)
  • due widget nel mezzo ma separati da 10 pixel
    HA_RIGHT,UDim(0.5,-5) HA_LEFT,UDim(0.5,5)

2

In caso di dubbio, perché non andare con il modello box CSS o una sua semplificazione?

È possibile specificare posizioni in percentuale o pixel. È possibile posizionare i contenitori con percentuali ma posizionare gli elementi al loro interno in pixel, ad esempio.


1

Mi piace usare le coordinate virtuali, ma basato su una risoluzione target comune (preferibilmente una delle risoluzioni più alte in cui ti aspetti che il gioco venga eseguito.

In questi giorni, una buona scelta potrebbe essere 1920x1080.

Tutte le opere d'arte e i modelli di schermo possono essere creati a quella risoluzione e ciò semplifica la misurazione di posizioni / distanze in pixel.

Se eseguito con un formato diverso rispetto alle coordinate virtuali, è possibile scegliere come adattarlo allo schermo (letterbox, ritaglio dei lati o un po 'di entrambi)

Quando codifico, trovo che "pensare in pixel" è molto più facile che pensare in coordinate normalizzate! - Voglio che il testo sia "50 pixel (virtuali) in altezza" anziché "0,0463 unità in altezza"


0

Dipende totalmente dal tipo di interfaccia grafica che hai, ma spesso i giochi hanno elementi ancorati lungo i bordi dello schermo e negli angoli, e quindi potrebbero avere una casella al centro dello schermo per una finestra di dialogo modale o qualcosa del genere.

Se questo è il tuo caso, allora potrei suggerire di utilizzare uno schema in cui si specifica un ancoraggio e un offset (x, y)? Questo sarebbe simile a BorderLayout di Java (ma forse con i quattro angoli, quattro medi dei bordi e un centro dello schermo). Ad esempio, è possibile specificare un offset di (0,0) dall'angolo in alto a sinistra; quindi l'elemento verrebbe ancorato esattamente nell'angolo dello schermo. E quindi, indipendentemente dalla risoluzione, dalle proporzioni e così via, avresti l'indicatore di salute nell'angolo dello schermo. Ma se si ancorasse un elemento nell'angolo in alto a destra, l'elemento verrebbe naturalmente ancorato rispetto al suo punto in alto a destra (anziché in alto a sinistra), quindi di nuovo verrebbe automaticamente ancorato all'angolo dello schermo, indipendentemente dalla risoluzione.

Consiglio vivamente contro le coordinate normalizzate 0.0-1.0; questi potrebbero variare in base alla precisione in virgola mobile. Le GUI devono essere mappate su pixel, a meno che tu non abbia una GUI 3D.


Bene, usando il posizionamento relativo e le ancore praticamente un dato per qualsiasi tipo di sistema di interfaccia utente. Sono specificamente più interessato alle misurazioni tra i diversi componenti. E per questo genere di cose, la distinzione della GUI 3D / 2D è un po 'confusa: specialmente quando si utilizzano quad di spazio dello schermo strutturato per acquisire immagini di dimensioni arbitrarie e ridimensionarle / posizionarle nello spazio dell'interfaccia utente.
MrCranky,

0

Molto dipende dal tipo di gioco e dalla situazione. Per i prototipi veloci e sporchi, preferisco pianificare l'interfaccia utente su carta millimetrata, scrivere un elenco di coordinate numeriche per una dimensione della finestra fissa e codificare tutto: è più facile e veloce per me. Ma per un progetto "reale" in cui si desidererebbero finestre ridimensionabili o risoluzioni dello schermo alternative, ciò non sarebbe ovviamente l'ideale, e sarebbe preferibile una soluzione che consenta il ridimensionamento in entrambe le direzioni.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.