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°19)   Marquer comme non lu.
240-185 Ecrit le: Mercredi 30 août 2006 à 10:55 Déconnecté(e)    Voir le profil de 240-185 Envoyer un email à 240-185 Envoyer un message privé à 240-185  

j'étale mes connaissances en démontrant par mes calculs (et par les faits...) que mon projet était réalisable.

Balance-nous tes calculs :]

Maintenant quelqu'un aurait-il des arguments pour me prouver que je suis un vrai noob ?

Dire que tout ça tient en RAM c'est bien joli, mais tu as pensé au pathfinding ? Il doit être suffisamment élaboré. Tu as pensé à l'algorithme du tour par tour ? Tu as pensé à comment organiser *toutes* les données pendant une partie ? Tu as pensé aux croissants ?

Tout ça pour te dire qu'un jeu se code d'abord sur du papier...
Tel un automate, le dinosaure noir s'avance vers le chef des Chomp et dit : "euh..."
    
./Post n°20   Marquer comme non lu.
Sasume Ecrit le: Mercredi 30 août 2006 à 10:58 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

TnT :
Maintenant quelqu'un aurait-il des arguments pour me prouver que je suis un vrai noob ?
Tu n'as toujours rien réalisé sur TI... (à part un ou deux hello world peut-être ?)
    
./Post n°21   Marquer comme non lu.
TnT Ecrit le: Mercredi 30 août 2006 à 11:03 Déconnecté(e)    Voir le profil de TnT Envoyer un email à TnT Envoyer un message privé à TnT  

Balance-nous tes calculs :]

Voici (déjà cité) :
En utilisant un système de compression, pourquoi pas ? Je pense qu'il y a moyen de tout mettre dans la RAM en se débrouillant bien. Voici comment je calcule.

Si on considère qu'un sprite de base fait 8x8 bits, on obtient 8 octets. Supposons maintenant (en comptant large) qu'un sprite atteigne 8 niveaux de gris, on obtient 8x8 octets soit 64 octets par sprite. Si la quantité de tous les sprites du jeu atteint les 1000, on obtient 64x1000 octets soit 64 000 octets. Or la RAM (vide, on est d'accord) avoisine les 200 000 octets. Il nous reste donc environ 130 000 octets pour gérer la carte et les entités.
En utilisant une carte de 256x100 cases avec des mots de 16 bits, on arrive à 25 600 x 2 = 51 200 octets pour la carte. Il nous reste donc environ 80 000 octets pour gérer le jeu.

Je pense que 80 000 octets permettent (surtout en ASM) de gérer correctement le reste du jeu ! Et on pourrait même prendre 2000 sprites différents au total, il nous resterait encore environ 10 000 octets pour la gestion du jeu, ce qui je pense reste encore faisable.

Et j'ai ici imaginé le pire des scénari concernant les graphismes...


Dire que tout ça tient en RAM c'est bien joli, mais tu as pensé au pathfinding ? Il doit être suffisamment élaboré. Tu as pensé à l'algorithme du tour par tour ? Tu as pensé à comment organiser *toutes* les données pendant une partie ? Tu as pensé aux croissants ?

Tout ça pour te dire qu'un jeu se code d'abord sur du papier...

Effectivement, il n'y a pas que les graphismes. J'ai pensé à ce qu'il pouvait y avoir par ailleurs, et j'ai estimé que 80 000 octets devraient être suffisant pour gérer tout le jeu (l'ASM permettant notament d'optimiser au maximum).
Je sais qu'il y a des contraintes et que ça n'est pas en disant "je vais faire un jeu" que ça se fait si facilement que ça, et c'est pour cette raison que j'ai posté dans la partie Projets, afin d'avoir vos avis et vos idées sur la question.

Et pas des insultes à la Onur... Ca n'est pas parce que je ne présente pas un projet complètement ficelé que je suis un noob..! On est ici pour en discuter non ?
    
./Post n°22   Marquer comme non lu.
Sasume Ecrit le: Mercredi 30 août 2006 à 11:04 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

napo> Euh je ne comprends pas trop ce que tu veux dire...
Un jeu au tour par tour te laisse la possibilité de réfléchir longtemps avant de déplacer tes unités, lesquelles disposent d'une quantité limité de mouvements par tour, et pendant ce temps tes adversaires sont gelés. L'unité de temps est le tour (tout se mesure par rapport à ça : les constructions, déplacements, évolutions, etc.).

Dans un jeu en temps réel, pendant que tu fais tes actions, les autres joueurs jouent aussi, sans aucune discontinuité.
    
./Post n°23   Marquer comme non lu.
TnT Ecrit le: Mercredi 30 août 2006 à 11:06 Déconnecté(e)    Voir le profil de TnT Envoyer un email à TnT Envoyer un message privé à TnT  

Tu n'as toujours rien réalisé sur TI... (à part un ou deux hello world peut-être ?)


Je n'ai rien releasé, ce qui est déjà différent. Et j'ai eu d'autres priorités que de finioler certains utilitaires. J'avais conçu un utilitaire qui permettait de demander un mot de passe à chaque allumage de la TI, tout ce qu'il me restait à faire était la partie graphismes. Le système en lui-même était au point (je pourrais le reprendre et le finir d'ailleurs, mais après 2 ans d'arrêt faut se replonger dans tout ça, ça revient pas d'un coup).
    
