Pixel art sur Amiga NG
-
Pour grafx2; vlà les requirements dans la doc de compilation des sources (celles que j’ai utilisé pour faire ma version linux)
=== Requirements ===
* gcc C compiler (other compilers may work, but are not officially supported)
* GNU make (other similar “make” tools may work, but are not supported) * SDL library v1.2 * SDL_image library * libpng (not on MacOSX)
* FreeType library (optional, for truetype fonts)
* SDL_ttf library (optional, for truetype fonts)
* Lua library v5.1 (optional, for Lua scripting)
Extra requirements for Windows:
* a POSIX environment: MSYS is fine, maybe Cygwin would work as well.
* use Mingw C compiler instead of gcc
Extra requirements for UNIX/X11 (Linux, FreeBSD, …):
* pkg-config (optional, for Lua scripting)
* X11 headers (optional, for truetype fonts)
Pour Gribouills Pixel Art Edition (
) ça serait super !!!Les trucs de base de chez base qu’il faut :
Un crayon, avec si possible une gestion bouton gauche=couleur principale, bouton droit=couleur secondaire
Un travail en pixel “dur” (pas de pression, antialias, ou autre)
Un rendu vrai taille du pixel (un pixel écran = un pixel dans le logiciel)
Une sauvegarde dans un mode non destructif (gif, png)
Des outils géométriques de base, sans antialising, pixel “dur” également : élipse, rectangle, ligne droite (ligne courbe type bézier, c’est pas mal non plus).
Une grille ajustable, configurable et affichable.
un UNDO-REDO réglable
Une taille de projet configurable à loisirs (pouvoir travailler au format final dés le départ)
Un aperçu taille réel avec en meme temps un aperçu loupe (configurable)
Une palette configurable, pour travailler en couleurs indexées.
La possibilitée de créer ses propres palettes (avec une option comme sur personal paint, ou on choisit deux couleurs, et on crée un gradient entre les deux, sur un nombre x de palliers…Dpaint et grafx2 doivent l’avoir aussi)
Fond transparent (pour utilisation émoticon, favicon, icone ou sprite)
Les trucs optionnels :
les calques (avec toujours une sauvegarde non destructive du projet…Certains diront que c’est plus du pixel art, moi je dis que ça permet surtout de travailler depuis un modele couleur, par exemple, ça permet aussi de faire des fenetres, lacs, etc…plus facilement)
des guides (oui pourquoi pas!)
la transparence
la création de patterns/tile
l’animation, avec mode “oignon”
C’est tout ce qui me vient à l’esprit pour le moment. Si tu as linux (via Wine) ou windows qque part, ou sur mac OSX, tu peux tester :
graphic Gales (win)
Pro Motion (win)
Pixen 2 (mac)
Pour ce que j’en ai lut, Pro Motion est le “photoshop” du pixel art.
Ces logiciels de pixel art sont plus proches (à mon avis) de ton projet que Grafx2. A savoir une interface multifenetrée “à la photoshop” intégré à l’OS, là ou Grafx2 utilise un monofenetre plus typé DOS (meme si ça semble un eccueil au départ, en fait c’est hyper ergonomique, et ça permet quand meme de travailler en fenetré sur le bureau windows, aros, mac ou linux).
Ce sont des workstations completes également (anim, tiling, etc…) donc complexes aussi.
Voilà si ça peut t’aider…Merci en tout cas
sinisrus a écrit :
…donc qui peut le plus peut le moins…
Cool tu peut nous faire un portage os4 alors?
Bon ok je déconne mais j’aimerai bien quand même avoir tes projets sur mon amiga un jour peut être.
Sinisrus: je te laisse responsable de tes sous-entendus!
Sinon Python doit fonctionner sous Amiga, si ce dernier est équiper d’une carte accélératrice PPC et du système MorphOS pour les “classics”. Donc Gribouillis aussi.
Grafx2 compile pour MorphOS avec un simple make. Demether l’aurait vite vu s’il avait essayé
Il reste quelques chemins à adapter ensuite… comme souvent avec ces projets “portables” mais uniquement à des unix.
@demether: en y réfléchissant un peu, gérer une image en couleurs indexées n’est pas évident: si un effet est appliqué sur la brosse, il faut pour chaque pixel:
1) convertir l’index en couleur (RGB, ou autre)
2) opérer sur cette couleur l’effet
3) convertir la couleur en index avec la possibilité d’utiliser un “dithering”.
Avec des images en couleurs réelles on élimine les étapes 1 et 3… et la 3 est très gourmande en CPU.
Alors sur des petites surface ok, mais sur des grandes… hum!
Bon je dis pas cela impossible, mais ça c’est des routines très spécialisées qui demande du travail.
Si une personne possède cette connaissance, je l’attend
Grafx2 compile pour MorphOS avec un simple make. Demether l’aurait vite vu s’il avait essayé
J’ai essayé justement, c’est meme le premier truc que j’ai fait. Hop le shell, hop dans la bonne arborescence, et make. Résultat : Make : commande inconnue
Du coup j’ai essayé de récuperer des trucs sur aminet en rapport (meme nom ou approchant) avec les requirements, puis de les mettre ou je pensai qu’ils devaient aller (libs, c, etc…) : meme résultat.
Du coup j’ai sur les conseils de Papiosaur récupéré le SDK (enfin je crois) : aucune idée de quoi faire avec. Bref Yomgui a vu juste, je sais pas ou commencer et comment ça marche.
@yomgui : La soluce de facilité (si j’ai compris ton idée) serait de tout simplement interdire (griser) certaines features en mode pixel art.Jettes un oeil aux outils de dessin de grafx2 (ou des autres softs) : un crayon, un pot de peinture, un outil ellipse, un outil rectangle, un aerographe. Evidemment, ya qques outils “complexes” (sphere et gradient, sur grafx2) mais si tu regardes leur comportements, on est encore dans les teintes “dures” sans transition complexe.
Quand aux brosses en elles meme (paintbrush choice), tu verras (toujours dans grafx, mais c’est valable pour les autres) qu’on a la encore pas de trucs complexe genre transparence, alpha ou que sais je. C’est juste des formes différentes, toujours basé sur le pixel unique taille réelle écran.
Essayes un peu de jouer avec les softs sus nommés, tu verras que ça reste trés médiéval. Pas d’anticrenalage, pas d’alpha et compagnie. Et le meilleur, dans tout ça, c’est qu’en pixel art, on veut pas plus. Si tu rajoutes des features plus complexes, ça sera boudé car pas assez “rootz”
Les mecs qui font du pixel art sur toshop ou gimp, ou meme tvpaint, c’est pas compliqué ils débrayent toutes les aides, l’antialiasing, tous les trucs complexes, pour ne garder que le crayon 1px dur, la grille et la loupe. Je schématise, mais c’est le cas.
Une idée serait peut etre un “fork” dédié pixel art de ton soft, pour ne pas polluer ses futures évolutions ?
En tout cas les couleurs indexées, en pixel art c’est obligatoire. Si on parle bien de la meme chose. Pour moi c’est un objet (gif, png) qui est chargé avec un jeu de couleurs limité dépendant. Genre, mon avatar, une 20aine de couleurs (bon là j’ai triché j’ai utilisé une base de 256couleurs), je sauve l’image avec ses 20couleurs propres à lui.
On peut imaginer une palette indexée (au hasard, 32couleurs
) avec lesquelles le graphiste doit faire ses sprites, ses tiles, ses fonds, et son interface, en piochant uniquement dans ces couleurs. D’ailleurs sur les sites de pixel art, apparement c’est un challenge assez courant dans les concours internes (genre faire un truc thématique sur 16couleurs déterminées).
demether a écrit :
Du coup j’ai sur les conseils de Papiosaur récupéré le SDK (enfin je crois) : aucune idée de quoi faire avec. Bref Yomgui a vu juste, je sais pas ou commencer et comment ça marche.
Mh, j’ai un peu de mal à comprendre ce qui t’a perdu en cours de route…
Le SDK est à télécharger ici : http://www.morphos-team.net/downloads.html
Il s’agit d’une archive lha. On peut, au choix, soit double-cliquer dessus pour naviguer dedans (ça marche mais tous les accès seront plus ou moins lents), soit extraire son contenu avec un clique droit puis “Extract”.
L’archive contient donc un répertoire “morphossdk” qu’il suffit d’ouvrir pour voir une icone “Installer”… sur laquelle double-cliquer.
La suite est tellement évidente (cliquer sur le gros bouton en bas et attendre) que je te laisse découvrir
Ca, télécharger et installer le sdk, c’est bon j’ai sut faire… (comme je disai papiosaur m’avait déja filé le lien)
C’est aprés que je sais pas quoi faire. :sweat:
EDIT : AAHAAAAAAAAAAAAAAAAAAAAAA OK
Maintenant il faut repartir dans le shell et faire le make
En fait moi comme je voyai un utilitaire avec une GUI dans le repertoire devellopement, je pensai qu’on devait passer par ça…et du coup j’ai pas eu l’idée de retester le “make” sous shell…
:sweat: Bon je mentirai si je disai qu’avec ça :
Work:grafx2/src> make
mkdir -p ../obj/morphos
gcc -Wall -gstabs -c `sdl-config –cflags` -c main.c -o ../obj/morphos/main.o
/bin/sh: sdl-config: not found
main.c:39: SDL.h: No such file or directory
main.c:40: SDL_image.h: No such file or directory
main.c:45: SDL_syswm.h: No such file or directory
In file included from main.c:50:
global.h:32: SDL.h: No such file or directory
In file included from main.c:57:
loadsave.h:31: SDL_image.h: No such file or directory
In file included from main.c:58:
sdlscreen.h:31: SDL.h: No such file or directory
make: *** [../obj/morphos/main.o] Error 1
Work:grafx2/src>
Je suis plus avancé, hein
Enfin si j’ai capté que c’est un probleme de directories, mais…C’est parce que je tente la compile depuis work ?
Enfin bon c’est pas aussi simple que ça quand on sait pas :sweat:
Bin il faut maintenant installer le SDK des bibliothèques SDL de MorphOS (PowerSDL SDK sur Aminet).
Comme sur Linux où tu as réussi à compiler le bousin, en fait…
Ce n’est pas le genre de truc qui vient pré-installé avec l’OS
C’est pas non plus le genre de trucs auquel on pense naturellement quand on est un pov’ user de base
Je vais voir ça, merci pour les indications !
Oui tout à fait. D’ailleurs un utilisateur n’est pas un programmeur et ne devrait pas compiler des trucs si cela ne l’intéresse pas.
Mais du coup je ne comprend pas comment et pourquoi tu as pu le faire pour ta distribution Linux où ce n’est pas forcément beaucoup plus simple
- Vous devez être connecté pour répondre à ce sujet.
