JEUX FLASH ENTIER
benpro82
Messages postés
76
Date d'inscription
lundi 9 juin 2003
Statut
Membre
Dernière intervention
6 août 2004
-
21 août 2003 à 10:14
Renziz Messages postés 1 Date d'inscription samedi 26 octobre 2013 Statut Membre Dernière intervention 26 octobre 2013 - 26 oct. 2013 à 13:42
Renziz Messages postés 1 Date d'inscription samedi 26 octobre 2013 Statut Membre Dernière intervention 26 octobre 2013 - 26 oct. 2013 à 13:42
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/13818-jeux-flash-entier
https://codes-sources.commentcamarche.net/source/13818-jeux-flash-entier
26 oct. 2013 à 13:42
1 mai 2009 à 12:37
http://looab.com/jfe/index.php
Cependant c'est une variante du moteur et seul le « niveau 3 » fonctionne
Et pour jouer au « puzzel bubble » il faut aller en bas de la map et cliquer sur « start »
après tout ce passe avec les touches directionnel.
1 mai 2009 à 12:05
donc pour commencer toutes mes excuses pour l'orthographe, la conjugaison, la grammaire, et le temps de réponse.
Donc ensuite pour en venir au chose utile.
Il est écrit dans la description de cette source :
"Bonjour,
donc, voila un jeux style rpg
réglable par xml,
le jeux est composé d'un moteur (jeuNouv15fla.swf)(c'est aussi l'anime que vous devez lancer pour jouer ),
..."
donc voilà et ironiquement et vue que me mon texte de présentation n'est pas écrit dans un français correcte. On peut en déduire que ce n'est pas réellement du français. Mais plutôt une obscure version non documenté, je me trouve logiquement dans l'impossibilité de pouvoir vous dire que vous ne savait pas lire.
Mais bon, même si la description n'est pas en français stricte, elle reste tout de même exécutable avec un interpréteur souple.
Mais, bon, bref, voilà.
Oui j'en conviens, mon humour et lamentable.
Mais bon entre deux lignes de code sa me relaxe.
Pour en revenir à cette source :
C'est de l'as2 voir as1 ( ça commence à dater ).
Donc je ne sais pas si je l'ai dit.
Mais cette sources n'est pas/plus forcement un très bon point de départ pour faire un jeux.
Mais bon, Il y as deux trois trucks intéressant.
Cependant, étant donnée la "maturité" de As3.
Je conseillerais à ceux motivés par l'idée de faire un jeu en flash de ce pencher sur les sources de GemRB (Game engine made with preRendered Background) (l'infinity engine).
D'autant que le adobe labs à sorti un module nommé Alchemy qui permet d'utiliser/compiler du code c ou c++
voir :
-1- Infinity Engine
http://en.wikipedia.org/wiki/Infinity_Engine
http://linux.prinas.si/gemrb/doku.php
-2- Alchemy
http://labs.adobe.com/wiki/index.php/Alchemy
voila voila
Après pour le server : udp et c# ou java selon les préférences.
hum, enfin la d'un coup j'ai un doute, je ne me souviens plus si as3 gère l'upd...
hum, fichtre dieu que c'est frustrant de ne pas tous savoir.
Voilà voilà.
25 déc. 2008 à 23:24
merci
24 janv. 2008 à 09:09
http://www.flashdevelop.org
Un ide Flash bien fait et surtout prometteur !
Allez y jeter un oeil.
Cordialement
nicolas Maucci
13 juin 2007 à 18:41
13 juin 2007 à 18:39
Je n'utilise plus cette outils mais tout est dans la doc.
De plus ce n'est pas pour te décourrager : Mais même une fois décompilé, tu n'irra pas trés loing, car tu n'aurra pas de faculté d'édition ur les images,et autre clip du jeu.
cordialement
13 juin 2007 à 18:19
13 juin 2007 à 17:48
par contre tu vas avoir du mal à editer les clips.
13 juin 2007 à 13:18
13 juin 2007 à 01:42
ensuite je recompilerai avec mtasc
http://www.mtasc.org/
c sur que c pas tres simple a mettre en oeuvre comme methode, et c'est moins convivial que d'utiliser l'IDE de flash mais vu que tu es sous debian tu dois avoir l'habitude :p
13 juin 2007 à 00:21
Hum.
Le plus simple est d'utiliser Flash( dispo chez Adobe )
Mais a ma connaisance Adobe n'as pour linstant pas sortir de version pour Linux.
L'édition de documment falsh(.fla) sans l'ide flash n'est pas evidente, voir inutile. Car pour l'instant Il ne me semble pas qu'une solution libre est de réelle aptitude pour modifier ce format de fichier.
Tommy
( conternant le help.swf ) utilise un decompilateur, Je n'ai plus le fichier sous la main depuis longtemp.
Cordialement
12 juin 2007 à 14:25
22 avril 2005 à 20:38
Même si les dessins ne sont pas réalistes(même si c'est cool en DA) cette source est trop bien pour apprendre!
Par contre, c'est quoi le code que tu as mis dans le bouton "fermer" du fichier help.swf car on a pas le fla de ce fichier!!
Merci!
18 mars 2005 à 16:36
Le problème c'est qu'il n'y a pas de fin.
Enfin c'est super.
P.S. Je n'et pas encore trouvé où est l'image du gars (ou le clip) !!!
22 janv. 2005 à 20:04
Ben pour l'astuce du jeu fait en flash et lu par director, c'est pas trop possible étant donné que nos profs liront notre code...
Enfin, merci quand même, c'est super sympas !
@+
didi
22 janv. 2005 à 15:27
Une des sources flash que j'ai posté est un éditeur de map, il pourrait te donner une idée pour ce qui est de la manipulation des maps ( un des multiples chemins ), en ce qui concerne director, tu peus faire ton jeu en flash puis le lire à partir de director via activeX, sinon : bonne chance.
Cordialement
Le FERBER
Nicolas MAucci
20 janv. 2005 à 23:38
Je suis désolée d'apporter un commentaire de plus qui n'a pas grand rapport avec les sources (super le jeu, bravo !)...
Bon voilà, je me présente, didi, j'suis en deuxième année d'iut SRC (bon j'vous dit pas ce que ça signifie car ça n'a pas grand chose à voir avec ce qu'on fait. En gros, c'est de la création et réalisation multimédia). J'ai un petit projet à rendre qui serait un jeu en director. Mais biensur, personne ne semble connaître director... Alors que c'est super pour faire des jeux en 2D voir 3D !!!! Enfin, du coup, comme je ne trouve aucune information, je cherche désespérément quelqu'un qui pourrait me venir en aide. J'en suis réduite à chercher des sources en AS pour les convertir en lingo... Mon gros problème dans mon jeu pour le moment est de gérer les plateformes du jeu... j'avais pensé à faire une map sous flash... mais je sais pas comment on en fait !
3 janv. 2005 à 10:42
Le game over est tributaire des pv du pj : un simple setteur getteur règle le problème, je dirrais bien que c'est un jeu d'enfant.
Cepandant il est vraie que je n'ais pas envie de me casser le dos a le faire , surtout que ce jeu n'en vaut pas la chandelle et qu'il ne me rapporte que des remarke inconstructive du genre
" tu utilise quoi comme prog " et "Tu as pas pensé au système de Game Over"
Voila, biensure je ne devrait pas être aussi "Mal gratté"
et je m'en excuse, mais méttez vous a ma place, cette source est un mine d'info en libre services, et comporte en elle même assez d'idée et de technique pour pallier au problème simple rencontré l'or de la réalisation d'un jeu, il suffit juste de lire le code , le comprendre, et le réutiliser, pas de copier coller juste comprendre les techniques.
Tant que personne ne ferra sa il est vraie que j'aurrais toujour se genre de question.
Et si par aprés avoir lu tout le code du jeu vous n'avez rien apris d'intérrésant, c'est que vous étiez capable de le faire vous-même, auqu'elle cas vous n'avez pas besoins de me poser de questions.
Donc je récapitule :
- sois vous etez assez bon pour le faire vous même et dans ce cas la vous n'avez pas besoin de me poser de question.
- sois vous n'avez pas encore le niveau pour le faire vous même. Dans ce cas la lisez et relisez tous le code et comprennez le, aprés quoi vous aurrez le niveau.
Donc dans les deux cas il n'y a pas besoins de posser de question ayant avoir avec les codes de cette source.
espérant ne pas vous avoir courroucé.
Cordialement
Le FERBER
Nicolas MAucci
3 janv. 2005 à 05:23
Tu as pas pensé au système de Game Over... C'est indispensable dans un jeu habituellement !
coolsalex666@hotmail.com
^ j'ai réélement besoins d'aide...
Merci d'avance ^^
6 déc. 2004 à 19:48
c'est logiciel son tro chere pour moi lol!
bye
merci
6 déc. 2004 à 02:03
si oui : elle n'est pas marrante
si non : c'est du 'flash' fait avec 'Macroméedia flash' ( regarde sur google pour plus de d'info).
Cordialement
Nicolas Maucci
"Les gens c'est comme tout : quand y'en à trop c'est pas bon pour la santé : alors de temp en temp vaux mieux en tuer un ou deux."
5 déc. 2004 à 14:00
ta utilisé koi kom logiciel pour le faire!
26 sept. 2004 à 01:45
2. Le player flash n'utilise en aucun cas les ressources de la carte graphique autrement que pour afficher le résultat (et non pour le calcul)
3. Programmation :
- Pas d'enterframe en continu
- Peu de movieclip
- Peu d'alpha
- Bitmap plutot que vectoriel
- Pas de hitTest (important)
- etc...
Bon c'est vrai flash n'est pas le meilleur outil pour ce genre de jeu, j'espère que ca s'arrangera avec 8ball (le prochain flash)
Au passage, dofus est terrible.
26 juil. 2004 à 14:39
Et bienvenue dans le monde des bugs et autre truck bizzard ... bref le monde de la programmation...
Un etrange alchimi entre des littres de caffé , des paquets de cloppes et des nerf d'accier.
Au passage voici un lien trés intérrésan pour qui veut faire du jeu flash :
http://www.dofus.com
Encore merci pour les compliement
et bonne continuation !
Cordialement
Nicolas Maucci
Ps: pardon pour les phautes je nais de correcteur automatique.
24 juil. 2004 à 23:29
jviens de commencer a aprendre le flash
Via flash mx 2004 sous win98
et franchement !!respect!!
des que je serai asser fort pour commencer a codé
j'esayerai de fair de nouvelle map ;)
mais franchement respect lol
PS: désoler pour les phautes
18 avril 2004 à 16:25
sous windows XP tu peux regarder et executer des fichiers qui sont dans un répértoire zip,c'est la connerie que j'ai faite et c pour ça que ça marchait pas ;)
g donc dézipé dans un dossier à part et là ça marche.
Bo jeu,dialogues sympas(ma préféré ce sont les supplications du blob),j'imagine que ça doit représenté des heures et des heures de travail.
Trés intéréssant.Bon courage et j'espère que tu pourras trouver du boulot avec ça.
salut et bon courage.
18 avril 2004 à 16:07
18 avril 2004 à 15:08
Je n'ais pas la solution.
je suis sous win 2000,
je vien de tester avec les lecteurs flash suivant
6.0 r21
6.0 r95
7.0.19.0
ainsi que le lpayer interne a flash mx
et sa tourne ( sans avoir recompilé bien sur)
bref, faudrait que je teste sous Xp, mais j'an estpas d'exemplaire sous la mains.
peut être que les fichiers sont en ascci au lui d'étre en utf8,
ou l'inverse.
bref, je ne pas t'aider sans devroir installer ou trouver un win XP,
malheuresement je n'ai pas le temp.
Cordialement
Nicolas Maucci
18 avril 2004 à 13:30
bonne logique pal.
Je n'ai rien compilé j'ai lancé l'animation que tu as cité au debut de tes commentaires,j'ai windows XP et j'ai la version 6 du lecteur flash .Mon interprete/compilateur flash est flash MX.Et ça marche toujours pas...
18 avril 2004 à 13:23
il est possible que le jeu ne fonctionne plus dans le cas ou tu le recompile sous flash MX 2004,
autre problème posible, j'ai fait ce jeu pour windows,
donc je n'ai pas fait attention a la caste des fichiers , il se peut que sa pause pb sous un autre system.
si tu le lance partir d'un serveur, vérifi les droits de lectures.
Vérifi que ton system n'est pas un MAC, si c'est le cas : trouve un pc pour tester le jeu.
Sinon, je peus te proposser mes services pour trouver une solutions, mais bon si tu est la, c'est pour ne pas avoir a dépenser d'argent dans les services d'un tiers developpeur... donc resert-toi un café et remet toi au boullot.
Cordialement
Nicolas Maucci
18 avril 2004 à 02:50
l'animation se bloque sur "chargement des niveaux" bien que tous les fichiers sont dans un seule et meme répértoire.Can u help please ?
Merci.
7 janv. 2004 à 09:33
je viens de regarder ton space invader, c'est du bon boullot, mais il faut encore l'améliorer sutout en terme de rapidité, j'ai du mal a suivre avec mon pauv 400...
IR, en ce qui concerne le temp d'écriture, ben, je ne le connais pas, mais j'aimerais bien.
cordialement
Nicolas Maucci
1 janv. 2004 à 07:32
17 déc. 2003 à 00:28
http://perso.wanadoo.fr/matosnet/invader.htm
C un peu long a car jy ai mis des sons, la prochainne foi je ferai mieu héhé:)
Sinon bravo ferber, l'interface est super net, les décos bien foutu, jtrouve ca bien technik, jcompte un jour faire aussi bien!
-MaT-
3 nov. 2003 à 19:33
cordialement
Nicolas Maucci
3 nov. 2003 à 16:54
lorsque je disais :
" je ne pense pas que ce soit un critère de jugement quand à l'interet du jeu.",
je veux dire que l'interet d'un jeu ne repose pas uniquement sur de beaux graphismes ou une programmation poussée.
il me suffit de citer l'exemple de Tetris, un jeu qui a conquit la planète avec des graphismes simplistes, et programmé en "quelques lignes".
par contre, une bonne realisation renfoce l'interet, ok.
quand à ton interet qui te pousse à jouer à un jeu ou à un autre, il est tout à faut subjectif et ne s'applique pas forcement aux autres personnes.
en constatant le succés incontestable des emulateurs de vieilles consoles sur pc, pourquoi diable penses-tu que tout ces joueurs perdent leur temps avec ces vieux jeux qui ne peuvent rivaliser avec les nouveautés XBox et compagnie?
mon objectif est de créer un action /rpg old-school sans pretention. j'aime cela et je sais que d'autres joueurs,même en nombre minime, prendront plaisir à y jouer.
cela n'apporte rien de neuf, mais ca plait tout de même à un certain public.
sinon, ne t'excuses pas; je ne considère pas ton "ton ralleur"; on parle et argumente; tout va bien.
très cordialament,
3 nov. 2003 à 04:30
Si vous pensé que la qualité de finition d'un jeux n'entre pas dans les critère de choix, vous devriez vous possez la question suivante.
En considérant que ce jeu/film/livre est gratuit mais qu'il ne rivalise pas avec un seul des de ces concurrent du commerce, voir même avec d'autre concurrent gratuit que je l'on peut trouver. Pourquoi perderai-je nom temp dessus ?
Ensuite, si par "vraie version" vous désignez un jeu aux-qu'elle on peut jouer en ligne ou via d'autre support : la reponse est non. personne n'aurrait d'interret à i jouer.
Cepandant excusez noi si nom ton semble "ralleur" mais ces dernier tes ne mon pas souris.
Cordialement
Nicolas Maucci.
1 nov. 2003 à 20:41
aucun rapport bien sur, avec ton petit jeu, qui exploite les capacités propres à Flash; d'ailleurs felicitations, j'aime bien la réalisation de ton jeu.
t'as fait une vraie version ?
( désolé, j'ai pas encore le niveau pour poser des questions techniques :(
31 oct. 2003 à 21:39
ça doit être posible de faire un jeu de la sorte.
Car il est vrai que le premièr zelda sur nes et basic, en fessant des map ne dépassant pas la taille de l'écran, et limitant le nombre de monstre par écran, je pense que s'est fessable.
Mais pour que çela tourne sans pb en pleine ecran sur un 366, sa doit vraiement être basic/minimaliste donc, je ne vois pas vraiment pourquoi quelqu'un y jourrais. En ce qui concerne l'utilité si personne n'y joue c'est assez réduit sauf si ce est pour l'étude de flash.
Cordialement
Nicolas Maucci
29 oct. 2003 à 23:51
tu affirme qu'un clone de zelda 1 fait sous flash serait injouable???
je ne pije pas là, je programme actuellement un action/rpg style zelda, ca tourne impecablement, en 40 image par secondes, sans ralentissement (ecran fixe,mais le scrolling est à-la Zelda 1)
et je bosse avec un tout petit PII 366.
tu ne dois pas appliquer la bonne technique de programmation je pense.
bon je vais tester ton jeu que je n'ai pas encore vu, mais à la lecture des critiques ca me botte déjà.
26 août 2003 à 20:00
26 août 2003 à 18:18
flash utilise les fonctions Api de gdi32.dll
le gdi, traites ces fonction est les envoi au driver concerné.
aprés on y'a aussi la dernier version du gfi , le gdi+,
il est facilement utilisable en c#
par contre en ce qui concerne la question ou gdi pompe les resources,
pour les calcule, je cherche encore,
mais bon....
dites mois si sa vous intérraise vraiement de savoir, parsque la la doc.....
je serrais partant pout dire,
que le gdi fait ces calcule en utilisant le proceseur et a la ram, est transfère les resultat au driver concerné,
si le driver concerné est le driver de la carte graphique il s'en suit alors une autre séri de calcule pour appliquer le resultat des demande a l'écran,
dans ce cas
on retombe sur ram+processeur+carte graphique
cordialement
Nicolas Maucci
26 août 2003 à 18:06
Ron Gery
Microsoft Developer Network Technology Group
Created: March 20, 1992
Abstract
This article provides a brief overview of the design and theory of the graphical component of the Microsoft Windows graphical environment. No details are covered.
Overview
The graphical component of the Microsoft Windows graphical environment is the graphics device interface (GDI). It communicates between the application and the device driver, which performs the hardware-specific functions that generate output. By acting as a buffer between applications and output devices, GDI presents a device-independent view of the world for the application while interacting in a device-dependent format with the device.
In the GDI environment are two working spaces—the logical and the physical. Logical space is inhabited by applications; it is the "ideal" world in which all colors are available, all fonts scale, and output resolution is phenomenal. Physical space, on the other hand, is the real world of devices, with limited color, strange output formats, and differing drawing capabilities. In Windows, an application does not need to understand the quirkiness of a new device. GDI code works on the new device if the device has a device driver.
GDI concepts mapped between the logical and the physical are objects (pens, brushes, fonts, palettes, and bitmaps), output primitives, and coordinates.
Objects are converted from logical objects to physical objects using the realization process. For example, an application creates a logical pen by calling CreatePen with the appropriate parameters. When the logical pen object is selected into a device context (DC) using SelectObject, GDI realizes the pen into a physical pen object that is used to communicate with the device. GDI passes the logical object to the device, and the device creates a device-specific object containing device-specific information. During realization, requested (logical) color is mapped to available colors, fonts are matched to the best available fonts, and patterns are prepared for output. Font selection is more complex than other realizations, and GDI, not the driver, performs most of the realization work. Similarly, palette realization (done at RealizePalette time as opposed to SelectPalette time) is done entirely within GDI. Bitmaps are an exception to the object realization process; although they have the device-independent bitmap (DIB) logical form, bitmap objects are always device specific and are never actually realized.
Output primitives are similarly passed as "logical" requests (to stretch the definition) to the device driver, which draws the primitive to the best of its ability and resolution. If the driver cannot handle a certain primitive—for example, it cannot draw an ellipse—GDI simulates the operation. For an Ellipse call, GDI calculates a polygon that represents a digitized ellipse. The resulting polygon can then be simulated as a polyline and a series of scanline fills if the device cannot draw polygons itself. The application, though, does not care what system component does the actual work; the primitive gets drawn.
An application can set up for itself any logical coordinate system, using SetMapMode, SetWindowExt, SetWindowOrg, SetViewportExt, and SetViewportOrg. In GDI that coordinate system is mapped to the device coordinate system, in which one unit equals one pixel and (0,0) defines the topmost, leftmost pixel on the output surface. The device driver sees only coordinates in its own space, whereas the application operates only in a coordinate space of its own, disregarding the physical pixel layout of the destination.
By maintaining the two separate but linked spaces, logical for the applications and physical for the devices, GDI creates a device-independent interface. Applications that make full use of the logical space and avoid device-specific assumptions can expect to operate successfully on any output device that comes down the turnpike.
http://msdn.microsoft.com/library/en-us/dngdi/html/msdn_gdiover2.asp
26 août 2003 à 17:57
The graphics device interface (GDI) provides functions and related structures that an application can use to generate graphical output for displays, printers, and other devices. Using GDI functions, you can draw lines, curves, closed figures, paths, text, and bitmap images. The color and style of the items you draw depends on the drawing objects — that is, pens, brushes, and fonts — that you create. You can use pens to draw lines and curves, brushes to fill the interiors of closed figures, and fonts to write text.
Applications direct output to a specified device by creating a device context (DC) for the device. The device context is a GDI-managed structure containing information about the device, such as its operating modes and current selections. An application creates a DC by using device context functions. GDI returns a device context handle, which is used in subsequent calls to identify the device. For example, using the handle, an application can retrieve information about the capabilities of the device, such as its technology type (display, printer, or other device) and the dimensions and resolution of the display surface.
Applications can direct output to a physical device, such as a display or printer, or to a "logical" device, such as a memory device or metafile. Logical devices give applications the means to store output in a form that is easy to send subsequently to a physical device. After an application records output in a metafile, it can play that metafile any number of times, sending the output to any number of physical devices.
Applications use attribute functions to set the operating modes and current selections for the device. The operating modes include the text and background colors, the mixing mode (also called the binary raster operation) that specifies how colors in a pen or brush combine with colors already on the display surface, and the mapping mode that specifies how GDI maps the coordinates used by the application to the coordinate system of the device. The current selections identify which drawing objects are used when drawing output.
For more information, see the following overviews.
http://msdn.microsoft.com/library/en-us/winprog/winprog/graphics_device_interface.asp
26 août 2003 à 17:51
A system component that processes graphics function calls from applications and passes them to the appropriate device driver.
26 août 2003 à 16:56
26 août 2003 à 16:46
DLL File: gdi32 or gdi32.dll
DLL Name: Windows GDI Client DLL
Description: Contains the Windows Graphical Device Interface (GDI) API used to display 2D graphics in Windows
System DLL: Yes
26 août 2003 à 15:45
bonjour Christophe
La transparence est biensur obtenue par calcul .
Cependant, les calculs ne sont pas tous effectués par le processeur de la carte mère, mais également par le processeur de la carte graphique lorsque cela concerne l'affichage (en fonction de ses capacités). Si la carte graphique n'est pas suffisament puissante, c'est le processeur de la carte mère qui s'en charge (d'ou une surcharge conséquente lorsque le site est important).
J'ai fait des test dans le passé sur la version 5 et des ordinateurs peu puissant (300 MHz) ayant des cartes graphiques différentes. Un jeu de course de voiture sans habillage graphique tourne de la même façon sur les deux (un chrono permet de mesurer le temps mis pour calculer chaque itération). Lorsque le jeu est habillé, une différence sensible apparait dans les chronos entre les deux ordinateurs, cette différence s'accroit à certains moment de la course (passage sous un pont par exemple avec effet de transparence). Le pb devient complexe car les itérations ne prennent pas le même temps, or dans le code, les voitures se déplacent d'une distance constante a chaque itération, on a donc plus un mouvement uniforme ! ( distance constante sur un temps non constant). J'ai essayé de corriger cela en mettant une distance non constante fonction du temps mis pour calculer l'ensemble des mouvements, des chocs, et de l'affichage. Ensuite est venu un autre pb, lorque j'ai essayer le jeu sur un ordinateur beaucoup plus puissant (1.2 GHz), les itérations sont beaucoup plus rapides, la voiture est alors incontrolable. En fait, même si sur tout les test, le nombre d'images par seconde est théoriquement le même, dans la réalité ce n'est plus le cas. L'influence de la carte graphique est a mon sens évidente, sans etre clairement définie.
Cependant les versions ultérieur des flash player gereront mieux ces pb et atténueront ces différences. C'est déjà le cas avec MX, ce le sera surement avec MX 2004.
*en tout K merci Ferber, paske on squat ta source et ca prends des tournures de forum ;) *
26 août 2003 à 13:10
26 août 2003 à 10:08
25 août 2003 à 19:40
on peut constanter que GDI32.DLL est utilisé.
les méthode inporté de cette dernières sont :
Import, GDI32.dll
Ordinal(Hint) Name
00000126 GetCurrentObject
00000177 GetTextExtentPoint32W
00000176 GetTextExtentPoint32A
0000004F DPtoLP
00000171 GetTextColor
00000110 GetBkMode
0000016D GetTextAlign
00000049 CreateRectRgn
00000123 GetClipRgn
00000045 CreatePen
000001D4 SetBkColor
0000010F GetBkColor
00000043 CreatePalette
00000203 StartDocA
0000005B EndDoc
0000020A StrokePath
0000009D ExtCreatePen
000001FA SetTextColor
000000A3 ExtTextOutW
000000A2 ExtTextOutA
000001CC SelectClipRgn
00000189 IntersectClipRect
000001F8 SetTextAlign
000001D5 SetBkMode
0000008E EnumFontFamiliesA
00000158 GetObjectType
00000122 GetClipBox
0000016B GetSystemPaletteEntries
000000AC FillPath
000001B6 Rectangle
0000018B LPtoDP
000001FD SetViewportOrgEx
00000012 BitBlt
0000004E CreateSolidBrush
00000041 CreateMetaFileA
00000201 SetWindowOrgEx
00000200 SetWindowExtEx
0000001C CloseMetaFile
00000053 DeleteMetaFile
0000004A CreateRectRgnIndirect
00000038 CreateFontIndirectA
0000017E GetTextMetricsA
00000178 GetTextExtentPointA
000001CF SelectPalette
000001B3 RealizePalette
0000002B CreateCompatibleDC
0000012D GetDeviceCaps
00000030 CreateDIBSection
00000051 DeleteDC
00000157 GetObjectA
000001C7 SaveDC
000001C0 RestoreDC
000001A6 PolyBezierTo
00000011 BeginPath
000001F2 SetPolyFillMode
00000191 MoveToEx
0000018D LineTo
0000005E EndPath
000001CB SelectClipPath
0000002A CreateCompatibleBitmap
000000DF GdiFlush
000001DE SetDIBitsToDevice
00000208 StretchDIBits
000001CE SelectObject
00000054 DeleteObject
00000206 StartPage
0000005D EndPage
00000167 GetStockObject
donc nous pouvont constaterque flash n'utilise pas directement la carte graphique , mais utilise les api disponibles.
Maintenant reste a savoir si GDI32.dll utilise la carte graphique
cordialement
Nicolas Maucci
25 août 2003 à 19:26
on peut aussi penser :
flash utilise des fonction d'affichage qui appartiennent au system d'exploitation.
on peut se dire que flash n'appèle pas la carte graphique car trop de paramètre peuvent rentré en conte ( et que l'objectif de macromédi et de produire un lecteur le plus légé possible).
donc disons que flash n'appéle pas la carte graphique
mais une Api générique, qu'i ne varie que trés peux selon le system.
disont la fonction 'A()';
flash n'appéle pas la carte graphique mais utilise donc a(); pour dessiner a l'ecran,
par contre la fonction A(); manage peut-être les resources, et choisi peut être ou les calcule sont éffectué selon les résources disponibles,
je pense qu'il est clair que flash ne peut pas contenir la définition de chaque carte graphique, et de chaque gdriver de carte graphique,
a mon avis il doit utilisé des fonction générique,
et il est envisageable que les dites fonction systems utilise ou non, la carte graph.
Biensure, ce ne sont que des théories basés sur les articles plus
haut trouvé sur le site de macromedia.
cordialement
Nicolas Maucci
25 août 2003 à 19:13
car on ne déssine plus 400 *300 , mais sur 1280 *1024
on a beau déssiner du verctoriel, au final, tous se retrouve pixels,
et en 400 L on en déssine trois Fois Mois qu'en 1280.
de surcroit,
on a toujour autre chôse que flash qui tourne dans le fond le desktop, et autre app,
si on posséde un carte graph puisante, les autre soft en cours peuvent aussi s'en servir, bouffant ainsi moin de cpu
donc si tu a une gros carte graphique et qu'une certaine partis des autres app en cours s'en serve, il y'as moin de cpu et ramm utilisé que pour un pc indent avec une carte graph moin puissante,
donc plus les apps utilise la carte graph , plus sa l'aisse de cpu et de ram a flash, donc flash tourne plus vite non par du fait qu'il utilise la carte graphique mais du fait que les autre prog utilise la carte et bouffe moins de cpu/ram
cordialement
Nicolas Maucci
25 août 2003 à 16:49
Prenez une anim en 400*300 avec plein de trucs qui bougent, des transparences et tout et tout... Bon ça passe plutot bien. Maintenant regardez la meme anim (donc le pros fait les memes calculs) mais en plein ecran (genre 1280*1024)... et ben là votre PC il fait moins le malin à moins d'avoir une G-force 8 512Mo... ;)
25 août 2003 à 08:08
24 août 2003 à 15:33
cepandant comme tout les chemin ménnent t'a rome..
si j'ai le tmp aujourdhui je regarder dans les sources du lecteur flash pour l'inux, pour voir comment ils fon, cepandant je ne suis pas sur de trouver grand chôse ca je ne dispose pas des library de base pour l'inux.
cordialement
Nicolas Maucci
24 août 2003 à 14:30
24 août 2003 à 14:19
En tout K si tu as raison, ca va changer ma façon de travailler en flash.
donc d'avance merci a tous les 2 :D
24 août 2003 à 13:52
une personne s'y connaisant pourrait confirmer ?
23 août 2003 à 18:24
Mes propos peuvent porté a confusion car je n'ai jamais dis ke : "on demanderai a la carte graphique de faire ces calculs" mais je parle de "ressources graphiques" donc de l'affichage...
A titre de test prends 1 anim matrix du concours (n'importe laquelle car elle correspondent a l'achetype ke je decris : " 1 anim avec pleins symboles diffrents ki bougent par interpolation et surtout ki utilisent de la transparence").
Tu n'auras pas le même resultat a pros égal, avec 1 ati 9500 pro et 1 carte avec 4 Mo de ram.
q?_?p
23 août 2003 à 17:49
23 août 2003 à 17:44
********************
Comment puis-je améliorer les performances de Macromedia Flash Player ?
La lecture du contenu Flash est généralement plus fluide sur les ordinateurs plus puissants. Une connexion plus rapide, RNIS ou T1, par exemple, permet de télécharger le contenu Flash très rapidement. Nous vous recommandons de fermer les applications autres que votre navigateur web pendant la lecture du contenu Flash. Vous pouvez également affecter 10 Mo de cache à votre navigateur. Sur le Macintosh, vous devrez affecter un minimum de 20 Mo de mémoire système à votre navigateur web.
//*******************************************
Macromedia Flash Player uses all CPU cycles during playback
Issue
When viewing a SWF file in the Macromedia Flash Player, the Task Manager shows 100% CPU usage, or all cycles in use.
Reason
The Flash Player requests all available (idle) CPU cycles to maintain a movie's maximum framerate during playback. However, the Flash Player will relinquish control to any other program requesting additional CPU cycles.
//************************************************
Flash movie playback can vary with processor speed; test the movie on computers of varying speeds
Test on all target platforms
When you develop a Macromedia Flash movie, you should spend some time defining who the audience for the movie will be. Part of this process is deciding what the minimum system requirements should be for the computers used by that audience.
Determine the slowest processor speed you want your movie to be able to play on and verify that the performance of your movie is acceptable on a processor of that speed. You should also determine if there is a range of configurations you will have to support (such as Windows NT and 2000, Macintosh) and test on enough of them so that you can infer success on all of them. Be sure to include parameters such as browser software, screen resolution, and memory in your testing.
23 août 2003 à 16:26
Cordialement
Moi
23 août 2003 à 15:15
oui, j'attend avec impatience le jour ou ils vont se décider a jarter director au profil de flash :)
Cordialement
Nicolas Maucci
23 août 2003 à 13:46
Il n'y a pas ke le processeur ki compte, en fait pour flash C surtout la carte video ki compte... kan je dis surtout ca depends du projet bien sûr ... par exemple dans 1 anim avec pleins symboles diffrents ki bougent par interpolation et surtout ki utilisent de la transparence, ce sont avant tout les ressources graphiques ki trinquent pas le pros...
voil@ CT juste en passant ;)
Pour la politique de macromédia, je pense kil veulent eviter ke flash ne canibalise director ... ce ki ne serait pas 1 mal a mon avis ;)
23 août 2003 à 03:05
l'avantage du 400, c'est qu'il est pourris, est si une anime tourne correctement dessus, y'as de grande chance qu'elle rame pas aillieur, c'est vraiment le seul avantage...
En ce qui concerne le fps et bien malheuresement sa n'as pas d'effet sur un 400, car il ne peut pas axélerer l'anime, a l'excéption du menu principale, (car a se moment il y'as peut de calcule) mais pendant le cours du jeu, la vitesse est la même que je sois en 12, 24 ou 50fps
seule, le changement de calité fait vrier la vitesse.
Le faire en C c'est surtout pour ne plus avoir a limiter le contenue, de peure, que sa rame, que sa soit trop long charger,
les limites... c'est a cause de sa que je n'ai même pas osé placer des bruitage est des musique d'ambiene dans l'annime.
y'as un truck qui m'embête avec flash, c'est qu'au cour des dernières version, on ne peut pas dire que la rapidité est vraiment changé, on a de nouvelle fonction a chanque fois, mais la vitesse change pas, et la flash 7 c'est pareille, des nouvelle fonction, gestion des erreurs, gestion du menu contextuel, un printerjoob, mais la vitesse, n'as pas changé, resultat, on peut en faire de plus en plus avec les même resources. d'un côté flash se raproche du java et du c#, de l'ottre il reste est bloqué par son manque de rapidité, c'est clair qu'avec un gros processeur sa passe, mais sa ne vas, pas !
imaginon, que l'on veuille refaire le premier zela, sur nes, on pourrait faire les script, les moteurs de déplacement, et on pourrait même le faire en réseau, mais ... alors que le premier zela avec un imulateur nes tourne sans problème sur un 400 sa serrait au limite du jouable avec flash ...
Certain de mes amis, me dirrait que flash n'est pas un vraie language de prog, que de toute façon c'est pas compilé, certe... Mais dans ce cas pourquoi macromédia, fourni des fonction comme hitTest()?
la politique de macromedia est bizard, comme si ils assaiyent de cantoner flash a de petites animations, et de laisser director, faire le gros du travaille !
director supporte la 3d, et il peut contenir des annimation flash...
cepandant director on en voit nullpard, tout le monde sans fou... même les graphiste n'on pas envie de mêtre les mains dedans( enfin la plus pard)
enfin, c'est vraiment frustrant, dans flash, je suis plus souvent limiter par des problème de temp de traitement que par des problème de manque fonction c'est comme si on roulez en formule 1 sur une route limité a 50.
on a toute un tas de fonction pour faire tout un tas de truck super, mais on sait que sa vas ramer chez la plus partdes utilisateur, alors que sa ne devrait pas.
m'enfin bon, je me mécarte du sujet,
en ce qui concerne le languague de dévellopement, pour le futur jeu, et bien, je serrais tenté de dire, que je ne veut être limité que par mom manque de savoir, car la c'est qu'un problème de temps,
aujourd'hi je devait finaliser un l'ouverture d'un prog en java, ce dernier devait s'ouvrir en doublecliquant sur une icone, sans ouverture de console dos, et en meme temps, devait lancer Mysql toujour sans ouverture de console, pas moyen de le faire, en java, cette saloperieest pourtant sencé être évolué, j'ai bien pensé le faire en c#, mais sa aurrais tourné au ridicule, faire, installer le framework .net, pour ensuite pouvoir installer lancer un prog java, enfin bref des limites toujours des limites, resultat je l'ai fait en c++
en99 j'ai commencé par le html, trop de limite,
je suis pasé au javascript trop de limite+trop de changement entre ie netscape etc,
je suis passé a flash trop, de limite ( compensé par plein d'avantage)
j'ai testé webdev, et j'ai regrété,
le perl, j'étais trop mauvais a l'époque pour m'en servir correctement, et le php, je m'ensers toujour, mais c'est pas avec sa que je vais faire un jeu ou une app.
pour le développement, je suis passé a windev, (et un peu de vb, pour faire des pauvres macros)
trop de limite je suis ensuite passé au c# et au java, trop de limite,
bon ben la passe au c++
tu me dirais, quitte a plus avoir de limite autant faire de l'assembleur, c'est vraie, mais je m'en sans pas le courrage.
En tout cas pour finir, c'est clair que flash est mon outils préféré !
en deux secondes on peut faire une forme est la faire se balader dans tout l'écran ! et si on deux minutes en plus, on peut la mêtre en ligne... c'est clair que c'est la folie,
l'éditeur est génial, bien qu'il lui manque toujour, une bonne complementation du code !
pourquoi il ne font pas un flash#, utilisable en local, avec des fonctions d'accés au ficher, des axés natifes au base de données, au clée de registres, avec un moteur 3d natif ?
il ont l'argent pour dévelloper, mais visiblement il sont loin d'être motivé il pourrait faire bien mieux.
Et merci pour le compliment au sujet des illustres :)
cordialement
Nicolas Maucci
22 août 2003 à 16:31
bonne continuation ++
22 août 2003 à 15:59
enfait ce qu'il c'est passé, c'est que j'avais envisagé, que les joueur eux même puisse réaliser des niveaus, pour cela je voulais faire un sript côté serveur, ou un joureur aurrais pus envoyer son niveau (.swf +xml ), les dialogue est autre pointxml,
ce script côté serveur, aurrais permit de rajouter une porte dans un niveau déja existant, et de relier cette porte au niveau qu'il vien de créer.
de cette façons on ne modifie que le niveaux.xml, en y rajoutant un node porte suplémentaire,
j'avais ausi en tête l'idée de faire un éditeur de niveau online,
pour le md,
tu vas me dire, c'est bien bô toutes ces parole , mais pourquoi je l'ai pas fait.....
et ben, enfait, c'est bien bô tout ces effort , mais quitte a galèrer auttant le faire en c++ que sa rame pas, que sa sois encore plus beau, et avec mes illustrations , non pas que les dessins du jeu ne sois pas de moi, mais simplement, c'est tout du vectoriel, et je souhaite que mon jeu reflète mes illustres ( http://www.chez.com/illustrations/)
dans ce cas tu vas me dire, pourquoi j'ai pas simplement abandoné le proget,
ben, je l'avais sacrément bien entammé, et de plus j'avais envie de placer une sources flash, ici, alors, j'ai fini, l'annime, qu'elle soit utilisable, et l'idée que d'autre plus motivé que moi, puisse s'en servir et l'amméliorer, genre, plein de niveau, avec un vraie senard, et pourquoi pas un mode multiplayer , sa me ferrait rêver. mais bon, la flash, sa rame trop, j'ai fait tout se que je pouvais pour avoir un moteur vachement légé et rapide, mais c'est pas assez a mon gout,
alors, je vais le refaire en c++, même si au final, je suis sur que j'en ai bien pour 2 a 3 ans, et que l'orsque je sortirais le jeu, personne voudrat y jouer car sa serra trop démodé,
mais bon, sa me démange....
Cordialement
Nicolas Maucci
22 août 2003 à 13:47
benpro2, il faut décompresser tes fichiers dans un meme répertoire et non lancer le swf seule, pfff , et ca ose s'apeller benPRO...
21 août 2003 à 14:16
Vos message me font très plaisirs,
En ce qui concerne l'attaque des ennemies, le system en lui même est laborieux...
1 l'utilisateur clique sur l'icone attaquer, le boutton informer l'objet "mouse" que le personnage passe en mode attaque,
MouseCursor.prototype.ActionAttaque
2 l'orsque l'utilisateur clique sur quellque chose,
la methode MouseCursor.prototype.onMouseDown est appelé,
cette dernière selon le mode choisi repère la position, pour ce qui est de l'attaque, la methode va parcourir le tableau _g.arrayMonstre et tester si la position du curseur touche l'un des monstre( ou toute autre entité qui a des pv )
si elle touche une entite , la variable "ActionsEncours" du personnage est modifié, devenant, ActionsEncours=new Array(3,cible);
le 3 représentant l'action d'attaque, et cible représentant l'entite du tableau _g.arrayMonstre que la souris a touché.
si le curseur n'as rien touché l'action devient une simple action de déplacement vers le clip mouse
new Array(0,_root.mouse);
l'action du personnage est maintenant défini.
maintenant l'ors du déplacemement du personnage et des monstres (function deplace), plusieurs action sont réalisés, en gros :
le personnage regarde ou il doit aller avec sa methode :
reposSouris();
dans cette methode le personnage selon l'action qu'il vas éffectuer a deux posibilité, si il marche,
il vas se récupérer la pose de la souris, sauf, si la souris touche l'interface, ( dans se cas c'est que l'utilisateur est entrain d'utiliser les option donc sa ne compte pas comme un déplacement ) deplus il vas vérifier que le bouton de la souris est enfoncé grace a la variable MD( true/false)
si l'action est autre qu'un déplacement de base,
il vas dans ce cas vérifier qu'il n'est pas en colision avec la cible et que la cible n'est pas lui-même, si il l'est il ne bouge pas
si il ne touche pas la cible est que la cible n'est pas lui même,
il vas récupèrer la position de la cible , avec un leger décalage, pour se positionner a côté de cette dernier.
maintenant le personnage sais ou il doit aller,
mais il ne sais pas si il peut y aller,
on teste ace moement la direction ou il doit aller, et pour chaque direction on vas tester les collistion avec le mur _root.monde.mur,
avec une méthode particulière,
si le X du perso est 10 et qu'il doit aller a x 20 on vas faire un hittest avec tout les point entre 10 et 20 ( pour être sur qu'il ne vas pas traverser les petit mur par megarde );
aprés tou sa on sait si il peut se déplace,
mainteant 3 posibilité
- il est bloqué par un mur, il n'avance plus
- il n'est pas bloqué par un mur il se déplace,
- il nest pas bloqué ar un mur, mais il a atteint sa déstination,
dans ce dernier cas, il peut maintenant effectuer les actions,
dans notre exemple il attaque,
il regarde si sa cible a plus de 0 pv (cible._pv);
si ouis il affiche l'annimation d'attauqe est appèle la méthode attaque()
cette methode parcours le tableau _level0.tDeph, et regarde si un clip, contenant plus de 0 pv et en train de toucher, l'arme du ppersonnage, ( représenté par le clip transparent nomé arme présent dans le clip du perso est du monstre ),
si il touche cible perd un _PV. a noter que la property _PV de l'objet entité appèle directement la frame de l'animation du personnage label Mort quand elle attend 0 ( c'est pareille pour, les coffre, les porte , les monstre);
aprés cela le personnage se pélace si il peut,
puis se redimentionne grace a la methode resize();
est si il est le personnage principale, le clip _root .monde est redimentionné et déplacé.
bref ce qui fait que l'attaque n'est pas super au point, c'est que la mêthode hittest dans reposesouris, est uitilisé avec les limite des clip est mon pas avec leur zone pleinne, car c'est plus rapide, et que l'on pas besoins de savoir si le perso touche au pixel prés une autre entité, le pixels prés n'étant utile que pour les mur.
voila, en cequi concerne le prob de chagement de niveau, et bien je n'ais pas d'idée, tout les fichier sont-il dans le meeme rep ?
voila, bref, je suis ravi que cette source vous plaise.
Cordialement
Nicolas Maucci
21 août 2003 à 11:29
sinon faudrai un peu raser ta barbe =)
21 août 2003 à 10:49
C une source tres riche avec ça je vais apprendre plein de trucs ...
pour les phautes je trouve ça marrant ;)
et enfin déso G po de soux :D
21 août 2003 à 10:14
Mais j'ai attendu mais toujours rien...
C'est de moi que sa vient...