Dalla console alle applicazioni GUI [chiuso]

Risposta di base: i grafici vengono realizzati premendo i frame su un frame buffer.

Risposta moderna: ti verrà data un'API per creare una "Finestra" o una "Scena" o qualcosa del genere. Trova un'API adatta ai tuoi obiettivi (GTK +, QT4, Windows (??)) e esegui alcuni tutorial per questo.

Se sei effettivamente interessato ai giochi o ad altri elementi grafici di basso livello, consulta questa pagina Esercizi SDL

Per imparare la GUI, tutto ciò che devi fare è mettere un'idea, solo una, che è: basata sugli eventi .

Questo è tutto, il pattern appare in tutta la GUI / roba da gioco. Quindi, qual è l'evento guidato? Prima di entrare nei dettagli, vediamo prima il programma della console di sequenza comune

ask user for some parameters
read file
calculate some values
write to the file
close the file
...

Sembra che ci sia un codice come questo, e qui, vediamo come appare un programma basato sugli eventi.

while event_queue is not empty:
    event = event_queue.get_event()
    if event is quit_event:
        break
    else if event is mouse_click_event:
        do something to response user
    else if event is key_board_event:
        do something to response user
    ....

Come potete vedere, la principale differenza tra le applicazioni di console comuni e le applicazioni GUI è la seguente: c'è un ciclo principale nell'applicazione GUI. Quindi, qual è il ciclo? E perché è guidato dagli eventi? È semplice, in un'applicazione GUI, non sappiamo cosa farà l'utente dopo, l'utente potrebbe fare clic su un pulsante "about", "ok" o "cancel". Quello che possiamo fare qui è aspettare, vedere cosa fa l'utente e fare una risposta. Ecco, "l'evento" è esattamente l'utente "azione" preso, e la nostra risposta è guidata dall'evento, quindi è così chiamata event-driven.

E parliamo del ciclo. Quel ciclo è semplice, controlla se c'è qualche evento in coda, se c'è, apre l'evento dalla coda e reagisce. Quindi, da dove vengono questi eventi? Di solito è da sistema operativo. Quando un utente esegue alcune azioni sulla nostra interfaccia, diciamo, un pulsante nella cornice della finestra, il sistema operativo mette gli eventi corrispondenti nella coda degli eventi.

Ancora non capisci? Puoi immaginare che ci sia un negozio, uno staff di nome Bob, e qui arrivano i clienti, si allineano in fila, lo staff può servire un solo cliente una volta, quando non c'è un cliente, lo staff può solo sedersi lì e gioca il suo dito. Il personale è il ciclo principale ei clienti sono gli eventi.

Quindi, cosa accadrebbe se Bob si prendesse tutto il suo tempo per occuparsi di un cliente e non lo finisse mai? Diciamo che un cliente fa una tale richiesta

I would like to order some elixir.

E qui Bob inizia il suo viaggio per guardare l'elisir. Riesci a sentire quelle parolacce da quei clienti in coda adesso? Sì, un grave problema comune appare nella gestione degli eventi è che ci viene bloccato nella gestione di un evento.

while event_queue is not empty:
    event = event_queue.get_event()
    if event is mouse_click_event:
        # I will never release the control!
        while True:
           pass  
    ....

Come puoi vedere, quando l'evento è mouse_click_event, entriamo nel campo di applicazione, ed è un ciclo infinito. Hai mai visto finestre "Nessuna risposta"? Sì, è così, alcuni eventi vengono bloccati nel ciclo principale, che ha causato il ciclo principale non può gestire altri eventi.

Si può dire "Ehi, sto usando wxWidget, qual è il problema con gli eventi", come ho detto, il pattern event-driven appare in tutte le applicazioni della GUI, inclusi QT / wxWidget / MFC / VB /. Net Framework .... almeno tutte le cose della GUI che conosco. Pertanto, una volta che puoi capire cosa è basato sugli eventi, sono tutti uguali .

Da una prospettiva GUI ci sono fondamentalmente 2 diversi tipi di applicazioni desktop.

1. Applicazione per finestre standard
2. gioco

La differenza è che un'applicazione di finestra standard utilizzerà in genere l'API del sistema operativo nativo fornita per fornire un'esperienza simile ad altre applicazioni esistenti sul sistema operativo. In genere un gioco prende il sopravvento sull'esperienza utente ed esclude qualsiasi paradigma esistente nel sistema operativo. L'approccio allo sviluppo di ciascuno è completamente diverso.

