TESSERACT, FPS java pour navigateur

Venez présenter vos projets et en donner des nouvelles. Pas de recrutement dans ce forum, merci.

Messagepar sebz » 10 Sep 2008, 10:07

OK ben je viendrai tester régulièrement, au cas où le problème se résorberait de lui même. Si je change de version de java (encore) je te tiens au courant.
Trululu
Avatar de l’utilisateur
sebz
Hello World, I'm new !
 
Messages: 109
Inscription: 16 Mai 2007, 09:05

Messagepar yoyonel » 10 Sep 2008, 10:34

J'ai teste :D

Ça commence a être bien class(e) !
Pas mal du tout les p'tits zozio qui volent et qui bombardent, bien sympa !
Ils facilitent le boulot pour le 1er niveau en plus !

Tu comptes diffuser tes sources de ce projet a un moment ?

YoYo
Avatar de l’utilisateur
yoyonel
Hello World, I'm new !
 
Messages: 105
Inscription: 12 Avr 2005, 21:25
Localisation: Lyon

Messagepar N_I_C_S » 10 Sep 2008, 12:04

@sebz
Merci, et désolé pour ces problèmes...

@yoyonel
Oui, tout à fait:) , quand le source sera bouclé je le mettrai en ligne sous GPL.
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Pas mal

Messagepar ninten » 18 Sep 2008, 19:43

Bonjour

Bon sang je suis très content de voir encore des jeux en Java en 3D!!! J'aime bien ton jeu, ça marche bien chez moi, c'est un bon début. Le problème est que j'ai du mal avec ta gestion de la souris et quand je tire sur les monstres volants, ils ne meurent pas.

J'ai lu les posts précédents, si tu as encore un problème avec le timer, sache que ça ne vient pas de Java mais du système en-dessous car sous Linux (Solaris aussi) j'ai une résolution de 1 ms et sous Windows c'est plutôt de l'ordre de 10 à 16 ms. Il y a quelques solutions de contournement, il faut aussi se méfier des processeurs AMD Dual Core, un membre de javagaming m'a montré que chez lui, par moment, le timer se comportait comme s'il remontait le temps pendant un très bref instant :00000018:

Enfin, comme tu as pu le voir, tu n'es pas le seul à faire des FPS sous forme d'applet, il y a déjà Art Attack de Vincent Stahl, Jake2 existe en version applet avec le Java Desktop Plug-In dans le JRE 1.6 update 10. Utiliser l'accélération matérielle n'est pas une contrainte de portabilité quand tu passes par OpenGL. Je ne vais pas te répéter ce que je t'ai déjà dit par email mais je te conseille vivement de garder ça dans un coin de ta tête quand tu commenceras à avoir des graphismes plus volumineux. Ton projet a un certain potentiel, n'hésite pas à le soumettre sur le FGF players' portal, nous manquons un peu de jeux en 3D. Bonne chance pour la suite en tout cas.

Java bien et toi?
ninten
 

Messagepar N_I_C_S » 19 Sep 2008, 00:56

Salut ninten,

merci pour tes commentaires et ton long e-mail, ça fait super plaisir de se voir accorder cette attention :cool: , je vais te répondre ici, ça sera plus simple...

D'abord, pour le petit laïus sur la page JavaGL, Tu as raisons, c'est plus du tout d'actualité et faut vraiment que je le change (il doit avoir 3 ans !)

Au sujet d'OpenGL, c'est vrai que c'est multi-plateforme mais ça reste quand même réservé minimum aux micro-ordinateurs. D'ailleurs c'est juste une spécification, après ce sont des cartes graphiques chères et sophistiquées qui se chargent de l'implémenter efficacement. En fait, mon but à terme est plutôt de viser les "petites" plate-formes : téléphones, mini-ordis, etc... Je vois bien Java 1.0 (ou du moins une version standard) arriver rapidement sur la plupart des mobiles, OpenGL peut-être pas tout de suite :D.

Pour l'utilisation sous-jacente par java, je dirais que les deux seules méthodes graphiques que le soft utilise ( fillPolygon() et drawLine() ) ont pour fonction d'afficher une forme 2D ou une ligne 2D monochrome. A mon avis, OpenGL doit pas monstrueusement accélérer ça ! Tous les systèmes ont une implémentation de base de ces fonctions très simples qu'un CPU exécute peut-être plus vite qu'une demande de fonction OpenGL ! Donc, qu'il y soit ou pas, je pense que ça n'a pas une réelle incidence sur les perfs du soft.

En plus, OpenGL est une technologie "pour grosse équipe". Je veux dire par là que pour l'exploiter à sa mesure et justifier d'utiliser ses énormes possibilités et les ressources que ça engendre, il faut produire un contenu en proportion ! Une lib énorme pour projets énormes...

Moi, mon but est tout autre : mon petit FPS vise très clairement le casual gaming. L'idée pour coller à cette évolution actuelle c'est : des applis très légères, une compatibilité "universelle", ...et de la 3D ! Et comme j'ai pas rencontré de techno adaptée à ces demandes, j'essaye de la faire ;) .

C'est aussi pour cette raison de compatibilité que je me tiens à une gestion rigoureusement standard du temps, et en bricolant un peu ça marche pas trop mal...

Cela dit, je me goure peut-être complètement de vision, et on aura bientôt des mobiles avec des grosses 8800GTX qui dépassent:D . Sérieusement, j'entends tes arguments, mais je tente une sorte de pari, ce qui fait qu'effectivement je m'em**rde peut-être pour rien...

Java bien et toi?

JBoss :D :D
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Messagepar ninten » 19 Sep 2008, 08:24

N_I_C_S a écrit:ça reste quand même réservé minimum aux micro-ordinateurs

Faux, il existe OpenGL-ES pour les téléphones et aussi son pendant Java qui s'appelle JOGL-ES.

N_I_C_S a écrit:D'ailleurs c'est juste une spécification, après ce sont des cartes graphiques chères et sophistiquées qui se chargent de l'implémenter efficacement. En fait, mon but à terme est plutôt de viser les "petites" plate-formes : téléphones, mini-ordis, etc... Je vois bien Java 1.0 (ou du moins une version standard) arriver rapidement sur la plupart des mobiles, OpenGL peut-être pas tout de suite :D.

Faux, mon jeu utilise OpenGL et il marche bien même avec une carte graphique de 2002. Comme beaucoup de logiciels même sous Windows utilisent OpenGL, les fondeurs sont obligés de fournir des pilotes décents et ce depuis de nombreuses années. De plus, JavaFX mobile arrive l'an prochain et a besoin d'accélération graphique, ça m'étonnerait que ça repose sur DirectX lol. Au final, les "petites" plateformes souffrent beaucoup plus que les grosses quand tu te contentes du rendu logiciel car quand tu as un petit processeur, en rendu logiciel avec Art Attack par exemple, tu descends vite sous la barre des 6 FPS et ça devient injouable alors qu'avec un jeu de la même complexité graphique avec un petit CPU et une "petite" carte graphique, en rendu matériel, tu restes proche des 20 FPS ce qui est à peu près jouable (et encore, sans scénographe, ce serait encore mieux avec :)).

