Du C: kinenveu ? - Page 2

-

-

Même en gagnant plus de moitié en passant en assembleur, c'est à dire mettons 5ko d'objet programme au lieu de 10 ou 15 (hors sprites, background...), on reste limité à 40ko de RAM utilisable.
Après c'est un choix vu qu'une cartouche de 256ko est la base : on fait une compile de plusieurs mini-jeux tous utilisables par BLL ou voit plus grand et on met des données en ROM qu'il faut bien charger à un moment ou un autre, en C ou en ASM, c'est pareil. Disons qu'en ASM, on doit trouver ça plus normal sans doute...

Orion_ :
je vois pas pourquoi y'a autant de probleme sur lynx, c'est quoi exactement le soucis ?

j'ai cru comprendre que sur Lynx on ne pouvait pas directement lire la ROM mais plutôt qu'on devait charger en RAM les données pour ensuite pouvoir les exploiter, c'est ça ?

-

Orion_
:

Fadest :
C'est vrai que vous avez plus de 64ko de RAM sur Jag...
Par que 256ko de ROM d'un coté, 40ko de RAM utilisable (il faut enlever les buffers écrans et divers autres trucs des 64) de l'autre.
Le moindre background qui fait 8ko, s'il en faut 4 + les sprites + les sons, en faisant vite le compte, il ne reste plus grand chose pour le programme en lui même (on parle de C là).

deja que je trouve limite de coder en C sur jag, alors sur lynx avec le processeur et les limite memoire qu'elle a je trouve ca vraiment domage. ca aide carement pas c'est sur. (et a mon avis c'est pas du tout adapter, d'ou les bidouillages)

ça dépend par ce qu'on entend coder en C
moi, je vois ça comme j'écris la logique du jeu en C et pour tout ce qui est critique, j'utilise des libs optimisés qui exploitent à fond la machine
je vois pas l'intérêt de s'embêter à écrire du code technique (structures de données un peu évoluées) qui n'a pas besoin forcément d'être ultra optimisé

le cas des arbres équilibrés (cf http://fr.wikipedia.org/wiki/Arbre_%C3%A9quilibr%C3%A9) est un parfait exemple de code très délicat à écrire et en ASM, tu vas passer des jours et des nuits à essayer de coder ça sans bogues pour finalement renoncer alors que dans un langage de plus haut niveau, ça sera encore technique à écrire mais tu auras plus de facilité à raisonner sur ton code

le bilan est que le programmeur ASM aura probablement utilisé au final une structure de données moins performantes (suite à un découragement) et donc son prog sera finalement plus lent

-

Pas obligé de leur filer l'aile ou la cuisse Quand je disais 'libc', c'est un truc qui ressemble, pas forcément porter le truc en entier (vu ce que ça risque de consommer)... Evidement, faut rester réaliste. Mais dans tout bon cours sur le C, tu vois toujours les composants du libc, donc histoire que tout le monde parle le même langage, autant avoir des fonctions qui s'appellent pareil. Ensuite, si derrière c'est codé differement sur une lib GPU ou DSP...

Kochise

Orion_
:

SebRmv :
ça dépend par ce qu'on entend coder en C
moi, je vois ça comme j'écris la logique du jeu en C et pour tout ce qui est critique, j'utilise des libs optimisés qui exploitent à fond la machine

oui la ok je suis d'accord, ca donne un gain de temps, mais il faut aussi savoir que le 68k ralenti pas mal les autres proc en acces, et ceux qui coderons en C en utilisant une lib qu'il n'on pas ecrite aurons pas mal de soucis, par exemple pour faire un scrolling a la vbl en 68k :/ et vu qu'il n'auront pas de connaissance de la jag auront du mal a ce le faire en asm au gpu/blitter ou a gerer l'op de la bonne maniere pour faire ca.
alors c sur on peu faire une lib de scrolling mais bon a ce train la y'en a des truc a faire pour satisfaire tout le monde ...

par ailleurs ce qui me choque un peu dans ce topic c'est que tu a eu une tres bonne initiative en simplifiant le coding en C sur jag avec une lib optimiser, mais en donnant la main certain demande carement le bras entier voir l'epaule ...

ok, je comprends ce que tu veux dire maintenant
oui, bah, c'est clair, en disclaimer il y aura: "c'est mal d'utiliser le 68k"
d'ailleurs, tu peux voir qu'une des premières fonctions que j'ai mise est stop68k()

Kochise :
Pas obligé de leur filer l'aile ou la cuisse Quand je disais 'libc', c'est un truc qui ressemble, pas forcément porter le truc en entier (vu ce que ça risque de consommer)... Evidement, faut rester réaliste. Mais dans tout bon cours sur le C, tu vois toujours les composants du libc, donc histoire que tout le monde parle le même langage, autant avoir des fonctions qui s'appellent pareil. Ensuite, si derrière c'est codé differement sur une lib GPU ou DSP...

Kochise

ok, d'après les premiers tests que j'ai pu faire ce soir, ça devrait être bon pour la libc

Kochise :
GT, les compilos de nos jours ne prennent plus 1 MiB pour afficher un simple "Hello World !", faudrait que tu mettes à jours tes références :/

Kochise

Heu désolé Zorro270, mais je vais citer un de tes programmes, Kochise a tu déjà utiliser ZView, tu as vu sa taille ? 541 Kilos (Un démi mega) et ceci pour voire des images, toi ca te choque pas un peu ? Topaze peut aussi afficher des images, dispose aussi d'un gestionnaire de modules, t'aide a faire les maps et j'ai rien touché a mes 44 Kilos. Meme si cela a evoluer, faut quand meme pas croire qu'un programme pourra t'optimiser correctement certaines choses, car un compilo pense toujours que sur une petite zone, voire une ligne, alors que nous nous comprenons, nous voyons beaucoup plus grand, ce qui permet des optimisations assez interressantes.

Le seul truc interressant a écrire en C, c'est les protections, car le code sortit d'un compilo est assez m.... a lire, j'ai essayé deux fois et bonne chance aux crackers

Mais je vais arreter là, sinon on va reprendre notre bonne vieille guerre

GT

SebRmv
:

Kochise :
Pas obligé de leur filer l'aile ou la cuisse Quand je disais 'libc', c'est un truc qui ressemble, pas forcément porter le truc en entier (vu ce que ça risque de consommer)... Evidement, faut rester réaliste. Mais dans tout bon cours sur le C, tu vois toujours les composants du libc, donc histoire que tout le monde parle le même langage, autant avoir des fonctions qui s'appellent pareil. Ensuite, si derrière c'est codé differement sur une lib GPU ou DSP...

Kochise

ok, d'après les premiers tests que j'ai pu faire ce soir, ça devrait être bon pour la libc

bon, alors, effectivement j'ai une libc qui marchotte mais je suis pas convaincu de cette implémentation qui me parait un peu lourde pour la Jaguar (ça va d'ailleurs dans le sens de GT: 100 ko pour faire un brave print, franchement ça me dépasse)

