je reprends donc:
c'est plus pour la partie physique des boules que j'aurais besoin d'aide....
car j'ai demandé à plusieurs profs de physiques qui n'ont pas su me réponde...
un petit dernier problème:
la pratique montre que si l'on ne donne pas d'effet à une boule, et que on lui fait faire 5-6 bandes (rebondir contre les bords de la table, contre les bandes...), parfois, dans certains cas, on remarque qu'aprés 2 ou 3 bandes la boule a de l'effet!!!
pourquoi ? comment ? quand ?
Je dirais que lorsque tu fais des bandes, ta boule frotte sur la bande et prend un effet vertical, mais comme la boule rencontre de suite après une autre bande de l'autre côté, l'inertie s'annule. Cependant, après 3 ou 4 bandes, la boule va moins vite sur le tapis, ce qui fait que tu remarques l'effet vertical induit par le frottement de la dernière bande.
Tu ne nous renseigne toujours pas sur quel OS ni quel moteur 3D tu veux pour faire tourner ton jeu, ce qui est qu'en même très important. De plus, le C a de gros défauts, le premier étant qu'il n'est pas orienté objet ! Dur pour un jeu 3D de nos jours.
tu peux très bien faire du C orienté objet.
exemple :
typedef struct _sphere{
int rayon;
}sphere;
typedef struct _boule{
int rayon;
int numero;
}boule;
typedef struct _balle{
int rayon;
char couleur;
}balle;
Si je fais une fonction
void sphere_Specifier_Rayon( sphere *sp, int rayon){
sp->rayon = rayon;
}
alors cette fonction sera utilisable pour les trois types car ils ont un champ en commun et qui est ( très important) à la meme position.
balle ba;
sphere sp;
boule bo;
sphere_Specifier_Rayon( &sp, 10);
sphere_Specifier_Rayon( ( sphere *)&ba, 10);
sphere_Specifier_Rayon( ( sphere *)&bo, 10);
Donc c'est une sorte d'heritage. De meme on peut introduire des pointeurs de fonctions dans les structures pour faire comme une classe.
'fin tout ça pour dire que personnellement, le fait que le C ne soit pas orienté objet pur ne me semble pas être problèmatique.
class Sphere:
def __init__(self, ray):
rayon = ray
sp=Sphere(ray=10)
bo=SPhere(ray=20)
Ca j'appele ca de l'orienté objet, et j'ai pu eu besoin de 20 lignes pour l'écrire, d'où gain de temps, et de simplicité.
lol, t'as pas eu besoin de 20 lignes mais t'as pas definit les classes sphere, balle et boule ( on sait pas quels membres ils contiennent) donc c'est sur moi aussi je peux faire 3 lignes comme ça.
Je ne pense pas que ce soit un problème: Il est tout à fait possible de faire la même chose avec un language procédural et un language objet. La ou ce dernier y gagne, c'est qu'il est beaucoup plus facile de créer des gros projets (et encore: le noyau linux est en c), et ce jeu ne va pas en faire partie. Mais bon, c'est vrai que c++ est quand même plus agréable que le c, même pour des petits programmes.Envoyé par joshua_fr
Eric
class Sphere:
def __init__(self, ray):
self.rayon = ray
class Balle(SPhere):
def __init__(self, ray, coul):
Sphere.__init__(ray)
self.couleur = coul
class Boule(SPhere):
def __init__(self, ray, num):
Sphere.__init__(ray)
self.numero = num
sp = Sphere(10)
ba = Balle(10, bleue)
bo = Boule(10, 48E+5)
Héritage?
Je sais bien que le C est puissant et qu'il est encore largement utilisé (enfin, dans les attaques de bas niveau, c'est pourquoi Linux est en C), mais faudrait utiliser les outils de son temps pour faire des programmes. Sinon on n'a qu'à revenir sur de l'assembleur !
http://glenux2.free.fr/index.php?pid=PPH101
Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
Ce n'est peut-être pas très utile de répondre à une conversation qui s'est interrompue en mai ?
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Je suis bien d'accord mais cela m'a fait mal au coeur quand j'ai vu la façon dont la question a été traitée... acx01b demandait des contact pour faire un jeu de billard... sans prétention et une armée de boutonneux lui est tombé dessus en considérant je ne sais pas très bien pourquoi qu'il voulait réaliser le jeu du siècle qui allait rivaliser avec je ne sais quel jeu sur Xbox ou autre... Le tout c'est emballé sur des histoire de rendu 3D alors que la seule chose que souhaitait acx01b c'était de faire un jeu le message
m'a semblé particulièrement déplacé !!! Il n'y a rien dedans qui soit un reflet de la réalité...
Voila !!! c'était une réponse d'humeur... Je ne suis pas un habitué de ce forum-ci, je vais plutôt du côté de la physique mais ça ne m'incite pas trop à venir parler programmation en tout les cas...
Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
pourquoi pas, si tu penses pouvoir intervenir avec plus de pondération que ce que tu as déploré ?mais ça ne m'incite pas trop à venir parler programmation en tout les cas...
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Parcequ'il est fatiguant de discuter avec des gens qui n'écoutent pas ce que tu dis... c'est vrai dans la vraie vie mais aussi sur un forum.
Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
Dommage jai raté ce topic, j'aurrai pu répondre 2 3 trucs.
Disons que la partie compliquée c'est de bien modellisé les interactions physiques. Le reste : représentation 3D, détection des collisions, c'est annexe et c'est vraiement pas compliqué.
Une personne avec un peu d'experience peu developper un proto simple en une semaine.
Ceci dit la simulation physique en temps réels pose des problemes asses amusants qui promettent quelques prise de tête aux personnes qui n'y sont pas familier.
Notons quil existe des bon prog de simulation de billiard :
Virtual Pool (payant)
Foobillard (GPL)
Ceci dit c'est vrai que la question n'a pas été posée correctement. Avec un plan precis et un début d'ébauche ca aurrait mieux passé.
Lu,
J'ai relu tout le fil car c'est vrai que ca datait un peu... Je ne vois pas où mon message est déplacé (je n'étais pas agressif): la question de base est "je veux faire un jeu de billard EN 3D, qui veut m'aider?". Désolé, mais déja, un jeu en 3D nécessite forcément de parler de l'affichage, si on affiche rien, je vois pas trop l'interet... Ensuite vu les problèmes qu'il se pose (boules qui sautent et tout), il avait l'air de vouloir fair un jeu un minimum réaliste, c'est à dire un gros projet et pas un petit jeu sans prétentionsBon ensuite bah désolé, mais pour aider quelqu'un, il faut bien avoir des renseignements...
Bref, je ne vois mais vraiment pas pourquoi mon message était déplacé.
Voilà le message de départ du post...
La première fois que le mot 3D apparait c'est :
Bah ptet qu'il compte créer son propre moteur 3D
Je pense que pour pouvoir aidé quelqu'un il faut d'abord essayer de comprendre ce qu'il cherche. Et pour aider il est souvent meilleur de positiver.
Enfin, visiblement acx01b n'a pas été découragé et est toujours présent sur le forum... Tant mieux
Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
De plus, le fil sur la physique des boules de billard parlais de trois dimensions. Je n'ai rien à ajouter.bah justement, l'idée c'est de faire un prog super puissant pour les effets:
plusieurs types de cannes, plusieurs types de tapis, plusieurs types de boules,
plusieurs types de bandes,
et d'en faire un qui permette de faire sauter la blanche!!
et puis il y a un truc que les autres jeux de billard ne prennent pas en compte:
quand la blanche est collée à la bande, ça limite la direction où tu peux taper avec ta canne! car si tu tapes en direction de la bande, la boule revient directement sur la canne, et il y a faute....
enfin voila
heuuu: l'affichage en 3d ce n'est que une matrix de donnée (ensemble de polygones), puis un calcul de cos et de sin pour laffichage en 2d sur l'écran !!!
PS: oui, j'aurais pu éviter ma pointe d'ironie sur le moteur 3D, je m'en excuse papa.
Du rendu software ? c'était mal barré.