N_I_C_S a écrit:Pour l'utilisation sous-jacente par java, je dirais que les deux seules méthodes graphiques que le soft utilise ( fillPolygon() et drawLine() ) ont pour fonction d'afficher une forme 2D ou une ligne 2D monochrome. A mon avis, OpenGL doit pas monstrueusement accélérer ça !

Raison de plus pour utiliser directement OpenGL. Ce que tu dis est faux, je te conseille d'aller voir dans les sources de Java, notamment dans les classes qui implémentent l'interface BufferedImageOp et tu verras qu'il y a en fait pas mal d'opérations qui sont accélérés par la carte, j'aurais pu donner d'autres exemples.

N_I_C_S a écrit:Tous les systèmes ont une implémentation de base de ces fonctions très simples qu'un CPU exécute peut-être plus vite qu'une demande de fonction OpenGL ! Donc, qu'il y soit ou pas, je pense que ça n'a pas une réelle incidence sur les perfs du soft.

Un appel de fonction OpenGL n'est pas lent, je ne sais pas d'où tu sors ça. Même si tu as une couche de support de rendu logiciel, quand tu as des pilotes pour ta carte graphique, l'OS se sert en priorité de la carte justement parce que c'est plus performant.

N_I_C_S a écrit:En plus, OpenGL est une technologie "pour grosse équipe". Je veux dire par là que pour l'exploiter à sa mesure et justifier d'utiliser ses énormes possibilités et les ressources que ça engendre, il faut produire un contenu en proportion ! Une lib énorme pour projets énormes...

C'est faux. Va sur d'autres forums de jeux Java dans la langue de Shakespeare et tu verras une foison de petits projets souvent en solo utilisant JOGL ou bien LWJGL.

N_I_C_S a écrit:Moi, mon but est tout autre : mon petit FPS vise très clairement le casual gaming. L'idée pour coller à cette évolution actuelle c'est : des applis très légères, une compatibilité "universelle", ...et de la 3D ! Et comme j'ai pas rencontré de techno adaptée à ces demandes, j'essaye de la faire ;) .

OpenGL répond déjà à cette demande et si tu avais mieux cherché, tu aurais trouvé presque une dizaine de moteurs 3D supportant à la fois le rendu logiciel et le rendu matériel, l'un d'eux marche même avec Java 1.1 pour le rendu logiciel.

N_I_C_S a écrit:C'est aussi pour cette raison de compatibilité que je me tiens à une gestion rigoureusement standard du temps, et en bricolant un peu ça marche pas trop mal...

Cela dit, je me goure peut-être complètement de vision, et on aura bientôt des mobiles avec des grosses 8800GTX qui dépassent:D . Sérieusement, j'entends tes arguments, mais je tente une sorte de pari, ce qui fait qu'effectivement je m'em**rde peut-être pour rien...

C'est juste que tu vas passer beaucoup de temps à réécrire ce qui existe déjà dans DzzD, d3caster ou JPCT au niveau du rendu logiciel et qui est très complet pour des motifs qui ne tiennent pas suffisament compte de la situation actuelle. Le risque à faire des choses comme ça c'est que ça te décourage quand tu tomberas sur certains obstacles. Penser au "casual gaming" n'exclut pas OpenGL. Si tu en as peur, dis-le. Quel intérêt autre que pédagogique trouves-tu à réinventer l'eau chaude? Moi j'ai réécrit un moteur 3D mais j'ai fait ça pour tester mes propres algorithmes aussi, des algorithmes que tu ne trouveras pas dans d'autres moteurs, je n'ai pas fait ça pour le plaisir de réécrire ce qui existe déjà. Le temps que tu passes à réinventer l'eau chaude est du temps en moins que tu peux consacrer au jeu vidéo en lui-même. De plus, pour les téléphones mobiles, tu verras que la réalité n'est pas si rose, J2ME est implémenté très différemment d'un téléphone à l'autre et tu es obligé de jongler entre plusieurs API, je te conseille vivement d'attendre que JavaFX Mobile soit au point et encore une fois de ne pas réécrire ce qui existe déjà. Ce serait bête qu'au final, ton projet tombe à plat parce que tu te seras épuisé à écrire une API de rendu logiciel au lieu de te servir de l'existant pour faire un casual game de qualité. J'ai 9 ans d'expérience en programmation de jeux vidéo et j'ai vu beaucoup de projets tomber à l'eau. On a encore peu de FPS écrit en Java alors ne lâche pas l'affaire.
ninten
 

Messagepar N_I_C_S » 19 Sep 2008, 11:23

il existe OpenGL-ES pour les téléphones
Ca doit concerner 1% des portables...

Pour le reste, je ne vais pas rentrer dans un stérile débat de geek, je dis simplement que sur ces plate-formes il est très probable qu'on voie une implémentation en masse d'un JRE standardisé bien avant celle d'une quelconque lib 3D. Voilà, je te parle réflexion sur l'avenir, tu me parles drivers. Je t'en remercie mais ces arguments, qui ne m'apprennent rien, ne sont aucunement en contradiction avec ma démarche (quand ils ne sont pas simplement de mauvaise foi). Je t'invite à relire attentivement mon post précédent.

Ah si :
Non, je n'ai pas "peur" d'OpenGL, un singe saurait s'en servir, c'est bien ce qui fait son succès ;)

On a encore peu de FPS écrit en Java alors ne lâche pas l'affaire.
Merci ! Je crois que je tiens le bon bout, l'appli est quasiment finie, après faudra que je fasse des bonnes maps qui envoient !:D
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Messagepar ninten » 19 Sep 2008, 14:02

N_I_C_S a écrit:Pour le reste, je ne vais pas rentrer dans un stérile débat de geek, je dis simplement que sur ces plate-formes il est très probable qu'on voie une implémentation en masse d'un JRE standardisé bien avant celle d'une quelconque lib 3D.

J2ME existe depuis déjà très longtemps, c'est sensé être standardisé mais chaque constructeur fait sa sauce et c'est l'enfer. Demande à des gens qui développent sur téléphones mobiles par exemple, ils te diront que c'est dur de faire tourner un jeu vidéo écrit en Java sur 4 téléphones différents sans devoir retoucher le code, il y a même des frameworks incluant un système de préprocesseurs qui ont été créés pour plus ou moins pallier à ça . Pour le son, on doit passer par MMAPI quand c'est possible, sinon il faut se contenter du support de base de J2ME ou trouver autre chose :(

Quant au rendu 3D sur mobile, contrairement à ce que tu dis, ça s'harmonise plus vite, il y a la JSR 239 (JOGL-ES) supportée moins largement comme tu le fais remarquer à juste titre et la JSR 297 (M3G) qui elle peut tout à fait fonctionner sur n'importe quel téléphone avec ou sans accélération matérielle.

N_I_C_S a écrit:Voilà, je te parle réflexion sur l'avenir, tu me parles drivers. Je t'en remercie mais ces arguments, qui ne m'apprennent rien, ne sont aucunement en contradiction avec ma démarche (quand ils ne sont pas simplement de mauvaise foi). Je t'invite à relire attentivement mon post précédent.

