Re: [COLECO] Commando return

par **youki** Mar 28 Juin 2011 - 23:48

1k de ram , c'etait deja 4 fois plus que le TI 99!!!.... il n'avait que 256 bytes de ram!!
Si si , je t'assure je rigole pas. Si tu avais plus de RAM c'etait parce qu'elle etait dans la cartouche.
http://en.wikipedia.org/wiki/Texas_Instruments_TI-99/4A

par **drfloyd** Mer 29 Juin 2011 - 7:29

et les 16ko de RAM disponibles pour le basic alors ?????

par Invité Mer 29 Juin 2011 - 8:58

Il me semblait avoir lu qu'elle avait 8 ko de ram est 16 ko de vram !!!

par **youki** Mer 29 Juin 2011 - 10:23

drfloyd a écrit:et les 16ko de RAM disponibles pour le basic alors ?????

Et c'est de la ram 8bits pas directement connecté au processeur. Ca passer par un multiplexer 16/8bits.

Il me semblait avoir lu qu'elle avait 8 ko de ram est 16 ko de vram !!!

Non, c'est 1k de RAM et 16ko de vram . Biensur en bidouillant tu peux te debrouiller d'utiliser la vram libre comme RAM , mais l'acces n'est pas directe , faut passer par le port du VDP . C'est pas pratique et c'est lent comparer a un acces ram direct.

par Invité Mer 29 Juin 2011 - 10:42

Il doit y avoir moyen de faire comme sur TI99, rajouter de la RAM dans la cartouche ?

La NES utilisait cette technique aussi pour augmenter la qualité graphique de certains jeux !

par **youki** Mer 29 Juin 2011 - 10:50

J'en ai parler sur un forums us de cette possibilité il y a quelque temps. Ca semble etre possible (avec certaine contrainte toutefois) .. par contre la Ram que tu mets, t'enleve autant de Rom. Ex: si tu mets 8k de Ram dans la cartouche, il ne te reste plus que 24k de Rom pour ton code au lieu de 32.

ensuite, il ya la technique du bank switching sur les cartouches. opcode utilise ca pour c'est jeux, ca permet d'avoir beaucoup plus de ROM . Mais bon c'est pas page de 16k... tu as 16k qui ne change pas , et tu as les second 16 qui tu peux switcher au besoin. Ca impose que ton programme gere ca specifiquement.

Et puis bon, tout ca ca demande du hardware particulier sur la cartouche. Ca augmente les couts... et en plus je trouve que c'est pas "authentique". En 1982 ces techniques n'etait pas envisageable. (principalement a cause du cout)..

par Invité Mer 29 Juin 2011 - 11:02

youki a écrit:J'en ai parler sur un forums us de cette possibilité il y a quelque temps. Ca semble etre possible (avec certaine contrainte toutefois) .. par contre la Ram que tu mets, t'enleve autant de Rom. Ex: si tu mets 8k de Ram dans la cartouche, il ne te reste plus que 24k de Rom pour ton code au lieu de 32.

Oui je pensais pas que la lecture était déjà arrivé à sa limite, je croyais que c'était 64 ko.
Forcément c'est moins intéressant, ou plus dur à programmer.

youki a écrit:ensuite, il ya la technique du bank switching sur les cartouches. opcode utilise ca pour c'est jeux, ca permet d'avoir beaucoup plus de ROM . Mais bon c'est pas page de 16k... tu as 16k qui ne change pas , et tu as les second 16 qui tu peux switcher au besoin. Ca impose que ton programme gere ca specifiquement.

ça parait compliqué à gérer, et moyennement intéressant, non ?

youki a écrit:Et puis bon, tout ca ca demande du hardware particulier sur la cartouche. Ca augmente les couts... et en plus je trouve que c'est pas "authentique". En 1982 ces techniques n'etait pas envisageable. (principalement a cause du cout)..

C'est dommage quand même, ça peut falloir le coup de le faire. ( sur emulateur ).

