[Logiciel] µDev++ - Version 1.3 disponible

Ben y a room_speed , j'ai juste oublié de faire en sorte qu'elle se colore :p

Genre tu met room_speed = 10; et paf le fps chute a 10

j'ai trouvé un bug bizarre ; quand on séléctionne un texte tabulé sans la tabulation et qu'on l'efface il enlève la tabulation mais pas la sélection. Sinon je suis impressionné par les performances du raytracer (par contre le mot clé register change rien aux perfs, enfin sans c'est pareil quoi)

Lol marrant le bug mais c'est vrai qu'en programmant les tabulations j'y avais pas pensé.
Merci de l'avoir trouvé je vais régler ça pour la suite

C'est vrai que register a pas l'air de faire grand chose, mais bon j'aurais essayé de gratter un peu lol.



Sinon j'ai fait un système de sprite sheet (feuilles de sprites) , on pourras donc charger et afficher des images .bmp dans les prochaines version.

Par contre j'aurais aimé charger du .png aussi, mais pas moyen de trouver un truc leger a compiler en static pour.
Après y a moyen de récupérer le morceau de SDL_Image qu'il faut, mais il resteras quand même la libpng.dll qui dépend de zlib.dll.
Bref ça m'énerve de devoir utiliser autant de dlls...


Après vivicool je me demandais comment tu gére la depth dans ogc, tu utilise le zbuffer d'opengl ?
Parce que j'avais essayé mais si on fait glEnable(GL_DEPTH_TEST) après tout les draw 2d sont perturbés et s'affichent dans l'ordre inverse de la normale.
J'ai bien essayé de mettre glDepthFunc(GL_LEQUAL) pour régler le problème mais avec ça la plupart des autres pc ont un blackscreen (alors que ça marche sur le mien ._.)
Si t'avais une solution ça m'aiderais bien

ah ah bin non j'utilise pas le depth test je fait un tri statique par type d'objet.
Perso j'aurais mis GL_LEQUAL et puis glTranslate(0,0,depth).
Sinon pour le png j'ai ce que tu cherche : http://members.gamedev.net/lode/projects/LodePNG/
Et si tu veux du jpeg http://www.saillard.org/programs_and_patches/tinyjpegdecoder/

Wow mais ils sont vraiment super tes liens, merci beaucoup !

Pour le glTranslate(0,0,depth) je testerais demain sur le pc de ma soeur et je te tient au courant

En tout cas encore merci, ça va vraiment me faire gagner un temps fou !

De rien pour les lien et puis pour opengl j'avais mal lu ce que t'avais mis (GL_LEQUAL), bizarre que ça marche mal et ça me semblerais encore plus bizarre que ça marche mieux avec le translate. Je vais voir si il y a pas mieux.

Juste une question bête :
Comment fais-tu pour colorer du texte à l'intérieur d'un QTextEdit ?
(Bien sûr à condition que ça soit un QTextEdit ^^)

Car moi même je travaille sur un projet Qt qui est TI Game Maker (éditeur de jeux sur calculatrice), et j'avoue que ça serait vachement plus puissant niveau présentation avec des couleurs !

Ah colorer un QTextEdit c'est tout un art :p
Encore heureux qu'il y a un exemple fournis avec Qt ici : C:\Qt\2010.01\qt\examples\richtext\syntaxhighlighter
Tu peut aussi le trouver sur le net si tu l'a pas.

Ah, en effet

Bon, on va dire que le noir et blanc c'est très bien pour l'instant ^^
Enfin, j'ai encore bien des choses à apprendre, la coloration c'est pas une priorité pour l'instant...

Ah ben Qt c'est du lourd, du très lourd même. Faut pas trop en vouloir d'un coup

Sinon devrais y avoir une nouvelle version dans la journée, avec la gestion des sprite_sheet et du blend_mode (au moins).