Je ne fais pas preuve de mauvaise foi. Ton but est d'écrire un FPS léger, en 3D et compatible "universellement", tu dis que tu n'as pas trouvé de technologies adaptées à ces critères et c'est avec ça que je ne suis pas d'accord, je te réponds que des technologies adaptées pour faire ça existent déjà aujourd'hui maintenant que ce soit sur PC, ordinateurs ultra-portables et sur téléphones mobiles à ceci près que pour ce dernier, ça s'avère beaucoup plus compliqué.

De toute façon, s'il existe d'un côté J2ME et de l'autre J2SE, c'est bien parce que les contraintes sont si différentes que même Sun n'a pas envisagé de faire une seule API à la fois pour les PC et les téléphones. Je vois mal comment tu pourrais réussir seul là où Sun a fait le choix de ne pas tenter (même pour JavaFX, les mobiles auront une API séparée). Tu me reproches de te parler de pilotes quand toi tu parles du futur mais JavaFX Mobile fait partie du futur justement.

Quand je parle de technologie, je pense aussi aux moteurs et j'en ai cité quelques uns qui marchent aussi bien en rendu logiciel qu'en rendu matériel. Qu'est-ce que ton moteur va apporter de plus concrètement?

Si tu tiens à faire ton propre moteur tout en sachant qu'il en existe déjà d'autres qui font ce que tu souhaites aussi bien voire mieux, tu devrais éviter de laisser entendre le contraire, tu devrais plutôt reconnaître que tu fais ça pour d'autres raisons sinon ça revient à nier ce que font déjà JPCT et 3DzzD pour ne citer qu'eux.

N_I_C_S a écrit:Ah si :
Non, je n'ai pas "peur" d'OpenGL, un singe saurait s'en servir, c'est bien ce qui fait son succès ;)

Si c'est si facile à utiliser et que ça permet d'écrire un FPS léger compatible "universellement", pourquoi n'as-tu pas opté pour cette solution?

N_I_C_S a écrit: Merci ! Je crois que je tiens le bon bout, l'appli est quasiment finie, après faudra que je fasse des bonnes maps qui envoient !:D

Bonne chance alors. Par contre, comme je te l'ai dit, il y a encore quelques petites choses qui altèrent le gameplay. Quand ce sera réglé, je pense que ton jeu sera vraiment très agréable à manier.
ninten
 

Messagepar ninten » 19 Sep 2008, 14:33

Pour les téléphones mobiles, il y a JGame, ça facilite la vie quand même un peu dans tout ce bazar :
http://www.13thmonkey.org/~boris/jgame/index.html
ninten
 

Messagepar N_I_C_S » 19 Sep 2008, 16:41

J2ME existe depuis déjà très longtemps, c'est sensé être standardisé mais chaque constructeur fait sa sauce et c'est l'enfer
Oui oui, c'est ce que je dis, et j'espère qu'il sera bientôt réellement standardisé sur toutes les machines !

Quant au rendu 3D sur mobile, contrairement à ce que tu dis, ça s'harmonise plus vite, il y a la JSR 239 (JOGL-ES) supportée moins largement comme tu le fais remarquer à juste titre et la JSR 297 (M3G) qui elle peut tout à fait fonctionner sur n'importe quel téléphone avec ou sans accélération matérielle
J'ai regardé la JSR 297 et c'est symptomatique de ce qui donne un discours erroné sur l'état de la 3D. Je pense que tu confonds technologie et spécifications. Car il s'agit d'une spécification, qui dit "on souhaite pouvoir faire ça ou ça...".

On y trouve : "Implementations without any graphics hardware must remain practical"

Ou plus loin : "After a reasonable transition period, vendors are expected to implement M3G 2.0 in new products"

Ce sont des souhaits, la techno n'existe pas pour le commun des utilisateurs, on peut presque considérer que j'implémente à l'avance la JSR 297 :D ! Et qui peut dire de combien sera cette "période raisonnable de transition" ?

Mon propos, c'est simplement qu'il y aura peut-être un créneau entre l'arrivée d'un java standard minimal et la fin de ce type de "reasonable transition period". Encore une fois, peut-être que je me trompe, peut-être pas, mais rien aujourd'hui ne justifie un avis catégorique ;) .

Quand je parle de technologie, je pense aussi aux moteurs et j'en ai cité quelques uns qui marchent aussi bien en rendu logiciel qu'en rendu matériel
Oui, j'avais déjà regardé dzzd et j'en avais un peu parlé sur un autre forum. Je vais pas recommencer, mais en gros je m'interroge sur leur définition de rendu software quand on y voit du z-buffer, des textures (avec MIP-MAPPING, interpolation linéaire, etc...) ou un éclairage par pixel avec un frame-rate à fond...

Y a un gars qui a réellement joué le jeu et qui a sorti une API qui s'appelle comme la mienne : JGL. Il s'est lancé dans l'implémentation totale d'OpenGL en java standard. Il a fait un travail titanesque !! Les sources sont libres, y a plus d'1 Mo, c'est n'importe quoi !! Par contre, il présente une seule démo animée, il s'agit d'un carré 2D blanc qui tourne et c'est saccadé... Il ne le fait pas pour le temps réel, c'est évident que ce type d'algo est incompatible avec un langage interprété comme java...

Qu'est-ce que ton moteur va apporter de plus concrètement?
Ben, déjà je le connait par coeur:D , et je pense avoir suivi d'autres voies que les API actuelles. J'ai fait quelques trucs inhabituels dont je suis assez fier, comme les arbres BSP "modifiables" dont je me sert pour les animations squelettales, ou l'idée de passer le point de vue par l'inverse de la matrice d'un objet mouvant, celui-ci est ainsi toujours affiché dans l'ordre avec très peu de calculs, etc... En fait tout un tas d'optimisations qui rendent possible la 3D animée réellement software. Alors je ne peux pas afficher les mêmes choses qu'une autre API, mais je les affiche très vite car j'économise nombre de lourdeurs des pipelines classiques !

J'ai aussi intégré pour le FPS un VRAI système de collisions (c'est vrai que le pauvre algo du javagl actuellement en ligne est...risible, j'aurais rien du mettre du tout...). Ce système est extrêmement rapide et léger car il n'utilise que des bounding-shapes simples et les plans des BSP. A l'heure ou tout le monde utilise des grosses lib physiques pour bouger 3 persos, je pense que c'est plus en phase avec l'esprit de ce type de projet.

il y a encore quelques petites choses qui altèrent le gameplay
Oui, j'avais laissé passer ce bug sur les oiseaux, merci, ça y est on peut leur marave la face:D (faut viser le "corps") ! Sinon, peux-tu me préciser ce que tu as trouvé gênant sur la souris :) ?
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Messagepar ninten » 19 Sep 2008, 18:47

N_I_C_S a écrit:Oui oui, c'est ce que je dis, et j'espère qu'il sera bientôt réellement standardisé sur toutes les machines !

Ce n'est pas du tout le chemin que ça prend alors que le problème se pose déjà depuis très longtemps si on parle uniquement de J2ME. JGame est une solution possible mais j'ai rien vu tourner en 3D avec par contre.