par Invité Mer 29 Juin 2011 - 11:13

youki a écrit:
Non, c'est 1k de RAM et 16ko de vram . Biensur en bidouillant tu peux te debrouiller d'utiliser la vram libre comme RAM , mais l'acces n'est pas directe , faut passer par le port du VDP . C'est pas pratique et c'est lent comparer a un acces ram direct.

Comme quoi souvent les infos sur les machines trouvées sur le net sont fausses .. Twisted Evil

par Invité Mer 29 Juin 2011 - 11:39

Des fausses infos, tu en trouve à la pelle sur le net.

par Invité Mer 29 Juin 2011 - 12:04

Oui c'est clair mais bon je trouve qu'en matière de specs consoles c'est plus souvent du gros n'importe quoi, que des infos fiables ..

par Invité Mer 29 Juin 2011 - 12:06

Je voulais parler de ça justement, mais je me suis mal exprimé, désolé.

par Invité Mer 29 Juin 2011 - 12:41

Pas de soucis ..

par **youki** Mer 29 Juin 2011 - 13:49

C'est vrai par exemple on lit partout que la PC Engine est mieux que la GX 4000 de Amstrad. C'est du grand n'importe quoi! Very Happy

par Invité Mer 29 Juin 2011 - 14:07

Ca y est, c'est plus l'amiga maintenant ,c'est au tour de la PCE Evil or Very Mad

Si shubibiman lit ça, il va te bouffer un tibia Mr. Green

par shubibiman Mer 29 Juin 2011 - 14:11

Ralala! Juste quand je me décide à lire ce topic :lol:
Touko a dû m'envoyer un message par télépathie pour me prévenir Mr. Green

par Invité Mer 29 Juin 2011 - 14:18

mdr !!

TROP TARD lol!

par **youki** Mer 29 Juin 2011 - 14:20

Touko a dû m'envoyer un message par télépathie pour me prévenir

Ca c'est pas possible, qui dit "télépathie" sous entend que les sujets emetteur et recepteur possède un cerveau! ... or dans ce là...l'emetteur il n'en a pas! Mr. Green

par Invité Mer 29 Juin 2011 - 14:55

Lol, c'est bas ça What a Face

par Invité Mer 29 Juin 2011 - 15:30

MEAAAH ! ça balance fort là !

par **65c02** Mer 29 Juin 2011 - 15:39

Bah.
Avec 1 Ko de ram ce sera vite oublié :)

par bfg Sam 9 Juil 2011 - 14:49

Bon, je sais qu'il y à des codeurs ici :) Je suis une quiche en mathématique et j'ai besoin que ma bullet aille d'un point a à un point b.

Sur pc j'aurais fait soit ça :

deltax = player.x - bullet.x
deltay = player.y - bullet.y
angle = atan2(deltax,deltay)
bullet.x += cos(angle)
bullet.y += sin(angle)

ou alors j'aurais calculé la ligne de mouvement avec un algo de Bresenham et stocké le tout dans une array de mes 4 gigas de mémoire.

Sauf que là, j'ai un petit proco, pas le droit d'utiliser de float, de multiplication de division et 1KO de ram ... Je sais que je peux utiliser des tables précalculés de COS et SIN en ROM, mais comment calculer un angle entre 2 points sans tout péter ?

Si quelqu'un à une idée, un algo, quoique ce soit ... Merci d'avance.

par akinos Sam 9 Juil 2011 - 15:09

bfg a écrit:Bon, je sais qu'il y à des codeurs ici :) Je suis une quiche en mathématique et j'ai besoin que ma bullet aille d'un point a à un point b.

Sur pc j'aurais fait soit ça :

deltax = player.x - bullet.x
deltay = player.y - bullet.y
angle = atan2(deltax,deltay)
bullet.x += cos(angle)
bullet.y += sin(angle)

