Les sprites sous CybergraphX et Picasso

[ludovic_lyon]

ludovic_lyon

#4937

Bonjour,

J’arrive à afficher des sprites hardware et des VSprites sans PB avec le chipset natif AGA de manière OSFriendly (Getsprite(), Changesprite() etc …), mais si j’ouvre un écran et une fenêtre dans un mode CGX ou Picasso, les sprites ne s’affichent pas. Pourtant, avec le débuggueur, je vérifie bien que le sprite 2 ou 4 par exemple a bien été alloué avec GetSprite-).

D’où ma question : CGX et Picasso ne sont-ils capables de gérer qu’un seul sprite = celui de la souris ?

Merci.

LC

[henes]

henes

#84880

CGX ne gère que le pointeur souris, effectivement. Cela n’aurait que peu d’intérêt puisque la plupart (tous ?) des chipsets n’ont de toute façon rien d’autre.

Sinon, il faudrait émuler des sprites hardware par logiciel… ce que CGX ne fait pas.

Aucune idée pour P96.

[Kamelito_L]

Kamelito_L

#84881

Quand on parle de sprite on galvaude souvent le terme, un sprite est un élément graphique généré par le hardware Amiga ou C64 ou Atari 800 etc…Le chipset video affiche les sprites tout en ne modifiant pas le background, ainsi on peut déplacer un sprite de toute forme sans avoir à se soucier des éléments présents à l’écran. Par contre quand on utilise une carte graphique il ne s’agit plus de sprite mais d’éléments graphiques qui doivent préserver le background appliquer des masques pour les éléments ayant des formes non carrés, et ce à chaque déplacement de l’élément graphique. Comme avec le blitter de l’Amiga qui est plus puissant mais plus contraignant que les sprites mais ces derniers sont limités en couleurs en taillle et en nombre.

Le mieux serait donc d’utiliser les bobs. (cf graphics library)

Kamelito

[Nagamé]

Nagamé

#84882

Juste un mot en passant

J’ai pas mal codé sur les consoles Snes, GameBoy et surtout la GameBoyAdvance (en amateur, bien sûr). Et j’ai rarement vu un système aussi évolué dans la gestion hardware des sprites. J’ai peu codé sur AGA (et il ya longtemps) mais les consoles de big N sont vraiment bluffante.

Un boulot dans j’était fier (sur Gba) était d’utiliser des sprites (permettant d’économiser de la mémoire vidéo au passage) mais de les redessiner en temps réel direct in memory. En résultat les avantages du point par point additionnant les avantages du mode sprite (hard cablé). Les jeux commerciaux ne se prennent jamais la tête : 3D -> point par point, 2D -> Sprites. Résultat des hardwares souvent sous-exploité.

Ca m’améne a une question, pourquoi des routines c2p/p2c étaient utilisé sur Amiga ? Pourquoi les pixels (d’un sprite) n’étaient pas modifié dans la mémoire directement (en suivant l’encodage du sprite bien entendu affiché bien sûr) ?

Amicalement,

Amiga 4000/60 desktop - 128Mo - Cyberstorm MkII avec module SCSI - Cybervision 64 - Xsurf - Subway USB

[SpiK3r]

SpiK3r

#84883

Faudrais une mise à jour de CGX pour que tout puisse être géré.

même passer les fenêtres en dehors de l’écran CGX ne sais pas le faire, alors qu’il faudrais le faire au lieu d’utiliser PowerWindows.

L'Amiga c'est plus fort que toi !

[mrodfr]

mrodfr

#84884

salut,

le mode planar contre chunky a donne des routines c2p.

Amiga affiche par plans (bitmaps) et pour faire des dooms, il fallait du point par point (chunky) d’ou les routines c2p. comme le miga a du mal a cause de la conversion a faire du doom et avec son petit processeur et que le doom a eu du succes sur PC, les jeux ont eu du succes sur PC.

sprites (2d) et point par point chunky (3d).

cote miga, l’absence de carte gfx par defaut a fini par degrader l’embiance.

cela dit, il y a des jeux tres colores qui utilisent la carte GFX et qui donnent de bon resultats, meme en amiblitz basic, comme les jeux de thilo kholer.

http://www.hd-rec.de/HD-Rec/home.html rubrique other stuff: artkanoid par exemple, qui ouvre une fenetre sur le WB en P96 et le jeu fonctionne.

C’est possible de le faire (Pas en sprite sur CGX ou p96) mais par d’autres moyens de code qui fonctionne sur Carte GFX avec P96 ou CGX.

changeIt 0.2 sur aminet. Marche sur P96 (une fenetre sur le WB).