N_I_C_S a écrit:Ce sont des souhaits, la techno n'existe pas pour le commun des utilisateurs, on peut presque considérer que j'implémente à l'avance la JSR 297 :D ! Et qui peut dire de combien sera cette "période raisonnable de transition" ?

Essaie "The Last Age 3D" sur téléphone mobile et tu vas vite comprendre que tu as déjà des jeux 3D en Java qui tournent très bien en rendu logiciel. La première version de M3G est déjà au point, regarde la JSR 184 :
http://jcp.org/en/jsr/detail?id=184

N_I_C_S a écrit:Mon propos, c'est simplement qu'il y aura peut-être un créneau entre l'arrivée d'un java standard minimal et la fin de ce type de "reasonable transition period". Encore une fois, peut-être que je me trompe, peut-être pas, mais rien aujourd'hui ne justifie un avis catégorique ;) .

Il y a déjà eu une "release" de M3G, elle est bien réelle et date de 2005, c'est pas tout jeune quand même. La JSR 297 concerne la version 2 de M3G donc désolé, tu ne seras pas le premier à faire de la 3D en rendu logiciel sur téléphone mobile donc le créneau "rendu logiciel en 3D" est déjà pris par Sun. Ca fait 3 ans que le segment est occupé donc je me permets d'être catégorique.

N_I_C_S a écrit:Oui, j'avais déjà regardé dzzd et j'en avais un peu parlé sur un autre forum. Je vais pas recommencer, mais en gros je m'interroge sur leur définition de rendu software quand on y voit du z-buffer, des textures (avec MIP-MAPPING, interpolation linéaire, etc...) ou un éclairage par pixel avec un frame-rate à fond...

Comment ça tu t'interroges sur leur définition du rendu logiciel? Il a réimplémenté l'algorithme du Z-buffer entre autres, où est le mal? Serais-tu en train de dire qu'il a utilisé la carte 3D pour le Z-buffer et que donc ce n'est pas du vrai rendu logiciel?

N_I_C_S a écrit:Y a un gars qui a réellement joué le jeu et qui a sorti une API qui s'appelle comme la mienne : JGL. Il s'est lancé dans l'implémentation totale d'OpenGL en java standard. Il a fait un travail titanesque !! Les sources sont libres, y a plus d'1 Mo, c'est n'importe quoi !! Par contre, il présente une seule démo animée, il s'agit d'un carré 2D blanc qui tourne et c'est saccadé... Il ne le fait pas pour le temps réel, c'est évident que ce type d'algo est incompatible avec un langage interprété comme java...

Depuis quand Java n'est pas fait pour du temps réel? Déjà, il existe Javolution et RTSJ. Quand je cherchais du travail l'an dernier, on m'a même proposé plusieurs projets en Java temps réel, ce n'est pas de la science-fiction. De plus, Java n'est pas un langage purement interprété, c'est un langage précompilé interprété (merci le compilateur JIT). Jake 2 a prouvé brillamment qu'on peut aller parfois même plus vite en Java qu'en C++ et il existe même quelques rares systèmes d'exploitation en Java (JNode par exemple). Je respecte JGL mais ce n'est pas parce que son implémentation est lente que Java est lent. La preuve, Kenneth Russell a insisté pour que la GLU disponible dans JOGL soit écrite en Java et le résultat est tout à fait satisfaisant. On peut écrire des trucs lents dans tous les langages, même les plus rapides. Certaines mauvaises langues disent que le ramasses-miettes produit des gros ralentissements qui rendraient impossible la création de FPS en Java mais ça ne tient pas la route une seule seconde, il n'y a qu'à regarder le frame rate de Jake 2 ou de Night Squad 2.

N_I_C_S a écrit:Ben, déjà je le connait par coeur:D , et je pense avoir suivi d'autres voies que les API actuelles. J'ai fait quelques trucs inhabituels dont je suis assez fier, comme les arbres BSP "modifiables" dont je me sert pour les animations squelettales, ou l'idée de passer le point de vue par l'inverse de la matrice d'un objet mouvant, celui-ci est ainsi toujours affiché dans l'ordre avec très peu de calculs, etc... En fait tout un tas d'optimisations qui rendent possible la 3D animée réellement software. Alors je ne peux pas afficher les mêmes choses qu'une autre API, mais je les affiche très vite car j'économise nombre de lourdeurs des pipelines classiques !

J'ai vu tourner JPCT plus vite que ton moteur avec des décors bien plus complexes sur le jeu Bloodridge qui tourne justement en rendu logiciel. JPCT utilise à la fois des octrees et des "portals". 3DzzD dispose d'un scénographe. Qu'est-ce qui te fait dire que "tes" optimisations ne sont pas présentes dans d'autres moteurs? As-tu été vérifier dans le code source? Si les pipelines étaient lourds, personne ne s'en servirait, je ne vois absolument pas où tu veux en venir. De plus, en théorie, rien ne t'empêcherait d'utiliser ton arbre BSP pour déterminer ce qui est visible pour le joueur et ne passer que ça à la carte graphique.

N_I_C_S a écrit:J'ai aussi intégré pour le FPS un VRAI système de collisions (c'est vrai que le pauvre algo du javagl actuellement en ligne est...risible, j'aurais rien du mettre du tout...). Ce système est extrêmement rapide et léger car il n'utilise que des bounding-shapes simples et les plans des BSP. A l'heure ou tout le monde utilise des grosses lib physiques pour bouger 3 persos, je pense que c'est plus en phase avec l'esprit de ce type de projet.

Je ne dis pas le contraire mais ça n'a rien de nouveau. Quake 2 (et donc Jake 2) utilise déjà un arbre BSP avec dans ses feuilles des volumes englobants très simples. Tu n'es pas le seul à faire ça. Je pense aussi comme toi que ça ne sert à rien de sortir le bazooka pour écraser une mouche, c'est pourquoi TUER n'utilise qu'une physique très très très basiques et ça suffit amplement pour le moment.

Justement, tu dis que Java n'est pas fait pour le temps réel mais tu te contredis toi-même puisque ton jeu tourne bien, il répond bien, c'est plutôt jouable. Certains gars qui disent que le garbage collector est un obstacle prennent comme exemple des démos techniques basés sur JBullet qui est rapide mais connu pour produire beaucoup trop de déchets et donc solliciter trop souvent le garbage collector. Si tu ne te sers pas de JBullet, ni de Java 3D ni de javax.vecmath, ça te retire une épine du pied, tu peux tout à fait avoir des performances très satisfaisantes. Ca montre aussi qu'utiliser des outils inadéquats pour bouger 3 pauvres gars peut être une solution plus coûteuse que de se contenter d'une physique plus rudimentaire.

N_I_C_S a écrit: Oui, j'avais laissé passer ce bug sur les oiseaux, merci, ça y est on peut leur marave la face:D (faut viser le "corps") ! Sinon, peux-tu me préciser ce que tu as trouvé gênant sur la souris :) ?

Je vais réessayer tout de suite et je vais te préciser ça. J'ai l'impression que tu cherches tout le temps à recentrer le curseur et ça me saoule de voir le pointeur de souris clignoter sur la fenêtre, désolé, question de goût.
ninten
 

