Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » Forum Ti68K » Projets » Alerte Rouge (57 réponse(s))
./REPRISE DU POST PRECEDENT (post n°38)   Marquer comme non lu.
Onur Ecrit le: Mercredi 30 août 2006 à 19:01 Déconnecté(e)    Voir le profil de Onur Envoyer un email à Onur Visiter le site WEB de Onur Envoyer un message privé à Onur  


Bon tu me demandais en quoi on voyait que t'étais un noob...

Un sprite en noir et blanc, on est bien d'accord, mais si on veut faire des niveaux de gris, il faut obligatoirement plus de mémoire, non ?

Il faut le double exactement. Voila le genre de choses qui montre que tu es loin d'avoir les capacités de faire le moindre jeu pour l'instant et tu viens créer un topic pour parler de faire un pur jeu... Mais bordel! "Tais toi et code!" ©kk.

Pour la partie gestion du jeu si, même si c'est pas énorme bien sûr. Un "xor al,al" prend moins de place que de mettre une variable à 0 en C (bon OK ça dépend des cas mais de toute façon je maîtrise pas assez le C pour TI pour faire ça).

Tu nous apprends quelque chose là.

Qu'est-ce donc ?
Si tu sais pas à quoi correspond OO (= orienté objet) c'est pas la peine de venir parler de l'optimisation xor al,al. al n'existe pas en asm68k en 4 ans tu as pas du avoir le temps de bien voir ca... c'est d0 on va dire. Et même, je pense que tigcc le fait cette optimisation.

Sache aussi que jeu n'implique pas asm. Bien au contraire pour gérer le jeu il faut plutot du haut niveau et pour les calculs critiques (gestion de l'affichage, ou certains calculs) il faut du asm. Le fait que tu dises "je vais tout faire en asm pour mieux optimiser" montre que tu n'y connais rien. Ca m'étonnerait que toi tu optimises mieux que tigcc, parce que tu es un humain et pas des plus brillants.

Mais comment est-ce que tu peux le savoir ?

En te lisant tout simplement..

Apres tout ca tu oses dire:
Je n'en suis pas à mon premier programme, loin de là...

Pourquoi voulez-vous à tout prix me faire passer pour un débutant ??


Je commence à me demander si tu fais pas exprès.

Faire un TSR appelé au sein d'une interruption c'est déjà autre chose...

Y en a marre aussi de tes fins de posts qui sont censés faire croire que tu t'y connais alors que tu t'enfonces de plus en plus.

Des vaporman on en a par-dessus la tête. Alors arrete de glander sur le web et code quelque chose de montrable.
Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...


et autres projets à finir avant 2010
    
./Post n°39   Marquer comme non lu.
Jfg Ecrit le: Mercredi 30 août 2006 à 19:03 Déconnecté(e)    Voir le profil de Jfg Envoyer un email à Jfg Visiter le site WEB de Jfg Envoyer un message privé à Jfg  


TnT :
-un sprite de 8*8 (64 pixels) se code avec 8 octets (64 bits)

Un sprite en noir et blanc, on est bien d'accord, mais si on veut faire des niveaux de gris, il faut obligatoirement plus de mémoire, non ?

oui, 2x plus


-c'est pas en utilisant de l'asm que tu va diminuer la conso de RAM.

Pour la partie gestion du jeu si, même si c'est pas énorme bien sûr. Un "xor al,al" prend moins de place que de mettre une variable à 0 en C (bon OK ça dépend des cas mais de toute façon je maîtrise pas assez le C pour TI pour faire ça).

arf, tu parlais de la taille du programme :D Dans ce cas, tu as raison.


-une approche OO est indispensable.

Qu'est-ce donc ?

Programmation orientée objet; c'est possible de faire sans, mais c'est beaucoup plus dur.



-On a tous été débutant un jour, mais on a pas commencé en créant des topics sur des jeux.

Pourquoi voulez-vous à tout prix me faire passer pour un débutant ??

parceque tu parles de faire un jeu compliqué, tout en ayant a priori rien programmé. Maintenant, on attend juste que tu nous prouves faux!
Kill Mario
    