Dato che non ho ancora sviluppato alcun gioco, non farò finta di parlare a quell'argomento. Da una prospettiva di finestre standard (* nix / Windows) sebbene l'esperienza di sviluppo sia piuttosto diversa da un'applicazione di console. Generalmente le applicazioni console presuppongono un'esperienza utente abbastanza seriale (ad esempio, l'app ha una buona idea di ciò che l'utente farà in seguito). In un'applicazione finestra / GUI, l'utente può fare più o meno quello che vuole, quindi a livello di applicazione tutto tende a essere (utente) guidato da un evento.

Se stai cercando un modo per saperne di più sullo sviluppo di un'applicazione GUI, ti suggerirei di reinventare la ruota e fare qualcosa che sai come dovrebbe funzionare. Un buon esempio potrebbe essere una reimplementazione di NotePad, o qualcosa di simile che sia semplice, ma dà una buona sensazione per alcune delle basi dello sviluppo di un'applicazione per Windows.

Innanzitutto potresti voler esaminare la libreria curses , che facilita la creazione di una piattaforma basata sul terminale interfacce.

Sul lato veramente grafico delle cose, il sistema di finestre OS è responsabile della maggior parte del sollevamento pesante. Generalmente il sistema operativo richiama un sacco di cose su una bitmap in memoria, e poi dice alla scheda grafica "Ehi, puoi mostrare questa merda sul monitor per favore?". Ripeti 60 volte al secondo.

Pertanto, quando vuoi scrivere un'interfaccia grafica corretta, molte delle cose che farai sono fondamentalmente solo parlando al sistema operativo - "Voglio che la mia finestra venga posizionata qui", "fammi sapere quando il mouse è sopra questa parte della finestra", "va bene puoi cambiare il puntatore del mouse in una clessidra per favore" ecc.

Ovviamente per la maggior parte degli usi si desidera utilizzare una libreria grafica per gestire le cose che parlano con il sistema operativo, lasciandoti libero di codificare la tua interfaccia utente in modo indipendente dalla piattaforma.

Beh, dipende davvero. Di solito dipende dalle librerie e dalle API utilizzate. Come se volessi creare una GUI, potresti usare QT4 o GTK +

Diciamo che vuoi fare un gioco? potresti usare SDL o Opengl. tutto dipende da cosa vuoi fare?

Espandere la risposta di Ken, dal punto di vista dello sviluppo del gioco, ci sono due modi per vederlo, dal momento che c'è un motore di gioco e i vari giochi che sono fatti tipicamente in un motore di gioco.

Un motore di gioco, fa le chiamate ad api grafiche (opengl e direct3D vengono in mente) per disegnare le diverse scene di gioco e animazioni, supporta il caricamento di forme modellate 3d in programmi come 3d max, supporta il caricamento di shader , aiuta a calcolare le intersezioni di tutti gli oggetti e dice quando due o più di essi si scontrano, fornisce un'interfaccia alla libreria del suono in modo che uno suoni i suoni se un personaggio ottiene un colpo alla testa (come il tuo capo) (e in questo caso openal, DirectSound e FMOD vengono in mente) e fornisce un modo per implementare i personaggi controllati dall'IA, che seguono le ciambelle non appena inizia il gioco (gustose ciambelle, ahahahah).

Poi, c'è il gioco che implementa le logiche del gioco (se il giocatore inizia a coltivare, viene colpito alla testa, o se il giocatore guerriero trova un mago viene immediatamente ghiacciato e poi il mago usa il cubetto di ghiaccio e uno sgabello mettere i piedi), e anche i personaggi modellati in alcuni software, e tutto ciò che è specifico per un gioco, dal momento che tutte le cose generali sono fornite dal motore. (Gamedev.org e gamasutra eccellono in questo)

C'è (almeno) un grosso problema che probabilmente incontrerai come uno sviluppatore CUI quando passi alla GUI: i programmi della GUI devono continuare a funzionare per continuare a mostrare e reagire all'utente (l'utente si aspetta reazione continua dall'interfaccia).

Quando si eseguono funzioni che richiedono un tempo un po 'più lungo (o devono essere eseguite continuamente), si dovrebbe essere consapevoli che la GUI potrebbe essere bloccata se non lo si fa nel modo giusto - affinché una GUI continui a funzionare normalmente deve continuare a correre in primo piano. Le funzioni continue (o che richiedono tempo) dovrebbero quasi sempre essere attivate in un altro thread, mentre si inviano eventi alla GUI quando cambia uno stato.

Alcuni sistemi GUI forniscono questo per te e astraggono questi dettagli per te (principalmente sistemi che hanno linguaggi separati di codice e di marcatura come WPF / Silverlight), ma in altri (come GLADE) devi gestirlo da solo.