./Post n°24   Marquer comme non lu.
240-185 Ecrit le: Mercredi 30 août 2006 à 11:24 Déconnecté(e)    Voir le profil de 240-185 Envoyer un email à 240-185 Envoyer un message privé à 240-185  

Si on considère qu'un sprite de base fait 8x8 bits,

8*8 pixels, non ?

on obtient 8 octets.

Nan, au minimum 64.

Supposons maintenant (en comptant large) qu'un sprite atteigne 8 niveaux de gris, on obtient 8x8 octets soit 64 octets par sprite.

Quand on veut faire un jeu, on ne suppose pas. On a déjà défini à quoi ressembleraient les sprites.

Si la quantité de tous les sprites du jeu atteint les 1000, on obtient 64x1000 octets soit 64 000 octets. Or la RAM (vide, on est d'accord) avoisine les 200 000 octets.

Je ne pense pas que tous les sprites atteignent seulement 1 Ko, ou alors on rogne les animations, et on a un truc digne de South Park (en termes d'animation) #tritop#

Il nous reste donc environ 130 000 octets pour gérer la carte et les entités.
En utilisant une carte de 256x100 cases avec des mots de 16 bits, on arrive à 25 600 x 2 = 51 200 octets pour la carte. Il nous reste donc environ 80 000 octets pour gérer le jeu.

Hum, finalement ce jeu est *peut-être* faisable, juste qu'un char de 8 bits devrait suffire pour représenter *une* case de la carte. Mais pour faire une carte potable, je te laisse le choix de la taille (64*64 devrait être raisonnable)

Et j'ai ici imaginé le pire des scénari concernant les graphismes...

Bah apparemment c'est pas assez pire.

napo> Euh je ne comprends pas trop ce que tu veux dire...
Un jeu au tour par tour te laisse la possibilité de réfléchir longtemps avant de déplacer tes unités, lesquelles disposent d'une quantité limité de mouvements par tour, et pendant ce temps tes adversaires sont gelés. L'unité de temps est le tour (tout se mesure par rapport à ça : les constructions, déplacements, évolutions, etc.).

C'est le tour par tour à la Warcraft III dont je voulais parler. Gérer une entité pendant la micro-seconde que dure le tour, puis au tour suivant, gérer une autre entité, puis au tour suivant, gérer encore une autre ^^

[edit] c'est quoi ce parsing foireux du ^^ ?
-Edité le Mercredi 30 août 2006 à 11:26 par 240-185-
Tel un automate, le dinosaure noir s'avance vers le chef des Chomp et dit : "euh..."
    
./Post n°25   Marquer comme non lu.
TnT Ecrit le: Mercredi 30 août 2006 à 11:46 Déconnecté(e)    Voir le profil de TnT Envoyer un email à TnT Envoyer un message privé à TnT  

8*8 pixels, non ?

Oui, mais je parlais en bits pour qu'on comprenne bien comment je passe des bits aux octets.
Nan, au minimum 64.

C'est ce que j'ai dis. Un sprite de base fait 8 pixels * 8 pixels = 64 pixels, c'est-à-dire 64 bits d'un point de vue mémoire. Or 64 bits = 8 octets, on est d'accord ? Ensuite, si chaque pixel a 8 niveaux de gris (au mieux), on multiplie notre besoin en mémoire par 8 (logique), donc on passe à 8 octets * 8 niveaux de gris = 64 octets pour un sprite de 8 pixels * 8 pixels de 8 niveaux de gris différents.
Quand on veut faire un jeu, on ne suppose pas. On a déjà défini à quoi ressembleraient les sprites.

Le but n'était pas de savoir combien prendraient exactement les graphismes, mais juste de savoir si tout pouvait tenir dans la RAM, rien d'autre.
Je ne pense pas que tous les sprites atteignent seulement 1 Ko, ou alors on rogne les animations, et on a un truc digne de South Park (en termes d'animation)

Non, on a 1000 sprites de 64 octets chacun, ce qui nous prend presque 64 Ko. Quand je dis 1000 sprites, c'est 1000 dessins différents (par exemple un tank pourrait faire 4 sprites accolés, un bâtiments 3*3 sprites,...).
Hum, finalement ce jeu est *peut-être* faisable, juste qu'un char de 8 bits devrait suffire pour représenter *une* case de la carte. Mais pour faire une carte potable, je te laisse le choix de la taille (64*64 devrait être raisonnable)

Un char de 16 bits est nécessaire, car dans la carte, chaque case doit faire référence au sprite qu'elle contient. Or comme on a 1000 sprites, et qu'un mot de 8 bits ne peut pas aller au-delà de 256, on est obligé de passer à 16 bits.
Autrement le jeu est faisable puisqu'il existe... ;) (voir un de mes posts précédent, à la suite de celui de Kevin).
    
./Post n°26   Marquer comme non lu.
RHJPP Ecrit le: Mercredi 30 août 2006 à 12:40 Déconnecté(e)    Voir le profil de RHJPP Envoyer un email à RHJPP Envoyer un message privé à RHJPP  


240-185 :
Si on considère qu'un sprite de base fait 8x8 bits,

8*8 pixels, non ?

on obtient 8 octets.

Nan, au minimum 64.


64 octets le sprite ? #fou2# #delire#
Et toi, 240-185, tu as déjà programmé quelque chose pour dire de telles idioties ?
-Edité le Mercredi 30 août 2006 à 12:41 par Thepro-
    
./Post n°27   Marquer comme non lu.
geogeo Ecrit le: Mercredi 30 août 2006 à 12:41 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Sérieux ça sert à rien de vous bouffer la gueule. :(
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°28   Marquer comme non lu.
Onur Ecrit le: Mercredi 30 août 2006 à 12:56 Déconnecté(e)    Voir le profil de Onur Envoyer un email à Onur Visiter le site WEB de Onur Envoyer un message privé à Onur  


Ca sert à rien de créer des topics vapors aussi... #roll#

TnT > Moi ce qui m'enerve c'est pas le fait que tu sois noob, biensur j'ai été moi aussi noob comme nous tous. Je ne l'oublie pas merci du conseil #tritop# Mais des mecs qui nous font perdre du temps en ne posant que des questions du genre "est-ce que c'est possible? je pense que oui..." et puis deux mois après finalement ils nous pondent 2 pauvres lignes qui se baladent sur l'écran avant d'abandonner le "projet", on en a connu je t'assure.

De plus, tu viens nous donner des leçons de systèmes d'exploitation ce qui me semble un peu déplacé car tu n'as pas vraiment l'air de t'y connaitre mais je sens plutot un copier-coller de choses lues ca et là sur le net.

Pour mémoire, tu avais "lancé" quoi comme projet il y a un an ici?
Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...


et autres projets à finir avant 2010
    
./Post n°29   Marquer comme non lu.
TnT Ecrit le: Mercredi 30 août 2006 à 13:25 Déconnecté(e)    Voir le profil de TnT Envoyer un email à TnT Envoyer un message privé à TnT  

Sérieux ça sert à rien de vous bouffer la gueule.

On est bien d'accord. :)

TnT > Moi ce qui m'enerve c'est pas le fait que tu sois noob, biensur j'ai été moi aussi noob comme nous tous. Je ne l'oublie pas merci du conseil #tritop# Mais des mecs qui nous font perdre du temps en ne posant que des questions du genre "est-ce que c'est possible? je pense que oui..." et puis deux mois après finalement ils nous pondent 2 pauvres lignes qui se baladent sur l'écran avant d'abandonner le "projet", on en a connu je t'assure.

Oui en effet, j'en ai aussi vu quelques uns et ça m'irrite aussi quand les gens font genre "je vais faire un satellite commandé par TI et jvais conquérir Mars tadaaa jsuis lmeilleur", mais c'est un projet auquel j'ai réfléchis plus d'une fois avant de poster ici.

De plus, tu viens nous donner des leçons de systèmes d'exploitation ce qui me semble un peu déplacé car tu n'as pas vraiment l'air de t'y connaitre mais je sens plutot un copier-coller de choses lues ca et là sur le net.

Je m'excuse si mes posts on été mal pris, je ne voulais absolument pas donner de leçons. Je sais comment tourne un ordinateur et un microprocesseur, et pour moi quand on parle de temps réel c'est quand le jeu gère plusieurs unités "en même temps", même s'il est évident (pour moi) qu'il les gère à la suite. Je voulais juste faire une comparaison avec le multitâches, afin d'imager mon propos, ni plus ni moins.

Pour mémoire, tu avais "lancé" quoi comme projet il y a un an ici?

Je crois que je n'avais rien posté précisément pour éviter de faire genre j'ai un super projet et finalement le laisser tomber après quelques lignes de codes.
J'avais commencé un économiseur d'écran (le ballet de lignes) qui fonctionnait d'un point de vue programme ; il aurait encore fallut l'intégrer à la TI pour qu'il se déclenche au bon d'un certain temps sans tout faire planter.
Comme un économiseur d'écran a peu d'intérêt sur une calculatrice (si ce n'est d'user les piles pour rien), j'ai préférer écrire un programme qui demande un mot de passe à l'allumage de la calculatrice (il en demande un quand on l'éteint par 2nd+ON, il n'en demande pas quand on l'éteint par Diamond+ON). Ce programme *fonctionne*, il faut juste mettre une jolie interface qui est déjà bien avancée, et éventuellement rajouter des options. Si je ne l'ai pas fini c'est parce que j'avais des choses plus importantes à ce moment là, mes études entre autres.
Ce que j'aurais voulu faire dans un premier temps c'était finir ce programme pour me remettre dans le bain, et ensuite attaquer le jeu (qui ne sera pas fait puisqu'il existe déjà).

Alors le jour où j'aurai fini ce programme de mot de passe, je le releaserai, mais c'est précisément pour éviter d'embêter le monde que je n'en ai pas parlé à l'époque.
    
./Post n°30   Marquer comme non lu.
240-185 Ecrit le: Mercredi 30 août 2006 à 14:17 Déconnecté(e)    Voir le profil de 240-185 Envoyer un email à 240-185 Envoyer un message privé à 240-185  

Thepro> http://www.ticalc.org/archives/files/fileinfo/384/38472.html
Quasiment fonctionnel, une partie du code source se trouve sur le nopaste de fpgforce. Rappelle-toi, c'était le jeu que j'ai présenté où tu as supprimé le lien sans en proposer un autre dans ton infinie intelligence #triso#

J'avais commencé un économiseur d'écran (le ballet de lignes) qui fonctionnait d'un point de vue programme ; il aurait encore fallut l'intégrer à la TI pour qu'il se déclenche au bon d'un certain temps sans tout faire planter.

Si si c'est possible, ça s'appelle un TSR #oui#

Ce que j'aurais voulu faire dans un premier temps c'était finir ce programme pour me remettre dans le bain, et ensuite attaquer le jeu (qui ne sera pas fait puisqu'il existe déjà).

Donc 30 posts pour rien. Au moins ça m'aura fait tuer le temps :o
-Edité le Mercredi 30 août 2006 à 14:18 par 240-185-
Tel un automate, le dinosaure noir s'avance vers le chef des Chomp et dit : "euh..."
    
./Post n°31   Marquer comme non lu.
TnT Ecrit le: Mercredi 30 août 2006 à 14:29 Déconnecté(e)    Voir le profil de TnT Envoyer un email à TnT Envoyer un message privé à TnT  

Donc 30 posts pour rien. Au moins ça m'aura fait tuer le temps :o


Pour la 3ème fois : j'ai mis le lien qui pointe vers le jeu en question juste sous le post de Kevin qui dit que le jeu existe, c'est sur la 1ère page du topic... #ouin#
    
./Post n°32   Marquer comme non lu.
RHJPP Ecrit le: Mercredi 30 août 2006 à 15:31 Déconnecté(e)    Voir le profil de RHJPP Envoyer un email à RHJPP Envoyer un message privé à RHJPP  


240-185 :
Thepro> http://www.ticalc.org/archives/files/fileinfo/384/38472.html
Quasiment fonctionnel, une partie du code source se trouve sur le nopaste de fpgforce. Rappelle-toi, c'était le jeu que j'ai présenté où tu as supprimé le lien sans en proposer un autre dans ton infinie intelligence #triso#

Arrête de te foutre du monde !
Le lien que tu donnes est exactement celui que j'avais mis à la place du tien (c'est vrai, pas tout de suite, fallait bien que je le trouve avant de le mettre (10 secondes après mon Édit, il y était)). Et geogeo est passé après pour mettre un autre lien, je ne sais même pas pourquoi, d'ailleurs...
    
./Post n°33   Marquer comme non lu.
240-185 Ecrit le: Mercredi 30 août 2006 à 15:43 Déconnecté(e)    Voir le profil de 240-185 Envoyer un email à 240-185 Envoyer un message privé à 240-185  

Allons bon, je lui poste un lien bien sous tous rapports histoire de pas faire apparaître mon ftp perso, et il trouve le moyen de râler... (Et je veux pas dire, mais il a quand même fallu un peu beaucoup de temps (environ une ou deux heures) avant que tu ne daignes poster le lien ticalc, donc le foutage de gueule, il n'est pas du tout du côté auquel tu crois)...
-Edité le Mercredi 30 août 2006 à 15:45 par 240-185-
Tel un automate, le dinosaure noir s'avance vers le chef des Chomp et dit : "euh..."
    
./Post n°34   Marquer comme non lu.
TnT Ecrit le: Mercredi 30 août 2006 à 16:01 Déconnecté(e)    Voir le profil de TnT Envoyer un email à TnT Envoyer un message privé à TnT  

Jsuis rassuré, y'a pas qu'avec moi que ça part en latte... ^^
    
./Post n°35   Marquer comme non lu.
Jfg Ecrit le: Mercredi 30 août 2006 à 16:27 Déconnecté(e)    Voir le profil de Jfg Envoyer un email à Jfg Visiter le site WEB de Jfg Envoyer un message privé à Jfg  


mdr ce topic :D (mais un peu triste aussi)

je vais résumer/rajouter mon grin de sel:

-un sprite de 8*8 (64 pixels) se code avec 8 octets (64 bits)
-les graphismes dans un rts ne sont pas un problème... tu dessines le fond avec le tilemap engine (où même un engin perso vu que il n'y a pas besoin de scrolling au pixel près), et après tu dessines les objets qui bougent par dessus.
-la ram n'est pas un problème non plus, tous les sprites peuvent être dans un fichier externe archivé en ROM. ce qui prendra l'essentiel de la ram, c'est les variables qui décrivent les batiments/guerrier/etc... et ça, ça prend en général pas beaucoup de place
-c'est pas en utilisant de l'asm que tu va diminuer la conso de RAM.
-une approche OO est indispensable.
-les difficultés sont le pathfinding, l'ia, et faire une interface graphique pratique.

-TnT, tu n'as pas les skillz pour réaliser le moindre aspect de ce jeu.
-On a tous été débutant un jour, mais on a pas commencé en créant des topics sur des jeux.
-ça fait un an que tu a commencé, et tu n'as rien fait de concret. perso, un an après avoir commencé le C je faisais un bomberman.
Kill Mario
    
./Post n°36   Marquer comme non lu.
RHJPP Ecrit le: Mercredi 30 août 2006 à 16:55 Déconnecté(e)    Voir le profil de RHJPP Envoyer un email à RHJPP Envoyer un message privé à RHJPP  


240-185 :
Allons bon, je lui poste un lien bien sous tous rapports histoire de pas faire apparaître mon ftp perso, et il trouve le moyen de râler...

Le pauvre... Alors que c'est lui qui passe son temps à...

(Et je veux pas dire, mais il a quand même fallu un peu beaucoup de temps (environ une ou deux heures) avant que tu ne daignes poster le lien ticalc, donc le foutage de gueule, il n'est pas du tout du côté auquel tu crois)...

C'est faux.

Encore une fois, je ne participerai pas avec toi à ton passe-temps favori (la guéguerre), tu n'as pas autre chose à faire ?
-Edité le Mercredi 30 août 2006 à 16:55 par Thepro-
    
./Post n°37   Marquer comme non lu.
TnT Ecrit le: Mercredi 30 août 2006 à 18:02 Déconnecté(e)    Voir le profil de TnT Envoyer un email à TnT Envoyer un message privé à 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 ?

-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).

-une approche OO est indispensable.

Qu'est-ce donc ?

-TnT, tu n'as pas les skillz pour réaliser le moindre aspect de ce jeu.

Mais comment est-ce que tu peux le savoir ? Je n'en suis pas à mon premier programme, loin de là...

-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 ??

-ça fait un an que tu a commencé, et tu n'as rien fait de concret. perso, un an après avoir commencé le C je faisais un bomberman.

L'ASM Z80, ça fait 6 ans, l'ASM 68k, 4 ans (si on compte depuis le début). Je sais que je n'ai rien fait de fini, mais ce que j'ai fais fonctionne tout de même. Ensuite faire des jolis titres c'est pas le plus important. Faire un TSR appelé au sein d'une interruption c'est déjà autre chose...
    
./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
    
  :: Index » Forum Ti68K » Projets » Alerte Rouge (57 réponse(s))
Pages : 2/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 49ms avec 18 requetes