./Post n°40   Marquer comme non lu.
Pollux Ecrit le: Mercredi 30 août 2006 à 21:09 Déconnecté(e)    Voir le profil de Pollux Envoyer un email à Pollux Envoyer un message privé à Pollux  

Je vous trouve tous très durs avec lui, alors qu'il n'a honnêtement rien dit qui puisse mériter ça #confus#
Je ne vois pas en quoi une approche OO est indispensable, ou bien en quoi le fait de ne pas connaître le jargon l'empêcherait de bien concevoir son programme...


TnT> c'est pas parce qu'il y a ctc2 que ça doit t'empêcher de réaliser un alerte rouge... surtout que je pense que le projet est abandonné alors qu'il est loin d'être fini (comme bcp de projets sur TI), donc ça peut valoir le coup d'en faire un qui soit plus utilisable ^^
Par contre j'ai l'impression que tu te focalises un peu trop sur les graphismes : rassure-toi, c'est pas ça qui va poser problème, ni au niveau RAM ni au niveau CPU si le reste est assez rapide... (alors qu'inversement, je pense que tu sous-estimes le reste : pour faire un pathfinding efficace sur des grandes maps, tu seras peut-être obligé d'y consacrer pas mal de RAM)

Essaye de réfléchir au pathfinding, aux structures de données, à l'interface, au mode link et à l'IA avec des graphismes hyper-primitifs (genre juste une lettre pour représenter une unité ou un bâtiment), ça te permettra de voir si ton projet tient le coup, plutôt que de passer du temps sur les graphismes pour finalement te rendre compte que le pathfinding est plus difficile que tu ne le crois, ou que c'est injouable sans souris, et abandonner le projet... Accessoirement, si tu as un truc fonctionnel mais sans graphismes tu trouveras probablement du monde pour t'aider à les faire, alors que *personne* ne te fera ton IA ou ton pathfinding même si tu as déjà tous les graphismes :)
    
./Post n°41   Marquer comme non lu.
Onur Ecrit le: Mercredi 30 août 2006 à 21:27 Déconnecté(e)    Voir le profil de Onur Envoyer un email à Onur Visiter le site WEB de Onur Envoyer un message privé à Onur  


#crayon#

dsl si j'ai été un peu irrité. Tu es peut etre un futur expert sur TI. Mais tu comprends, on s'est payé des jeffix, ou bien des mecs qui nous disaient "je fais un compilo C vite fait dans une semaine" alors bon.
Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...


et autres projets à finir avant 2010
    
./Post n°42   Marquer comme non lu.
Kevin Kofler Ecrit le: Vendredi 1er septembre 2006 à 16:06 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


TnT :
Quand je veux le lancer, il me met "Déplacement de données invalides dans le programme ASM".
Any idea ?

