Carte graphique Amiga classique

[Anonyme]

Anonyme

#9654

Bonjour à tous,

j’ai quelques interrogation en se qui concerne les cartes GFX disponibles sur nos Amiga classiques, voila, nous avons envie de créer des jeux pour ANG, mais est-ce que nos programmes fonctionnerait sur nos Amiga classiques?

Avec hollywood, il est dans l’obligation d’avoir un Amiga+carte GFX, hors, nous ne connaissons personnes qui a se type de matériels. Nous nous demandons la chose suivante, est-ce qu’un Amiga (de base)+Carte GFX peut exécuter et de façon plus que correcte nos programmes hollywood?

Nous sommes bien sûr obligé de passer par une résolution de 320×256 maxi afin de ne pas demander à nos 6800×0 trop de boulot car holly reste un langage assez lourd malgrès la multitude de combine (dont Andreas ne doit pas être au courant) pour optimiser les programmes, et j’en suis sur qu’il y en a plein puisque j’en ai trouvé beaucoup.

Il y a la carte graphiti mais est-ce que l’indivision seul peut aider? y-a t’il parmis vous des utilisateurs qui ont des Amiga 500 ou 1200 ou 4000 ou autres qui ont une carte graphiques? Qui serait prêt pour tester nos programmes et nous faire des retour de vitesse, jouabilité, autres?

On manque de donnée pour optimiser et ciblé les utilisateurs, se serait dommage de créer QUE des jeux NG alors qu’il serait possible de créer des jeux classique en modifiant que quelque lignes de codes pour que se soit jouable (voir même plus) sur nos classiques.

En plus, c’est un formidable challenge de faire tourné des jeux créer avec hollywood (qui je le rappel à un moteur de rendu assez lourd) pour des amiga originel dans un esprit d’optimisation.

Qui pourrait m’éclairer sur les cartes GFX amiga (compatibilité avec hollywood)?

Qui pourrait tester les programmes que l’on créer et qui ont un amiga classique+carte GFX?

Merci de votre aide

[Xanxi]

Xanxi

#148556

Actuellement, j’ai mon 4000 avec 68040 + Cybervision 64/3D, mais je dois le réparer suite à un problème d’alimentation.

Tu peux m’envoyer tes programmes à tester.

J’ai aussi une GVP Spectrum dans mon 2000 et une Pixel64 dans mon A1200T Ateo, mais ces deux là sont pour le moment démontés.

Par contre je n’utilise que Picasso96 et pas cyberGraphx.

100% Amiga Classic
BOING!!!!

[Tarzin]

Tarzin

#148557

une Pixel64 dans mon A1200T Ateo, mais ces deux là sont pour le moment démontés

C’est dans ce cadre là, qu’Hollywood semblait montrer des faiblesse. La lecture d’un JPG ou PNG étant une catastrophe

Solutions:

– problème de datatype ?

– passer sur de l’IFF à la place

mais nous avons besoin de confirmations

[JiDeWe]

JiDeWe

#148558

j’ai ça:)

4060 cv64

mais ne soit par trop pressé j’ai du taf avec le bateau en ce moment……..

1 A500 2mo, 1 A500 512ko +ACA500+, 1 A 1200 quasi neuf, 1 Atari 520Ste 4mo + UltraSatan dual, 1 Falcon030 avec DFB1X , 1 MSX2 8235 avec Carnivore2, 1 MSX28250 (fmstéréopack, music mode, MegaFlashRom et quelques D7 et KTouche ).
maxime perpétuelle : si je cours en zigzag ce n'est pas pour éviter le balles, mais les c..s, et si un cachalot vient sur ton babord, il est prioritaire, sur tribord aussi... (B.M.)

[Anonyme]

Anonyme

#148559

@Xanxi et Jidewe:

Ok, on vous enverra nos prg pour test 680×0+Cgfx, par contre, il me faudrait vos email ou je puisse envoyer nos prg, vous pouvez me les transmettre via MP