Messagepar ninten » 19 Sep 2008, 19:25

Je viens de réessayer. J'ai réussi à buter les monstres volants. Le problème avec le curseur est que par moment ça fait des mouvements saccadés. Le pire c'est quand je fais des grands mouvements de souris, ça me fait des mouvements minuscules voire un mouvement inverse, c'est un problème que j'avais eu moi aussi par le passé (ah ça fera déjà presque 2 ans bientôt).
Ecoute, je t'en prie, ton jeu est prometteur, je trouve ça déjà sympa à jouer, utilise la partie de mon code qui gère la souris, c'est Riven et Bienator de Javagaming.org qui m'ont donné la piste que j'ai implémentée et ça marche rudement bien.

J'aime bien l'espèce d'effet quand tu passes dans le téléporteur.
ninten
 

Messagepar N_I_C_S » 19 Sep 2008, 20:24

Bon, là ça devient débile...

Je ne vais pas relancer ces polémiques quasi-uniquement basées sur des mésinterprétations de ce que j'ai écrit, mais comme je suis patient je vais juste répondre à 2 choses :

1 - Les boites de jeux NE FONT PAS de 3D sur mobile : Ca veut dire QU'IL N'EXISTE PAS AUJOURD'HUI je ne sais quelle API/Standard/JSR 3D dont l'utilisation soit RENTABLE, C'est a dire suffisamment REPANDU dans le parc actuel (définition d'un STANDARD). Donc L'AVENIR RESTE OUVERT, C'est pas la peine de balancer des pages pour t'exciter à ne pas me démontrer que j'ai tort. C'est bon, on a fait 3 fois le tour, on va peut-être s'arrêter là.

2 - Je n'ai JAMAIS dit que j'étais le seul à faire ça ou ça, ou que mon projet était meilleur que ceci-cela ! J'ai toujours été respectueux du travail des autres. Alors faire telle ou telle comparaison ou me prêter une sorte de prétention que je n'ai pas, franchement ça va vite me gonfler...

Je reposterai pour donner des nouvelle de l'avancée (et vraisemblablement de l'achèvement) du soft. "Débat" clos, next...

[EDIT dernier post] je vais regarder ton code de souris, merci pour les compliments.
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Messagepar ninten » 19 Sep 2008, 21:50

N_I_C_S a écrit:Les boites de jeux NE FONT PAS de 3D sur mobile : Ca veut dire QU'IL N'EXISTE PAS AUJOURD'HUI je ne sais quelle API/Standard/JSR 3D dont l'utilisation soit RENTABLE, C'est a dire suffisamment REPANDU dans le parc actuel (définition d'un STANDARD). Donc L'AVENIR RESTE OUVERT, C'est pas la peine de balancer des pages pour t'exciter à ne pas me démontrer que j'ai tort. C'est bon, on a fait 3 fois le tour, on va peut-être s'arrêter là.

Je peux encore donner d'autres exemples de jeux vidéo 3D en Java pour téléphone mobile et je sais bien que Gameloft par exemple vend depuis déjà pas mal de temps des jeux "Next Gen" (lol j'aime pas ce terme) pour téléphone mobile :
http://www.gameloft.fr/jeux-3d/
Même Sony Ericsson propose d'utiliser M3G sur ses téléphones, le plugin en question apparaît ici :
https://developer.sonyericsson.com/site/global/home/java_3d/p_java3d.jsp
Nokia écrit même:
The first version of M3G was ratified in the Java Community Process in November 2003. Nokia researchers were leading the specification work. Devices with built-in support for the standard can be expected to hit the market during the first half of 2004.

http://www.nokia.com/A4126517

N_I_C_S a écrit:2 - Je n'ai JAMAIS dit que j'étais le seul à faire ça ou ça, ou que mon projet était meilleur que ceci-cela ! J'ai toujours été respectueux du travail des autres. Alors faire telle ou telle comparaison ou me prêter une sorte de prétention que je n'ai pas, franchement ça va vite me gonfler...

Quand tu dis que tu n'as pas trouvé de technologies légères pour faire de la 3D et compatible "universellement", ça laisse entendre que tu penses qu'il n'y en a pas. Tu as bien écrit :
L'idée pour coller à cette évolution actuelle c'est : des applis très légères, une compatibilité "universelle", ...et de la 3D ! Et comme j'ai pas rencontré de techno adaptée à ces demandes, j'essaye de la faire



Par conséquent, il existe déjà une API pour faire du rendu logiciel et matériel sur téléphone mobile. Même avant M3G, il y avait déjà l'API propriétaire Mascot Capsule. L'avenir est donc bien moins ouvert que tu le prétends. Désolé s'il y a eu un malentendu concernant tes prétentions mais ta formulation était ambigüe. Chomsky a écrit que le langage est une approximation. Je te laisse un lien vers un joli tutoriel pour apprendre les bases de M3G en mode immédiat :00000030:
http://www.ibm.com/developerworks/wireless/library/wi-mobile1/
Bonne lecture :)

Rappel historique : Sony Ericsson, Nokia et Motorola furent les premiers fabricants à adopter M3G, vinrent ensuite Samsung, Sanyo, BenQ...

Si en lisant ça, tu penses encore que j'ai fumé la moquette, je t'invite à lire les caractéristiques de mon téléphone mobile Samsung SGH-Z630, le détail des API supportées est ici :
http://mobilezoo.biz/Samsung_SGH-Z630_specs

N_I_C_S a écrit:Je reposterai pour donner des nouvelle de l'avancée (et vraisemblablement de l'achèvement) du soft. "Débat" clos, next...

[EDIT dernier post] je vais regarder ton code de souris, merci pour les compliments.

C'est déjà fini? Je pensais que tu comptais solliciter un artiste pour te faire de belles arènes. Pense à enregistrer ton jeu sur le "FGF players' portal" pour que beaucoup d'autres gens puissent apprécier ton oeuvre.

Encore une chose. On m'a fait la remarque pour mon jeu il y a longtemps, elle est valable pour le tien. Certains joueurs utilisent uniquement le clavier. Serait-il possible que tu permettes au joueur de tourner et d'avancer avec les flèches? Pourquoi n'as-tu pas pris la configuration standard du clavier comme c'est le cas dans d'autres jeux?
ninten
 

Messagepar ninten » 19 Sep 2008, 22:29

Voilà le code pour la souris :
Code: Tout sélectionner
/**
     * Contribution from Riven
     * @return
     */
    public final Point getDelta(){       
       Point pointer=MouseInfo.getPointerInfo().getLocation();
       int xDelta=pointer.x-centerx;
       int yDelta=pointer.y-centery;
       if(xDelta==0 && yDelta==0)
           {// robot caused this OR user did not do anything
            return(new Point(0,0));
           }
       else
           {robot.mouseMove(centerx, centery);
            return(new Point(xDelta, yDelta));
           }     
    }


centerx et centery représentent les coordonnées du centre de ta fenêtre.

Pour cacher le pointeur de souris, tu peux faire ça :
Code: Tout sélectionner
BufferedImage cursor=new BufferedImage(1,1,BufferedImage.TYPE_INT_ARGB);
       cursor.setRGB(0,0,0);
       frame.setCursor(Toolkit.getDefaultToolkit().createCustomCursor(cursor,new Point(0,0),"empty cursor"));