ou alors j'aurais calculé la ligne de mouvement avec un algo de Bresenham et stocké le tout dans une array de mes 4 gigas de mémoire.

Sauf que là, j'ai un petit proco, pas le droit d'utiliser de float, de multiplication de division et 1KO de ram ... Je sais que je peux utiliser des tables précalculés de COS et SIN en ROM, mais comment calculer un angle entre 2 points sans tout péter ?

Si quelqu'un à une idée, un algo, quoique ce soit ... Merci d'avance.

Bah, Bfg :)

Si tu fais partir ta bullet en ligne droite de ton point A(x1,y1) au point B(x2,y2), peux tu utiliser une équation réduit de droite avec Y = aX + b ?

A partir de tes deux points A et B, tu calcules les coefficients a et b de ta droite. Puis tu fait évoluer, point par point, en faisant varier x (ou Y) en calculant l'avancée selon l'équation à partir du point A.

Au pire, tu fais "mort instantanée du point B si A tire" cheers

par **65c02** Sam 9 Juil 2011 - 15:28

Sur une bécane moderne tu déplace ton bullet en lui ajoutant le vecteur (dest - pos bullet) normalisé puis multiplié par sa vitesse.
Sur un vieux 8 Bits regarde plutôt l'algo de tracé de ligne de bresenham

par **youki** Sam 9 Juil 2011 - 15:31

une simple equation de droite, ca marche pas?Y=aX+b ? Et pour le coefficient directeur , tu ignore les decimals, tu calcules tout en int. Ca fait des approximation , c'est sur. Mais dans le context du jeu ca peut le faire. Enfin j'ai fait un truc comme ca dans GnZ . Si tu commences a vouloir une "rigueur mathematique" dans un jeu coleco , t'es pas sortit de l'auberge!!!

par bfg Sam 9 Juil 2011 - 16:25

Un indice était donné. Dans ma question , je suis une quiche en math ... Alors j'avoue vous m'avez tous largué la Very Happy

par bfg Sam 9 Juil 2011 - 16:28

65c02 a écrit:Sur une bécane moderne tu déplace ton bullet en lui ajoutant le vecteur (dest - pos bullet) normalisé puis multiplié par sa vitesse.
Sur un vieux 8 Bits regarde plutôt l'algo de tracé de ligne de bresenham

Je peux pas stocker les points de la ligne ... Erelancer l'algo a chaque fois pour un point ne donne pas un bon mouvement ... (j'ai teste) Sad

par **65c02** Sam 9 Juil 2011 - 19:22

relancer à chaque fois c'est mauvais parce que tu perds l'erreur, mais si tu stock l'octant et l'erreur ça marche. Même si la destination change (j'ai testé aussi :p )
Ça évite de calculer la pente d'un vecteur directeur (une division en moins)
par contre c'est chiant à mettre en place.
En fait un bresenham c'est une sorte de calcul en virgule fixe sur un axe

par Invité Sam 9 Juil 2011 - 21:30

Bah ax+b c'est bien ..

tu as A ton point de depart, x le decalage sur l'axe des X (que tu incrémentes dans un tir en diago ou lateral), et b le decalage sur l'axes des y (que tu incrémentes pour un tir en diago ou droit) ..

par bfg Mar 12 Juil 2011 - 19:42

C'est bon, j'ai quelquechose de pas non plus extrèmement précis, mais suffisamment pour rendre le jeu INFERNAL !! :) :) Sans bouffer de proco ...

par Invité Mar 12 Juil 2011 - 19:47

Ah, et c'est quoi ??? juste pour info What a Face

par jf Mar 12 Juil 2011 - 20:27

le jeu de tir avec le tank :p

Tu ne peux pas faire un "tableau" avec les valeurs, comme cela pas besoin de calculer et tu imposes des valeurs ?

Si tu n'as pas assez de place pour tout stocker, tu peux aussi agrandir les "formes" comme cela moins de points à calculer ? (trouver un juste milieu)