De la consola a las aplicaciones GUI [cerrado]

7

Soy un programador principiante y todo lo que he trabajado hasta ahora son aplicaciones de consola en C ++. En cuanto a la codificación, ¿cómo se crea el lado gráfico de los programas? Entiendo que la lógica que estoy usando desde las aplicaciones de la consola será la misma, pero ¿cómo crean los programadores los gráficos en los que se usa esta lógica? Sé que es una pregunta ambigua, pero básicamente estoy tratando de entender cómo crearía un programa que no sea una aplicación de consola, como un videojuego o una aplicación para iPhone.

    
pregunta Matt 25.02.2011 - 02:00

7 respuestas

4

Respuesta básica: los gráficos se crean al insertar marcos en un búfer de marcos.

Respuesta moderna: se te dará una API para hacer una "Ventana" o una "Escena" o algo así. Encuentre una API que se ajuste a sus objetivos (GTK +, QT4, Windows (??)) y ejecute algunos tutoriales para ello.

Si está realmente interesado en juegos, o en más gráficos de bajo nivel, consulte esta Página de ejercicios de SDL.

    
respondido por el ProdigySim 25.02.2011 - 02:22
7

Para aprender GUI, todo lo que tienes que hacer es poner una idea en tu mente, solo una, que es: impulsada por eventos .

Eso es todo, el patrón aparece en todas las cosas de GUI / gaming. Entonces, ¿qué es el evento impulsado? Antes de entrar en detalles, veamos primero el programa de consola de secuencia común

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

Parece ser un código como este, y aquí, veamos cómo se ve un programa basado en eventos.

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
    ....

Como puede ver, la principal diferencia entre las aplicaciones de consola comunes y las aplicaciones GUI es: hay un bucle principal en la aplicación GUI. Entonces, ¿qué es el bucle? ¿Y por qué es impulsado por eventos? Eso es simple, en una aplicación GUI, no sabemos qué hará el usuario a continuación, el usuario podría hacer clic en el botón "acerca de", "aceptar" o "cancelar". Lo que podemos hacer aquí es esperar, ver qué hace el usuario y responder. Eso es, el "evento" es exactamente la "acción" que tomó el usuario, y nuestra respuesta es impulsada por el evento, por lo tanto, es llamada por evento.

Y hablemos del bucle. Ese bucle es simple, comprueba si hay algún evento en la cola, si lo hay, saca el evento de la cola y reacciona. Entonces, ¿de dónde son esos eventos? Por lo general es de OS. Cuando un usuario realiza algunas acciones en nuestra interfaz, digamos, un botón en el marco de nuestra ventana, el sistema operativo coloca los eventos correspondientes en la cola de eventos.

¿Todavía no entiendes? Se puede imaginar que hay una tienda, un personal llamado Bob, y aquí vienen los clientes, se alinean en una cola, el personal solo puede atender a un cliente una vez, cuando no hay un cliente, el personal solo puede sentarse allí y toca su dedo. El personal es el bucle principal, y los clientes son los eventos.

Entonces, ¿qué pasaría si Bob se tomara todo su tiempo para tratar con un cliente y nunca lo terminara? Digamos, un cliente hace tal solicitud

I would like to order some elixir.

Y aquí Bob comienza su viaje para buscar elixir. ¿Puedes escuchar esas palabras sucias de esos clientes en la cola ahora? Sí, un problema común importante que aparece en el evento es que se nos bloquea en el manejo de 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  
    ....

Como puede ver, cuando el evento es mouse_click_event, entramos en el ámbito y es un bucle sin fin. ¿Alguna vez viste ventanas de "No hay respuesta"? Sí, eso es todo, algún evento se bloquea en el bucle principal, lo que causó que el bucle principal no pueda manejar ningún otro evento.

Puede decir "¡Hola! Estoy usando wxWidget, ¿qué pasa con el evento controlado?", como dije, el patrón dirigido por el evento aparece en todas las aplicaciones GUI, incluyendo QT / wxWidget / MFC / VB /. Net Framework ... al menos todo lo que conozco de GUI. Por lo tanto, una vez que pueda entender qué es impulsado por un evento, todos son iguales .

    
respondido por el Fang-Pen Lin 25.02.2011 - 17:43
2

Desde la perspectiva de la GUI, existen básicamente 2 tipos diferentes de aplicaciones de escritorio.

  1. aplicación de ventanas estándar
  2. juego

La diferencia es que una aplicación de ventana estándar normalmente usará la API del SO nativo provista para proporcionar una experiencia similar a otras aplicaciones que existen en el SO. Un juego generalmente toma el control de la experiencia del usuario y excluye cualquier paradigma que exista en el sistema operativo. El enfoque para desarrollar cada uno es completamente diferente.

