MOTEUR 2D 8BITS PURE BASIC
cs_EBArtSoft
Messages postés
4525
Date d'inscription
dimanche 29 septembre 2002
Statut
Modérateur
Dernière intervention
22 avril 2019
-
30 janv. 2004 à 10:32
didyman Messages postés 86 Date d'inscription vendredi 26 novembre 2004 Statut Membre Dernière intervention 8 novembre 2007 - 29 sept. 2005 à 21:07
didyman Messages postés 86 Date d'inscription vendredi 26 novembre 2004 Statut Membre Dernière intervention 8 novembre 2007 - 29 sept. 2005 à 21:07
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/19882-moteur-2d-8bits-pure-basic
https://codes-sources.commentcamarche.net/source/19882-moteur-2d-8bits-pure-basic
29 sept. 2005 à 21:07
Mais c'est super cool d'avoir essayer d'en faire un sois même... 10/10
9 juin 2004 à 13:58
(pour les actions je sais c'est pas facil mais bon, j'ai du mal a le consevoir comme un vrai moteur sinon)
(ha oki reponse 5 et 11 desole mais bon ca serai bien quand meme)
(Joli boulot pour du vb. J'aime ta facon de code, je code exactement pareille :) nom de variable (koi ke jevolu encore sur ca), nettetez du code (un pur bonheur que de lire un code comme celui la), et enfin les nom de fichiers :) je croirai presque que c moi qui la fait haha)
9 juin 2004 à 13:49
Layer au Dessous >> Layer des Sprites >> Layer au Dessus ?
9 juin 2004 à 13:46
22 mai 2004 à 17:41
EG256C.dll
Comment pourrais-je me la procurer please
26 févr. 2004 à 18:13
19 févr. 2004 à 16:12
- Ajout de la dll cpp bibliotheque graphique
- Ajout d'une couche directdraw
- Gestion des sprites de differentes tailles
- Ajout d'une couche d'alpha blending (effet de transperence)
- Tris des sprites fixé
@+
ps : j'ai ajouté l'éditeur ;P
31 janv. 2004 à 19:15
toujours la methode la plus rapide ! mais bon si tu le vois
comme ça alors...
Sinon pour le code de l'editeur (je ne veus pas le diffuser pour le moment car il n'est pas fini) mais envoi moi un msg avec une
adresse mail valide je te le fillerais volontié
@+
31 janv. 2004 à 19:10
pour les effets possibles j'y avais pensé aussi pour creer l'ombre du vaisseau ou sa transparence mais j'ai opté pour les hdc car c'etait plus rapide et que je code pas en asm :/
cette methode que tu utilise est d'ailleur celle utilisé par l'api directdraw qui utilise uniquement des dibs donc oui pour la dll asm
directdraw permet aussi cette technique du dessin point par point sur des surfaces via la propriétée Lock j'ai d'ailleurs pu tester un sample qui animait un sprite en rotation avec transaprence tout en directdraw7
et c'etait tres rapide (normale c'est le but de DD7)
donc je suis préssé de voir evoluer ton projet :)
heu tu comptes donner la source de l'editeur de tiles ?
31 janv. 2004 à 12:06
Tout d'abord merci pour vos conseil
Maitenant voici je ce j'en pense :
1- je n'utiliserais dans ce projet QUE 256 couleurs
c'est absolument fait expres et cela ne changera. c'est un point de
vue technique qui correspond au projet auquel je souhaite aboutir.
2 - l'API stretchdibbit fonctionne dans tout les format de couleur et d'ecran depend de getdevcaps cf: doc msdn
3 - Je ne souhaite pas non plus utiliser de modules de classe encore
une fois cela vient de la technique que je souhaite enployer la vitesse de moteur n'en sera que diminuer par la gestion memoire des objets par vb (cela dit c'est une idée a prevoir pour facilité la maitenance du code)
4 - Pour ce qui est de l'emploi de DC c'est completement proscrit ! tout simplement par ce que je veus maitrisé le process de dessin, car une fois de plus le but est de pouvoir gerer la transparence, l'alphablending, rotation, paletissation et autre effet encore non implementé ce qui revient tres lourd avec un DC de plus cela reviendrais a allouer un espace memoire que l'on a deja alloué au chargement des tiles
5 - Il est IMPOSSIBLE d'utiliser la technique du redessin partiel car viendra pluie neige et autre effet de superposition qui vont demander trop de tampon et de recalcul donc mieu vau garder le bon vieu temp reel qui finallement tourne plutot bien compte tenu du fait qu'il n'est pas encore optimisé
6 - L'usage de GetAsyncKeyState est completement hors sujet car elle necessietrais un appel au api a chaque cycle alors que le technique du callback (evenement) permet de garder une trace de la touche dans un tableau qui ne subit aucune modification si le joueur n'appuie pas donc gain de temp (de plus niveau machine l'indexation est plus rapide que l'appel)
7 - Pour ce qui est du nombre de touche je ne vois pas ou est le probleme ? tout les jeux aujourd'hui son jouable avec une manette qui possede au minimum deux ou trois boutons Il suffit de bien gerer les menus.
8 - Pour ce qui est de setpixel alors c'est carrement du delire car explique moi comment une appel a une API peut etre plus rapide que Table(x)=Byte ? je suis conscient que la methode de clipping laisse a desirer mais la c'est pousser un peu loin car setpixel ne vas pas dessiner tout de suite non plus il vas verifier la validité du dc (donc il faut en créer un) puis il vas regarder la taille du buffer selectionner la methode en fonction du nombre de couleur de plan etc... non c'est tout vue ... Table(x) = Byte !
9 - sinon pour les sprite ne t'inquite pas j'ai deja prevue le coup il serons gerer differement dans la 3 eme version et pourrons avoir n'importe quel taille
10 - Pour ce qui est enfin de la "core" c'etait deja l'idée au tout debut de la source regarde la description il est deja mentioner la DLL ASM qui est deja pratiquement fini et je vous l'assure devra bouster convenablement la partie graphique ! j'ai meme rajouter une couche pour gerer la superposition des arbres ombre pot de fleur etc...
11 - L'idée du queryperformancecounter est vraissemblalement l'idée la plus plausible je vais voir ça !
voili voilou c'etait mon avis sur la chose
encore merci pour vos effort
@+
31 janv. 2004 à 05:11
en fait les ressources sont boufées par le tracage bit a bit de l'image ca equiveaux a utiliser un hdc et l'api setpixel pour tracer l'image ^^
donc c'est lent d'ou 2 soultion :
coder une dll asm pour speeder tout le processe de tracage de l'image
ou utiliser des hdc pour le stockage en memoire et bliter des blocs de bits comme dans mon moteur hybrid
un truc sympas a faire serait d'essayer la solution du hdc + Setpixel pour voir la difference de vitesse
surtout que la la taille des sprites et des tiles est de 16*16 :/
31 janv. 2004 à 03:32
surtout la maniere dont tu dessine les sprites etc ... sur le buffer
en utilisant des bytes ^^
en fait il serait interessant d'utiliser l'api QueryPerformanceCounter pour savoir si cette methode est plus rapide que de creer un hdc et d'y faire un strectdibits du sprite je vais voir pour testouiller ca de plus pres pour en avoir le coeur net...
sinon il pourrrait etre interessant de mettre ce genre de fonctions (comme je disait) dans la partie affichage du moteur sous forme de dll externe (codée en asm ou autre) et faire de meme avec le 'core' du moteur ainsi on pourrait y acceder via vb et ca serais plus rapide ^^
autre solution une dll (oui encore) pour les fonctions 'lourdes' sur le traitement de l'image et le reste dans vb
enfin y a plein de solutions je pense ^^
30 janv. 2004 à 22:35
un buffer pour le fond (arriere plan)
un buffer pour les objets (second plan)
un buffer pour les sprites (premier plan)
quand un sprite bouge, au lieu de redessiner tout le fond tu recuperes la zone de l'ecran sous le sprite (une sauvegarde d'une zone du fond en gros) et lorsque tu dessine le sprite tu redessine la zone a l'ancienne position du sprite et voila :)
avantages de cette methode:
affichage plus rapide car moins de pixels a changer (par rapport a la taille de ton fond)
hum keyb(255) ??
pourqoui ne pas utiliser l'api GetAsyncKeyState avec un tabelau modifiable du genre :
Dim TabTouche(20) as integer
Tabtouche(0) = 32 ' VbkeySpace (pour la pose)
..
..
Tabtouche(20) = 27 'VbkeyEscape (pour quitter par exemple)
puis dans le code:
If GetAsyncKeyState(Tabtouche(0)) then Pause = Not Pause
comme ca tu peut virer le doevents de la boucle principale ce qui accelere encore le 'core' de ton moteur et te permet de modifier les touches pendant l'execution par exemple comme une option pour modifier ses touches dans le jeux :)
reste a savoir le nombre de touches dont tu auras besoin ...
normalement 16 touches suffise comme sur console :
Haut
Bas
Gauche
Droite
Select
Start
A
B
C
X
Y
Z
L1
L2
R1
R2
car sinon le support joystick seras chiant si on a pas access a toutes les touches clavier ^^ (un joy = 16 touches max)
ensuite tu peux faires des combinaisons de touches la ca se complique pour le clavier :
Haut + Droite
etc..
dans le code ca donne :
if GetAsyncKeyState(vbKeyup) and GetAsyncKeyState(VbkeyRight) then
la pas de pb
mais imagine que tu ais 17 touches clavier
il te faux alors gerer des trucs du genre :
if joy(BoutonA) And joy(BoutonB) Then Pause = Not Pause 'Tabtouche(17)
la ca ce compilque un peu au niveau de la sauvegarde des parametrres user pour le joypad ou niveau du code ...
enfin si ca t'interesse ...
30 janv. 2004 à 19:32
DE la même Facon, si tu fait ALt Ctl Supp tu verras que ton prog Bouffe 100% des ressources Processeur, ce qui est indigne de Toi !!!
Si tu mets l'incrementation des Ticks dans un Timer (un waitable Timer par exe http://www.vbfrance.com/code.aspx?ID=17608)
Tu passes à 10% des ressources ???? ce qui est plus top non !!!
A+
Afyn
30 janv. 2004 à 18:43
dans modmain.bas , dans la sub Main()
remplace :
nTick = GetTickCount + 2
par :
nTick = GetTickCount + 30
tu gagneras environs :
'30 millisecondes => 1000/30 =~ 333 fois par secondes
au lieu de 1000/2 = 500 fois par secondes soit
un Gain de 177 cycles par secondes, ca decharge le processeur sans ralentir le prog en gros 30 images par secondes sans effet de sacade... (ca peut aider pour faire tourner sur une plus petite config non ?
30 janv. 2004 à 18:17
pour la limitation de couleurs il te suffit de separer les tiles des sprites comme dans mon projet de moteur 3D hybrid ce qui te permettras d'utiliser une palette differente pour chaque sprite comme dans rpgmaker
ensuite au lieu de Gettickcount utilse plutot l'api QueryPerformanceCounter (cf ma source moteur Hybrid) c'est plus rapide et ca permet de "skipper" des frames si le pc est pas assez puissant tout en gardant une vitesse d'animation qui parait constante
en gros si le pc est pas assez rapide tu ne recalcule pas l'image et tu l'affiche pas, ainsi la vitesse de ton moteur est independante de la vitesse du processeur c'est l'ideal pour les jeux :)
- heu tu pourrait fournir la source de l'editeur avec ? ca m'interesse beaucoup ^^
- l'api stretchdibbits ne doit pas fonctionner si le bureau est en 256 couleurs (mais j'en suis pas sur) dans ce cas precis une palette globale est alors necessaire pour l'ensemble des tiles et sprites mais c'est moins interessant et moins beau :/
voila pour mes remarques sinon niveau optimisation on pourrait detacher le moteur d'affichage du 'core' afin de par exemple permettre un affichage software ou hardware (via directx par exemple)
ca permettrai aussi de pouvoir patcher le core sans modifier la partie affichage et inversement ainsi que d'ajouter des 'plugins' de gestion de l'affichage (comme dans certains jeux)
- si tu regarde mon moteur Hybrid 2d/3d tu remarqueras que je joue avec les palettes des sprites en gros j'indexe des palettes puis je blit les données bitmaps avec la nouvelle palette je pense que c'est facilement adaptable.
- on pourer aussi exposer des classes d'objet a vbscript et donc rendre le moteur scriptable ce qui serait fort interessant aussi
en gros je suis partant pour t'aider dans ses taches si tu en as le courage :)
sur ce 10/10 pour cette mini demo qui peut etre deviendras grande ? :op
30 janv. 2004 à 11:44
Sinon, chapeau bas...
30 janv. 2004 à 11:03
(Dsl je taff deja sur un projet perso (DX9, 3D et tt et tt...) dc je l'utiliserai pas pr prog, mais ca peut etre sympa , nostalgie des RPG....) :)
En tt k le rendu est plutot joli pr qq chose similaire a du qbasic (j'ai aussi commencé dessus)
30 janv. 2004 à 10:32
(même s'il faut ajouter qlq API...)
;-)