@Tarzin:

Je pense comme toi, a mon avis, pour les version 680×0 (et même NG) il faut passer exclusivement par le format d’image IFF, je pense que le jpg ou autre format, sont des format trop lourds à décompresser et le problème est le suivant, est-ce que holly décompresse 1 fois le fichier d’image et le garde en mémoire ou (et je pense plus a sa du fait de la lenteur du moteur) il décompresse l’image à chaque appel de celle ci?!

Après, est-ce que le format IFF EST le format d’image le plus rapide?! j’en sais rien, seul les gars calé en programmation et pas des bidouilleurs comme nous le savent, idem pour le son, le mp3? est-il décompresser avant ou en temps réels? vaut mieux garder le format son .mod ou AIFF ou IFF, sa prend de la place, mais au moins, sa ne demande pas plus de travail au CPU, ne pas oubier que si on perd du temps CPU sur le son et les graphes tous sa à cause de format compressé avec des algo de décompression complexe et lourd ralentira considérablement nos jeux et prg alors que si on gagne des cycles CPU, on pourrait ajouté des effets supplémentaire voir même un format d’écran plus grand.

Qui peut renseigner?

Merci de vos infos, sa aidera à faire des petits jeux sympa pour la communauté.

[CrashMidnick]

CrashMidnick

#148560

Je peux également tester sur mon 2060 + PIV + Toccata ou 4040 + PII

Pour mon email, cf profil.

A++

"But who needs a Megadrive when you have got a smart Amiga!" - 1993, Alien Breed 2 -

[Catmil]

Catmil

#148561

Je vais peut-être vous parraître ignare mais c’est quoi « hollywood » en quelques mots ?

J’ai une CV64/3D sur 4060 et je peux éventuellement faire aussi des essais, si ça peut vous aider. Je suis sur WB3.1, c’est suffisant ?

AGA only : 1200 4000

[Anonyme]

Anonyme

#148562

@Catmil:

Hollywood est un langage de programmation orienté multimédia, multiplateforme, et objet.

Il y a des similitudes avec le monde de windows, hollywood designer est en gros un powerpoint et hollywood (le langage) serait le visual basic pour hollywood designer.

Un adepte d’Amos/Amos Pro ou un ancien programmeur des langages cités avant, ne se sentirait, mais alors, pas du tout largué par se langage, il est simple, facile à mettre en oeuvre.

Le point noir d’hollywood reste le moteur de rendu 2D qui reste assez lourd, mais j’ai plein de combine pour accélérer les scripts.

Hollywood est extrêment simple et contient plus de 400 commandes (gfx/sfx/dos/table/etc…). Il est très proche du langage LUA de base, LUA qui est utilisé pour de nombreux programme comme le menu de starcraft2 ou comme langage de base de la PS portable pour programmeur du dimanche.

L’intérêt ++ de se langage est sa portabilité, le script créé peut être compilé pour Morphos, AmigaOS 4.x, Amiga classique + Carte GFX, Windows, Warp3D, MacOS, et plein d’autres comme linux (le dernier en date).

Peux cher et efficace, il est très vite exploitable et permet rapidement de créer des petits programmes sympathique.

Personnelllement, j’essai d’exploiter à fond se langage en essayant de contourner ses défauts comme la plupart des langages de programmation orienté objet qui ne permette pas de taper dans le hardware car très dépendant de l’optimisation des librairies ou autres.

Un script pour un scroll ne prend que quelques lignes, un script pour un jeu idem, voir mon script pour un casse briques, et encore, il est facilement optimisable.

Hollywood est un peux l’Amos des NG, malheureusement sans la puissance d’Amos qui était bien plus optimisé.

voici un script pour le casse brique, code source de base en basic loco, tiré du bouquin de l’amstrad, le programme original se nommé « BUSTOUT »

@VERSION 4,0