je m’egare dans ma reponse mais c’est possible sans passer par le sprite sur CGX ou P96. J(ai jamais code mais je le constate par des exemples deja vu au fil de temps

[ludovic_lyon]

ludovic_lyon

#84885

Merci pour vos infos !

LC

[Kamelito_L]

Kamelito_L

#84886

Comme dit le C2P c’est pour la 3D les sprites c de la 2D.

Sur Amiga les sprites étaient modifiés dynamiquement via des copperlist ce qui a donné par exemple des playfield en sprite qui permettait sur Amiga d’avoir un premier plan en 32 couleurs et un second en 4. Par exemple sur Apydia, et Risky Woods. Jim Power modifié aussi dynamiquement les sprites en mémoire avec une grosse copperlist en utilisant le 68000 ce qui permettait d’avoir des scrolling de playfield en sprite et permettait à l’Amiga d’avoir plus de couleurs que le 2×8 que permet le mode dual playfied.

Kamelito

[ACE]

ACE

#84887

quand je vous ecoute ca me rappelle la belle epoque que de nostalgie

Le PSG qui gagne la ligue des champions c'est possible ... Que dans Swos.
Amiga Morphos Rules.

[leo]

leo

#84888

Si tu veux faire des trucs pas trop évolulés, tu peux utiliser BltBitmap() (de mémoire c’est ca). Ainsi ca fonctionnera aussi bien sur AGA que sur CGX/P96…

@+,

Léo.

[Nagamé]

Nagamé

#84889

Haaaaaa ! les boules : j’ai passé 5/10 minutes à écrire une longue réponse. Et vlan il m’a renvoyé « vous n’êtes pas connecté » (session perdu).

@Kamelito_L : Je disais donc que je comprennais pas tout. Trop de mots spécifique amiga (ou trop hard) pour moi. L’exemple dont je parlais plus haut est « défi de noel » qui tourne en mode « sprite ».

Grosso modo, la GBA permet 2 catégories de mode :

– le mode bitmap avec 1 seul plan 240*160*256coul point barre. Toute la mémoire vidéo a été utilisé.

– le mode « sprite » avec 2 backgrounds et plein de sprite. La limite étant la mémoire vidéo : les sprites et backgrounds sont composés de « tile » (bloc de 8*. Dernier avantage du mode, il permet des « effets » cablé.

Dans le cas de mon raycaster, il y a le 1er background avec 2 tiles (le fond), le 2eme avec le raycaster (mur+enemies) et le reste en sprite (arme, cadre, niveau de vie). Il y a de nombreux avantages a travailler en mode « sprite » : par ex, je met un fligue enorme en 1*1 et surtout je libére du CPU pour qu’il se concentre sur le moteur.

Au final le seul raycaster en 1*1 de la GBA, TOUS les autres sont en 2*1 et… en mode bitmap (amateur et commerciaux). Pour avoir passé des soirées a tester toutes les combinaisons possible, il est quasi impossible de faire un raycaster en 1*1 en mode bitmap.

Il est dommage de se buter sur le shéma « sprite->2D, bitmap->3D » sur les machines qui n’ont pas été concu pour le bitmap.

Redessiner des sprites à la vbl n’est pas trés compliqué, il suffit de connaître les adresses mémoires et comprendre l’organisation de la dite mémoire.

J’ai donc toujours été étonné de voir les routines de conversion sur Amiga :sweat: Mais il y a surement une bonne raison…

Amiga 4000/60 desktop - 128Mo - Cyberstorm MkII avec module SCSI - Cybervision 64 - Xsurf - Subway USB

[mrodfr]

mrodfr

#84890

salut,

J’ai donc toujours été étonné de voir les routines de conversion sur Amiga Mais il y a surement une bonne raison…

Va savoir, il y a une chronologie en annees. les consoles sont apparu apres le miga mort. de bonnes idees cotés programmation consoles (ou parties d’idees) sont peut etre a prendre et a utiliser coté miga AGA ou P96/CGX (mais bon, je ne suis pas calé dans ce domaine maleureusement).

le code amiga jeux a tj été une copie d’un précurseur, jimpower a été un exemple d’innovation, certaine demos aussi (le souvenir d’une avec des niveaux tres colores qui bougent les uns des autres, lointain souvenir,…).

[leo]

leo

#84891

Haaaaaa ! les boules : j’ai passé 5/10 minutes à écrire une longue réponse. Et vlan il m’a renvoyé « vous n’êtes pas connecté » (session perdu).

En pressant « back » tu peux pas retrouver ton texte ?

Vive Opera, je vous le dis moi

Sinon, content de voir que mon post t’as été inutile

Si je comprend bien, tu penses en gros faire de la 3D, et dessiner ton « écran » à l’aide de sprites ? Et tu te demandes pourquoi ils ne faisaient pas comme ca à l’époque ?

[henes]

henes

#84892

@nagame

J’ai tout oublié mais l’amiga n’a qu’une poignée de sprites (8 ?) et ceux ci n’ont que très peu de couleurs (8 en OCS, 16 avec l’AGA ?). Ils peuvent être aussi hauts que voulu mais sont extrèmement limités en largeur (complètement oublié les chiffres là…) et celle-ci diminue lorsque le « fetchmode » augmente (bidouille de Commodore pour faire croire que l’AGA est plus rapide que l’OCS).

Enfin l’image affichée par ces sprites est elle aussi en planar. Ce qui complique leur utilisation pour de la 3D ou du raycasting.

Bref, pas trop comparable avec la GBA

Mais certains jeux utilisent les sprites pour faire d’autres plans d’affichage (parfois en réutilisant un même sprite sur la même ligne, ce qui n’était pas prévu à la base). Jim Power par exemple.

Ca fait longtemps que je n’ai plus touché à ces horreurs (ou trucs géniaux, au choix) donc complétez ou corrigez moi si j’ai fait des bourdes. Merci

[Kamelito_L]

Kamelito_L

#84893

L’Amiga a aussi un mode 2 écrans en 2×8 couleurs pour l’OCS/ECS (chipsets) et 2×16 je crois pour l’AGA.

Par contre tu n’as que 8 sprites de longueurs illimitées. En largeur tu n’as que 16 pîxels en OCS/ECS et 64 pixels en AGA avec 4 couleurs pour chaque sprite. Ce qui fait au maximum 128 pixels pour « bitmap » sprite et 512 en Aga ce qui est bien.

Kamelito