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.
Bon, je me suis implémenté un petit Thread pour mon éditeur de cartes qui permet d'afficher en temps réel une sélection à la souris, ça marche nickel. J'ai juste eu besoin de créer le thread avec la méthode que j'utilisais auparavant
Faudra nettoyer un peu ce fichier, il est assez crade
EDIT: J'ai laissé le shmup de côté. Je vais me faire un ensemble d'outils pour faciliter la création de jeux, entièrement via une interface graphique de type RPG Maker.
Hum, je suis confronté à un petit problème de design.
J'aimerais donner la possibilité aux utilisateurs de choisir la taille des tuiles qu'ils souhaitent utiliser. Mais je ne peux pas augmenter la taille maximum des maps en même temps (problème de mémoire). Déjà que là, je suis sur une machine à 1.5 Go, à la maison 2 Go et si j'ai déjà un problème de mémoire, c'est grave
Je m'explique: avec des tuiles de 16 * 16 pixels, on peut faire des maps très grandes (je comptais limiter à 1600 * 1600 pixels). Mais en quadruplant la résolution des tuiles (32 * 32), la taille maximale de la map doit rester la même, donc elle devient 4 fois plus petite mais 4 fois plus détaillée !
Alors est ce que ça vaut le coup de proposer du 64 * 64
Hum, je suis confronté à un petit problème de design.
J'aimerais donner la possibilité aux utilisateurs de choisir la taille des tuiles qu'ils souhaitent utiliser. Mais je ne peux pas augmenter la taille maximum des maps en même temps (problème de mémoire). Déjà que là, je suis sur une machine à 1.5 Go, à la maison 2 Go et si j'ai déjà un problème de mémoire, c'est grave
Je m'explique: avec des tuiles de 16 * 16 pixels, on peut faire des maps très grandes (je comptais limiter à 1600 * 1600 pixels). Mais en quadruplant la résolution des tuiles (32 * 32), la taille maximale de la map doit rester la même, donc elle devient 4 fois plus petite mais 4 fois plus détaillée !
Alors est ce que ça vaut le coup de proposer du 64 * 64
Déjà là faut que tu m'expliques un truc: admettons que 1 pixel soit codé sur 32 bits soit 4 octets (avec une couche alpha, tout ca):
1600 * 1600 * 4 = 10 240 000
En gros le poids total d'un buffer qui contiendrait l'intégralité de ta map tournerait aux environs de 10Mo (9.765625 dixit la calto de Windows).
Comment tu peux avoir un problème de mémoire
Après j'ai franchement du mal à comprendre ce que tu entends par problème de design. La dernière fois que j'aie fait une gestion de map dans le genre ca a finit avec un tableau de pointeurs vers des cases dont la taille était contrainte par typage (class Map templatée avec la taille des cases qui n'accepte dans son tableau que des Cell templatées avec la meme valeur) histoire que ca meurt directement à la compilation si je fais un truc de travers. Mais dans ton cas faut que tu puisses changer la taille des cases de manière dynamique je suppose.
---------------
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d.
1f u c4n wr1t3 1t t00.
Non, le choix de la taille des cases sera fait à la création du projet et conservée ensuite.
Pour le problème de mémoire, écoute j'en suis moi-même étonné, mais avec des tases de 32 * 32 pixels, j'ai tenté de créer une map de 100 * 100 cases et boum, exception OutOfMemory...
Il le place pas plutôt dans la mémoire vidéo mon buffer ? C'est peut être la mémoire vidéo qui est pleine, sur mon portable du boulot y a une carte graphique intégrée Intel...
J'ai trouvé pourquoi: Java limite la quantité de mémoire maximum allouable par défaut pour une application. Je l'ai changée à 256 Mo pour mon appli et je n'ai plus d'erreur
Sur les conseils d'un collègue très expérimenté en Java, je pense finalement ne pas coder le moteur graphique et utiliser quelque chose qui existe déjà.
Ca m'a l'air pas mal ça, je vais voir ce que je peux en faire !
EDIT: Bon, ce n'est pas qu'un moteur graphique en fait C'est un moteur graphique et sonore basé sur LWJGL (binding OpenGL/AL pour Java). Ca devrait me faire gagner énormément de temps, mais pas de doc fournie...
Essaie de voir si Java SDL ne peut pas te convenir... La version C me donne toute satisfaction et est versatile (image, son, support du pad, etc). Par ailleurs, la librairie elle-même est très utilisée et bien documentée.
En fait, j'aimerais me simplifier la vie en utilisant des méthodes déjà testées et approuvées pour toutes les tâches de base (affichage, collisions, gestion des périphériques...)
Ben SDL, personnellement, j'ai testé, et j'approuve... J'ai commencé en 1999 je crois avec cette couche d'interface, et je l'utilise toujours aujourd'hui pour tout ce qui est bitmap et ne nécessite pas d'UI (auquel cas je me sers de FLTK).
Maintenant, je ne sais pas ce que ça donne sous Java.
Par contre, ça gère l'affichage et les périphériques, mais les collisions, il faudra autre chose (je gère ça moi-même, mais je crois qu'il y a des bibliothèques associées à SDL qui le font)
C'est justement ce que je ne veux pas: une librairie graphique...
C'est un moteur qu'il me faut, j'ai pas envie de réinventer la roue alors qu'il existe des solutions performantes avec lesquelles je ne pourrais de toute façon jamais rivaliser dans un temps raisonnable
Entendu, je peux comprendre... Pour moi, une grande partie du plaisir est justement de raffiner le moteur
Pareil, mais y'a quand même des trucs qui m'embêtent avec la SDL pour une bibliothèque de rendu 2D: - certaines opérations super couteuses (rotation de sprites, mais surtout le blit qui fait que blitter 640*480 ca peut pas se faire à 60fps constant avec un pentium M 1,75GHz) - pas de gestion des plans (ca et la lenteur du blit a fini par me faire coder un ersatz de Z-buffer de cases 2^n * 2^n px) - pas de gestion de graphe de scène - pas de gestion des animations La prochaine fois que je me lance dans un moteur de rendu 2D, je sens qu'il y aura de l'OpenGL en dessous
Pareil, mais y'a quand même des trucs qui m'embêtent avec la SDL pour une bibliothèque de rendu 2D:
- certaines opérations super couteuses (rotation de sprites,
Ce n'est pas une partie de la SDL, ce truc. Cela dit, programmer une rotationde sprite SANS support hardware, c'est délicat. Si tu as besoin de ce genre de chose, il est raisonnable d'envisager de passer en OpenGL (ou SDL-OpenGL)
mais surtout le blit qui fait que blitter 640*480 ca peut pas se faire à 60fps constant avec un pentium M 1,75GHz)
Ca, ça me surprend énormément, j'ai de meilleures performances il me semble avec mon Pentium III 700 (et une carte vidéo de merde). Même sur un K6-II 450, j'avais plus de 30fps sur du 800x600 avec un overdraw important (5 ou 6 couches minimum). Il y a trente-six façons de gérer le blit et la mémoire vidéo, est-tu sûr d'avoir bien réglé le bouzin ? (un truc qui améliore BEAUCOUP aussi les choses, c'est de transférer le sprite dans le format du buffer, c'est quasi-indispensable... Ca se fait à coup de SDL_Surface* SDL_DisplayFormat(SDL_Surface* surf) )
- pas de gestion des plans (ca et la lenteur du blit a fini par me faire coder un ersatz de Z-buffer de cases 2^n * 2^n px)
- pas de gestion de graphe de scène
- pas de gestion des animations
Vi, c'est purement et simplement une couche d'interface. Ce sont des choses parmi les premières que j'ai créées dans mon moteur. A mon avis, c'est une bonne chose qu'elles ne soient pas dans SDL, ça n'a rien à y faire, mais une surcouche "officielle" pourrait être un plus certain.
Après vérification, tu as bien un soucis quelque part... J'ai zieuté pour trouver quelques tests de performances de SDL, en 800x600, et si tu choisis bien tes flags (et à mon avis, si tu lui demande de choisir lui-même la meilleure solution), c'est beaucoup plus que ce que tu as.
Vérifie que tes surfaces sont bien converties, que tu as activé le RLE_ACCEL sur les surfaces avec transparence (indispensable), que tu utilises le hardware et que tu n'as pas de problème lié à la profondeur des couleurs.
Ceci dit, il est une chose importante : la 2D n'est plus accélérée actuellement, donc les évolutions en terme de vitesse ces dernières années sont proches de zéro... OpenGL semble être incontournable si tu veux profiter de la vitesse des machines actuelles (c'est quelques lignes pour charger les sprites, tu as tes plans, ta transparence, et la rotation/zoom)
que tu as activé le RLE_ACCEL sur les surfaces avec transparence (indispensable),
Sauf que j'utilise pas de color key. J'avais bien deux ou trois sprites avec de l'alpha blending mais là où j'avais des problèmes de perfs c'etait quand j'essayais d'actualiser le background à chaque frame qui pour le coup n'avait rien de transparent. Après vu que sur ma machine de dev, la mémoire vidéo est partagée avec la RAM je sais pas si on peut vraiment dire que je mets mon bordel dans de la mémoire vidéo...
Citation :
que tu utilises le hardware et que tu n'as pas de problème lié à la profondeur des couleurs.
Qu'est-ce que tu entends par problème lié à la profondeur des couleurs? Si c'est une histoire de conversion couteuse pour coller à la surface d'affichage je pense pas, tout était en 24bits.
Citation :
Ceci dit, il est une chose importante : la 2D n'est plus accélérée actuellement, donc les évolutions en terme de vitesse ces dernières années sont proches de zéro... OpenGL semble être incontournable si tu veux profiter de la vitesse des machines actuelles (c'est quelques lignes pour charger les sprites, tu as tes plans, ta transparence, et la rotation/zoom)
Voir même un graphe de scène avec OSG ou un truc du genre. Après j'ai eu deux trois échos de gens qui ont tentés de faire de l'OpenGL sous Vista et qui ont eu l'impression que c'était plus accéléré non plus Du coup je me tate...
Sauf que j'utilise pas de color key. J'avais bien deux ou trois sprites avec de l'alpha blending mais là où j'avais des problèmes de perfs c'etait quand j'essayais d'actualiser le background à chaque frame qui pour le coup n'avait rien de transparent.
Etrange... J'ai eu des problèmes de performances de ce genre au début, quand je n'utilisais pas DisplayFormat et les bonnes options, mais plus depuis.
Après vu que sur ma machine de dev, la mémoire vidéo est partagée avec la RAM je sais pas si on peut vraiment dire que je mets mon bordel dans de la mémoire vidéo...
Je crois bien que HW_SURFACE, ce n'est pas juste une histoire de localisation physique, mais aussi du choix des fonctions qui permettent le blit. Même si c'est la même mémoire, je pense qu'il faut creuser par là... D'autant qu'à mon avis, la mémoire est la même, mais les plages processeur et GPU sont bien distinctes.
Qu'est-ce que tu entends par problème lié à la profondeur des couleurs? Si c'est une histoire de conversion couteuse pour coller à la surface d'affichage je pense pas, tout était en 24bits.
Je pensais à ça (surtout le 32bits qui est très lent). Une raison de moins
Voir même un graphe de scène avec OSG ou un truc du genre. Après j'ai eu deux trois échos de gens qui ont tentés de faire de l'OpenGL sous Vista et qui ont eu l'impression que c'était plus accéléré non plus
Vous avez besoin de quoi, en terme de graphe de scène pour un jeu 2D ? En général, je me démerde avec un truc perso tout simple ou un conteneur STL (genre une display list par plan) et je n'ai pas souvent eu besoin de trucs bien spévcifiques. Du moins pas autant qu'en 3D où on a davantage d'objets articulés ou composites qui nécessitent des structures compliquées...
Vous avez besoin de quoi, en terme de graphe de scène pour un jeu 2D ? En général, je me démerde avec un truc perso tout simple ou un conteneur STL (genre une display list par plan) et je n'ai pas souvent eu besoin de trucs bien spévcifiques. Du moins pas autant qu'en 3D où on a davantage d'objets articulés ou composites qui nécessitent des structures compliquées...
Moi ca me sert surtout pour automatiser tout ce qui est positionnement relatif. Typiquement quand tu utilises plusieurs sprites pour représenter un seul objet comme un tank dont le déplacement du cannon est relatif à la position de la base. Bon dans mon cas l'utilisation est plus limitée: je bricole un T-RPG. En gros l'arrière plan faitoffice de map de jeu et au premier plan j'ai les unités. Au niveau du graphe de scène, les unités sont filles de l'arrière plan et positionnées relativement à cet arrière plan. Du coup pour ce qui était gestion du scrolling je suis pénard vis à vis des unités.
---------------
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d.
1f u c4n wr1t3 1t t00.
Vi, c'est ce que je disais... certes, tu peux avoir du positionnement relatif, mais dans un jeu 2D, c'est nettement moins crucial et problématique que dans un jeu 3D (surtout sans rotation).
Pour un jeu de type stratégie (et j'en ai codé un récemment, un moteur générique qui supporte aussi bien des clones de Advance Wars que de Fire Emblem, et gère de façon transparente la 2D classique, la 2D hexagonale et la 3D isométrique... Il faudra que je le termine d'ailleurs et que je développe un skin complet), en général, le seul scrolling que tu aies besoin, c'est un point de référence (genre le haut à gauche de l'écran), tu décales tous les éléments de l'opposé de cette référence, et c'est fini (et ce qui sort de l'écran n'est pas dessiné, tu n'as potentiellement même pas à filtrer)
Oh quelle misère ce Golden T Game Engine Ils ont mis tous les chemins en relatif, ce qui fait que lorsque je veux charger une image, celle-ci doit être présente dans le même dossier ou un sous-dossier que la classe qui charge l'image
Mis à part ça, j'avais songé à utiliser JGame à la place, mais GTGE est quand même beaucoup mieux foutu.
En plus lire un MP3 en 2 lignes de code, quel pied
Bon, je me suis décidé à dépoussiérer mon projet d'IUT (Zelda).
OMG l'horreur que c'est Mon code à moi a déjà besoin de quelques retouches, mais celui de mon partenaire, c'est encore pire Au boulot !
Ah, les joies de relire du vieux code source.
L'autre jour je suis retombé sur du vieux code en basic que j'avais fait genre au collège: aucune fonction, que du goto et pas d'indentation.
Parfois la jeunesse, c'est moche
Ah, les joies de relire du vieux code source.
L'autre jour je suis retombé sur du vieux code en basic que j'avais fait genre au collège: aucune fonction, que du goto et pas d'indentation.
Parfois la jeunesse, c'est moche
En même temps, j'ai débuté avec du Basic 1.0, langage sans indentation, sans fonctions (enfin, des gosub à un numéro de ligne), et par deux fois il a fallu que je magouille le code parce que j'étais bloqué par la limite des 65000 lignes.
Et tout ça SANS éditeur, ça revenait en gros à programmer avec cat, >> et edline...
Alors oui, le code n'est pas un monstre d'élégance, mais au moins, j'avais des excuses
Cela dit, c'est vrai que écrire du code lisible, ça vient avec le temps.
© 2000-2008, Splitgames Network - Tous droits réservés | Nous contacter