Résolution de l'écran
Résolu23 réponses
Utilisateur anonyme
13 mars 2009 à 11:00
13 mars 2009 à 11:00
Bonjour
Premièrement, je te déconseille d'utiliser Swing avec JOGL, ça passe très mal sur certaines machines, mieux vaut faire une Frame et mettre un GLCanvas dedans. Evite de mélanger un canvas fait pour AWT avec un conteneur Swing. Si tu tiens à Swing, utilise plutôt un GLJPanel.
Je te conseille de jeter un coup d'oeil dans le tutoriel de Sun (en anglais) sur l'exclusive full-screen mode.
J'ai du mal à comprendre la structuration de ton code, tu compliques les choses inutilement. Je te conseille de faire ainsi :
Frame frame = new Frame();
frame.setLocation(0,0);//sets the window at the top left corner
frame.setUndecorated(true);//makes the decoration disappear
frame.setIgnoreRepaint(true);//prevents the system from calling repaint automatically
//gets the size of the screen
int screenWidth=(int)Toolkit.getDefaultToolkit().getScreenSize().getWidth();
int screenHeight=(int)Toolkit.getDefaultToolkit().getScreenSize().getHeight();
frame.setSize(screenWidth,screenHeight);
//bug fix : under Linux, sometimes the window was drawn below the taskbar
frame.setResizable(true);
GLCapabilities capabilities=new GLCapabilities();
capabilities.setDoubleBuffered(true);//enables double buffering
capabilities.setHardwareAccelerated(true);//enables hardware acceleration
GLCanvas canvas=new GLCanvas(capabilities);
canvas.setAutoSwapBufferMode(false);//prevents any auto buffer swapping
//TODO: add your GLEventListener here
//TODO: call display() once here
frame.add(canvas);
frame.setVisible(true);
canvas.requestFocus();
GraphicsDevice device=GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
if(device.isDisplayChangeSupported() && device.isFullScreenModeSupported())
{
DisplayMode oldDisplayMode = device.getDisplayMode();
DisplayMode newDisplayMode = new DisplayMode(400, 400,oldDisplayMode.getBitDepth(),oldDisplayMode.getDisplayRate());
try {
device.setFullScreenWindow(frame);
device.setDisplayMode(newDisplayMode);
} finally {
myDevice.setDisplayMode(oldDisplayMode);
myDevice.setFullScreenWindow(null);
}
}
Ton erreur a été principalement de changer le mode d'affichage avant de passer en exclusive full-screen mode, il faut lire la documentation Java :
http://java.sun.com/docs/books/tutorial/extra/fullscreen/exclusivemode.html
Enfin, pour le tutoriel, va voir sur mon site, j'en ai fait un, il n'est pas fini mais au pire, tu peux toujours me demander un coup de main et passe nous voir sur javagaming.org, nous serons heureux d'aider un programmeur de jeux en Java :D
Bonne programmation.
P.S: n'oublie pas de désactiver DirectDraw sous Windows quand tu déploies ton application sur le web sinon tu vas avoir de mauvaises surprises.
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Premièrement, je te déconseille d'utiliser Swing avec JOGL, ça passe très mal sur certaines machines, mieux vaut faire une Frame et mettre un GLCanvas dedans. Evite de mélanger un canvas fait pour AWT avec un conteneur Swing. Si tu tiens à Swing, utilise plutôt un GLJPanel.
Je te conseille de jeter un coup d'oeil dans le tutoriel de Sun (en anglais) sur l'exclusive full-screen mode.
J'ai du mal à comprendre la structuration de ton code, tu compliques les choses inutilement. Je te conseille de faire ainsi :
Frame frame = new Frame();
frame.setLocation(0,0);//sets the window at the top left corner
frame.setUndecorated(true);//makes the decoration disappear
frame.setIgnoreRepaint(true);//prevents the system from calling repaint automatically
//gets the size of the screen
int screenWidth=(int)Toolkit.getDefaultToolkit().getScreenSize().getWidth();
int screenHeight=(int)Toolkit.getDefaultToolkit().getScreenSize().getHeight();
frame.setSize(screenWidth,screenHeight);
//bug fix : under Linux, sometimes the window was drawn below the taskbar
frame.setResizable(true);
GLCapabilities capabilities=new GLCapabilities();
capabilities.setDoubleBuffered(true);//enables double buffering
capabilities.setHardwareAccelerated(true);//enables hardware acceleration
GLCanvas canvas=new GLCanvas(capabilities);
canvas.setAutoSwapBufferMode(false);//prevents any auto buffer swapping
//TODO: add your GLEventListener here
//TODO: call display() once here
frame.add(canvas);
frame.setVisible(true);
canvas.requestFocus();
GraphicsDevice device=GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
if(device.isDisplayChangeSupported() && device.isFullScreenModeSupported())
{
DisplayMode oldDisplayMode = device.getDisplayMode();
DisplayMode newDisplayMode = new DisplayMode(400, 400,oldDisplayMode.getBitDepth(),oldDisplayMode.getDisplayRate());
try {
device.setFullScreenWindow(frame);
device.setDisplayMode(newDisplayMode);
} finally {
myDevice.setDisplayMode(oldDisplayMode);
myDevice.setFullScreenWindow(null);
}
}
Ton erreur a été principalement de changer le mode d'affichage avant de passer en exclusive full-screen mode, il faut lire la documentation Java :
http://java.sun.com/docs/books/tutorial/extra/fullscreen/exclusivemode.html
Enfin, pour le tutoriel, va voir sur mon site, j'en ai fait un, il n'est pas fini mais au pire, tu peux toujours me demander un coup de main et passe nous voir sur javagaming.org, nous serons heureux d'aider un programmeur de jeux en Java :D
Bonne programmation.
P.S: n'oublie pas de désactiver DirectDraw sous Windows quand tu déploies ton application sur le web sinon tu vas avoir de mauvaises surprises.
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Utilisateur anonyme
13 mars 2009 à 01:23
13 mars 2009 à 01:23
Salut
Il est possible que ton système supporte seulement le mode plein écran simulé et dans ce cas, tu ne pourras pas changer la résolution de l'écran. As-tu essayé de passer en mode debug? Cordialement
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Il est possible que ton système supporte seulement le mode plein écran simulé et dans ce cas, tu ne pourras pas changer la résolution de l'écran. As-tu essayé de passer en mode debug? Cordialement
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Utilisateur anonyme
13 mars 2009 à 01:24
13 mars 2009 à 01:24
Montre aussi le code dont tu te sers pour passer en mode plein écran.
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Utilisateur anonyme
13 mars 2009 à 07:40
13 mars 2009 à 07:40
Merci beaucoup de t'intéresser à mon problème.
Je suis sous windows vista avec un ordinateur d'assez bonne puissance.
Voici le code :
import java.awt.DisplayMode;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JComponent;
import javax.swing.JWindow;
public class Test {
/**
* Classe main
* @param args
*/
public static void main(String[] args) {
//mettre l'écran en résolution 1280*1024
GraphicsDevice device = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
DisplayMode mode = new DisplayMode(400, 400, 32, DisplayMode.REFRESH_RATE_UNKNOWN);
if(device.isDisplayChangeSupported()){
device.setDisplayMode(mode);
}
Canvas jc = new Canvas();
jc.setBackground(Color.WHITE);
device.setFullScreenWindow(jc);
GUIHelper.showOnFrame(jc);
}
}
@SuppressWarnings("serial")
class Canvas extends JWindow {
public void paint(Graphics g) {
Color c = g.getColor();
g.setColor(Color.RED);
g.fillRect(10,10,80,80);
g.setColor(Color.BLUE);
g.fillOval(150,50,80,80);
g.setColor(c);
}
}
@SuppressWarnings("serial")
class GUIHelper {
public static void showOnFrame(JWindow component) {
JWindow frame = new JWindow();
WindowAdapter wa = new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
};
frame.addWindowListener(wa);
frame.getContentPane().add(component);
frame.pack();
frame.setVisible(true);
}
}
<!-- Code colorisé via http://tools.codes-sources.com/colorizeCode.aspx
(Merci de conserver ce commentaire si vous utilisez ce code html) -->
La classe de dessin est codé de manière "bourrin", c'est juste pour un test je ne sais pas dessiner dans une JWindow sinon.
Le but au final, c'est de travailler grâce à jogl en opengl dans la JWindow, pour ça je fais une jwindow, je change ma résolution d'écran, et je mets la JWindow en mode plein écran.
Ensuite je compte mettre un canvas de JOGL pour swing dedans pour faire de l'open GL.
Merci d'avance si tu vois la solution pour la résolution d'écran.
++ et bonne prog
PS : c'est quoi le problème de serial sous eclipse pour mes deux classes à la fin, serializable class ?
PS 2: chapeau pour ton FPS, j'y avais déjà joué, connaitrais-tu des tutos sympas en JOGL, j'en ai peu pour commencer.
PS 3: c'est bien un canvas de jogl qu'il faut mettre dans ma jwindow, et ce canvas doit être celui adapté pour swing, c'est le ***Panel (je ne sais plus le nom, je regarderai cela ce soir) ?
Je suis sous windows vista avec un ordinateur d'assez bonne puissance.
Voici le code :
import java.awt.DisplayMode;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JComponent;
import javax.swing.JWindow;
public class Test {
/**
* Classe main
* @param args
*/
public static void main(String[] args) {
//mettre l'écran en résolution 1280*1024
GraphicsDevice device = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
DisplayMode mode = new DisplayMode(400, 400, 32, DisplayMode.REFRESH_RATE_UNKNOWN);
if(device.isDisplayChangeSupported()){
device.setDisplayMode(mode);
}
Canvas jc = new Canvas();
jc.setBackground(Color.WHITE);
device.setFullScreenWindow(jc);
GUIHelper.showOnFrame(jc);
}
}
@SuppressWarnings("serial")
class Canvas extends JWindow {
public void paint(Graphics g) {
Color c = g.getColor();
g.setColor(Color.RED);
g.fillRect(10,10,80,80);
g.setColor(Color.BLUE);
g.fillOval(150,50,80,80);
g.setColor(c);
}
}
@SuppressWarnings("serial")
class GUIHelper {
public static void showOnFrame(JWindow component) {
JWindow frame = new JWindow();
WindowAdapter wa = new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
};
frame.addWindowListener(wa);
frame.getContentPane().add(component);
frame.pack();
frame.setVisible(true);
}
}
<!-- Code colorisé via http://tools.codes-sources.com/colorizeCode.aspx
(Merci de conserver ce commentaire si vous utilisez ce code html) -->
La classe de dessin est codé de manière "bourrin", c'est juste pour un test je ne sais pas dessiner dans une JWindow sinon.
Le but au final, c'est de travailler grâce à jogl en opengl dans la JWindow, pour ça je fais une jwindow, je change ma résolution d'écran, et je mets la JWindow en mode plein écran.
Ensuite je compte mettre un canvas de JOGL pour swing dedans pour faire de l'open GL.
Merci d'avance si tu vois la solution pour la résolution d'écran.
++ et bonne prog
PS : c'est quoi le problème de serial sous eclipse pour mes deux classes à la fin, serializable class ?
PS 2: chapeau pour ton FPS, j'y avais déjà joué, connaitrais-tu des tutos sympas en JOGL, j'en ai peu pour commencer.
PS 3: c'est bien un canvas de jogl qu'il faut mettre dans ma jwindow, et ce canvas doit être celui adapté pour swing, c'est le ***Panel (je ne sais plus le nom, je regarderai cela ce soir) ?
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Utilisateur anonyme
13 mars 2009 à 07:43
13 mars 2009 à 07:43
Voici le code, je ne sais pas pourquoi il ne veut pas mettre mon code colorisé.
import java.awt.DisplayMode;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JComponent;
import javax.swing.JWindow;
public class Test {
/**
* Classe main
* @param args
*/
public static void main(String[] args) {
//mettre l'écran en résolution 1280*1024
GraphicsDevice device = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
DisplayMode mode = new DisplayMode(400, 400, 32, DisplayMode.REFRESH_RATE_UNKNOWN);
if(device.isDisplayChangeSupported()){
device.setDisplayMode(mode);
}
Canvas jc = new Canvas();
jc.setBackground(Color.WHITE);
device.setFullScreenWindow(jc);
GUIHelper.showOnFrame(jc);
}
}
@SuppressWarnings("serial")
class Canvas extends JWindow {
public void paint(Graphics g) {
Color c = g.getColor();
g.setColor(Color.RED);
g.fillRect(10,10,80,80);
g.setColor(Color.BLUE);
g.fillOval(150,50,80,80);
g.setColor(c);
}
}
@SuppressWarnings("serial")
class GUIHelper {
public static void showOnFrame(JWindow component) {
JWindow frame = new JWindow();
WindowAdapter wa = new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
};
frame.addWindowListener(wa);
frame.getContentPane().add(component);
frame.pack();
frame.setVisible(true);
}
}
++ et bonne prog
import java.awt.DisplayMode;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JComponent;
import javax.swing.JWindow;
public class Test {
/**
* Classe main
* @param args
*/
public static void main(String[] args) {
//mettre l'écran en résolution 1280*1024
GraphicsDevice device = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
DisplayMode mode = new DisplayMode(400, 400, 32, DisplayMode.REFRESH_RATE_UNKNOWN);
if(device.isDisplayChangeSupported()){
device.setDisplayMode(mode);
}
Canvas jc = new Canvas();
jc.setBackground(Color.WHITE);
device.setFullScreenWindow(jc);
GUIHelper.showOnFrame(jc);
}
}
@SuppressWarnings("serial")
class Canvas extends JWindow {
public void paint(Graphics g) {
Color c = g.getColor();
g.setColor(Color.RED);
g.fillRect(10,10,80,80);
g.setColor(Color.BLUE);
g.fillOval(150,50,80,80);
g.setColor(c);
}
}
@SuppressWarnings("serial")
class GUIHelper {
public static void showOnFrame(JWindow component) {
JWindow frame = new JWindow();
WindowAdapter wa = new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
};
frame.addWindowListener(wa);
frame.getContentPane().add(component);
frame.pack();
frame.setVisible(true);
}
}
++ et bonne prog
Utilisateur anonyme
13 mars 2009 à 11:02
13 mars 2009 à 11:02
Utilise ça quand tu lances ton application de préférence :
-Dsun.java2d.noddraw=true
Tu as l'équivalent aussi pour les applets et pour Java Webstart. Bon courage.
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
-Dsun.java2d.noddraw=true
Tu as l'équivalent aussi pour les applets et pour Java Webstart. Bon courage.
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Utilisateur anonyme
13 mars 2009 à 12:52
13 mars 2009 à 12:52
Merci beaucoup de ton aide.
Sinon je n'ai pas trouvé de tutorial sur ton site
Je vais tester dès ce soir ta méthode.
Si je peux te poser quelques questions :
- je vais donc utiliser awt, cependant swing gère l'affichage dans un thread à part il me semble, faut-il alors créer soi-même un thread pour gérer l'affichage awt, ou comme il s'agit juste d'une simple fenêtre où je travaille dedans avec opengl, faut-il faire le thread sur ce que je fais avec opengl et jogl ?
- c'est quoi directdraw (je ne développe pas pour le web )
- si je veux distribuer mon appli, je mets le jogl.jar dans le bon package où j'ai mon appli, mais où dois-je mettre la dll de jogl ?
- si j'ai bien compris, il faut d'abord créer sa fenêtre, et après changer la résolution de l'écran ?
- enfin, pourquoi faire une frame undecorated et pas l'équivalent d'une jwindow qui doit être une window en awt ?
Merci d'avance et désolé pour toutes ces questions, j'ai la doc de l'api java, mais c'est pas toujours clair, il faut sûrement prendre l'habitude.
++ et bonne prog
Sinon je n'ai pas trouvé de tutorial sur ton site
Je vais tester dès ce soir ta méthode.
Si je peux te poser quelques questions :
- je vais donc utiliser awt, cependant swing gère l'affichage dans un thread à part il me semble, faut-il alors créer soi-même un thread pour gérer l'affichage awt, ou comme il s'agit juste d'une simple fenêtre où je travaille dedans avec opengl, faut-il faire le thread sur ce que je fais avec opengl et jogl ?
- c'est quoi directdraw (je ne développe pas pour le web )
- si je veux distribuer mon appli, je mets le jogl.jar dans le bon package où j'ai mon appli, mais où dois-je mettre la dll de jogl ?
- si j'ai bien compris, il faut d'abord créer sa fenêtre, et après changer la résolution de l'écran ?
- enfin, pourquoi faire une frame undecorated et pas l'équivalent d'une jwindow qui doit être une window en awt ?
Merci d'avance et désolé pour toutes ces questions, j'ai la doc de l'api java, mais c'est pas toujours clair, il faut sûrement prendre l'habitude.
++ et bonne prog
Utilisateur anonyme
13 mars 2009 à 13:23
13 mars 2009 à 13:23
Pardon j'ai oublié de mettre le lien je crois : http://tuer.developpez.com/
Que tu sois dans Swing ou dans AWT, l'affichage est toujours fait dans l'Event Dispatching Thread. OpenGL ne doit être appelé que dans ce thread mais c'est assez facile, seule la méthode display(GLAutoDrawable drawable) doit dessiner dans le canevas, c'est aussi simple que ça. Tu peux soit utiliser un Animator qui va raffraîchir le canevas tout seul, soit raffraîchir le canevas explicitement dans ta boucle principale.
OpenGL et DirectDraw/Direct3D sont deux API qui permettent d'accéder à l'accélération graphique matérielle. Il ne faut pas les utiliser en même temps. C'est pourquoi il faut désactiver DirectDraw pour éviter que ça pose problème au niveau de la couche de pilotes.
Pour distribuer ton application, oublie les DLL sauf si tu veux absolument priver les utilisateurs de Linux de la possibilité de tester ton programme. Regarde dans mon tutoriel, j'explique comment faire ça. Il faut juste rajouter une ligne dans le fichier JNLP et Java Webstart va charger l'extension JOGL avec les bons JAR et les bons modules natifs, ce n'est pas à toi de t'en préoccuper. Regarde dans la rubrique 5.4 de mon tutoriel.
Il faut d'abord créer la fenêtre, passer en mode exclusive fullscreen et alors tu as le droit de changer la résolution (certains systèmes n'autorisent que le mode plein écran mais pas le changement de résolution).
N'utilise pas une Window pour cette raison :
A window must have either a frame, dialog, or another window defined as its
owner when it's constructed.
Ca sort de la documentation. Dans tous les cas, il te faut au moins une Frame en AWT.
Tiens-moi au courant pour la suite.
Bonne programmation :)
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Que tu sois dans Swing ou dans AWT, l'affichage est toujours fait dans l'Event Dispatching Thread. OpenGL ne doit être appelé que dans ce thread mais c'est assez facile, seule la méthode display(GLAutoDrawable drawable) doit dessiner dans le canevas, c'est aussi simple que ça. Tu peux soit utiliser un Animator qui va raffraîchir le canevas tout seul, soit raffraîchir le canevas explicitement dans ta boucle principale.
OpenGL et DirectDraw/Direct3D sont deux API qui permettent d'accéder à l'accélération graphique matérielle. Il ne faut pas les utiliser en même temps. C'est pourquoi il faut désactiver DirectDraw pour éviter que ça pose problème au niveau de la couche de pilotes.
Pour distribuer ton application, oublie les DLL sauf si tu veux absolument priver les utilisateurs de Linux de la possibilité de tester ton programme. Regarde dans mon tutoriel, j'explique comment faire ça. Il faut juste rajouter une ligne dans le fichier JNLP et Java Webstart va charger l'extension JOGL avec les bons JAR et les bons modules natifs, ce n'est pas à toi de t'en préoccuper. Regarde dans la rubrique 5.4 de mon tutoriel.
Il faut d'abord créer la fenêtre, passer en mode exclusive fullscreen et alors tu as le droit de changer la résolution (certains systèmes n'autorisent que le mode plein écran mais pas le changement de résolution).
N'utilise pas une Window pour cette raison :
A window must have either a frame, dialog, or another window defined as its
owner when it's constructed.
Ca sort de la documentation. Dans tous les cas, il te faut au moins une Frame en AWT.
Tiens-moi au courant pour la suite.
Bonne programmation :)
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Utilisateur anonyme
13 mars 2009 à 14:16
13 mars 2009 à 14:16
Merci beaucoup pour toute ton aide, je vais tester tout ça ce soir.
A window must have either a frame, dialog, or another window defined as its owner when it's constructed.
Cela signifie que pour avoir une window, il faut la mettre dans un conteneur comme une frame ?
Quel est l'intérêt d'une window, je pensais que c'était comme une frame mais sans barre (undecorated) ?
J'ai de toute façon beaucoup de mal entre les différents termes canvas, container, component, ...
"Pour distribuer ton application, oublie les DLL"
Ce sera à chaque utilisateur d'aller chercher les dll ou les .so selon le système, c'est ça ?
Je ne compte pas faire une javawebstart pour le moment, peut-être quand l'application sera plus ou moins développé.
Est-ce qu'on peut désactiver le directdraw directement dans le code java, et le remettre à la fin de l'application ?
"javagaming.org, nous serons heureux d'aider un programmeur de jeux en Java :D"
Merci beaucoup pour tout le temps que tu prends à aider des pauvres programmeurs comme moi.
Mais je ne programme pas de jeu, en tout cas pas pour le moment, j'essaye avec un ami de coder un modeste moteur 3D, par la suite un moteur de jeu, dans le but de faire quelque chose de simple mais que nous connaitrons dans les moindres détails pour faire des jeux, et qui serait adapté à nos besoins exacts (orientation RTS du moteur).
++ et bonne prog
PS : ne t'inquiète pas, je te tiendrai au courant de l'avancée du projet, mais pour le moment nous sommes en SUP, et donc pas le temps de programmer ET DE faire un site web, donc je poserai sûrement beaucoup de questions sur le forum, ce qui permettera de voir où on en est.
De toute façon on veut faire un code open source, donc si tu veux les sources y a aucn problème, mais pour le moment y a rien, on en est juste à réfléchir à l'architecture du moteur et on veut tester JOGL awt.
A window must have either a frame, dialog, or another window defined as its owner when it's constructed.
Cela signifie que pour avoir une window, il faut la mettre dans un conteneur comme une frame ?
Quel est l'intérêt d'une window, je pensais que c'était comme une frame mais sans barre (undecorated) ?
J'ai de toute façon beaucoup de mal entre les différents termes canvas, container, component, ...
"Pour distribuer ton application, oublie les DLL"
Ce sera à chaque utilisateur d'aller chercher les dll ou les .so selon le système, c'est ça ?
Je ne compte pas faire une javawebstart pour le moment, peut-être quand l'application sera plus ou moins développé.
Est-ce qu'on peut désactiver le directdraw directement dans le code java, et le remettre à la fin de l'application ?
"javagaming.org, nous serons heureux d'aider un programmeur de jeux en Java :D"
Merci beaucoup pour tout le temps que tu prends à aider des pauvres programmeurs comme moi.
Mais je ne programme pas de jeu, en tout cas pas pour le moment, j'essaye avec un ami de coder un modeste moteur 3D, par la suite un moteur de jeu, dans le but de faire quelque chose de simple mais que nous connaitrons dans les moindres détails pour faire des jeux, et qui serait adapté à nos besoins exacts (orientation RTS du moteur).
++ et bonne prog
PS : ne t'inquiète pas, je te tiendrai au courant de l'avancée du projet, mais pour le moment nous sommes en SUP, et donc pas le temps de programmer ET DE faire un site web, donc je poserai sûrement beaucoup de questions sur le forum, ce qui permettera de voir où on en est.
De toute façon on veut faire un code open source, donc si tu veux les sources y a aucn problème, mais pour le moment y a rien, on en est juste à réfléchir à l'architecture du moteur et on veut tester JOGL awt.
Utilisateur anonyme
13 mars 2009 à 16:37
13 mars 2009 à 16:37
Le plus simple est de ne pas t'embêter avec une Window et de faire juste une Frame.
Non ce ne sera pas à chaque utilisateur d'aller chercher ce qu'il lui faut (ou alors les programmeurs installeront eux-mêmes JOGL comme je l'ai fait). L'intérêt de Java Webstart est que l'utilisateur clique sur OK et ça roule, rien de plus. Cela permet aux gens de tester le produit régulièrement et c'est facile à faire, tu fais un ou plusieurs JAR, tu fourres tout dedans, tu fais un fichier JNLP et c'est tout. Par la suite, tu mets juste à jour ton ou tes JAR, ça prend très peu de temps. Au pire, je t'aiderai à écrire ce fichier JNLP, on aura à mettre à jour l'URL vers tes propres JAR. Cela permet d'avoir des retours réguliers des bêta testeurs, ça encourage les gens à suivre le projet, c'est plus motivant.
On ne peut pas désactiver DirectDraw à l'intérieur du code Java mais quand la JVM finit son exécution, elle remet tout au propre.
Je te préviens quand même qu'écrire un moteur 3D nécessite des années, c'est ce que j'ai fait. Ca permet d'apprendre beaucoup de choses mais je ne suis pas sûr que ce soit la meilleure solution sur le long terme sauf si tu fais de la recherche algorithmique (ce qui a été mon cas). Certains moteurs 3D sont assez simples à utiliser, je pense notamment à JPCT, JMonkeyEngine, Xith3D, Avengina... Il est assez difficile de maintenir un moteur 3D uniquement pour ses propres besoins. Tu vas rencontrer les mêmes problèmes que moi, j'espère que tu ne te décourageras pas. Bon courage.
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Non ce ne sera pas à chaque utilisateur d'aller chercher ce qu'il lui faut (ou alors les programmeurs installeront eux-mêmes JOGL comme je l'ai fait). L'intérêt de Java Webstart est que l'utilisateur clique sur OK et ça roule, rien de plus. Cela permet aux gens de tester le produit régulièrement et c'est facile à faire, tu fais un ou plusieurs JAR, tu fourres tout dedans, tu fais un fichier JNLP et c'est tout. Par la suite, tu mets juste à jour ton ou tes JAR, ça prend très peu de temps. Au pire, je t'aiderai à écrire ce fichier JNLP, on aura à mettre à jour l'URL vers tes propres JAR. Cela permet d'avoir des retours réguliers des bêta testeurs, ça encourage les gens à suivre le projet, c'est plus motivant.
On ne peut pas désactiver DirectDraw à l'intérieur du code Java mais quand la JVM finit son exécution, elle remet tout au propre.
Je te préviens quand même qu'écrire un moteur 3D nécessite des années, c'est ce que j'ai fait. Ca permet d'apprendre beaucoup de choses mais je ne suis pas sûr que ce soit la meilleure solution sur le long terme sauf si tu fais de la recherche algorithmique (ce qui a été mon cas). Certains moteurs 3D sont assez simples à utiliser, je pense notamment à JPCT, JMonkeyEngine, Xith3D, Avengina... Il est assez difficile de maintenir un moteur 3D uniquement pour ses propres besoins. Tu vas rencontrer les mêmes problèmes que moi, j'espère que tu ne te décourageras pas. Bon courage.
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Utilisateur anonyme
13 mars 2009 à 19:11
13 mars 2009 à 19:11
Je te demanderai ton aide pour le javawebstart quand j'aurai quelque chose de concret, et si je trouve un site pour héberger mon projet pour ne pas avoir besoin d'entretenir tout un site.
Je teste ton code ce soir et je te tiens informé.
Quant au moteur 3D je t'explique
Je ne veux pas faire mon moteur pour faire un jeu avec, je veux plutôt faire mon moteur pour le plaisir et apprendre, et si un jour il marche bien, je l'utiliserai. Disons juste que je sais par contre ce que je veux qu'il fasse et pour quel genre de jeux il sera le mieux.
Je m'intéresse beaucoup à l'algorithmique, disons que j'ai envie d'apprendre, je note tout ce que je vais faire sur un papier, et je cherche des moyens de le résoudre.
Là, par exemple, ça fait une semaine qu'on cherche avec mon pote comment sélectionner un gars sur la carte.
On compte créer une map aux reliefs aléatoires avec certains points (point au sens de point dans l'espace) "cles". On interpole ces points par de bonnes fonctions. On récupère les points de cette fonction régulièrement avec un certain pas.
On crée un tableau de cases qui permets de savoir l'altitude du relief z à un certain point (x,y).
On veut que quand l'utilisateur clique sur un gars, il soit séléctionné.
Notre idée c'est de faire une correspondance entre les coordonnées de la souris sur l'écran et les coordonnées (x,y) sur la map selon comment est la caméra. Mais comme algo ça a l'air TRES dur, donc on se demande comment faire sinon. En effet, l'ecran est un carré, alors que la caméra voit un trapèze sur la map 3D à cause de la perspective.
Tout ça c'est du raisonnement papier, on ne sait même pas si c'est la bonne façon de faire pour un RTS, de diviser la map en cases. C'est ce qui a l'air de plus simple à gérer, pour le pathfinding, la montée d'un gars sur une pente, ..., puisque qu'à chaque (x,y) on connait z.
Mais en programmation on commence par le côté 3D, on va faire en premier une classe de rendu qui implémente toutes les fonctions de JOGL dont nous nous servirons. Ce sera une classe abstraite, et toutes les autres classes, par exemple le loader, hériteront de cette classe pour faire abstraction de JOGL. Je pourrai te détailler l'architecture si t'as envie.
Enfin bon plein de problèmes, d'un côté on cherche pour la structure d'un RTS tous les algos, et d'un autre on commence à coder le moteur 3D. Tandis que le moteur d'intelligence artificielle, gestion des évènements, ... qui utiliseront tous ces algos viendront beaucoup plus tard.
Enfin en tout cas merci pour toute ton aide, ce soir je teste ton code et essaye JOGL, pour voir si je l'ai bien installé. J'espère que les methodes JOGL sont les mêmes que opengl, car mon pote a déjà fait du code en C pour des trucs simples en opengl (c'est moi qui l'ai converti à apprendre le java).
++ et bonne prog
Je teste ton code ce soir et je te tiens informé.
Quant au moteur 3D je t'explique
Je ne veux pas faire mon moteur pour faire un jeu avec, je veux plutôt faire mon moteur pour le plaisir et apprendre, et si un jour il marche bien, je l'utiliserai. Disons juste que je sais par contre ce que je veux qu'il fasse et pour quel genre de jeux il sera le mieux.
Je m'intéresse beaucoup à l'algorithmique, disons que j'ai envie d'apprendre, je note tout ce que je vais faire sur un papier, et je cherche des moyens de le résoudre.
Là, par exemple, ça fait une semaine qu'on cherche avec mon pote comment sélectionner un gars sur la carte.
On compte créer une map aux reliefs aléatoires avec certains points (point au sens de point dans l'espace) "cles". On interpole ces points par de bonnes fonctions. On récupère les points de cette fonction régulièrement avec un certain pas.
On crée un tableau de cases qui permets de savoir l'altitude du relief z à un certain point (x,y).
On veut que quand l'utilisateur clique sur un gars, il soit séléctionné.
Notre idée c'est de faire une correspondance entre les coordonnées de la souris sur l'écran et les coordonnées (x,y) sur la map selon comment est la caméra. Mais comme algo ça a l'air TRES dur, donc on se demande comment faire sinon. En effet, l'ecran est un carré, alors que la caméra voit un trapèze sur la map 3D à cause de la perspective.
Tout ça c'est du raisonnement papier, on ne sait même pas si c'est la bonne façon de faire pour un RTS, de diviser la map en cases. C'est ce qui a l'air de plus simple à gérer, pour le pathfinding, la montée d'un gars sur une pente, ..., puisque qu'à chaque (x,y) on connait z.
Mais en programmation on commence par le côté 3D, on va faire en premier une classe de rendu qui implémente toutes les fonctions de JOGL dont nous nous servirons. Ce sera une classe abstraite, et toutes les autres classes, par exemple le loader, hériteront de cette classe pour faire abstraction de JOGL. Je pourrai te détailler l'architecture si t'as envie.
Enfin bon plein de problèmes, d'un côté on cherche pour la structure d'un RTS tous les algos, et d'un autre on commence à coder le moteur 3D. Tandis que le moteur d'intelligence artificielle, gestion des évènements, ... qui utiliseront tous ces algos viendront beaucoup plus tard.
Enfin en tout cas merci pour toute ton aide, ce soir je teste ton code et essaye JOGL, pour voir si je l'ai bien installé. J'espère que les methodes JOGL sont les mêmes que opengl, car mon pote a déjà fait du code en C pour des trucs simples en opengl (c'est moi qui l'ai converti à apprendre le java).
++ et bonne prog
Utilisateur anonyme
13 mars 2009 à 21:23
13 mars 2009 à 21:23
Bonne nouvelle, le code marche, JOGL marche donc aussi, c'est une très bonne chose
Cependant je me permets de te poser quelques questions sur ton code (j'ai modifié 2 3 trucs qui n'étaient pas bon, faute dans la méthode getRefreshRate au lieu de je ne sais plus et 1ou 2 variables différentes pour désigner la même chose (device et MyDevice).
Ou est le thread EDT d'awt ?
Quel est l'intérêt de cette méthode ? frame.setIgnoreRepaint(true);
Pourquoi faire cette méthode si au final on met la fenêtre en plein écran ? frame.setSize(screenWidth,screenHeight);
Pourquoi vouloir que l'utilisateur change la taille de la fenêtre ? frame.setResizable(true);
canvas.setAutoSwapBufferMode(false); Ca complique les choses, il faut swapper les buffers manuellement ? (je sais pas ce qu'est swapper les buffers ^^, ni même ce qu'est un buffer, enfin pour moi c'est un tampon qui stocke les données pour réaliser l'affichage en un bloc et d'un coup)
//TODO: add your GLEventListener here : faut faire un thread à part pour gérer les évenements ? jJavais prévu d'implémenter les évenements dans une classe à part.
Merci d'avance
++ et bonne prog
Cependant je me permets de te poser quelques questions sur ton code (j'ai modifié 2 3 trucs qui n'étaient pas bon, faute dans la méthode getRefreshRate au lieu de je ne sais plus et 1ou 2 variables différentes pour désigner la même chose (device et MyDevice).
Ou est le thread EDT d'awt ?
Quel est l'intérêt de cette méthode ? frame.setIgnoreRepaint(true);
Pourquoi faire cette méthode si au final on met la fenêtre en plein écran ? frame.setSize(screenWidth,screenHeight);
Pourquoi vouloir que l'utilisateur change la taille de la fenêtre ? frame.setResizable(true);
canvas.setAutoSwapBufferMode(false); Ca complique les choses, il faut swapper les buffers manuellement ? (je sais pas ce qu'est swapper les buffers ^^, ni même ce qu'est un buffer, enfin pour moi c'est un tampon qui stocke les données pour réaliser l'affichage en un bloc et d'un coup)
//TODO: add your GLEventListener here : faut faire un thread à part pour gérer les évenements ? jJavais prévu d'implémenter les évenements dans une classe à part.
Merci d'avance
++ et bonne prog
Utilisateur anonyme
13 mars 2009 à 21:42
13 mars 2009 à 21:42
J'arrête après ça, promis, mais j'ai oublié encore deux trois questions.
La gestion des évènements, c'est gérer par AWT, pas par JOGL, et il faut le faire sur le canvas GLcanvas, pas sur la frame, c'est bien ça ?
Et l'appel des méthodes d'openGL, ça se passe dans le thread EDT, c'est bien ça ? Mais alors le thread EDT est différent pour chaque canvas ?
Enfin il faut swapper les buffers manuellement pour l'affichage, dans la boucle princpale, et rafraichir la frame dans la boucle principale aussi ?
Au fait si tu avais un tuto sympa sur l'affichage, parce qu'entre les fonctions d'affichage, et utiliser AWT ou JOGL, je suis un peu largué
Merci d'avance de toute ton aide apportée et de tout le temps que tu prends pour aider peut-être un projet à naître
++ et bonne prog
PS : quand je tape thread EDT je tombe que sur des trucs swing dans google
La gestion des évènements, c'est gérer par AWT, pas par JOGL, et il faut le faire sur le canvas GLcanvas, pas sur la frame, c'est bien ça ?
Et l'appel des méthodes d'openGL, ça se passe dans le thread EDT, c'est bien ça ? Mais alors le thread EDT est différent pour chaque canvas ?
Enfin il faut swapper les buffers manuellement pour l'affichage, dans la boucle princpale, et rafraichir la frame dans la boucle principale aussi ?
Au fait si tu avais un tuto sympa sur l'affichage, parce qu'entre les fonctions d'affichage, et utiliser AWT ou JOGL, je suis un peu largué
Merci d'avance de toute ton aide apportée et de tout le temps que tu prends pour aider peut-être un projet à naître
++ et bonne prog
PS : quand je tape thread EDT je tombe que sur des trucs swing dans google
Utilisateur anonyme
13 mars 2009 à 22:09
13 mars 2009 à 22:09
Apparemment, tu n'as pas fait attention aux commentaires écrits dans la langue de Shakespeare. Pour le code, j'avais écrit ça à l'arrache, il se peut que tu aies eu à modifier quelques petites choses mais il faudra que tu me montres ce que tu as fait pour que je sois sûr que ça marchera partout.
Tu ne manipules pas le processus léger (thread) EDT directement, c'est implicite mais tu peux vérifier que tu es dessus, j'ai oublié le nom de la méthode :s
frame.setIgnoreRepaint(true); permet de ne repeindre que ce qui est dans la fenêtre, notre canevas en l'occurrence, ça améliore les performances.
frame.setSize(screenWidth,screenHeight); permet de donner à la fenêtre la taille de l'écran au cas où un testeur serait sur un système qui ne supporte pas du tout l'exclusive full-screen mode, ça peut arriver, il faut le prendre en compte.
frame.setResizable(true); permet juste de contourner un bogue de Metacity sous Linux qui faisait que la barre des tâches se dessinait par dessus
canvas.setAutoSwapBufferMode(false); empêche le canevas de se raffraîchir à des moments peut-être inopportuns. Tu permutes les tampons toi-même à la fin de la méthode display(GLAutoDrawable drawable) de ton GLEventListener en appelant glSwapBuffers.
Un GLEventListener va justement te permettre de faire une classe à part (pas besoin d'un autre thread) qui va se comporter comme GLUT, il va gérer l'affichage, l'initialisation, les cas où la configuration de l'affichage change à l'exécution... Regarde la documentation de JOGL.
AWT et JOGL sont très liés en fait, tu ne peux pas utiliser JOGL sans AWT sauf dans la future version 2.0. C'est bien le canevas qui devra capter les événements, pas la Frame. Une erreur de débutant serait de mélanger les deux... Cependant, ça reste des événements AWT.
OpenGL est intrinsèquement single-threadée. Il y a un seul processus léger pour un contexte OpenGL à ma connaissance. Il est plutôt rare d'utiliser plusieurs canevas OpenGL dans une même fenêtre.
Il faut permuter les tampons uniquement dans la méthode display(GLAutoDrawable drawable) de ton GLEventListener, ta boucle va juste appeler la méthode display() du canevas.
Je t'ai orienté vers mon tutoriel et je te conseille de jeter un coup d'oeil à mon code source, notamment la classe main.GameGLView et main.GameController.
Bonne programmation
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Tu ne manipules pas le processus léger (thread) EDT directement, c'est implicite mais tu peux vérifier que tu es dessus, j'ai oublié le nom de la méthode :s
frame.setIgnoreRepaint(true); permet de ne repeindre que ce qui est dans la fenêtre, notre canevas en l'occurrence, ça améliore les performances.
frame.setSize(screenWidth,screenHeight); permet de donner à la fenêtre la taille de l'écran au cas où un testeur serait sur un système qui ne supporte pas du tout l'exclusive full-screen mode, ça peut arriver, il faut le prendre en compte.
frame.setResizable(true); permet juste de contourner un bogue de Metacity sous Linux qui faisait que la barre des tâches se dessinait par dessus
canvas.setAutoSwapBufferMode(false); empêche le canevas de se raffraîchir à des moments peut-être inopportuns. Tu permutes les tampons toi-même à la fin de la méthode display(GLAutoDrawable drawable) de ton GLEventListener en appelant glSwapBuffers.
Un GLEventListener va justement te permettre de faire une classe à part (pas besoin d'un autre thread) qui va se comporter comme GLUT, il va gérer l'affichage, l'initialisation, les cas où la configuration de l'affichage change à l'exécution... Regarde la documentation de JOGL.
AWT et JOGL sont très liés en fait, tu ne peux pas utiliser JOGL sans AWT sauf dans la future version 2.0. C'est bien le canevas qui devra capter les événements, pas la Frame. Une erreur de débutant serait de mélanger les deux... Cependant, ça reste des événements AWT.
OpenGL est intrinsèquement single-threadée. Il y a un seul processus léger pour un contexte OpenGL à ma connaissance. Il est plutôt rare d'utiliser plusieurs canevas OpenGL dans une même fenêtre.
Il faut permuter les tampons uniquement dans la méthode display(GLAutoDrawable drawable) de ton GLEventListener, ta boucle va juste appeler la méthode display() du canevas.
Je t'ai orienté vers mon tutoriel et je te conseille de jeter un coup d'oeil à mon code source, notamment la classe main.GameGLView et main.GameController.
Bonne programmation
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Utilisateur anonyme
13 mars 2009 à 23:21
13 mars 2009 à 23:21
J'essaye demain de faire ça, et de comprendre le GLEventListener ainsi que le reste. Je vais me lancer pour voir ce que cela donne, de toute façon j'utiliserai encore beaucoup le forum Je pense que sans test on arrive à rien, je vais bien devoir m'habituer à la doc de l'api un jour.
Et sinon que penses-tu de ma manière de créer une map, expliquée en haut de cette page ?
++ et bonne prog
PS : ton jeu gère t'il des shaders ? (HS je sais, mais je me renseigne un peu sur les techniques qui se font)
Et sinon que penses-tu de ma manière de créer une map, expliquée en haut de cette page ?
++ et bonne prog
PS : ton jeu gère t'il des shaders ? (HS je sais, mais je me renseigne un peu sur les techniques qui se font)
Utilisateur anonyme
14 mars 2009 à 00:01
14 mars 2009 à 00:01
Tu crées des points un peu aléatoirement (mais de façon paramétrée j'espère), tu génères alors une height map, ça tient la route, il faudra que j'y jette un coup d'oeil plus en détail.
Mon jeu n'utilise pas les shaders pour le moment car la priorité était de faire d'abord marcher mon FPS sur des bécanes modestes avant de mettre des trucs qui claquent et qui utilisent des extensions assez "récentes".
Bonne programmation
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Mon jeu n'utilise pas les shaders pour le moment car la priorité était de faire d'abord marcher mon FPS sur des bécanes modestes avant de mettre des trucs qui claquent et qui utilisent des extensions assez "récentes".
Bonne programmation
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Utilisateur anonyme
14 mars 2009 à 07:37
14 mars 2009 à 07:37
Merci beaucoup pour le nom de cette méthode. Je ne savais pas ce que c'était. Tu sais on essaye de trouver nous même nos idées, c'est dur de savoir tout ce qui se fait en matière de moteurs.
Les points créés sont bien sûr paramétrés, c'est pas du pur aléatoire, j'étais juste pas rentré dans les détails.
En tout je te redis merci pour tout, et sûrement à très bientôt sur un nouveau post, parce que programmer ne s'apprend pas en un jour
++ et bonne prog
Les points créés sont bien sûr paramétrés, c'est pas du pur aléatoire, j'étais juste pas rentré dans les détails.
En tout je te redis merci pour tout, et sûrement à très bientôt sur un nouveau post, parce que programmer ne s'apprend pas en un jour
++ et bonne prog
Utilisateur anonyme
14 mars 2009 à 08:15
14 mars 2009 à 08:15
Bonjour
Je te conseille de te documenter sur ce qui existe déjà au niveau algorithmique pour éviter de réinventer l'eau chaude et surtout car on fait rarement mieux.
Bonne programmation
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Je te conseille de te documenter sur ce qui existe déjà au niveau algorithmique pour éviter de réinventer l'eau chaude et surtout car on fait rarement mieux.
Bonne programmation
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
Utilisateur anonyme
14 mars 2009 à 11:25
14 mars 2009 à 11:25
Je me suis mal exprimé, je voulais dire qu'on trouve nos algos nous-mêmes parce que sur le net on ne trouve pas toujours tout.
Si je pouvais je réutiliserai tous les algos existant déjà.
Par exemple on va reprendre l'algorithme A* pour le pathfinding.
Et même si beaucoup d'algorithmes sont exposés sur internet, il y a très peu de chose sur la structure même d'un moteur, par exemple gérer une map avec un tableau cases (je rentrerai dans les détails quand on commencera cette partie là).
Déjà rien que trouvé des tutos clairs sur JOGL c'est le parcours du combattant.
Cet aprem si j'ai le temps je commence à faire ma classe de test qui permettera l'affichage, pour tester toutes les classes du moteur.
Si jamais, je te pose la question par hasard, vois tu comment faire un algo qui permetterait avec un clic de souris sur l'écran de séléctionner un personnage sur la carte ?
L'idée pour le moment, c'est donc de gérer la map avec des cases. Il y aura deux types de tableaux, un tableau 1 de la map dans le sens du relief, avec de toutes petites cases qui permetteront d'implémenter la heightmap. Un tableau 2 avec de grandes cases pour gérer le placement des personnages et bâtiments, pour le pathfinding, ...
Le tableau permettera de récupérer l'altitude en un point x,y, pour que le personnage suive le relief en permanence par exemple.
Le tableau repère le personnage de manière plus grossière.
Le but serait de faire une correspondance entre le clic souris sur l'écran(x,y) et un personnage sur la map.
Si le terrain est plat, aucun problème, on fait une correspondance entre les positions à l'écran et ce que voit la caméra (quoi que l'algo doit être dur).
Mais si le relief change, imaginons une montagne au milieu de l'écran, le sommet est apparaît logiquement en haut de l'écran puisque le terrain monte, mais la position du sommet sur la map, elle, correspond toujours au milieu de ce que voit la caméra. Je veux dire qu'une montagne au centre de la vision de la caméra cache sur l'écran le paysage derrière et apparaît jusqu'en haut de l'écran.
Donc même si 'lalgo précédent marchait, impossible ici.
J'ai donc pensé qu'il fallait faire "suivre" à la souris les coordonnées du relief, une sorte de correspond non plus en x,y mais bien en x,y,z. La position de la souris sur l'écran (x,y) correpsondrait à une position 3D sur la map (x,y,z) en fonction du placement de la caméra bien sûr.
Mais l'algo m'a l'air dur, je ne vois pas comment faire.
Je me demane donc en "vrai" dans les RTS, comme la séléction d'un personnage est géré.
Ne te casse pas la tête la-dessus, c'était juste pour savoir si il y avait une méthode connue là-dessus, et pour t'en apprendre à un peu plus sur les détails de notre projet
Bonne journée
++ et bonne prog
Si je pouvais je réutiliserai tous les algos existant déjà.
Par exemple on va reprendre l'algorithme A* pour le pathfinding.
Et même si beaucoup d'algorithmes sont exposés sur internet, il y a très peu de chose sur la structure même d'un moteur, par exemple gérer une map avec un tableau cases (je rentrerai dans les détails quand on commencera cette partie là).
Déjà rien que trouvé des tutos clairs sur JOGL c'est le parcours du combattant.
Cet aprem si j'ai le temps je commence à faire ma classe de test qui permettera l'affichage, pour tester toutes les classes du moteur.
Si jamais, je te pose la question par hasard, vois tu comment faire un algo qui permetterait avec un clic de souris sur l'écran de séléctionner un personnage sur la carte ?
L'idée pour le moment, c'est donc de gérer la map avec des cases. Il y aura deux types de tableaux, un tableau 1 de la map dans le sens du relief, avec de toutes petites cases qui permetteront d'implémenter la heightmap. Un tableau 2 avec de grandes cases pour gérer le placement des personnages et bâtiments, pour le pathfinding, ...
Le tableau permettera de récupérer l'altitude en un point x,y, pour que le personnage suive le relief en permanence par exemple.
Le tableau repère le personnage de manière plus grossière.
Le but serait de faire une correspondance entre le clic souris sur l'écran(x,y) et un personnage sur la map.
Si le terrain est plat, aucun problème, on fait une correspondance entre les positions à l'écran et ce que voit la caméra (quoi que l'algo doit être dur).
Mais si le relief change, imaginons une montagne au milieu de l'écran, le sommet est apparaît logiquement en haut de l'écran puisque le terrain monte, mais la position du sommet sur la map, elle, correspond toujours au milieu de ce que voit la caméra. Je veux dire qu'une montagne au centre de la vision de la caméra cache sur l'écran le paysage derrière et apparaît jusqu'en haut de l'écran.
Donc même si 'lalgo précédent marchait, impossible ici.
J'ai donc pensé qu'il fallait faire "suivre" à la souris les coordonnées du relief, une sorte de correspond non plus en x,y mais bien en x,y,z. La position de la souris sur l'écran (x,y) correpsondrait à une position 3D sur la map (x,y,z) en fonction du placement de la caméra bien sûr.
Mais l'algo m'a l'air dur, je ne vois pas comment faire.
Je me demane donc en "vrai" dans les RTS, comme la séléction d'un personnage est géré.
Ne te casse pas la tête la-dessus, c'était juste pour savoir si il y avait une méthode connue là-dessus, et pour t'en apprendre à un peu plus sur les détails de notre projet
Bonne journée
++ et bonne prog
Utilisateur anonyme
14 mars 2009 à 11:34
14 mars 2009 à 11:34
Essaie avec le picking. Bon courage.
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java
TUER : http://tuer.tuxfamily.org/tuer.php
yeah! vive java