Voilà, ça t'évitera de farfouiller dans mon code pas très propre.
ninten
 

Messagepar N_I_C_S » 21 Sep 2008, 13:47

Salut,

Ca y est, j'ai (enfin) implémenté mes tourelles (ça se passe online sur http://javagl.sourceforge.net/tesseract/:) ), j'en ai mis 2 contre les "oiseaux" sur le 1er niveau de la démo, je trouve ça rigolo ! Bon, certes ces tourelles sont un peu petites, mais ça vient juste de mon modèle moisi, en fait on peut immédiatement appliquer n'importe quelle forme ou animation à chaque entité... A ce propos, n'y aurait-il pas un graphiste indulgent qui passerait sur cette page ? toi, OUI TOI, rejoins un projet certes modeste mais qui n'attend que ton talent pour s'exprimer !!:p

Voilà, sinon c'était le dernier type d'entité prévu, la base de l'application est terminée (snif, c'est triste)... Je vais faire le ménage dans les sources, commenter tout ça et balancer cette première version sur sourceforge.

De toute façon, le coeur du soft ne va pas beaucoup bouger pendant l'élaboration du contenu. Par contre, je compte bien rajouter en masse des possibilités "cosmétiques" selon le gameplay voulu. Par exemple j'avais pensé pouvoir faire des niveaux verticaux, "suspendus" au-dessus de maps liquides, etc... A ce propos, toi qui me lit, tu as l'âme d'un level-designer motivé par les maps intelligentes, surprenantes et intenses (je le sais!) Rejoins-moi ! Ensemble, nous produirons une fantasmagorie d'abstraction froide et d'hystérie !!:p

Voilou, sinon je vais commencer à chercher quelques portails de jeux sympas avec un minimum de fréquentation...

Je vais également entamer un éditeur de maps en ligne, où les joueurs pourront faire leurs niveaux, les partager, les comparer, les tester en direct, etc... merci encore à Warshadow, c'est son idée, c'est l'idée du siècle:cool: :cool: .

@ninten
Bon allez, pour la route, celle-la elle est trop belle :
c'est déjà fini ?
Ben...Oui... Tout le monde ne peut pas mettre 2 ans pour amoindrir un programme existant :p

c'est pour rire... Non, sérieusement, si tu le souhaite je peux t'indiquer quelques tutoriaux sur la gestion de projet et le génie logiciel, ce sont des matières très utiles en informatique, y-compris dans le domaine des jeux vidéos;) . Et comme je serais désolé d'être à nouveau ambigu, j'espère que tu n'interprèteras pas cela comme de la prétention mais comme une réelle volonté de t'aider... Cela dit, comme je l'écris moi-même : l'ambigüité n'est pas tant dans le langage en lui-même que dans le cerveau du lecteur. si tu veux, je te donnerai des liens sur Aristote et le réalisme;) .
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Messagepar ninten » 21 Sep 2008, 15:24

N_I_C_S a écrit:Voilou, sinon je vais commencer à chercher quelques portails de jeux sympas avec un minimum de fréquentation...

Je peux te donner un coup de main pour ça. Pense à mon portail comme je te l'ai déjà dit. Je voulais ajouter ton jeu mais je ne trouve que les sources de JavaGL qui datent de janvier 2008, je ne trouve pas les sources récentes de ton jeu.
Pense aussi au Java Game Tome même si j'avoue avoir des désaccords avec le chef du projet. Il y a aussi happypenguin.org, games4linux.eu, des tonnes de wiki et de documentation où tu peux t'incruster. Je peux m'en occuper tout de suite si tu le désires. Je tiens à ce que les jeux vidéo open source gratuits en Java aient la meilleure visibilité possible.

N_I_C_S a écrit:@ninten
Bon allez, pour la route, celle-la elle est trop belle :
Ben...Oui... Tout le monde ne peut pas mettre 2 ans pour amoindrir un programme existant :p

c'est pour rire... Non, sérieusement, si tu le souhaite je peux t'indiquer quelques tutoriaux sur la gestion de projet et le génie logiciel, ce sont des matières très utiles en informatique, y-compris dans le domaine des jeux vidéos;) . Et comme je serais désolé d'être à nouveau ambigu, j'espère que tu n'interprèteras pas cela comme de la prétention mais comme une réelle volonté de t'aider... Cela dit, comme je l'écris moi-même : l'ambigüité n'est pas tant dans le langage en lui-même que dans le cerveau du lecteur. si tu veux, je te donnerai des liens sur Aristote et le réalisme;) .

Bon, je prends ça au second degré. Je n'ai vraiment pas envie que les programmeurs de jeux vidéo en Java se crèpent le chignon car unis, nous sommes bien plus forts.

J'ai parlé à l'auteur de 3DzzD, histoire de voir si c'est juste moi qui avais mal compris ce que tu disais et il a confirmé que tu l'as accusé d'utiliser la carte graphique dans son mode de rendu logiciel. Je ne suis pas le seul à t'avoir mal compris alors?

Enfin, pense à ajouter un compteur de FPS, la possibilité d'augmenter la résolution et une carte avec au moins 500 000 quadrilatères, histoire que je mesure à quel point mon moteur est nul par rapport au tien ;) Je dois avouer que c'est un amoindrissement de passer de 1 à 8 FPS et de 64 Mo d'utilisation de mémoire à 11 Mo :D Il se peut que nous n'ayons pas la même définition du mot "amoindrissement" :)

Le pire dans tout ça est que je me donne encore 4 ans pour amoindrir ce programme...
ninten
 

Messagepar ninten » 21 Sep 2008, 15:50

Je viens de tester de nouveau ton jeu. Les tourelles marchent bien. Par contre, j'arrive à bouger avec la souris uniquement quand je fais de tout petits mouvements.
ninten
 

Messagepar N_I_C_S » 21 Sep 2008, 16:47

J'ai parlé à ******, l'auteur de 3DzzD
Saches que DzzDDzzD (puisque c'est, je crois, son pseudo ici, je ne me permettrais pas de donner son nom sans savoir s'il le souhaite) et moi avons des rapports tout à fait courtois sur un autre forum, et que tu parles en son nom d'une conversation qui n'est même pas sur ce site et qui ne te concerne en rien, je pense que ça peut vite le gonfler également, je dis ça pour toi;) ...

Maintenant, si tu veux laisser des commentaires, serait-il possible d'éviter ce genre de gaminerie qui n'intéresse personne, ou de te répandre sur toi et tes projets, et de rester dans le sujet de la discussion : le jeu ? Je te remercie;) .
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Messagepar ninten » 21 Sep 2008, 19:29

N_I_C_S a écrit:Maintenant, si tu veux laisser des commentaires, serait-il possible d'éviter ce genre de gaminerie qui n'intéresse personne, ou de te répandre sur toi et tes projets, et de rester dans le sujet de la discussion : le jeu ? Je te remercie;) .

C'est l'hôpital qui se moque de la charité ou quoi? C'est toi qui as parlé de mon jeu :
N_I_C_S a écrit:Ben...Oui... Tout le monde ne peut pas mettre 2 ans pour amoindrir un programme existant :p