sinon, c'est cool, on peut justement envoyer des messages à l'Alpine et ça peut être bien sympa d'utiliser ça comme console

en conclusion, je vais abandonner la piste newlib donc...

j'écris la logique du jeu en C et pour tout ce qui est critique, j'utilise des libs optimisés qui exploitent à fond la machine

je vois pas l'intérêt de s'embêter à écrire du code technique (structures de données un peu évoluées) qui n'a pas besoin forcément d'être ultra optimisé...

... Et qui va rendre le dev. plus long.

C'est le raisonnement que l'on pratique dans "ma" société, et c'est la seul solution pour survivre dans ce secteur... Bref! Le temps c'est de l'argent !


Poursuit tes efforts Seb, car je peux t'assurer qu'ils seront récompensés !

T.P.T



+ =

templeton
:

j'écris la logique du jeu en C et pour tout ce qui est critique, j'utilise des libs optimisés qui exploitent à fond la machine

je vois pas l'intérêt de s'embêter à écrire du code technique (structures de données un peu évoluées) qui n'a pas besoin forcément d'être ultra optimisé...

... Et qui va rendre le dev. plus long.

C'est le raisonnement que l'on pratique dans "ma" société, et c'est la seul solution pour survivre dans ce secteur... Bref! Le temps c'est de l'argent !


Poursuit tes efforts Seb, car je peux t'assurer qu'ils seront récompensés !

T.P.T



+ =

t'inquiète , j'y compte bien

*.abs ... c'est quoi ?

edit :
ok j'ai trouvé : http://filext.com/detaillist.php?extdetail=abs ... sauvegarde pour un sudoku

templeton :
+ =

Lol !!!


GT

Fadest :
En réponse à _Orion ;

C'est vrai que vous avez plus de 64ko de RAM sur Jag...
Par que 256ko de ROM d'un coté, 40ko de RAM utilisable (il faut enlever les buffers écrans et divers autres trucs des 64) de l'autre.

...........................

