Je m'étais fait la même réflexion... Mais quand on corrige des projets dans des écoles d'ingénieur, c'est pratique, les fautes d'orthographe pour détecter les plagiats
pas faux... ça et les headers auto-renseignés avec le login de la dernière personne à avoir édité le fichier
Citation :
La réflexion ou recherche de classes/méthodes par nom, effectivement c'est limite hors sujet pour du Java mais comme ça existe, j'ai voulu tenter !
Oh tu sais... à l'extreme limite de l'acceptable ça se fait aussi en C (fonctions / variables globales) sur les bibliothèques Mais l'intérêt principal de l'avoir en Java c'est plutôt pour tout ce qui est webservices avec la génération automatique du talon par exemple.
Après peut être que javac est capable d'optimiser la chose mais j'ai de sérieux doutes.
Citation :
2. Pour la réalloc je sais, c'est pour ça que j'ai mis un bloc de commentaire à un moment pour me rappeler de me préoccuper de cette gestion. Car si on le laisse faire tout seul, il fait 1 réalloc à chaque ajout après le nombre défini par défaut Je ne savais pas que Vector était déconseillé, je vais donc utiliser autre chose
En fait pour être honnête ce qui me semble le plus dangereux c'est pas forcément le réalloc en lui-même. C'est surtout que si tu as des références quelque part vers des instances de classes dans ton Vector je sais pas si la JVM les mets aussi à jour. Techniquement ça doit être possible via le garbage collector mais ça doit lui faire très mal à la tête en multi-thread
pas faux... ça et les headers auto-renseignés avec le login de la dernière personne à avoir édité le fichier
Citation :
La réflexion ou recherche de classes/méthodes par nom, effectivement c'est limite hors sujet pour du Java mais comme ça existe, j'ai voulu tenter !
Oh tu sais... à l'extreme limite de l'acceptable ça se fait aussi en C (fonctions / variables globales) sur les bibliothèques Mais l'intérêt principal de l'avoir en Java c'est plutôt pour tout ce qui est webservices avec la génération automatique du talon par exemple. Après peut être que javac est capable d'optimiser la chose mais j'ai de sérieux doutes.
Citation :
2. Pour la réalloc je sais, c'est pour ça que j'ai mis un bloc de commentaire à un moment pour me rappeler de me préoccuper de cette gestion. Car si on le laisse faire tout seul, il fait 1 réalloc à chaque ajout après le nombre défini par défaut Je ne savais pas que Vector était déconseillé, je vais donc utiliser autre chose
En fait pour être honnête ce qui me semble le plus dangereux c'est pas forcément le réalloc en lui-même. C'est surtout que si tu as des références quelque part vers des instances de classes dans ton Vector je sais pas si la JVM les mets aussi à jour. Techniquement ça doit être possible via le garbage collector mais ça doit lui faire très mal à la tête en multi-thread
Oui, la réflexion j'utilise ça au boulot pour les Webservices Je pense que la JVM s'occupe de tout mettre à jour, sinon c'est un peu stupide
EDIT : En multi-thread, c'est géré et je sais pas si ça lui donne mal à la tête mais la synchronisation est gérée avec Vector contrairement aux autres classes de Collection. Sinon, rien dans la doc de Vector ne dit qu'il ne faut plus l'utiliser http://java.sun.com/j2se/1.5.0/docs/api/
Je vais tenter un peu la généricité, ça peut servir. Mais pour l'affichage, je n'ai, à mon sens, que 2 grands choix possibles : une classe qui fait un "mauvais" boulot en allant appeler des méthodes draw de chaque objet (cette méthode ne me tente pas) ou alors une classe qui s'occupe de l'affichage à elle toute seule en allant chercher ce dont elle a besoin dans les objets (ma méthode actuelle).
Message édité par Aru le 03-08-2007 à 23:50:57
---------------
Playfrance's Monk of Twilight -> Aru
* La classe Vector va t'elle enfin disparaitre de l'API Swing ou au moins les ArrayList vont-elles apparaitre ? Depuis le temps que Sun deconseille le Vector.
Vector ne disparaîtra jamais, on doit malheureusement soutenir notre passé. Gérer un Vector et une List implique d'énormes modifications dans JTable et crois moi tu ne veux pas voir le code de la JTable. Cela dit c'est possible.
Si je cherche un peu plus, je retrouverai les conseils de sun ou je l'ai lu, mais là c'est assez clair. Je vais plutôt lire ton code
Message édité par wadisnake le 04-08-2007 à 01:33:16
OK, moi j'avais regardé uniquement la documentation des Collections et de la classe Vector, et là dedans ils ne disent rien.
J'ai pas poussé les recherches plus loin
Je vais donc trouver autre chose.
---------------
Playfrance's Monk of Twilight -> Aru
J'ai changé quelques éléments déjà.
J'ai remplacé le Vector par une LinkedList (plus de gestion du nombre d'objets en mémoire comme ça), et cette LinkedList est du type DrawableObject, ma classe qui est la super classe de tous les objets qui sont rendus à l'écran.
De cette manière, adieu la réflexion, j'appelle directement les méthodes. En fait, j'avais codé la première version au boulot vite fait quand j'avais pas grand chose à faire et on a que Java 1.4.2... Donc si je faisais de la généricité, Eclipse me sortait qu'il fallait la version 1.5.
---------------
Playfrance's Monk of Twilight -> Aru
Je me suis lancé dans un concept de Layers (couches) dynamique, ça devrait être sympa pour la réutilisation de code plus tard...
En gros le principe :
- une LinkedList de layers, de la couche la plus basse à la plus haute
- une LinkedList d'objets à dessiner, qui comprennent un attribut "layer" de type int, qui donnera l'index de la couche sur laquelle dessiner l'objet.
Et donc pour dessiner le tout, 2 boucles imbriquées qui parcourent d'abord la liste des couches, puis testent pour chaque objet s'il doit être sur cette couche ou non et le dessine le cas échéant.
---------------
Playfrance's Monk of Twilight -> Aru
Il fut un temps où je t'aurais dit que c'est inefficace (si tu as un layer de bullets et que tu codes un daimaku, tu vas analyser des centaines d'objets inutilement pour trouver les trois vaisseaux sur la couche correspondante) mais ça n'a plus trop d'importance. Garder une liste des objets pour chaque layer est toutefois plus 'logique' (et ça peut être plus simple à gérer), mais si tu es à l'aise comme ça, continue, c'est le plus important.
Merci. En effet, le défaut de cette méthode est que je parcours toute la liste des objets autant de fois qu'il y a de couches, pour 10 objets ça va, quand y en a plus ça devient problématique mais je ne pense pas que ça va poser un gros problème de perfs. A moins que je ne vise 60 FPS
EDIT : Je pense que je vais corriger mon implémentation pour éviter ce problème, mais je veux à tout prix éviter les tableaux, la réallocation dynamique est beaucoup trop coûteuse...
mais je ne pense pas que ça va poser un gros problème de perfs.
Honnêtement, je ne pense pas non plus. Et ce MEME si tu vises du 200fps. Vu les processeurs actuels, même si tu as dix mille sprites, ça ne prendrait encore que quelque chose comme un vingtième de milliseconde. C'est l'affichage proprement dit qui va être pénalisant. Je ne sais pas ce que ça donne en Java, mais en SDL, il m'a fallu ruser pas mal de ce côté (soigneusement mettre les bitmaps dans le format de l'écran par exemple) mais c'est parfaitement fluide sur mon portable et sa carte graphique merdique, et j'en suis à quelque chose comme 7 ou 8000 objets à dessiner à l'écran.
Je pense que je vais corriger mon implémentation pour éviter ce problème, mais je veux à tout prix éviter les tableaux, la réallocation dynamique est beaucoup trop coûteuse...
Une LinkedList pour chaque plan ? Ca parait le plus simple/pratique...
Honnêtement, je ne pense pas non plus. Et ce MEME si tu vises du 200fps. Vu les processeurs actuels, même si tu as dix mille sprites, ça ne prendrait encore que quelque chose comme un vingtième de milliseconde. C'est l'affichage proprement dit qui va être pénalisant. Je ne sais pas ce que ça donne en Java, mais en SDL, il m'a fallu ruser pas mal de ce côté (soigneusement mettre les bitmaps dans le format de l'écran par exemple) mais c'est parfaitement fluide sur mon portable et sa carte graphique merdique, et j'en suis à quelque chose comme 7 ou 8000 objets à dessiner à l'écran.
Une LinkedList pour chaque plan ? Ca parait le plus simple/pratique...
Oui, c'est le plus simple mais c'est pas ce que je veux
Oui, c'est le plus simple mais c'est pas ce que je veux
Au pire, rien ne t'empêche d'avoir deux structures qui référencient tes instances si tu as besoin d'une liste "simple" par ailleurs. C'est planqué mais derrière ça reste des pointeurs Sinon tu peux aussi tenter des trucs plus tordus comme une LinkedList triée sur l'index du layer (mais dans ce cas là faut maintenir le tri à la main au moment de l'ajout parce que lancer un tri de toute la liste est suicidaire niveau perfs) ou une multimap indexée sur le layer. Par contre comment faire les deux derniers en java là je sais pas (en C++ la multimap doit se faire en deux lignes... ptet 5 pour la liste maintenue triée si c'est bien indenté... donc en java ça doit pas faire beaucoup plus).
Au pire, rien ne t'empêche d'avoir deux structures qui référencient tes instances si tu as besoin d'une liste "simple" par ailleurs. C'est planqué mais derrière ça reste des pointeurs Sinon tu peux aussi tenter des trucs plus tordus comme une LinkedList triée sur l'index du layer
C'est, comme je le disais plus haut, le genre de structure que j'envisagerais, mais l'important est de trouver une structure qui te plaise...
mais dans ce cas là faut maintenir le tri à la main au moment de l'ajout parce que lancer un tri de toute la liste est suicidaire niveau perfs
Non, pas vraiment... D'une part ce n'est pas une grande liste (10k éléments maximum ?) et d'autre part c'est tout à fait implémentable en radix voire en radix amélioré, autrement dit c'est un tri linéaire en nombre d'éléments... Donc si c'est une fois par affichage, ça passerait (on fait bien du radix pour trier des soupes de polygones bien plus grosses). Mais ce serait quand même un sacré gâchis, surtout que tu peux garder des pointeurs sur les entrées de chaque plan.
Je n'ai pas d'attribut qui me donne la priorité d'affichage d'un objet par rapport à un autre... S'il est placé dans la liste avant, il s'affichera avant, sinon il faut le déplacer et dans ce cas là, j'avoue que c'est pas super pratique ce que j'ai mis en place
Je pense qu'il serait plus sage que j'ajoute un attribut adéquat
---------------
Playfrance's Monk of Twilight -> Aru
Non, pas vraiment... D'une part ce n'est pas une grande liste (10k éléments maximum ?) et d'autre part c'est tout à fait implémentable en radix voire en radix amélioré, autrement dit c'est un tri linéaire en nombre d'éléments... Donc si c'est une fois par affichage, ça passerait (on fait bien du radix pour trier des soupes de polygones bien plus grosses).
Certes, seulement un sort de List dans la bibliothèque java ça a plus de chances d'être un bubble sort ou un quick sort (déjà que la VM est pas foutue d'allouer plus de 2Go ). Et quitte à implémenter radix, c'est sans doute plus rapide de faire une procédure d'ajout qui garanti que la liste reste triée (à supposer que personne s'amuse à la modifier autrement).
Citation :
Mais ce serait quand même un sacré gâchis, surtout que tu peux garder des pointeurs sur les entrées de chaque plan.
Certes oui, ou comment remplacer du linéaire par du constant
J'ai rarement envie de réinventer la roue, surtout quand ça fonctionne très bien
En fait, perso, j'ai rarement envie d'utiliser la roue d'un autre, sauf quand c'est réellement complexe (ce qui touche au hard notamment, ou les GUI, du coup j'utilise SDL, FLTK ou GLUT). Mais pour le reste, je refais l'essentiel à ma sauce. Même la STL, bien souvent, je m'en passe (je la touve régulièrement mal fichue, et mal intégrée au langage).
Edit : souvent, c'est handicapant, d'ailleurs... je déteste réutiliser du code que je n'ai pas écrit.
Ben là surtout, je veux arriver le plus vite possible à un éditeur de jeu basique qui me permet de faire ce dont j'ai envie en codant le moins possible...
Donc je vais pas m'amuser à tout écrire, je fais le moteur d'affichage basé sur les classes du JDK et pour le reste, on verra
---------------
Playfrance's Monk of Twilight -> Aru
En fait, perso, j'ai rarement envie d'utiliser la roue d'un autre, sauf quand c'est réellement complexe (ce qui touche au hard notamment, ou les GUI, du coup j'utilise SDL, FLTK ou GLUT). Mais pour le reste, je refais l'essentiel à ma sauce. Même la STL, bien souvent, je m'en passe (je la touve régulièrement mal fichue, et mal intégrée au langage).
Edit : souvent, c'est handicapant, d'ailleurs... je déteste réutiliser du code que je n'ai pas écrit.
Bein, le principal problème de la roue en C++, c'est que tu as plusieurs modèles qui ont pas tous le même comportement sur sol glissant. Je me risquerais pas à dire que la STL bibendows est un pneu lisse mais quand tu sais pas que faire ++ sur un iterator en fin de liste ça segfaulte t'as quelques doutes sur l'adhérence du caoutchouc. Donc là recoder la chambre à air je comprends. Mais en java tout l'intérêt c'est que c'est la même roue partout tant que l'essieu n'est pas révisé. C'est vrai qu'il peut être tentant, avec le dernier essieu, d'utiliser un pneu acceptant tous les enjoliveurs sans devoir jouer du tournevis. Cependant si à chaque démarrage de la voiture il faut roder les pneus, personnellement je garde le tournevis.
Bein, le principal problème de la roue en C++, c'est que tu as plusieurs modèles qui ont pas tous le même comportement sur sol glissant. Je me risquerais pas à dire que la STL bibendows est un pneu lisse mais quand tu sais pas que faire ++ sur un iterator en fin de liste ça segfaulte t'as quelques doutes sur l'adhérence du caoutchouc. Donc là recoder la chambre à air je comprends. Mais en java tout l'intérêt c'est que c'est la même roue partout tant que l'essieu n'est pas révisé. C'est vrai qu'il peut être tentant, avec le dernier essieu, d'utiliser un pneu acceptant tous les enjoliveurs sans devoir jouer du tournevis. Cependant si à chaque démarrage de la voiture il faut roder les pneus, personnellement je garde le tournevis.
Spoiler :
Non non, je n'ai rien bu
T'es sûr que t'as rien bu ?
Spoiler :
Ou t'avais pas compris que réinventer la roue était une expression ?
---------------
Playfrance's Monk of Twilight -> Aru
J'ai trouvé une idée de gameplay qui peut être intéressante, je n'ai jamais rien vu de tel dans un autre shmup mais en même temps je ne les ai pas tous essayés (loin de là...), donc peut-être que ça existe déjà
Par contre, je ne vous en fait pas part maintenant. Pas que j'ai peur qu'on me vole mon idée, mais je préfère l'implémenter avant d'en parler plus en détail
Par contre, je ne vous en fait pas part maintenant. Pas que j'ai peur qu'on me vole mon idée, mais je préfère l'implémenter avant d'en parler plus en détail
Disons que je vais tenter un mariage entre le shmup et mon genre préféré : le RPG Rien de très mielleux, ne vous inquiétez pas, ça sera très loin du Shmup/RPG sorti sur GBA dont j'ai oublié le nom
---------------
Playfrance's Monk of Twilight -> Aru
J'ai du mal a voir quand meme ce qu'il y a de neuf dans l'approche. Le principe meme de certains shmup c'est que la puissance des armes augmente en fonction du nombre d'ennemis abbatus / de balles frolees / de balles absorbees / etc... ce qui s'apparente pas mal a du leveling (meme si on perd les dits bonus quand on meurt) et dans d'autres on fait de la customisation de vaisseau entre les missions avec de l'argent gagne en mission. L'un dans l'autre c'est pas des genres si antinomiques que ca.
Rah, merci de m'y faire penser... Je compte chercher quelques gemmes par trop inconnues, et TSS en faisait partie, mais je l'avais oublié. Certes, ce n'est pas le plus important (celui-là, je sais pouvoir le trouver sur NCSX pour une vingtaine d'euros), mais bon... Si je tombe dessus...
D'autres suggestions dans le genre, tant qu'à faire ?
Rah, merci de m'y faire penser... Je compte chercher quelques gemmes par trop inconnues, et TSS en faisait partie, mais je l'avais oublié. Certes, ce n'est pas le plus important (celui-là, je sais pouvoir le trouver sur NCSX pour une vingtaine d'euros), mais bon... Si je tombe dessus...
D'autres suggestions dans le genre, tant qu'à faire ?
Dans le genre ovni ou shmup hum... en shmup: blazing star, last resort et viewpoint c'est a peu pres tout ce que je connais d'autre sur neo.
en ovnis... super dodge ball
J'ai du mal a voir quand meme ce qu'il y a de neuf dans l'approche. Le principe meme de certains shmup c'est que la puissance des armes augmente en fonction du nombre d'ennemis abbatus / de balles frolees / de balles absorbees / etc... ce qui s'apparente pas mal a du leveling (meme si on perd les dits bonus quand on meurt) et dans d'autres on fait de la customisation de vaisseau entre les missions avec de l'argent gagne en mission. L'un dans l'autre c'est pas des genres si antinomiques que ca.
C'était une approche similaire que je voulais faire, mais qu'on ne perdrait pas en mourant.
Mais ce n'est pas tout
---------------
Playfrance's Monk of Twilight -> Aru
Je pense qu'il y a pas mal de variations sur cette idée, mais j'attends de voir la tienne.
Et puis, les cross, il y en a de curieux qui se révèlent être excellents (le fameux croisement récent en Puzzle-RPG où ils ont fabriqué un RPG où les combats sont des variations de Bejeweled)
Dans le genre ovni ou shmup hum... en shmup: blazing star, last resort et viewpoint c'est a peu pres tout ce que je connais d'autre sur neo.
en ovnis... super dodge ball
Je ne pensais pas Neo Geo, en fait. En fait, tout sauf Neo, Saturn et Xbox (vu que ce sont les consoles qu'il me manque ). Je pensais schmups, mais en fait je cherche n'importe quoi... J'aimerais bien trouver Umihara Kawase sur SNES par exemple. Enfin bon, peu importe...
Rah, merci de m'y faire penser... Je compte chercher quelques gemmes par trop inconnues, et TSS en faisait partie, mais je l'avais oublié. Certes, ce n'est pas le plus important (celui-là, je sais pouvoir le trouver sur NCSX pour une vingtaine d'euros), mais bon... Si je tombe dessus...
D'autres suggestions dans le genre, tant qu'à faire ?
Bon déjà il existe des Twinkle Star Sprites sur Dream et sur PS2. La version PS2 se trouve assez facilement il me semble. Mais ce n'est pas l'originale. Enfin elle ne semble pas pourrie pour autant.
Ma version préférée c'est l'arcade (également sortie sur saturn). Elle marche très bien sous MAME.
A deux joueur c'est super fun.
Sinon en ovni arcade je te conseille Gunbarich (toujours compatible MAME).
C'est un mix entre un casse brique et un flipper le tout dans un esprit shmup (c'est un spin off de Gunbird).
C'est rapidement assez hystérique. Bien trippant.
Et puis, tiens, je viens d'acheter Odama sur GC. Je l'ai pas encore testé, mais ça à l'air bien ovniesque aussi.
Un RTS à commande vocale, mélangé à un jeu de ... flipper. Il parait que c'est un peu dur, mais très bon.
Enfin je te dirais ça quand j'y aurai touché. Pas le temps pour l'instant.
R-type Tactics n'est effectivement pas encore sorti.
Grosse grosse attente....
Il l'est, maintenant, je crois (j'ai vu passer le test Famitsu il y a plus de deux semaines, il me semble ?)
Merci pour les suggestions, en tout cas. Gunbarich, je ne connaissais pas. Odama, j'ai failli l'acheter, si jamais je le trouve, pourquoi pas, ça m'interpellait. Et vib ribbon, oui, je connais, même si je n'ai pas le jeu non plus...
Oui, ca explique pourquoi Famitsu l'avait testé et que je ne l'avais apercu nulle part. C'est le même numéro de Famitsu qui a testé Mario Strikers, sorti aussi hier, donc ce n'était pas si vieux...
Bon, je suppose que je ne vous apprends rien en vous disant que ça n'avance pas du tout
Pas le temps de coder, ni l'envie (je fais que ça au boulot, donc en rentrant le soir, j'ai envie de faire autre chose). Ca ne veut pas dire que j'abandonne mon projet, loin de là, mais je vais avancer trèèèèèès lentement.
Sinon, je viens de tester Adobe Media Player et du coup voir à quoi ça ressemble une appli AIR, je vais me pencher dessus pour voir ce que peut faire ce runtime
Je me demande si ça serait jouable, un jeu en JS/HTML, comme celui que je compte faire en Java.
Mais pour un shoot, je me demande si y a moyen de faire quelque chose de potable avec AIR sans utiliser Flash. A priori, ça devrait être possible avec Flex. Mais en HTML/JS, j'y crois moyen
Mais pour un shoot, je me demande si y a moyen de faire quelque chose de potable avec AIR sans utiliser Flash. A priori, ça devrait être possible avec Flex. Mais en HTML/JS, j'y crois moyen
Quand tu parles de Flash tu parles de Flash CS3 le logiciel ? Parce qu'AIR est basé sur l'API presentation de Flash, et effectivement tu peux ignorer sans vergogne Flash CS3 et tout faire en ActionScript avec le Flex SDK.
Je ne savais pas que Vector était déconseillé, je vais donc utiliser autre chose 
mais la synchronisation est gérée avec Vector contrairement aux autres classes de Collection.
) mais T-rpg...
© 2000-2008, Splitgames Network - Tous droits réservés | Nous contacter