j`ai très envi de teste a mon retour en france

Cool, avec de la chance j'aurais posté la version ou on peut utiliser des sprites :p

onilink_ a écrit:

Cool, avec de la chance j'aurais posté la version ou on peut utiliser des sprites :p

"bave"

Si la gestion des sprites est bonne j'essayerais de porter le développement mon jeu.

Ouai enfin non attend un peu alors.

Je vais mettre les choses au clair.
Ce logiciel, uDev++ ne sert qu'a faire de petites applications graphiques vite fait et aussi pour ce familiariser avec le C++.

Après ce qu'il faut que vous sachiez c'est que je sortirais une version spéciale : uDev GameMaker (ou un autre nom m'en fou, si vous avez des suggestions d'ailleurs...) , qui elle seras axée sur les jeux vidéos et comprendras toutes les fonctions de uDev++, mais avec une gestion complète des instances, cartes, et tout ce dont on a besoin pour développer rapidement un jeu.

Si j'ai encore rien sorti c'est que j'arrive pas vraiment a créer l'interface en fait...
Je voudrais en faire une qui ressemble vite fait a GM, avec un gestionnaire de dossiers sur la gauche mais ça je galère a la faire
(les exemples de QTreeView sont dur a trouver , et la plupart trop exagéré pour ce que je veux faire : un truc simple mais efficace.)

Bref soyez patients :/

Il est trop fort tonton Oni !

Très pratique, un programme léger et simple pour tester rapidement ses scripts, ça évite de nous créer des projets de tests et de tout copier/coller de l'inclusion des librairies "principales" jusqu'à la boucle d'évènement dans le main...

Je vais beaucoup l'utiliser.

Tu devrais plus accentuer ces arguments dans la présentation de uDev++.

haha merci lolman content que tu aime bien :p

l0lmanPH a écrit:

Tu devrais plus accentuer ces arguments dans la présentation de uDev++.

lol j'ai jamais été bon pour la parlote moi, mais je vais essayer

Ouais mais le marketing c'est important quand-même.

P.S : Je t'ai envoyé via MSN (plus rapide) des bugs remarqués, questions, autres idées, et j'ai aussi proposé un nouveau nom pour ton log (à développer).

Ah ben thx, vais voir ça de suite :p

edit : j'ai rien reçu ...


Bon pour les nouvelles je suis en train d'intégrer pas mal de fonctions, de faire des tuto sur les containers de la stl, ajouter des outils et corriger des bugs.
En gros la prochaine version mettra pas mal de temps a venir, mais elle devrait être pas mal complète.

En tout cas si vous avez des suggestions n'hésitez pas.

J't'ai envoyé à ton adresse oni_ !
Ce serait bête que tu puisses pas lire j't'ai spammé à mort (voir attaque DDOS).

Ah un tuto sur la STL ça peut être intéressant en effet, même si c'est un peu en extra. ^^

Ton logiciel uDev m'a fait penser à quelque chose de très intéressant :
étant donné que l'un des avantages de Gm est d'avoir des fonctions pré-établie qui sont utiles, facile à utiliser et fonctionnelles, je me disais qu'il serait très intéressant de voir comment réaliser ces fonctions, dans d'autres langages).

Bien évidemment, on pense au c/c++, mais je pensais aussi à leur adaptation en purebasic, Python, etc.. Pour ceux intéressés.

On pourrait voir cela comme des sortes de "lib" GMconvertTo, dont le but serait de pouvoir utiliser ces fonctions dans un autre langage.

J'ai regardé notamment ton fichier fonctions.h, mais je n'ai pas trouvé la fonctions en elle. Par exemple :

Code:

double point_distance(double x1, double y1, double x2, double y2);
double point_direction(double x1, double y1, double x2, double y2);
double lengthdir_x(double len, double dir);
double lengthdir_y(double len, double dir);

Où se trouve la fonction complète, pour pouvoir l'adapter ?

Par exemple, celle-ci est complète :

Code:

inline double max(double x, double y, double z)
{
    if(x>y) { if(x>z) return x; else return z; } if(y>z) return y; return z;
}

Et donc, on peut l'adapter pour d'autres langages .
Si on a accès aux fonctions complètes, j'essaerai de faire une lib pour purebasic qui pourrais s'appeler the GameMakerLibForPureBasic

Certaines fonctions qui m'intéresseraient (avec la fonction complète ) :
- move_towards_point()
- mp_potential_step_object et toutes les tonctions mp d'ailleurs
- les fonctions liées aux collisions : collision_circle, collision-rectangle (facile, celle-ci) et collision-ellipse


voiloutch, bonne continuation

distance entre deux points :
d=sqrt[ (x1-x2)² + (y1-y2)² ]

direction entre deux points :
angle=arctan2(y1-y2,x2-x1) //bon ça c'est la formule sous GM mais l'ordre des arguments peut changer, entk le plus simple est d'utiliser l'arctan2
et l'angle est en radians donc pour mettre en degré, rajouter /pi*180

si tu veux comprendre comment marche le mp_potential_step, cherche des informations sur l'algorithme A* (A star) et le move_toward_point est juste un déplacement de coordonnées tout simple il me semble, en fonction de la direction.

lengthdir_x(len,dir) correspond à cos(dir)*len et lengthdir_y(len,dir) c'est sin(dir)*len avec encore une conversion radian vers degré.
pour les collisions ça se trouve sur internet, c'est essentiellement des maths, la traduction n'est généralement pas trop compliquée.

>blendman

Si on vois la source de max avec 3 argument c'est parce qu'elle est inliné (pour le moment).
Les autres fonctions on été compilées dans un fichier objet.
Pour la source je la publierais certainement, mais pas avant d'avoir tout codé. (Dans un petit moment quoi :p)


Sinon pour qq fonctions qui t'intéressent :

Collision circle : tu regarde juste si la distance entre l'objet et le centre du cercle est inférieur ou égale au rayon (tout con)
Pour l'ellipse : Tu récupère le rayon en fonction de l'angle entre l'ellipse et l'objet (trigo), et tu fait un test de distances.

Si t'est mauvais en trigo je te conseille de t'y mettre, c'est vraiment le truc a connaitre quand on fait des jeux

Trigo + vecteurs = rulz :p

onilink_ a écrit:

Si t'est mauvais en trigo je te conseille de t'y mettre, c'est vraiment le truc a connaitre quand on fait des jeux

hophophop, je ne suis pas mauvais du tout en trigo, je suis juste une énorme quiche

Sinon, merci pour les informations, je vais essayer de regarder tout ça

Pour ce qui est de la trigo c'est très simple.

L'intérêt principal est de pouvoir représenter des coordonnées en fonctions d'un angle, et d'une distance.

En gros si tu veux obtenir les coordonnées d'un point sur un cercle, il te suffit de connaitre l'angle entre le point et l'axe x, et le rayon du cercle.
Xpt = cos( angle en radians ) * rayon
Ypt = sin( angle en radians ) * rayon

en GM :
Xpt = lengthdir_x(rayon, angle)
[...]

Rien qu'avec ça on peut faire plein de trucs, entre autre tracer des cercles, déplacer des objets en fonction d'un vecteur directionnel, dessiner des spirales, etc etc x)

c'est bon, j'ai testé... pas mal du tout!

alors : est-ce que keyboard_check marche? ou plutôt vk_quelquechose marche?

Pour l'instant y a que keyboard_check , et les seules constantes prédéfinies sont vk_right, up, etc

Par contre tu peut provisoirement utiliser celles de la SDL : http://sdl.beuc.net/sdl.wiki/SDLKey

Edit : des questions de lolman auxquelles je répond pour tout le monde.

Lolman a écrit:

Pourquoi utilises-tu la SDL alors que tu connais maintenant la SFML

Car je ne l'utilise pas pour l'affichage, juste pour les events et le fenêtrage.
La sdl est beaucoup plus légère que SFML, c'est donc un bon compromis.
De plus je compte plus tard coder moi même mon système de fenêtres etc, afin de ne mettre
que ce dont j'ai besoin.

Lolman a écrit:

j'ai juste essayé ça dans le create
for(int i = 100; i < 200; i++)
for(int j = 100; j < 200; j++)
draw_point(i, j);
et ça loade anormalement lentement

Tout simplement parce que la fonction draw point est inadaptée a la création d'un plasma.
Pour cela il faut utiliser un primitive :
draw_primitive_begin(pr_pointlist);
draw_vertex(x, y); [...]
draw_primitive_end();

De cette manière ton plasma seras affiché très rapidement.
(chez moi j'arrive tranquillement a 50 fps pour du 640*480)

Après même avec draw point ça devrais être beaucoup plus rapide, tu doit avoir mal configuré ta carte graphique.
J'ai eu le même soucis avec ma nvidia geforce 8400 gs , et la résolution du problème est
dans le panneau de configuration de nvidia, faut mettre les perfs au max, quitte a diminuer l'aa.

Lolman a écrit:

chez moi la doc marche pas

Si y a un bug tu peut toujours l'ouvrir depuis le dossier.
Je mettrais une version html normale aussi, pour ceux qui ont des problèmes avec les chm.

Lolman a écrit:

à quoi sert l'évènement "End" ?

C'est un event qui va s'effectuer juste avant que le main ne ce termine.
Pratique pour libérer la mémoire, etc.

Lolman a écrit:

le nom de ton programme est trop bateau et n'est pas assez explicite
je penserais plutôt à FastCoding ou FastDev

moi j'aime bien, mais si les utilisateurs préfèrent un autre nom, alors y auras qu'a faire un
système de vote.

Lolman a écrit:

et ce serait bien que ta coloration syntaxique détecte les commentaires sur plusieurs lignes
...et que tes fichiers .udv s'ouvrent par défaut avec ton logiciel...et que par défaut,

l'explorateur de fichiers (quand on fait CTRL + O) soit dans le dossier du programme

C'est prévu pour les prochaines versions.

un "bug" : les commentaires /* ... */ ne se colorises pas...

sinon, j'arrive pas a lancé mon truc mais sinon rien de grave...

robotic76 a écrit:

distance entre deux points :
d=sqrt[ (x1-x2)² + (y1-y2)² ]

ok, je m'en servirai car c'est pareil en purebasic

Citation :

direction entre deux points :
angle=arctan2(y1-y2,x2-x1)

cool, je viens de trouver l'équivalent pour purebasic c'est Atan2(x,y), la classe.

Citation :

si tu veux comprendre comment marche le mp_potential_step, cherche des informations sur l'algorithme A* (A star)

yep, j'ai commencé à regarder ça.

Citation :

le move_toward_point est juste un déplacement de coordonnées tout simple il me semble, en fonction de la direction.
lengthdir_x(len,dir) correspond à cos(dir)*len et lengthdir_y(len,dir) c'est sin(dir)*len avec encore une conversion radian vers degré.

oui, tu en as parlé tout à l'heure sur un autre sujet.
Tu as même donné l'équivalent en code (qui marche pour la plupart des langages :

Code:

dir=arctan2((cible_y-y),(cible_x-x))
x+= cos(dir)*vit
y+= sin(dir)*vit

J'ai testé avec purebasic et ça fonctionne aussi, c'est classe . Bon, ça ne réagit pas tout à fait de la même manière, mais c'est à peu près fonctionnel.

Citation :

pour les collisions ça se trouve sur internet, c'est essentiellement des maths, la traduction n'est généralement pas trop compliquée.

ok, je regarderai à l'occasion.

onilink_ a écrit:

Collision circle : tu regarde juste si la distance entre l'objet et le centre du cercle est inférieur ou égale au rayon (tout con)

ah oui, ok, je crois que je vois .

Citation :

Pour l'ellipse : Tu récupère le rayon en fonction de l'angle entre l'ellipse et l'objet (trigo), et tu fait un test de distances.

je vois aussi vaguement le truc, faudrait que j'essaie.

Citation :

Si t'est mauvais en trigo je te conseille de t'y mettre, c'est vraiment le truc a connaitre quand on fait des jeux

et ben, ça revient petit à petit en fait .

onilink_ a écrit:

En gros si tu veux obtenir les coordonnées d'un point sur un cercle, il te suffit de connaitre l'angle entre le point et l'axe x, et le rayon du cercle.
Xpt = cos( angle en radians ) * rayon
Ypt = sin( angle en radians ) * rayon

Rien qu'avec ça on peut faire plein de trucs, entre autre tracer des cercles, déplacer des objets en fonction d'un vecteur directionnel, dessiner des spirales, etc etc x)

oui, j'ai remarqué que rien qu'avec le calcul de l'angle et de la distance entre 2 points, ça ouvrait plein de portes , qui étaient pas vraiment fermées en plus .

Merci pour votre en tout cas, les amis .