@DISPLAY{WIDTH=320,HEIGHT=256}

CreateBrush(1,8,8,#GREEN)

CreateBrush(2,4,4,#RED)

CreateBrush(3,40,8,#BLUE)

CreateBrush(4,2,2,#WHITE)

CreateBrush(5,40,2,#WHITE)

CreateBrush(6,1,8,#WHITE)

CreateBrush(7,8,1,#WHITE)

MixBrush(1,6,128)

MixBrush(1,7,128)

MixBrush(2,4,128)

MixBrush(3,5,128)

Local XBarre=0

Local XBall=0

Local YBall=128

Local Vie=3

Local Score=0

Local XSens=1

Local YSens=-1

Local Renvoie=False

Local Casse=False

/*Attention, Tableau, le premier chiffre est la coordonnée X des briques*/

/*Le Deuxième Chiffre ET le Numéro de Brush, 1 étant la Brush Brique*/

LIGNE={}

LIGNE={0,1,8,1,16,1,24,1,32,1,40,1,48,1,56,1,64,1,72,1,80,1,88,1,96,1,104,1,112,1,

120,1,128,1,136,1,144,1,152,1,160,1,168,1,176,1,184,1,192,1,200,1,208,1,216,1,224,

1,232,1,240,1,248,1,256,1,264,1,272,1,280,1,288,1,296,1,304,1,312,1,320,1}

Function Ball()

XBall=XBall+XSens

YBall=Yball+YSens

If XBall=312 Then XSens=-1

If XBall=0 Then XSens=1

If YBall=10 Then YSens=1

Renvoie=Collision(#BRUSH,3,XBarre,248,2,XBall,YBall)

For x=1 To 81 Step 2

If ligne[x]<>1 Then ligne[x-1]=-50

Casse=Collision(#BRUSH,2,XBall,yball,1,Ligne[x-1],20)

If Casse=True

Ysens=1

Ligne[x]=4

Score=Score+10

EndIf

Next

If Renvoie=True Then Ysens=-1

If YBall=256

Ysens=-1

Vie=Vie-1

EndIf

DisplayBrush(2,XBall,Yball)

EndFunction

Function Ecran()

For x=1 To 81 Step 2

DisplayBrush(Ligne[x],Ligne[x-1],20)

Next

TextOut(0,0,"Score : ")

TextOut(80,0,Score)

TextOut(260,0,"Vie : ")

TextOut(310,0,Vie)

EndFunction

Function Player()

Flip

Cls

Ball()

Ecran()

XBarre=MouseX()

If XBarre<0 Then XBarre=0

If XBarre>280 Then XBarre=280

DisplayBrush(3,XBarre,250)

EndFunction

SetInterval (1,Player,20)

BeginDoubleBuffer

Repeat

WaitEvent

Until Vie=0

Si tu veux plus d’infos sur se langage, contact moi ou tarzin, les 2 seuls frenchie, pour le moment, à essayer d’exploiter se langage

[henes]

henes

#148563

L’Indivision ne peut rien accélèrer ou ralentir puisqu’il s’agit d’un dispositif externe.

L’IFF ILBM conserve les données en planar et ne peut donc en aucune façon être le format le plus approprié à une carte graphique fonctionnant en RGB et/ou chunky.

De plus, quelque soit le format utilisé, il y aura touours conversion puisque chaque carte peut offrir des formats de pixel différents de ses congénères (RGB16, BGR16, BGR15, ARGB32, etc).

Mais, pour un programme bien conçu, cela ne doit pas avoir beaucoup d’importance puisque chaque image ne doit être chargée et convertie au format approprié qu’un unique fois au lancement. Ou à chaque changement de niveau. En tout cas, pas pendant le jeu

Au final, mon conseil serait donc plutôt de demander à l’auteur d’Hollywood comment réussir à ne faire charger et convertir cette image qu’une seule et unique fois.

Cela dit, l’ILBM a pour lui l’avantage de donner des petits fichiers lorsqu’on se limite à un faible nombre de couleurs. Ce qui peut lui permettre d’être chargé plus vite sur 68k.

[Anonyme]

Anonyme

#148564

@Henes:

On est mal barré quoi… mais avant la conversion, il y a la décompression de l’image (je pense), donc on peut gagner du temps que sur la décompression car la conversion se fait via la carte graphique tandis que la décompression se fait via le CPU (je croit, mais alors, pas sur du tout).

On recherche le format d’image ayant le moins décompression possible, pour gagner du temps CPU (par la décompression) et ainsi gagner quelque cycle pour le jeux et pas pour décompresser.

Dommage pour l’indivision (fais chier même) :sweat:

[henes]

henes

#148565

Non, tout est toujours fait au CPU. Sauf dans le cas de la CV64 et de son chip « Roxxler » qui s’occupe des conversions planar -> chunky ou quelque chose du genre.

Tu as par contre raison pour la décompression (que j’incluais dans le chagement). Mais les accès disque de certaines (la plupart ?) machines 68k étant tellement lents, il faut tout de même vérifier si la taille du fichier ne peut pas permettre de gagner/perdre encore plus de temps…

[Anonyme]

Anonyme

#148566

@Henes:

Sa m’a l’air bien plus compliqué que je ne le pensé… Bon, Hollywood, charge 1 seul fois le fichier image et le sauvegarde de suite en mémoire (sa c’est sur), donc les accès dsk (désolé lol) ne sont pas très important… remarque que si le jeu met 3 heures à se charger, sa devient vite chiant. bon, passons sa, je verrai en fonction des retours que j’ai pour les versions 680×0+carte GFX.

Je vais demander a andreas comment se comporte hollywood avec sa, mais comment en être sûr?! y’a pas un programme ou un code générique qui permet de tester sa, car malheureusement (pour moi) j’ai très peux confiance aux concepteur des outils que j’utilise et j’aimerai vérifier par moi même.

Remarque que « normalement », si il y a vraiment décompression à l’utilisation de l’image, je devrais le voir par l’intermédiaire de mon moteur de test (en FPS) car si je prend le même script et que j’utilise du Jpg, Png, IFF, ou autres, je devrais voir une différence du fait de la sois disant perte de temps du CPU.

En gros, il faut que je créai un moteur 2D basique, que je charge une même image (résolution/profondeur de couleur/Nbre de couleur) dans la plupart des formats existant et exploitable, que je joue avec se format pendant X temps pour ensuite passé au format suivant et ainsi de suite. La je verrai si il y a des différences. Si il y en a pas, on peut donc considéré que le fichier image est décompressé en mémoire avant son utilisation, par contre, pour le MP3, sa m’étonnerai, je pense que pour la musique, on doit essayer de garder le format Mod. ou .mod qui demande à mon avis moins de ressources, on peut faire du direct to disk, mais comme tu le dis avant, les accès dsk sur 680×0 sont trop lent…

[ANTEK]

ANTEK

#148567

et dans vos amiga classics, vous incluez des configs comme la mienne?

A1200 avec carte PPC + CV PPC (chipset permedia 2), ou alors une voodoo 3 3000 monté sur bus ELBOX?

PS: je sais meme pas ce qu’est Hollywood en fait

[Anonyme]

Anonyme

#148568

@ANTEK: Oui, sa compte… pour hollywood, voir plus haut, je décrit un peux se langage de programmation

[davebraco]

davebraco

#148569

Sans vouloir être médisant, au niveau des jeux avec Hollywood, ne vaudrait-il pas mieux laisser tomber le 68k?

(As tu fait tester supercars sur un 68K?)

EDIT:

Ou alors ce genre de jeu qui bouge pas des masses (pierre, papier, ciseaux)

http://www.os4depot.net/share/game/board/bedgames1.lha