Maintenant, sur Jag avec 2 mo (c'est bien ça ?) de RAM, même par rapport à une ROM de 4 mo, le problème est moins crucial, je te l'accorde.

Oui mais on tourne beaucoup plus souvent avec du True Color et la facture graphe grimpe très vite, un simple écran 320*240=150 Kilos

GT Plein

Orion_ :
par ailleurs ce qui me choque un peu dans ce topic c'est que tu a eu une tres bonne initiative en simplifiant le coding en C sur jag avec une lib optimiser, mais en donnant la main certain demande carement le bras entier voir l'epaule ...

Si c'est de moi que tu parles, dans mon premier message, je dis clairement qu'il y a a tout ce qui peut me convenir, ensuite le monsieur a dit "Lachez vous"

Maintenant, il y a moyen d'avoir des jeux sympas à jouer sans scrolling à la VBL, ni zoom et tout ça. Et pas besoin de l'assembleur pour ça. Il suffit juste d'ajuster ces outils à ses besoins et vice-versa...

mariaud :
*.abs ... c'est quoi ?

edit :
ok j'ai trouvé : http://filext.com/detaillist.php?extdetail=abs ... sauvegarde pour un sudoku

non, c'est un *.bin en fait

Fadest :
Bon, je ne sais pas si c'est déjà géré ou pas mais :

1 - possibilité que le point d'action x,y d'un sprite ne corresponde pas au coin haut-gauche, mais puisse être défini à la création du sprite (ou à son init)
-> parallèle Lynx : si tu as un cercle, tu peux à la création de l'objet sprite définir le point d'action x,y au centre du cercle. C'est super pratique pour les effets zooms et autre effets de déformation et plein d'autres calculs si on s'en sert bien...

ça c'est fait maintenant
c'est vrai que c'est bien pratique

par contre, pour les collisions, je vois pas de moyen simple et rapide de gérer les scaled sprites de la jag

scaled 1-bit mask et mask binary test au blitter (avec un AND) ?

Kochise

Kochise :
scaled 1-bit mask et mask binary test au blitter (avec un AND) ?

Kochise

Le probleme c'est que les Scaled sprites sont hard, si on veut les tester on est obligé de generer completement le mask en zoomant a la main . D'ou le probleme on en avait déjà discuté avec Seb et pour l'instant aucune solution vraiment rapide va t'on dire.


GT Pas zoomé #

@Seb :

Pour les collisions, ça aurait été la cerise sur le gateau, mais s'il y a déjà une routine au pixel pour les sprites non zoomés, c'est tout bon.

oui Kochise, on peut faire au blitter en theorie

disons que j'ai trop la flemme pour gérer les sprites déformés pour les collisions

hop là, petite maj pour dire que j'ai fait les stubs avec le mod player de Sinister
donc le son (mod + sample) tout simple maintenant

D'autres news depuis ?

Si quelqu'un veut créer un émulateur Atari 2600

ça avance doucement
s'il y en a que ça intéresse et qui viennent à la RGC, on pourra en parler volontiers

je compte écrire un petit tuto pour mettre en place l'environnement de dév (orienté linux quand même)

après, je compte bien distribuer mes libs mais il y a un peu de cosmétique à faire avant

Seb

Pour perpétuer une tradition ancestrale de pinaillage, je ferai immédiatement remarquer que la fonction attach_sprite_to_display_at_layer() ne prend pas ses arguments dans le sens ou son nom les cite, ce qui, à n'en pas douter, est une irréfutable preuve d'une incohérence rédhibitoire! Alors mon petit Seb, veuillez revoir votre copie! hop hop hop!

Sinon pour compléter l'histoire des fopen/fclose, je vois mal leur intérêt si les données qu'on veut lire sont déjà disponible (sans traitement préalable) dans l'espace mémoire adressable de la jag.

Par contre, si c'est pour lire des graphismes compressés (avec Zip [par ce que c'est hyper courant], ou mieux, je viens d'ailleurs de finir de lire le chapitre "compression arithmétique" du Salomon 3e ed°, une magnifique bible du domaine, et je compte bien aller continuer en regardant le PPM) alors là je trouve ça une excellente idée! Et je pense Seb, que c'est en ligne avec tes recherches sur la compression arithmétique. Peut-être même avais-tu pensé à coder une compression/décompression PPM??

En tout cas, imaginons que nous ayons (quelque part dans l'espace mémoire de la jag) une archive Zip (qui pourrait éventuellement être organisée avec des sous-répertoires?) alors y accéder à coup de fopen()/fread(), c'est un peu le top du confort, non?

stabylo :
Pour perpétuer une tradition ancestrale de pinaillage, je ferai immédiatement remarquer que la fonction attach_sprite_to_display_at_layer() ne prend pas ses arguments dans le sens ou son nom les cite, ce qui, à n'en pas douter, est une irréfutable preuve d'une incohérence rédhibitoire! Alors mon petit Seb, veuillez revoir votre copie! hop hop hop!

je te reconnais bien là

Sinon pour compléter l'histoire des fopen/fclose, je vois mal leur intérêt si les données qu'on veut lire sont déjà disponible (sans traitement préalable) dans l'espace mémoire adressable de la jag.

Par contre, si c'est pour lire des graphismes compressés (avec Zip [par ce que c'est hyper courant], ou mieux, je viens d'ailleurs de finir de lire le chapitre "compression arithmétique" du Salomon 3e ed°, une magnifique bible du domaine, et je compte bien aller continuer en regardant le PPM) alors là je trouve ça une excellente idée! Et je pense Seb, que c'est en ligne avec tes recherches sur la compression arithmétique. Peut-être même avais-tu pensé à coder une compression/décompression PPM??

En tout cas, imaginons que nous ayons (quelque part dans l'espace mémoire de la jag) une archive Zip (qui pourrait éventuellement être organisée avec des sous-répertoires?) alors y accéder à coup de fopen()/fread(), c'est un peu le top du confort, non?

euh, ne nous enflammons pas hein
les fopen/fclose auront un intérêt avec la JagCF
j'ai un début d'implémentation de stdio et je me suis fait une petite console
je suis assez content de ce design mais il faudra l'éprouver en faisant le lien avec la JagCF

PS: ça pourrait s'appeler "comment encoder des objets en C en 3 leçons"

Je suis trés intéressé par ton futur devkit C SebRmv, il me restera à trouver une Jag.