Re: COLECOVISION [TOPIC GENERALISTE]

[bfg]

C'est un plateforme .

Ben si c'est un jeu de plateforme avec scrolling fluide sur 32ko c'est fort.
Je ne comprends toujours pas comment fonctionne un pitfall 2 ou un moon patrol sur Coleco avec des scrollings aussi fluide ... Je pense que je ne saurais jamais en faire d'ailleurs

[Invité]

C'est clair que sur une machine sans scroll hard c'est chaud, après peut être que pour un premier jet tu vises trop haut non ??
CAD direct un scroll multi, alors que je pense qu'un horizontal serrait le moins difficile ..
Après peut être aussi que le C, pour ce genre d'exercice, n'est peut être pas adapté non plus, shifter des tiles en temps réel ou 1 sur 2 ..

[bfg]

C'est clair que sur une machine sans scroll hard c'est chaud, après peut être que pour un premier jet tu vises trop haut non ??
CAD direct un scroll multi, alors que je pense qu'un horizontal serrait le moins difficile ..
Après peut être aussi que le C, pour ce genre d'exercice, n'est peut être pas adapté non plus, shifter des tiles en temps réel ou 1 sur 2 ..

Ha non, je veux pas faire un scroll multi, je veux juste comprendre comment en faire un horizontal fluide. Je vois la théorie de la chose, mais pour mettre ça en pratique ... je veux dire, comment agencer les caractères pour que ça marche ? Comment shifter les caractères en temps réel sans bouffer toutes la ram ? Et d'ailleurs comment agencer le bordel à l'écran pour que le shift fonctionne ?