Vieux lanceur... Essaie de lancer le PPG avec ttstart 2.00. Si tu as une V200, essaie le V200 Executables Patcher, si tu as une Titanium, essaie GhostBuster. Les deux sont à utiliser sur le PPG et te donnent un exécutable décompressé (vu qu'on ne peut pas recompresser ttpack on-calc).

Sinon: Non, une approche OO n'est pas indispensable, à mon avis un bon programmeur procédural peut faire ça en entièrement procédural. XOR (ou plutôt eor sur 68k!) n'est pas la manière la plus rapide d'effacer un registre sur 68k (c'est moveq.l #0,%d0). Et Onur n'est pas la bonne personne pour se plaindre de vaporware (même si effectivement le coup du compilateur C en une semaine est totalement risible, je suis bien d'accord sur ce point-là).
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°43   Marquer comme non lu.
Vic Ecrit le: Samedi 2 septembre 2006 à 20:57 Déconnecté(e)    Voir le profil de Vic Envoyer un email à Vic Envoyer un message privé à Vic  

Ce projet n’est peut être pas impossible a faire.

Tu te focalises trop sur les sprites et sur ta présentation graphique.

Premièrement, tes sprites tu les laissent dans ta Flash et pour en utiliser un tu l’affiche avec tes fonction d’affichage de sprites en utilisant un pointeur far comme ça ta RAM n’est pas submergé de sprites.

Deuxièmement, enlèves toi de la tête que tu vas tout faire en ASM ça sera déjà bien assez difficile comme ça en C (personnellement le C++ sur des systèmes embarqué j’accroche pas)
L’ASM doit étre utilisé seulement pour les fonctions d’affichage de sprites ou d’autres trucs du genre qui ne doivent pas prendre du temps.

Troisièmement, l’aspect graphique dans le développement d’un logiciel ou un jeux ou quoi que çe soit d’autre n’est pas prioritaire.
Il faut d’abord te faire un « plan » de ton moteur et t’y tenir

J’ai un peu réfléchi comment j’aurais fait ce plan, je vais essayé de l’exposé (bien sur d’autres solutions peuvent être plus pertinente) :

Il faut que chaque unité soit représentée par une structure afin de créer une liste chaînée que tu déclareras et supprimera avec des allocations dynamiques.
Ainsi, lorsque une unité est morte il suffit de faire un free () sur la structure de cette unité et de d’initialiser les pointeurs des structure « d’avant » et « d’après »





DECLARATION DE STRUCTURES GLOBALE

Struct unité
{char equipe ;
char type ;
char domage ;
long aller_a_x ;
long aller_a_y ;
long position_actuel_x ;
long position_actuel_y ;
struct unitée *p_precedent ; //peut-être inutile
struct unitée *p_suivant ;
}

FONCTIONS


Void tirer_sur énemis (struct unité *premiere_de_file ,long position_x_énemis, long position_y_énemis)
{
En déroulant la liste chaîné jusque a la fin :
-rechercher l’unité ennemis présente à cette position (unité concernée)
-décrémenter le champ « domage » de la structure relative a l’unité concernée

SI domage == 0
ALORS supprimer la structure de cette unité
}






Void action (struct unité *unité_courante)
{
SI unité courante pas arrivée a destination
ALORS générer un déplacement élémentaire (dx, dy) de unité courante en tenant compte
des obstacles et du relief
SI énemis détecté à portée de tir
ALORS tirer_sur énemis (struct*p_enemis, position_x_énemis, position_y_énemis)
}



Je vais m’arrêter là pour ce qui est des fonctions ç’est a toi de trouver celles qu’il te faut (fonction qui permet de donner les ordres, affichage d’une zone du champ de bataille, gestion des batiments…).
Maintenant je vais expliquer comment j’aurai utilisé fonctions dans le main() :

MAIN

Il faut les que les 2 équipe aient une liste chaînée de « struct unité ».
Ainsi, dans chaque cycle du programme tu pourras utiliser les commandes suivante


SI joueur donne ordre ALORS Ordre_amis ( ????????) //init position_actuel_x (y)
Ordre_énemis ( ???????) //IA
action (struct unité *unité_courante_amis) ;
action (struct unité * unité_courante _énemis) ;
unité_courante_amis = unité suivante amis
unité_courante_énemis = unité suivante enemis
affichage_zone (x, y)


Le plus gros problème de cette méthode ç’est que plus il y aura d’unités, plus un cycle de programme vas prendre du temps donc il faudra limité le nombre d’unité de chaque équipe.
Bien sur il y a d’autres solutions, hein…

(Désolé si je dis pas juste sur certain détails mais je programme pas sur Ti)

    
./Post n°44   Marquer comme non lu.
Jfg Ecrit le: Samedi 2 septembre 2006 à 22:02 Déconnecté(e)    Voir le profil de Jfg Envoyer un email à Jfg Visiter le site WEB de Jfg Envoyer un message privé à Jfg  


"SI unité courante pas arrivée a destination
ALORS générer un déplacement élémentaire (dx, dy) de unité courante en tenant compte
des obstacles et du relief"

les unités ne se déplacent pas pareil, par exemple les soldats se déplacent moins vite que les tanks, et les unités aeriennes se moquent carrement des obstacles.

Ce que je ferais moi, c'est de mettre un pointeur de fonction "action" dans la structure "unité" qui pointerait vers la méthode fonction adéquate. En plus, toutes les unités ne peuvent pas forcement attaquer. Et certaines peuvent attaquer de plusieurs manière différente. Donc on pourrait même faire une classe structure "unité_qui_attaque" qui hériterait contienderait la structure unité.
Kill Mario
    
./Post n°45   Marquer comme non lu.
Onur Ecrit le: Samedi 2 septembre 2006 à 22:15 Déconnecté(e)    Voir le profil de Onur Envoyer un email à Onur Visiter le site WEB de Onur Envoyer un message privé à Onur  


Ecoute Jf, on a été plusieurs à dire que OO n'était pas nécessaire et tu tentes malgré tout d'imposer ton idéologie de codage... L'ironie qui consiste à barrer les mots de OO pour faire le mec oprimé dont on refuse les idées ne passe pas avec nous.
Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...


et autres projets à finir avant 2010
    
./Post n°46   Marquer comme non lu.
Jfg Ecrit le: Samedi 2 septembre 2006 à 22:24 Déconnecté(e)    Voir le profil de Jfg Envoyer un email à Jfg Visiter le site WEB de Jfg Envoyer un message privé à Jfg  


je ne faisais que suggérer une autre méthode... maintenant, si t'est parano et que tu vois de l'OO partout je m'en bas les oo.

En tout cas, ça serait interessant de parler du pathfinding, parceque ça m'ettonerait qu'on puisse utiliser des algo bourrins.
Kill Mario
    
./Post n°47   Marquer comme non lu.
geogeo Ecrit le: Dimanche 3 septembre 2006 à 14:09 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


En effet l'approche objet n'est pas forcément necessaire mais bon on constate rapidement que sur de gros projets comme celui là ça devient vite utile.
Pour le jeu je verrais une approche style script où chaque paramètre d'une unité est listé c'est à dire:
- Sprite
- Damage
- Velocité
- Zone de visibilité (permet de visité une plus grand zone et d'enlever son brouillard)
- Armes (primaire et secondaire). Sont telles capable de détruire un batiment, un avion...?
- Armure
- Coût de construction
- Niveau de disponibilité (c'est-à-dire que l'arme est disponible après avoir construit un certain nombre de batiments...)
- Unité réparable ?
...

Ce listage peut être directement codé ou tout simplement lu à partir d'un fichier de configuration puis codé.
Et en effet le plus important à mes yeux dans ce style de jeu est de géré l'IA, le Pathfinding et les combinaisons de possibilités assez simplement.
Et comme d'hab dans les jeux je pense que A* comme Pathfinding est un rès bon choix d'algo.
-Edité le Dimanche 3 septembre 2006 à 14:12 par geogeo-
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°48   Marquer comme non lu.
Link Ecrit le: Dimanche 3 septembre 2006 à 15:16 Déconnecté(e)    Voir le profil de Link Envoyer un email à Link Visiter le site WEB de Link Envoyer un message privé à Link  

Geogeo: Là, tu donnes des paramètres par TYPE d'unité, n'est-ce pas?
Les paramètres par unité seront différents... (Position, HP, cible/destination...)
    
./Post n°49   Marquer comme non lu.
geogeo Ecrit le: Dimanche 3 septembre 2006 à 17:49 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Non paramètres pour chaque unité et non par type.
Mais là rien à voir avec la position, cible... se sont ici des paramètres générals genre à combien de pixels je me déplace à chaque frame, ou encore je suis disponible au niveau x de technologie et pourquoi je suis visible à x pixels de distance et donc je peux tirer jusqu'à cette fameuse distance.
Alerte Rouge a (à mon sens) le même type de fonctionnement qu'un RPG et donc chaque objet sur la carte (que ça soit un pont, arbre, tank, batiment) doit être géré par des messages.
-Edité le Dimanche 3 septembre 2006 à 17:50 par geogeo-
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°50   Marquer comme non lu.
Link Ecrit le: Dimanche 3 septembre 2006 à 21:22 Déconnecté(e)    Voir le profil de Link Envoyer un email à Link Visiter le site WEB de Link Envoyer un message privé à Link  

J'ai déjà regardé dans les fichiers d'Alerte Rouge, notamment le fameux rules.ini.
Toutes les unités d'un même type (tous les mitrailleurs, tous les grenadiers, tous les tanks mammouth) sur le terrain ont exactement les mêmes caractéristiques. Seul leur état (HP, etc.) change.

D'ailleurs, les armes elles-mêmes ont leurs stats également. C'est à la définition de la mitraillette qu'on trouve les dégats qu'elle inflige et le temps d'attente entre chaque tir.
-Edité le Dimanche 3 septembre 2006 à 21:23 par Link-
    
./Post n°51   Marquer comme non lu.
Kevin Kofler Ecrit le: Dimanche 3 septembre 2006 à 21:45 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Jfg, on voit de l'OO parce que ton truc est de l'OO. Les pointeurs de fonctions n'ont rien à faire dans des structures en un style purement procédural, ça existe en programmation OO (ce que le système que tu proposes est) et en programmation fonctionnelle (où la fonction est un objet comme un autre).
-Edité le Dimanche 3 septembre 2006 à 21:46 par Kevin Kofler-
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°52   Marquer comme non lu.
geogeo Ecrit le: Lundi 4 septembre 2006 à 12:08 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Link :
Toutes les unités d'un même type (tous les mitrailleurs, tous les grenadiers, tous les tanks mammouth) sur le terrain ont exactement les mêmes caractéristiques. Seul leur état (HP, etc.) change.


Oui en effet d'où mon idée d'avoir une organisation un peu près équivalente à Rules.ini.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°53   Marquer comme non lu.
Onur Ecrit le: Lundi 4 septembre 2006 à 17:29 Déconnecté(e)    Voir le profil de Onur Envoyer un email à Onur Visiter le site WEB de Onur Envoyer un message privé à Onur  


Je ne vois pas pourquoi on parle de HP alors qu'on est sur un forum pour TI :/
Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...


et autres projets à finir avant 2010
    
./Post n°54   Marquer comme non lu.
240-185 Ecrit le: Lundi 4 septembre 2006 à 18:30 Déconnecté(e)    Voir le profil de 240-185 Envoyer un email à 240-185 Envoyer un message privé à 240-185  

Hit Points #triso#
Tel un automate, le dinosaure noir s'avance vers le chef des Chomp et dit : "euh..."
    
./Post n°55   Marquer comme non lu.
Link Ecrit le: Lundi 4 septembre 2006 à 21:30 Déconnecté(e)    Voir le profil de Link Envoyer un email à Link Visiter le site WEB de Link Envoyer un message privé à Link  

Ah bon? Je croyais que ça voulait dire Harry Potter #spin#
    
./Post n°56   Marquer comme non lu.
240-185 Ecrit le: Lundi 4 septembre 2006 à 21:41 Déconnecté(e)    Voir le profil de 240-185 Envoyer un email à 240-185 Envoyer un message privé à 240-185  

Healing Potion :p
Tel un automate, le dinosaure noir s'avance vers le chef des Chomp et dit : "euh..."
    
./Post n°57   Marquer comme non lu.
Rafou Ecrit le: Dimanche 1er octobre 2006 à 10:49 Déconnecté(e)    Voir le profil de Rafou Envoyer un email à Rafou Envoyer un message privé à Rafou  

Il y a longtemps, j'avais essayé de développer Age Of Empires avec des amis. Au moins juste une démo, avec une carte et une civilisation, histoire de voir ce que ça pourraît donner.
Sauf que quand on a vu que notre petite démo ramait à mort et qu'elle prenaît 30ko pour une carte qui comprend 4 sprites et un menu de jeu, et qu'on auraît dû tout faire directement en ASM alors qu'on connaissaît que dalle à l'ASM, on a abandonné...
Et quand je vois le projet StarCraft (68k) qui est en développement depuis 2 ans (environ)... je crois qu'il faut vraiment être calé pour faire un rts comme Alerte Rouge.
    
  :: Index » Forum Ti68K » Projets » Alerte Rouge (57 réponse(s))
Pages : 3/3     « 1 2 [3] » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 65.25ms avec 18 requetes