Je n'ai fait que te répondre. Maintenant, tu sais que je ne partage pas ton sens de l'humour alors restons-en là.

Pour en revenir à ton jeu, il y a un truc que je ne saisis pas. JavaGL est sous licence GPL, les sources sont bien sur sourceforge. Si j'ai bien compris, ton jeu utilise JavaGL. Comment se fait-il que je ne trouve pas tes sources? C'est moi qui n'ai pas cherché au bon endroit ou bien tu ne les as pas encore publiées?
ninten
 

Messagepar N_I_C_S » 21 Sep 2008, 19:42

C'est l'hôpital qui se moque de la charité ou quoi? C'est toi qui as parlé de mon jeu
Ooh... Tu as cru que je parlais de toi ? je ne cite personne poutant:( , si tu as cru toi-même reconnaître ton projet, j'y suis pour rien... (C'est vrai que c'est marrant ta façon de discuter:) )

Si j'ai bien compris, ton jeu utilise JavaGL. Comment se fait-il que je ne trouve pas tes sources? C'est moi qui n'ai pas cherché au bon endroit ou bien tu ne les as pas encore publiées?


Voilà, sinon c'était le dernier type d'entité prévu, la base de l'application est terminée (snif, c'est triste)... Je vais faire le ménage dans les sources, commenter tout ça et balancer cette première version sur sourceforge.
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Messagepar ninten » 21 Sep 2008, 19:58

N_I_C_S a écrit:Ooh... Tu as cru que je parlais de toi ? je ne cite personne poutant:( , si tu as cru toi-même reconnaître ton projet, j'y suis pour rien... (C'est vrai que c'est marrant ta façon de discuter:) )

Des petits crétins sont venus sur mon blog et ont posté à peu de choses près le même genre de remarques que la tienne. Je ne m'étends pas à ce sujet car ça n'a rien à voir avec ton jeu. Tu as bien mis
@ninten
donc c'était à moi que la remarque qui suivait était adressée.

Pour le code source, j'ai regardé dans le projet javagl sur sourceforge; si j'ai bien compris, tu comptes soumettre ton jeu mais ça n'a pas encore été fait. Je ne sais pas si tu as modifié le code pour gérer la souris car là, je ne perçois pas de changement.
ninten
 

Messagepar N_I_C_S » 24 Sep 2008, 02:01

Des petits crétins sont venus sur mon blog et ont posté à peu de choses près le même genre de remarques que la tienne
Ah bin voilà, je préfère quand tu t'énerves !!:p :p

Bon allez, on est mal parti et c'est dommage, alors je vais essayer de répondre aussi clairement que possible à ton post où tu disais "faux, faux, faux, ..." avec des arguments que j'ai reçu comme fallacieux. J'espère que ça dissipera quelques malentendus :

Faux, il existe OpenGL-ES pour les téléphones et aussi son pendant Java qui s'appelle JOGL-ES.
Bon, là, on était d'accord, ça concerne peu de matos.

Faux, mon jeu utilise OpenGL et il marche bien même avec une carte graphique de 2002. Comme beaucoup de logiciels même sous Windows utilisent OpenGL, les fondeurs sont obligés de fournir des pilotes décents et ce depuis de nombreuses années. De plus, JavaFX mobile arrive l'an prochain et a besoin d'accélération graphique, ça m'étonnerait que ça repose sur DirectX lol. Au final, les "petites" plateformes souffrent beaucoup plus que les grosses quand tu te contentes du rendu logiciel car quand tu as un petit processeur, en rendu logiciel avec Art Attack par exemple, tu descends vite sous la barre des 6 FPS et ça devient injouable alors qu'avec un jeu de la même complexité graphique avec un petit CPU et une "petite" carte graphique, en rendu matériel, tu restes proche des 20 FPS ce qui est à peu près jouable (et encore, sans scénographe, ce serait encore mieux avec ).
[WARNING mauvaise foi] Pourquoi ne peux-tu pas considérer ta carte de 2002 comme chère et sophistiquée (surtout en 2002) ? Je comparais bien sûr à d'autres matos. Après tu expliques qu'une grosse plateforme est plus performante qu'une petite, et qu'OpenGL accélère le rendu. Merci, mais j'en étais conscient...

Raison de plus pour utiliser directement OpenGL. Ce que tu dis est faux, je te conseille d'aller voir dans les sources de Java, notamment dans les classes qui implémentent l'interface BufferedImageOp et tu verras qu'il y a en fait pas mal d'opérations qui sont accélérés par la carte, j'aurais pu donner d'autres exemples.
[WARNING erreur logique] J'expliquais le caractère basique d'opérations graphiques et tu dis : pourquoi ne pas utiliser explicitement une grosse lib 3D puisqu'elle peut le faire aussi ?
[Vrai argument] Exact, je ne sais pas ce qui se passe exactement sous les fonctions 2D java, je vais m'y intéresser.

Un appel de fonction OpenGL n'est pas lent, je ne sais pas d'où tu sors ça. Même si tu as une couche de support de rendu logiciel, quand tu as des pilotes pour ta carte graphique, l'OS se sert en priorité de la carte justement parce que c'est plus performant.
[WARNING manque d'humour] Oh, c'est bon, je disais en gros que les fonctions que j'utilise sont vraiment basiques... Maintenant, si je dis q'un algo de Bresenham est plus rapide qu'une demande/réponse d'un GPU je veux bien en discuter, as-tu des chiffres, pour quelles machines, etc...

C'est faux. Va sur d'autres forums de jeux Java dans la langue de Shakespeare et tu verras une foison de petits projets souvent en solo utilisant JOGL ou bien LWJGL.
[WARNING mauvaise foi] Donc tu crois qu'opengl est très utilisé ? Je crois que tu as raison... Non mais je voulais juste dire que les plate-formes utilisant OpenGL sont puissantes, donc permettent des applications de plus en plus grosses, donc nécéssitent des équipes nombreuses, etc... C'est une philosophie générale qui ne me semble pas adaptée à mon projet. est-ce que j'ai le droit d'avoir cette idée ?? surtout que, si ça t'inquiète, je peux passer en rendu OpenGL en 2 minutes...

OpenGL répond déjà à cette demande et si tu avais mieux cherché, tu aurais trouvé presque une dizaine de moteurs 3D supportant à la fois le rendu logiciel et le rendu matériel, l'un d'eux marche même avec Java 1.1 pour le rendu logiciel.
[WARNING erreur logique] Tu dis qu'OpenGL répond aux demandes mais tu vantes des moteurs ayant des rendus logiciels, je ne comprends plus... Par ailleurs, tu parles de 10 moteurs, n'as-tu pas reproché aux 9 autres de faire la même chose que le premier ? Votre Honneur, je réclame quand même le droit de faire ma lib adaptée à mon jeu, même si tu ne la trouve pas pertinente...

C'est juste que tu vas passer beaucoup de temps à réécrire ce qui existe déjà dans DzzD, d3caster ou JPCT au niveau du rendu logiciel et qui est très complet pour des motifs qui ne tiennent pas suffisament compte de la situation actuelle
[WARNING Condescendance déplacée] C'est gentil de t'inquiéter mais ça va, merci... La lib graphique est terminée et a l'avantage de pouvoir s'adapter facilement aux standards puisqu'entièrement implémentée (qui peut le plus peut le moins). Si un jour telle fonctionnalité réclame d'utiliser une lib, on remplace l'algo par l'appel correspondant et basta. C'est en ce sens que j'ai voulu faire un système (presque) quasi-immédiatement adaptable et extensible aux autres technologies.


J'en profite pour dire que j'attends la réponse de sourceforge pour l'hébergement Tesseract, et j'ai mis en ligne la dernière version de JavaGL utilisée dans l'appli. Bon, il n'y a pas vraiment de nouvelle fonctionnalités, plutôt des améliorations et optimisations en tous genres;) . C'est en téléchargement sur http://sourceforge.net/projects/javagl/.
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Messagepar N_I_C_S » 24 Sep 2008, 03:33

@ninten
Plutôt que d'apprendre les JSR par coeur, DEVELOPPE TON JEU, P**AIN !!! Pense au raycast, aux portals, aux CSG mais FOUS-Y DES VAMPIRES !!! Si on se fait agresser par des trucs qu'on comprend même pas l'image, j'achète!!!
Avatar de l’utilisateur
N_I_C_S
Hello World, I'm new !
 
Messages: 295
Inscription: 03 Sep 2008, 21:46

Messagepar ninten » 24 Sep 2008, 09:08

N_I_C_S a écrit: [WARNING mauvaise foi] Pourquoi ne peux-tu pas considérer ta carte de 2002 comme chère et sophistiquée (surtout en 2002) ? Je comparais bien sûr à d'autres matos. Après tu expliques qu'une grosse plateforme est plus performante qu'une petite, et qu'OpenGL accélère le rendu. Merci, mais j'en étais conscient...

J'explique que tu veux un FPS qui marche partout et qui utilise le rendu logiciel mais justement, ce sont les ordinateurs avec les processeurs les moins puissants qui vont en pâtir là où tu pourrais avoir des performances acceptables en rendu matériel. Je vais essayer de trouver un exemple pertinent. Prends un celeron 700 Mhz avec un chieux chipset VIA (même pas cher en 2002). En utilisant du rendu logiciel, même en l'optimisant, je ne suis pas sûr que tu aurais de meilleures performances qu'en rendu matériel, je pense même que ce serait difficilement jouable sauf en baissant pas mal la résolution (ce que tu permets déjà donc c'est pas mal de ce point de vue).