Je vois le jeu d'Oscar Toledo qui ressemble à un Ghost'n Goblins (j'ai pas le nom en tête la), le putain de scroll il est fluide, et la rom fait 256 ko. Je suppose que ses tiles sont préshifté, mais comment il les agence en mémoire pour que ça marche ?

Bref en C ou en Assembleur, j'arrive déja pas, sur le papier à comprendre comment ça fonctionne ... C'est mal barré pour l'implémentation

[Invité]

ah .. si  ca ressemble a du MSX ,ca doit etre bien moche.

Quand tu vois cela, je pense pas que ce soit moche http://www.rgcd.co.uk/2012/02/zombie-incident-msx.html

[bfg]

ah .. si  ca ressemble a du MSX ,ca doit etre bien moche.

Quand tu vois cela, je pense pas que ce soit moche http://www.rgcd.co.uk/2012/02/zombie-incident-msx.html

Il est excellent ce jeu d'ailleurs ! Librement téléchargeable et aussi en cartouche pas cher.
Au fait msieurs, tu penses à moi steup ?   (cf mon mail).

[drfloyd]

pourquoi dire du mal du MSX alors que quelque part c'est une Coleco améliorée non ????

[bfg]

pourquoi dire du mal du MSX alors que quelque part c'est une Coleco améliorée non ????

Parce que Youki est taquin, c'est tout

[Fabf]

pourquoi dire du mal du MSX alors que quelque part c'est une Coleco améliorée non ????

Parce que Youki est taquin, c'est tout

C'est pour ça que j'ai laissé passer, mais attention la prochaine fois

[Invité]

Au fait msieurs, tu penses à moi steup ?   (cf mon mail).

Mais j'ai répondu le 22 si tu parles de l'émulateur [/quote]

[Invité]

Je vois le jeu d'Oscar Toledo qui ressemble à un Ghost'n Goblins (j'ai pas le nom en tête la), le putain de scroll il est fluide, et la rom fait 256 ko. Je suppose que ses tiles sont préshifté, mais comment il les agence en mémoire pour que ça marche ?

Je pense qu'un scrolling pour commencer style un mur de brique serrait pas mal .
tu n'as besoin que de 1 ou 4 tiles (mur avec une tile 16x16), et tu le mets sur toute la largeur de ton écran pour simplifier .
Soit tu shiftes en temps réel toutes les tiles (1 ou 4) et tu remplaces en VRAM les actuelles par les nouvelles, ça va modifier toute ta map d'un coup, soit tu fais le même chose avec des preshiftées .
avec les briques juste un shift avec un ROL/tile (rotate left suffit) pour faire un pseudo scroll au pixel.
Avec des tiles simples tu peux avoir une grande surface de scroll, au détriment de la variéte, le tout est de trouver le juste milieu.

Un scroll comme celui de princess quest est le même principe en juste un peu plus complexe, mais je suppose qu'il ne shifte pas tout l'écran à chaque fois .

Et si j'ai bien compris, la coleco ne peut que transférer en VRAM pendant le vblank non ??
Donc ça limite d'autant les possibilités, car je suppose que c'est le CPU qui doit transférer, donc le C doit limiter encore plus .

Après tu as encore plus simple, limiter ton scroll à 8 pixels, mais là je pense que tu sais déjà faire .

[bfg]

Au fait msieurs, tu penses à moi steup ?   (cf mon mail).

Mais j'ai répondu le 22 si tu parles de l'émulateur

[/quote]

Vi mais tu me l'as pas envoyé

[youki]

Ce qui est vraiment limitant sur la Coleco pour les scrolls (enfin du moins pour moi)  c'est la RAM.  Il n'y aurait ne serait ce que 4k de RAM ca changerai la vie plutot que ces ridicules 1 k.

Heu..sinon pour le MSX , je plaisantais biensur... ce qui est moche c'est le CPC.


bon sinon donc c'est un jeu de plateforme avec Scrolling?

[bfg]

Je vois le jeu d'Oscar Toledo qui ressemble à un Ghost'n Goblins (j'ai pas le nom en tête la), le putain de scroll il est fluide, et la rom fait 256 ko. Je suppose que ses tiles sont préshifté, mais comment il les agence en mémoire pour que ça marche ?

Je pense qu'un scrolling pour commencer style un mur de brique serrait pas mal .
tu n'as besoin que de 1 ou 4 tiles (mur avec une tile 16x16), et tu le mets sur toute la largeur de ton écran pour simplifier .
Soit tu shiftes en temps réel toutes les tiles (1 ou 4) et tu remplaces en VRAM les actuelles par les nouvelles, ça va modifier toute ta map d'un coup, soit tu fais le même chose avec des preshiftées .
avec les briques juste un shift avec un ROL/tile (rotate left suffit) pour faire un pseudo scroll au pixel.
Avec des tiles simples tu peux avoir une grande surface de scroll, au détriment de la variéte, le tout est de trouver le juste milieu.

Un scroll comme celui de princess quest est le même principe en juste un peu plus complexe, mais je suppose qu'il ne shifte pas tout l'écran à chaque fois .

Et si j'ai bien compris, la coleco ne peut que transférer en VRAM pendant le vblank non ??
Donc ça limite d'autant les possibilités, car je suppose que c'est le CPU qui doit transférer, donc le C doit limiter encore plus .

Après tu as encore plus simple, limiter ton scroll à 8 pixels, mais là je pense que tu sais déjà faire .

Ca ça va :) J'arrive à la faire sans problème. Mais putain qu'est  que ça bouffe de la ram !! Et c'est facile pour répéter un pattern.

Mais dans le cas de princess quest, c'est pas un pattern qui est répété ! Dans le cas de Moon patrol non plus.

Et même pour les scrolls à 8 pixels, si on fait une image fullscreen, il faut réussir à raffraichir 768 octets.
En sachant qu'en C, on en à que 700 de libres avec le kit de dev ... Et si on fait en plusieurs fois, ben c'est pas génial coté proco graphique, il est rapide sur une grosse mise à jour, mais plusieurs petites, c'est pas génial ...

Bref je suis une merde sur le sujet

[youki]

Avec plus de 32k ,   128k pour Princess Quest, ca facilite bien les choses.

[Invité]

Et même pour les scrolls à 8 pixels, si on fait une image fullscreen, il faut réussir à raffraichir 768 octets.
En sachant qu'en C, on en à que 700 de libres avec le kit de dev ... Et si on fait en plusieurs fois, ben c'est pas génial coté proco graphique, il est rapide sur une grosse mise à jour, mais plusieurs petites, c'est pas génial ...

Dans ce cas là, je pense que de modifier directement la map en VRAM est plus rapide, surtout pour du scroll à la tile .

Pour ce que j'ai vu de moon patrol, c'est comme avec le mur, une animation cyclique (au moins pour les montagnes,et le scroll du bas),les trous fait par les bombes ce sont des sprites, je pense que le scroll n'a rien à voir avec celui de princess quest .

[youki]

Le Pb sur coleco (et Msx) , c'est que les access VRAM sont super lent.  Alors modifier la map dans la VRAM c'est pas top du tout.

En effet moon patrol c'est un pas un "vrai" scroll.  C'est un peu comme mon Battle of Hoth , en plus lent.

[Invité]

Le Pb sur coleco (et Msx) , c'est que les access VRAM sont super lent.  Alors modifier la map dans la VRAM c'est pas top du tout.

Ca revient au même que de le swap de tiles pourtant, peut être pas sur coleco ??

[drfloyd]

Heu..sinon pour le MSX , je plaisantais biensur... ce qui est moche c'est le CPC.

ouf, tu es passé près du ban à vie.

Pour le CPC, tu vas avoir des problemes avec un certain fan de la machine ici........

[Invité]

Heu..sinon pour le MSX , je plaisantais biensur... ce qui est moche c'est le CPC. 

En terme graphique heureusement que le CPC affiche des écrans plus beaux que le MSX, sinon on se serait cru sur C64  

[drfloyd]

c'est quand meme dingue que pour uen console revotionnaire haut de gamme et chere ils n'aient mis que 1ko de RAM...

Okok, on est en 1982, ca coute tres cher... mais quand meme bordel...

4ko aurait été parfait pour les développeurs.

[Fabf]

De ce que j'ai vu, on peut monter jusqu'à 8ko sans grosse modif, par contre à l'époque 8ko en SRAM ça devait couter un bras.

[TotOOntHeMooN]

c'est quand meme dingue que pour une console revotionnaire haut de gamme et chere ils n'aient mis que 1ko de RAM...

La Coleco peut gérer 8Ko linéaire sur la plage d'adresse de la RAM.
Je pense qu'elle devait-être équipée de 8K donc... Mais, je rigole hein, un type aux achats a du se croire plus malin que tout le monde et a du commander "8Kb" au lieu de "8KB" car il avait un meilleur prix !
(je ris jaune, car des bourdes plus grosses sont déjà arrivées dans le passé)

Quoi qu'il en soit, sur une console, la RAM c'est juste utile pour stocker ce qui change. (stack, variables, buffers)
Tout le reste peut-être en ROM... Et comme il est possible de se servir de la VRAM, c'est au moins 4K de dispo pour stocker des données temporaires.

[drfloyd]

Serieux, c'est p'etre ca qui est arrivé... une confusion entre Kb et KB ??!!!

Ok c'etait cher mais on avait des micro 8 bit avec 16ko pas tres cher à la meme epoque.....

La Coleco avec 8ko, le fantasme de Bfg et Youki

[TotOOntHeMooN]

Je pense que la confusion fut possible oui.
Si mes souvenirs sont bons, elle est équipée de 8 puces de 1024x1bit au lieu de 8 puces de 1024x8bit.
(soit 8Kb et non 8KB)

[Invité]

LOL, ça serait énorme ça !!

[Fabf]

Si mes souvenirs sont bons, elle est équipée de 8 puces de 1024x1bit au lieu de 8 puces de 1024x8bit.
(soit 8Kb et non 8KB)

Non elle est équipée d'une SRAM 1ko pour la RAM et 8 chips DRAM pour la VRAM.

A l'époque les DRAM étaient bien moins chères que les SRAM ce qui explique que certains micros soient dotés de 16, 32 voir 64ko.

[drfloyd]

imaginez que ca soit une erreur.... effet papillon possible ou pas ?

avec 8ko la console propose des trucs de ouf et resiste au crash...Cartonne en 84 et 85 aux USA et en Europe, fait renoncer Nintendo à sortir la Famicom aux USA, Nintendo en reste au software et sort tous ses tubes sur la Coleco (Zelda, Super Mario Bros, Metroid....) et Coleco serait aujourd'hui à la place de Nintendo ????

[Fabf]

Je pense pas que ce soit une erreur d'achat, les PCB sont bien fais pour cette RAM.

Erreur de ma part il y a deux chips 1024ko x 4 bits.

[TotOOntHeMooN]

Dans tous les cas, c'était une erreur de ne pas mettre 8Ko. (matérielle ou marketing)
Car oui, la vie de la console aurait été tout autre sur le marché.

Pour avoir vérifier le schéma, c'est le VDP qui dispose de 8 chips de RAM et non la CPU... La RAM principale est composée de 2 puces de 512x4bit. (mais rien empèche d'avoir confondu 8KB avec 8Kb)

Enfin...

[drfloyd]

quand on pense que la Nes avait 2ko de RAM (mais avec la possibilité d'en mettre sur la cartouche en rab)

[Invité]

avec 8ko la console propose des trucs de ouf et resiste au crash..

LOL, Dans ton effet papillon tu oublies aussi le surcoût de la machine avec 8x plus de ram .
En 82 ça devait faire mal au fion, déjà qu'elle était pas donnée avec 1ko ..