Como no he desarrollado ningún juego, no pretendo hablar sobre ese tema. Desde una perspectiva de ventanas estándar (* nix / Windows), aunque la experiencia de desarrollo es bastante diferente de una aplicación de consola. Normalmente, las aplicaciones de consola asumen una experiencia de usuario bastante en serie (es decir, la aplicación tiene una buena idea de lo que el usuario hará a continuación). En una aplicación basada en Windows / GUI, el usuario puede hacer más o menos lo que quiera, así que a nivel de la aplicación, todo tiende a ser impulsado por eventos (usuario).

Si está buscando una forma de aprender más sobre el desarrollo de una aplicación GUI, sugeriría reinventar la rueda y hacer algo que sepa cómo debería funcionar. Un buen ejemplo sería una reimplementación de NotePad, o algo similar que sea simple pero que dé una buena idea de algunos de los aspectos básicos del desarrollo de una aplicación de Windows.

    
respondido por el Ken Henderson 25.02.2011 - 02:51
1

En primer lugar, es posible que desee buscar en la biblioteca curses , que facilita la creación de terminales interfaces.

En el lado verdaderamente gráfico de las cosas, el sistema de ventanas del sistema operativo es responsable de la mayor parte del trabajo pesado. En general, el sistema operativo dibuja un montón de cosas en un mapa de bits en la memoria y luego le dice a la tarjeta gráfica "Oye, ¿puedes mostrar esta mierda en el monitor, por favor?". Repita 60 veces por segundo.

Por lo tanto, cuando desee escribir una interfaz gráfica adecuada, muchas de las cosas que va a hacer es básicamente hablar con el sistema operativo: "Quiero que mi ventana se coloque aquí", "Avíseme cuando el mouse esté sobre esta parte de la ventana", "Bien, ¿puede cambiar el puntero del mouse a un reloj de arena?"

Por supuesto, para la mayoría de los usos, desea utilizar una biblioteca de gráficos para manejar esas cosas de hablar con el sistema operativo, dejándolo libre para codificar su interfaz de usuario de forma independiente de la plataforma.

    
respondido por el Anon. 25.02.2011 - 02:28
0

Bueno, realmente depende. Por lo general, depende de las bibliotecas y APIs utilizadas. Al igual que si desea crear una GUI, puede usar QT4 o GTK +

Digamos que quieres hacer un juego? puede utilizar SDL o Opengl. ¿Realmente todo depende de lo que quieras hacer?

    
respondido por el user6791 25.02.2011 - 02:14
0

Ampliando la respuesta de Ken, desde la perspectiva del desarrollo del juego, hay dos formas de ver esto, ya que hay un motor de juego y los diversos juegos que se hacen típicamente en un motor de juego.

Un motor de juego, hace que las llamadas a la api gráfica (opengl y direct3D vienen en mente) para dibujar las diferentes escenas y animaciones del juego, admite la carga de formas 3d modeladas en programas como 3d max, admite la carga de sombreadores , ayuda a calcular las intersecciones de todos los objetos, y dice que cuando dos o más de ellos chocan, proporciona una interfaz a la biblioteca de sonidos para que uno pueda reproducir sonidos si un personaje recibe un disparo en la cabeza (como su jefe) (y en este caso openal, DirectSound y FMOD vienen a la mente), y proporciona una manera de implementar personajes controlados por AI, que persiguen las donas tan pronto como comienza el juego (donas sabrosas, ahahahah).

Luego, está el juego que implementa las lógicas del juego (si el jugador comienza a cultivar, le disparan en la cabeza o si el jugador guerrero encuentra un mago, se congela inmediatamente y luego el mago usa el cubo de hielo y un taburete para poner es pies), y también los personajes modelados en algún software, y todo lo que es específico de un juego, ya que el motor proporciona todas las cosas generales. (Gamedev.org y gamasutra sobresalen en esto)

    
respondido por el Coyote21 25.02.2011 - 10:25
0

Hay un (por lo menos) un gran problema con el que probablemente se encontrará como desarrollador de CUI cuando se cambie a la GUI: los programas de la GUI deben continuar ejecutándose para seguir mostrándose y reaccionando ante el usuario (el usuario espera reacción continua desde la interfaz).

Cuando vaya a ejecutar funciones que demoran un poco más (o necesita ejecutarlas continuamente), debe tener en cuenta que su GUI podría estar congelada si no lo hace de la manera correcta: para que una GUI continúe ejecutándose Normalmente debe seguir ejecutándose en primer plano. Por lo tanto, las funciones continuas (o que consumen mucho tiempo) casi siempre deberían activarse en otro hilo, mientras se envían eventos a la GUI cuando cambia el estado.

Algunos sistemas GUI proporcionan esto para usted y abstraen estos detalles (en su mayoría sistemas que tienen lenguajes de marcado y de código separados como WPF / Silverlight), pero en otros (como GLADE) usted tiene que gestionar esto por sí mismo.

    
respondido por el vstrien 25.02.2011 - 10:38

Lea otras preguntas en las etiquetas