N_I_C_S a écrit:[WARNING manque d'humour] Oh, c'est bon, je disais en gros que les fonctions que j'utilise sont vraiment basiques... Maintenant, si je dis q'un algo de Bresenham est plus rapide qu'une demande/réponse d'un GPU je veux bien en discuter, as-tu des chiffres, pour quelles machines, etc...

Qu'est-ce qui prouve que ton implémentation de Bresenham est meilleure que celle qu'utilise OpenGL?

N_I_C_S a écrit: [WARNING mauvaise foi] Donc tu crois qu'opengl est très utilisé ? Je crois que tu as raison... Non mais je voulais juste dire que les plate-formes utilisant OpenGL sont puissantes, donc permettent des applications de plus en plus grosses, donc nécéssitent des équipes nombreuses, etc... C'est une philosophie générale qui ne me semble pas adaptée à mon projet. est-ce que j'ai le droit d'avoir cette idée ?? surtout que, si ça t'inquiète, je peux passer en rendu OpenGL en 2 minutes...

Tu as le droit de le penser, ce n'est pas le problème mais c'est faux. De plus, ça dépend de ce que tu entends par "passer en rendu OpenGL en 2 minutes". Il y a une différence entre activer le pipeline OpenGL, juste utiliser glDrawPixels mais en gardant des algorithmes dont tu te sers à l'heure actuelle pour le rendu logiciel et refondre complètement ton moteur pour te servir d'OpenGL partout où c'est possible. Pour la première possibilité, je pense que tu peux faire ça en deux minutes; pour les deux autres, ça demande un peu plus de travail.

N_I_C_S a écrit: [WARNING erreur logique] Tu dis qu'OpenGL répond aux demandes mais tu vantes des moteurs ayant des rendus logiciels, je ne comprends plus... Par ailleurs, tu parles de 10 moteurs, n'as-tu pas reproché aux 9 autres de faire la même chose que le premier ? Votre Honneur, je réclame quand même le droit de faire ma lib adaptée à mon jeu, même si tu ne la trouve pas pertinente...

Je vante des moteurs qui ont les deux, le rendu logiciel et le rendu matériel. Déjà, parmi les moteurs que je connais et disposant des deux modes de rendu, chacun apportait quelque chose, l'un utilisait des arbres binaires, l'autre des arbres octaires, l'un utilisait un Z-buffer logiciel, l'autre un W-buffer logiciel, l'un passe par JOGL pour le rendu matériel, l'autre par LWJGL. Personne ne t'empêche d'écrire ton propre moteur mais moi, en te lisant, j'avais cru comprendre que tu prétendais que les moteurs existants ne correspondaient pas à tes besoins alors que ce que tu as énuméré comme étant tes besoins aurait pu être comblé par des moteurs existants. Si ce n'est pas le cas, alors cela signifie que tu as omis d'en citer certains.

N_I_C_S a écrit: [WARNING Condescendance déplacée] C'est gentil de t'inquiéter mais ça va, merci... La lib graphique est terminée et a l'avantage de pouvoir s'adapter facilement aux standards puisqu'entièrement implémentée (qui peut le plus peut le moins). Si un jour telle fonctionnalité réclame d'utiliser une lib, on remplace l'algo par l'appel correspondant et basta. C'est en ce sens que j'ai voulu faire un système (presque) quasi-immédiatement adaptable et extensible aux autres technologies.

L'utilisation d'une librairie peut demander une refonte bien plus profonde que ce que tu laisses entendre, surtout si on pense à un binding d'OpenGL, je suis passé par là, c'est hallucinant tout ce que j'ai dû changer. Dans ce cas, quelles autres technologies as-tu à l'esprit?

N_I_C_S a écrit:@ninten
Plutôt que d'apprendre les JSR par coeur, DEVELOPPE TON JEU, P**AIN !!! Pense au raycast, aux portals, aux CSG mais FOUS-Y DES VAMPIRES !!! Si on se fait agresser par des trucs qu'on comprend même pas l'image, j'achète!!!

Si tu t'étais un peu plus penché sur ce que je fais, tu saurais que ça fait environ un an et demi que j'ai viré le raycasting et un peu plus d'un an que je travaille sur mon algorithme de division de l'espace en cellules et en portails (c'est aussi pour ça que je n'ai pas pris un moteur existant) qui est presque fini, j'ai même pris un jour de congé aujourd'hui pour tenter de le boucler. Ne me reproche pas de parler de mon jeu, c'est toi qui aborde le sujet, je te réponds.
ninten
 

PrécédenteSuivante

Retourner vers Présentations et suivis

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 0 invités

cron