Il n'y pas assez de programmeur de jeu - Page 3

enfin, peut etre

c pas pke elle est faite sur psp qu'elle sera bien, au contraire, vaut mieux faire qq chose de simple mais lisible et intuitif

pokered n'est pas fini mais il le sera !

j'espere bien !

oui mais faudrait que je recode pas mal de trucs
et la j'ai pas trop le temps!

bah je me doute, c comme moi si un jour je veux finir darkhole

Et bien entendu, vive la TIGCC Team (en particulier Zeljko) sans laquelle TICT n'existerait probablement pas...

> Mais ces deux équipes ne sont pas les seules à faire un boulot formidable.
> Je pense à la T3, par exemple, qui a aussi fait (et qui continue de faire) un excellent boulot !
Remarquez que je n'ai pas dit le contraire. Et le fait que je ne sois pas d'accord avec les programmeurs sous kernel sur la façon d'utiliser la 89/92+/V200 ne m'autorise pas à dire qu'ils sont mauvais (tiens, je me répète, j'ai déjà écrit ça il y a moins d'une demi-heure...)

> je considère que toute équipe fait du bon boulot à partir du moment où celui-ci est apprécié...
C'est une façon de voir les choses, et je suis assez d'accord.

Par contre, il y a peu d'équipes qui ont apporté des routines pour TIGCCLIB... TICT en fait partie, mais pas la T3 à ma connaissance.
Et je relance l'appel à documenter les fonctions de unknown.h...

pas la T3 à ma connaissance

C'est leur choix.
A nous de le respecter, même si nous ne le comprennons ou n'approuvons pas.
si tu part comme ça, la TCI non plus n'a jamais apporté de routines pr TIGCCLIB

C'est une façon de voir les choses, et je suis assez d'accord.

Et le fait que je ne sois pas d'accord avec les programmeurs sous kernel sur la façon d'utiliser la 89/92+/V200 ne m'autorise pas à dire qu'ils sont mauvais (tiens, je me répète, j'ai déjà écrit ça il y a moins d'une demi-heure...)

Oué, ça me dit quelque chose
je ne reformulerai pas la réponse que j'ai donné il y a une demi-heure pas besoin.

XDanger
a écrit : Et bien entendu, vive la TIGCC Team (en particulier Zeljko) sans laquelle TICT n'existerait probablement pas...

Merci.

Par contre, il y a peu d'équipes qui ont apporté des routines pour TIGCCLIB... TICT en fait partie,

Merci beaucoup d'ailleurs.

mais pas la T3 à ma connaissance.

En effet.
PpHd préfère mettre ses routines dans des librairies dynamiques ou dans PreOs plutôt que de les contribuer à TIGCCLIB.

Et je relance l'appel à documenter les fonctions de unknown.h...

Merci. Tous les intéressez sont appelés à nous contacter à Team@tigcc.ticalc.org .

moi ça me derange pas que PpHD fasse des trucs pour kernel

Sauf que TIGCCLIB peut être utilisée par tout le monde, y compris les programmeurs pour kernel.

ben les trucs de kernel peuvent etre utilisés par tous les possesseurs de TI

Pas par des programmeurs _nostub.
Ni d'ailleurs par des programmeurs qui programment sous GPL (parce que les kernels et les librairies dynamiques comme genlib ne sont pas sous GPL et ne font pas partie du système d'exploitation de la plateforme - TIGCCLIB est sous une licence compatible avec la GPL (licence TIGCCLIB = GPL + exception pour permettre l'utilisation dans des programmes sous une licence quelconque)).

Je préfère que PpHd fasse un jeu/utilitaire que faire une doc

bah il code un moteur 3D et une ROM

Moi je prepare un jeu, mais il demande tellement de ressource graphique que la version actuelle de Xlib ne tiens pas le coup. Donc il faut que je reprogramme XLib en VeryHard optimisation qui utilise du pre/semipre-shifting

Une optimisation en vitesse, mais pas en taille...
Si ça nécessite trop de ressources, ça peut aussi être dû au fait que le processeur qui n'est pas assez puissant pour ce que tu veux faire...

> PpHd préfère mettre ses routines dans des librairies dynamiques ou dans PreOs plutôt que de les contribuer à TIGCCLIB
Malheureusement, en effet...

liquid: tes arguments sont irrecevables...

MDR !! g pas argumenté !

Timad, comme il a deja ete explique plusieurs fois, le fait d'avoir un moteur graphique ne suffit pas a faire tourner n'importe quoi, si le jeu en lui meme est trop lourd pour une ti tu n'y peux pas grand chose, si tu me dis ensuite que le jeu est de type 2D, on peut a peu pres tout faire tourner sur ti, y a qu'a voir sonic et autre kirby! je ne crois pas que c'est en améliorant ta lib deja suffisement rapide pour faire un sonic like que tu arriveras a ton but, plutot en revoyant la manière de faire ton jeu...

XDanger
a écrit : Une optimisation en vitesse, mais pas en taille...

Bref, j'appelle ça plutôt un pessimisation qu'une optimisation. D'autant plus que ça augmente la taille du programme beaucoup plus que sa vitesse.

liquid
a écrit : MDR !! g pas argumenté !

Le problème est là, justement! Ce n'est pas bien de prétendre quelque chose sans être en mesure de le justifier.

nan c toi qui es borné, un prgm kernel peut etre utilisé par tt le monde, t'installes le kernel et tu le desinstalles apres

Ça ne change rien au fait qu'une librairie kernel ne peut pas être utilisée par un programmeur _nostub.

du moins, pas de façon simple


(je nuance, vu que Genlib est utilisable en nostub )

gennlib.a, ce n'est pas du _nostub, c'est de l'émulation kernel. Ce n'est pas la même chose.

jusque qu'après, tu as toujours défini nostub par prog n'ayant pas besoin de kernel.
avec genlib.a, pas besoin de kernel => nostub.

ou alors, il faut inventer un troisième nom ?
toujours est-il que c considéré comme nostub par les utilisateurs, puisqu'ils n'ont pas à installer de kernel...

Et si genlib.a c pas du nostub, alors les Dll de TIGCC en sont-elle ?

Strictement parlant, _nostub = pas de stub. Donc le programme qui appelle genlib est toujours en _nostub techniquement. Mais il y a un émulateur kernel intégré dans gennlib.a, et genlib n'est clairement pas du _nostub, donc l'ensemble programme+genlib ne l'est pas non plus (0 stub + 1 stub = 1 stub != 0 stub).

Les DLLs _nostub n'émulent pas le format kernel. Une DLL _nostub:
- ne contient pas de stub kernel
- ne contient pas de header kernel
- ne contient pas de ROM_CALLs en jsr doorsos/tios::toto
- ne contient pas de RAM_CALLs, BSS, ...
- utilise le format de table de relogements de AMS!

OK pour le point de vue technique.


cela dit, pr l'utilisateur, Dll nostub et genlib utilisée sans kernel, c pareil.

du _mistub

Je suis d'accord avec squale92.
L'avantage du nostub est de lancer le jeu sans kernel ce qui est plus facile pour l'utilisateur!
Mais le mistub d genlib est transparent alors moa si je connaissait pas le systeme je considerait que c'est du nostub!
D'ailleur je trouve le mistub de genlib tres interressant!