Day.png);">
Apprendre


Vous êtes
nouveau sur
Oniromancie?

Visite guidée
du site


Découvrir
RPG Maker


Apprendre
RPG Maker

Tutoriels
Guides
Making-of

Dans le
Forum

Section Entraide

Jeux: puie z / Jeux: Citymaime - Chapitre 1 / Jeux: Mer, îles et fous / News: Du neuf dans le making / News: Muma|Rope est disponible en (...) / Chat

Bienvenue
visiteur !




publicité RPG Maker!

Statistiques

Liste des
membres


Contact

Mentions légales

338 connectés actuellement

30735589 visiteurs
depuis l'ouverture

2554 visiteurs
aujourd'hui



Barre de séparation

Partenaires

Indiexpo

Akademiya RPG Maker

Blog Alioune Fall

Fairy Tail Constellations

ConsoleFun

RPG Maker - La Communauté

Le Comptoir Du clickeur

Lunae - le bazar d'Emz0

Tous nos partenaires

Devenir
partenaire



Blog de Monos

7 publications

Aller à la page 1


Monos - posté le 03/01/2023 à 06:50:42 (57322 messages postés)

❤ 2

Vive le homebrew

image
Mes consoles à moi

Introduction
La PVSNESlib est une bibliothèque de fonction et d'outil pour créer des jeux sur la fameuse Super Nintendo.
Elle est réalisé par mon ami Alekmaul.

Cette lib permet de coder dans le langage c. (Très utilisé sur les machines retro) et bien sur en Assembleur.
Elle comprend des outils comme un compilateur C, un logiciel de conversion d'image, des outils pour utiliser tiles pour faire ses map.

Cette lib peut être utilisé sur Windows et Linux. (Je pense aussi sur mac en recompilant tout les outils.)

Le Github pour récupérer la lib.
La documentation




Mes Videos Tuto
Je suis en train de faire des vidéos tuto sur la SNES.


Installation de la lib

C'est pas très compliqué mais il y a une paire de dépendance. (Python , MSYS et des variables d'environnement à toucher ce qui peut être compliqué pour les gens qui n'ont pas l'habitude. Souvent l'installation merde à cause de Python)


Le Vram
Dans une machine retro le plus important c'est de comprendre comment fonctionne la Vram.
Ou se stock les graphismes, l'organisation de l'écran, les sprites. La snes fait intervenir des "pointeurs" pour cibler des parties de la vram. Au début c'est pas facile à comprendre.


Sprites
Et oui, la snes permet d'afficher 128 sprites !


Le pad
Petite vidéo sur une utilisation très simple du pad de la snes.
LA snes peut gérer 5 pads. C'est vraiment sympathique.


Convertir les images en data pour la snes !


Utilisation de Vmain pour bien envoyer des datas en Vram !!!


Priorité des tiles/background

* ------------------------------------------------------------------------------------------*
Des infos technique de la snes qui va évoluer en fonction de mes connaissances
* ------------------------------------------------------------------------------------------*

La Super Nes ou snes ou Super Famicom
- La machine débarque fin 1990 au japon, elle remplace la nes.
- Elle possède un processeur 8/16bits (si si) cadancé à 3.58 en mode maximum.
- Elle possède deux puces graphique. Le PPU1 qui gère les tiles et sprites et PPU2 pour la palette de couleur et le signale Video.

La résolution de la console est de 256x224 px à 512*448pixel. (en fonction du mode vidéo)
La machine possède 128 ko de Ram de travaille (contre 64ko pour la Megadrive, 2ko pour la nes et 8ko pour la master system et Pc Engine).
La machine possède 64ko de video Ram. (Identique à la Megadrive). Pour information (encore ?) la master system dispose 16ko en Vram et 2ko est disponible pour la nes(mais la nes n'a pas besoin de mémoriser ses paterne de tiles en VRAM elle sont mémoriser en dur dans une puce(la CHR))
La VRAM permet de mémoriser les tilemaps et les paternes graphiques.

La capacité maximum d'une cartouche est de 4Mo sans bank switching.(c.a.d sans echanger une partie de ram cartouche par une autre.)

La snes permet de gérer 128 sprites à l'écran elle possède sa propre mémoire pour mémoriser les informations du sprite à afficher. (Seul les paterns des sprites sont memoriser dans la Vram les donnés / position d'un sprites à sa propre mémoire pour faire simple).

Les modes Video
La Snes possède plusieurs mode d'affichage. La puce graphique est une des plus puissantes de sa génération. (Avis personnelle) Elle surplante celle de la megadrive. (Mais la megadrive à un meilleur CPU !!!)

La SNES possède 8 modes video.

- Le Mode 0 : permet d'avoir 4 background. Chaque background est en mode 4 couleurs.
- Le Mode 1 : Permet d'avoir 3 background. Les 2 premier background est en mode 16 couleurs. Le 3em est en mode 4 couleurs. (Mode la plus utilisé dans la snes ?)
- Le Mode 2 : Permet d'avoir deux background de 16 couleurs.
- Le mode 3 : Permet d'avoir le premier background en 256 couleurs et le 2em background en 16 couleurs.
- Le mode 4 : Permet d'avoir le premier background en 256 couleurs et le 2em background en 4 couleurs.
- Le mode 5 : Permet d'avoir le premier background en 16 couleurs et le 2em background en 4 couleurs.
- Le mode 6 : Permet d'avoir un seul background en 16 couleurs
- Le Mode 7 : Permet d'avoir le premier background en 256 couleurs.
- Le Mode 7extbg permet d'avoir le premier background en 256 couleurs et le 2nd en 128 couleurs

Sans vraiment me mouiller, plouf, Seul deux modes vidéo est vraiment très utilisé. Le mode 1 pour avoir les 2 background en mode 8 palettes de 16 et un troisième plan qui peut aider pour les hud (voir des effets) et le mode 7 ! Les autres mode est plus souvent la pour faire le kikoulou à la megadrive !!!
(ta vu j'ai plus de mode video que toi ! Na !)
Notons que certain mode vidéo se ressemble en apparence mais possède des options différentes sur le scrolling.


Les Palettes
La SNES possède un espace ram pour mémoriser la palette de couleurs. Cette espace et de 512 octets.
Le SNES permet de mémoriser 256 couleurs. Chaque couleurs est encodé sur 2 octets et le Format d'encodage d'une couleurs est sur 15 bits.
5 bits pour de Bleu, 5 bits de Vert, et 5 Nuances pour le rouge. Ce qui fait 32 nuances de chaque teintes soit 32768 possibilités.
L'encodage est la suivante :

0BBBBBVV
VVVRRRRR
Le 1er bit n'est pas utilisé.

------------------------
* Mode 16 couleurs *
------------------------
Les 256 couleurs de la palettes de couleurs est en réalité divisiés en 16 palettes de 16 couleurs dont la premier couleurs d'une série est la couleurs transparente.
Les 8 premières palettes sont reservés au tiles des background. Et les 8 dernières palettes de couleurs sont reservés pour les sprites.

-------------------------------------------
* Le Mode 0 et 4 couleurs de la snes *
-------------------------------------------
Le Mode 0 et des background en mode 4 couleurs n'utilisent pas des palettes de 16 couleurs mais de 4 couleurs.
Les 32 premiers couleurs sont découpé en 8 palettes de 4 couleurs. Et la 1er couleurs de chaque série est n'est pas affichés. (Couleurs transparente)

-------------------------
* Mode 256 couleurs *
-------------------------
Ce mode permet d'avoir un tiles qui pioche dans les 256 couleurs de la palette.


Configuration du background
Chaque background Peut être configuré de 4 manière. Ce qui corespond à la taille du background en tiles.
(Notons que sur SNES un tile est de 8x8 pixel ou 16x16 pixel, mais encore une fois quand je regarde les jeux en emulation c'est fréquament configuré sur le mode 8x8 pixels)
- 32x32 tiles
- 32x64 tiles
- 64x32 tiles
- 64x64 tiles.

Chaque emplacement dans le background (tilemap), est encodé sur deux octets.
Ce qui fait qu'une tilemap de 32x32 tiles prend 2048 octets dans la VRAM.
Une tilmap de 32x64 (ou 64x32) prend 4096 octets.
Et une tilemap de 64x64 tiles prend 8192 octets dans la Vram.

Chaque double octet permet (un mots) d'afficher un tile à l'écran avec des options.
Une tilemap possède la capacité de piocher dans 1024 tiles. (10 bits), Et choisir entre un panel de 8 palettes de couleurs pour le tiles à afficher, (3 bits), un bit de priorité pour le tile afficher 1 bit pour retourner verticalement le tile à afficher, et un autre pour retourner horizontalement le tile à afficher.

Encodage d'une case de la tilemap sur deux octets.
VHOPPPCC CCCCCCCC
V : Flip Vertical.
H : Flip Horizontal.
O : Tile priorité
PPP : Palette de couleurs
CCCCCCCCCC : Index du tiles à afficher.

Chaque Background possède deux pointeurs dans la VRAM.
Un pointeur pour savoir ou la Tilemap se trouve dans la VRAM.
Et un pointeur pur savoir ou se trouve l'index 0 de son catalogue de tile à afficher.
Ce qui veux dire que chaque background peut posséder son jeu de tile si le pointeur de tiles est différent d'un autre background...

Envoyer des datas au CPU
Le pvsnes lib possède des "fonction" pour travailler directement les registres de la snes.

Portion de code : Tout sélectionner

1
REG_VMAIN = value


CE registre permet de configurer le mode incrémentation du PPU. Pour faire simple la SNES à un mode automatique quand on envois une data dans la VRAM incrémenté l'adresse Cible automatiquement sans avoir besoin de reconfigurer l'adresse en question. Pratique. MAIS cette incrémentation se fait automatiquement après qu'on à memoriser une valeur dans le 1er octet ou le 2em octet.
J'explique : La vram fonction sur un mots de 16 bits. (deux octets). Le premier octet est le poids faible et le 2em octet est le poid fort.

Si le bit du poids fort du Vmain (registre 8bit) est 0, incrémentation se fait après que l'octet du poid faible est mémorisé en Vram.
Si le bit du poids faible du Vmain est à 1, l'incrémentation se fait après que l'octet du poids fort est mémorisé en Vram.

Portion de code : Tout sélectionner

1
REG_VMADDLH


Permet de mémoriser l'adresse en mots ou va débuter le transfère de data en Vram.
Attention la valeur est en mots est non en octet.
REG_VMADDLH = 0x2 revient à taper à l'adresse 0x4 de la Vram.

C'est ce registre qui est incrémenté automatiquement.

Portion de code : Tout sélectionner

1
REG_VMDATALH


Permet d'envoyer une valeur 16bits directement en Vram. Pratique pour updater la tilemap. Dans cette exemple
REG_VMDATALH = 0b0010000000000100 ;
Permet d'envoyer un tiles dont l'index est 4 avec une priorité de 1.
Attention l'encodage ici est bien dans l'ordre mais une fois en Vram c'est les 8 derniers bit qui est mémorisé dans l'octet 0 et les 8 premier bit dans l'octet 1.

Il faut bien passer le bit 7 à 1 du registre Vmain pour que l’incrémentation se déclenche correctement !

Portion de code : Tout sélectionner

1
   REG_VMDATAL


Permet d'envoyer dans Vram l'octet du poids faible.

Portion de code : Tout sélectionner

1
REG_VMDATAH 


Permet d'envoyer dans la Vram l'octet du poids fort.

Encore une fois faite attention à l'ordre d'écriture des fonctions et la configuration du Vmain.

Notons aussi que se sont des registres CPU. Les datas sont envoyer quand la Vram est "ouverte" en ecriture.
c.a.d quand l'écran est éteint, ou quand le balaye écran est en train de remonter au haut de l'écran. (Après le signale du Vblank !)

Priorité des tiles/background

En Mode video 1 de la snes !

Portion de code : Tout sélectionner

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
  BG3 tiles with priority 1 if bit 3 of $2105 is set
  Sprites with priority 3
  BG1 tiles with priority 1
  BG2 tiles with priority 1
  Sprites with priority 2
  
  BG1 tiles with priority 0
  BG2 tiles with priority 0
  Sprites with priority 1
  BG3 tiles with priority 1 if bit 3 of $2105 is clear
  Sprites with priority 0
  BG3 tiles with priority 0
 



Taille d'un patern !!!
J'ai pas beaucoup parlé de ça mais voyons un peu ce que prend un patern en Vram.
Un patern est un tile de 8x8pixel. (Notre mosaique).
En fonction du mode vidéo il peut être encodé sur 2bits par pixel (4 couleurs), 4 bits par pixel(16 couleurs), ou 8 bits par pixel(256 couleurs, il tape dans tous le nuancier)

Un sprite c'est obligatoirement des paterns sur 16 couleurs.

En mode (nes), soit 4 couleurs un patern de 8x8 prend 16 octets en Vram.
En mode 16 couleurs on est à 32 octets par patern en Vram.
En mode 256 couleurs on est à 64 octets par patern en Vram.

N'oublions pas que dans la Vram il faut aussi placer la tilemap des background.
Chaque background possède 4 tailles
- 32*32 tiles. (2048 octets dans le PPU)
- 64*32 tiles. (4096 octets dans le PPU)
- 32*64 tiles. (4096 octets dans le PPU)
- 64*64 tiles. (8192 octets dans le PPU)

Et que la Vram est limité à 64ko de Ram !
Aller petite calcule voir ce que la Vram peut manger à un instant T !:

- On peux adresse 512 sprites : Ce qui fait déja 16384 octets.
- Chaque background peut adresse 1024 tiles pour l'exo on reste en 8x8.
Ce qui fait : 32,789 ko en mode 16 couleurs pour un jeu de tileset complet.
Il reste en gros 16ko pour les tilemap. Notons qu'en mode 4 couleurs du mode 1 faut des tiles adapté. (16ko pour un jeu de 1024 tuiles). Outch. Tous ne passe pas

Tout ne passe pas !!! Voila c'était un petit exo pour s'en rendre compte.
La création d'un jeu retro est toujours un équilibre de pattern / sprite / background en Vram !

Notons que ce petit exo est calculé sur un instant T. Un jeu sur SNES remplace fréquemment les graphismes. (tileset/spritset) dans la Vram...


Petit travaille sur la Vram
*****************************
*** Travaille sur la Vram ***
*****************************
25/01/2023

Notes : Les adresses sont en octets et non en mots...

* ============================== *
* Position du pointeur de sprite *
* ============================== *

4 blocs de $4000 (16384 octets) index de 0 et 511 tiles pour les sprites.

$0000 ($2000)
$4000 ($6000)
$8000 ($A000)
$C000 ($E000)

* =============================== *
* Position du pointeur de tilemap *
* =============================== *
4 configurations de tilempap
- 32*32 tiles. (2048 octets dans le PPU)
- 64*32 tiles. (4096 octets dans le PPU)
- 32*64 tiles. (4096 octets dans le PPU)
- 64*64 tiles. (8192 octets dans le PPU)
1 ecran = un bloc de $800

1 à 4 background en fonction du mode vidéo.

$0000
$0800
$1000
$1800
$2000
$2800
$3000
$3800
$4000
$4800
$5000
$5800
$6000
$6800
$7000
$7800
$8000
$8800
$9000
$9800
$A000
$A800
$B000
$B800
$C000
$C800
$D000
$D800
$E000
$E800
$F000
$F800



* =============================== *
* Position du pointeur de tileset *
* =============================== *

en pattern de 8x8

2 bits par pixel = 16 octets (16318 octets le tileset $4000)
4 bits par pixel = 32 octets (32768 octets le tileset $8000)
8 bits par pixel = 64 octets.(65536 octets le tileset $FFFF)

1024 patterns (8*8 ou 16x16) par background.

$0000
$2000
$4000
$6000
$8000
$A000
$C000
$E000

......Mode 4 bpp ... 2bpp

$0000 => $8000 => $4000
$2000 => $A000 => $6000
$4000 => $C000 => $8000
$6000 => $E000 => $A000
$8000 => // => $C000
$A000 => // => $E000
$C000 => // => //
$E000 => // => //

========
* Vram *
========
Screen
------------------------------
$0000 = Sprites
$0800
$1000
$1800
$2000
$2800
$3000
$3800
------------------------------
$4000 = Sprite
$4800
$5000
$5800
$6000
$6800
$7000
$7800
-----------------------------
$8000 = Sprite
$8800
$9000
$9800
$A000
$A800
$B000
$B800
-----------------------------
$C000 = Sprites
$C800
$D000
$D800
$E000
$E800
$F000
$F800

Signer du nez ?

Accéder au message sur le forum


Monos - posté le 18/06/2021 à 19:06:37 (57322 messages postés)

❤ 5

Vive le homebrew

image


Deadland Journal de création d'un CRPG

Mise à jour le 18/06/2021

Sysnopsis
Suite à un virus, la famine et la pauvreté s'est installé dans le monde entier. Les hommes se soulève contre les gouvernent à telle point que ce dernier n'hésite pas à frapper dur et même avec l'arme Atomic ! La terre est pratiquement dévastée par la folie des hommes.

Nous sommes en 2105, le monde se reconstruit petit à petit, mais la violence existe toujours.
Pillage, Viol, meurtre... Le monde est dangereux.

Retrouvé il y a 1 an, à la porte de la mort par des locaux , vous rappelant de rien, vous participez à la vie du village. Jusqu'au jour ou des rêves de votre passé surgie et vous donne l'envie d'en savoir plus sur vous. Vous partez à la conquête de votre passé.

Un CRPG c'est quoi ?
Un CRPG c'est l'acronyme de Computer Role Playing Game. Ce sont les jeux de rôle sur micro-ordinateur. Souvent se sont les jeux de type occidentaux. (Fallout, Bulder gate,Elder Scrool...). Contrairement au JRPG qui se concentre plus sur l'"histoire" et la mise en scène, les CRPG sont plus concentré sur la création des personnages, un Levels up plus maitrisé par le joueur.

Deadland se veut dans la tradition des ultima et surtout Wasterland. Un monde Post Apocalyptique.

Un Hombrew sur Atari St(e)
Deadland est développé pour une vielle machine. L'atari Ste. La machine possède des contraintes techniques que nous connaissons plus. (Même Rpg Maker 2000 et 2003 est plus évolué au terme puissance et rendu graphique xd)

Pour faire simple la machine de base possède 512ko de ram. Une résolution de 320x200 pixel, avec une palette de 16 couleurs (Dit programmable sur un nuancier de 4096 teintes)

Je n'ai pas de sprite machine. Mais je possède un blitter. Pour faire simple un co processeur qui permet de copier/coller des morceaux de graphismes très rapidement ce qui permet alléger le processeur principal. (En réalité ça copie juste des donnés en mémoire)

Le ste possède un lecteur de disquette de type pc avec une capacité de 720ko.

Au niveau ram, s'il le faut, je peux quand même utiliser trois configurations.

- 512 ko, 1 mo ou 4 mo

Ceci dit si je veux rester compatible avec le maximum de machine de base, mon objectif est de rester sur du 512ko. Mais je n'ai pas de scrupule à utiliser de la ram supplémentaire.

Le Stf
Un petit mot sur l'atar stf, c'est la machine atari 16 bits la plus répendu. Grand frère sur ste.
La machine embarque 512ko de ram, n'a pas de blitter, (donc pour faire les copies d'image, c'est le processeur principal qui s'en occupe), et le nuancier n'est que de 512 couleurs.
image


Les outils de programmation
Je programme le jeu en langage C. Qui reste un langage très adapté pour programmer les vieilles machines. Après l'assembleur bien sûr.

J'utilise la suite "VBCC" qui possède le compilateur et le linker en cross dev. c.a.d que je programme sur mon PC Windows ce qui rend la chose très pratique.

J'utilise une lib externe pour avoir des fonctions pratique pour le ST. L'atari STX Engine. Une lib pour le STE mais qui va être plus tard etre compatible pour le Stf. Lien

Au niveau de l'ide c'est not pad ++ pour moi. Simple et sans prise de tête. On me pousse sur VS code Studio, mais ça ne marche pas avec moi.
image

Au niveau du lancement de la compilation, j'utilise un simple fichier bat avec des commandes directes. Pas de makefile que je trouve inutile dans mon utilisation.

Outils Graphique et Choix de ma palette de couleur !
J'utilise la basse résolution du St qui me permet d'afficher 320x200 pixels à l'écran. Ce mode vidéo me permet d'utiliser une palette de 16 couleurs.
(Il existe deux autres modes vidéo sur le st. Le 640x200px avec une palette de 4 couleurs, et le 640x400px avec une palette de 2 couleurs (noir et blanc))

J'ai fait le choix d'une palette unique tout le long du jeu avec la palette d'Arne.
https://androidarts.com/palette/16pal.htm

Le ST n'accepte pas le PNJ, ni le Bitmap... Il a un encodage à lui. Mon Workflow au niveau graphisme est simple, j'ai créé sur Photoshop CC mon nuancier de la palette de Arne. Pour tous les graphismes je ne dois pas changer l'ordre des 16 couleurs. Je réalise ma tambouille, j'index mon image avec mon nuancier, et je sauvegarde l'image en PNG.

Je dois mouliner cette image dans un autre format. Le format PI1. Pour cela j'utilise le logiciel grafx2 qui me permet de charger un png et de sauvegarder dans d'autre format tout en gardant l'ordre des 16 couleurs dans l'image. A partir de là je peux travailler mon "image" sur l'Atari st.
image

J'ai trouvé un logiciel sans avoir besoin de passer par grafx2 pour convertir en pi1 mais il ne garde par l'ordre des couleurs et élimine même les couleurs non utilisés. Ce qui peut poser des soucis quand je dois utiliser plusieurs planches d'image en même temps.

Pour info ce logiciel se nomme pngtopi1 https://github.com/benjihan/pngtopi1
Il existe peut-être un autre logiciel, mais jusque-là, je n'ai rien trouvé qui me convient.

L'étape Photoshop n'est pas vraiment obligatoire, mais je suis beaucoup plus à laisse avec ce logiciel que d'autre logiciel de dessin. C'est juste une question d'habitude.

Des captures d'écran
image
Début d'un system de combat.
Les icones représentes (Attaque avec son arme équipé, attaque corps à corps, utiliser un objet, recharger son arme, fuire, inventaire pour changer d'équipement)

Le system se veut simple. On calcule qui à l'initiative (PJ et Monstre) et le plus rapide fait une action. Puis on recommance le calcule de l'initiative. Je vais très certainement ajouter un facteur de fatigue.
]

image
Représentation du jeu. Déplacement map en case par case, icone pour choix des actions.
(Mouvement, inventaire,Entrer/sortie, blanc si j'ai une idée, recherche, et 4 choix)

image
image
System de création du personnage provisoire.

Des vidéos !






FAQ
Q : Pourquoi sur 39 colonnes et non 40. C'est quoi cette barre noire à droite ?
R : Cela vient à une limitation de la lib pour copier les images. J'utilise le blitter pour copier les données rapidement, et laurent à coder sa fonction sur des pas de 16px de largeur. J'ai dû donc m'adapter à cette contrainte technique.

Q : Pourquoi un STE ? Cela devrait tourner sur un STF
R : C'est toujours lié à la lib de lolo. En utilisant le blitter en hard (je suppose), il faut donc un blitter pour faire tourner le projet. Mais normalement il doit corriger ça pour faire tourner sa lib sur un STF et rendre l'utilisation du blitter en mode Software s'il n'est pas présent sur une machine.

Q : Pourquoi tu utilises qu'une seule palette de 16 couleurs ? L'Atari peut changer de palette ! Ce n'est pas un Commodore 64 !
R : C'est par simplicité des choses. Arriver au bout du projet serait énorme pour moi. Je suis seul, donc je me simplifie la vie. Surtout sur les graphismes.



Mission Edition physique
Le but à long terme c'est de créer une édition physique. Disquette/Boite/livret/Carte...
Le jeu devrait être en Français et en anglais. (J'ai une personne qui parle anglais à la maison xd)
Pour le moment il est trop tôt pour savoir sur combien de disquette ça va tenir et si les deux langues vont cohabiter dans le jeu. Tout ça est une question de Ram.


A suivre ...

Signer du nez ?

Accéder au message sur le forum


Monos - posté le 10/05/2021 à 19:35:01 (57322 messages postés)

❤ 1

Vive le homebrew

En passant le site en sécurisé, mes images se re affiche directe, cool.
L'année 2020 fut une bonne année pour ma collection.

Le C4CPC
J'ai récupéré une C4CPC pour ma GX4000 de chez amstrad. Une carte qui permet de placer les jeux dedans. (et les hombrew). La carte permet aussi d'être utilisé dans amstrad plus.

image

Everdrive Famicom
image
Une carte flash pour la famicom. Ce qui est cool c'est qu'elle a le port usb pour être branché sur le pc et envoyer les rom directement.

ZX Spectrum + et 48k
image
Une machine qui à très bien fonctionné en Angleterre.

image
J'ai aussi une des premières version du ZX avec clavier en membranne.

Un Commodre 64
image
Un autre modèle du C64. Je l'aime bien celui la.

un Amiga 600
Juste avant le 1er confinement. , j'ai récupéré un Amiga 600.
image
Son avantage c'est qu'il est compacte. Très pratique pour être transporté.

L'everdrive X7 de la megadrive
image
Une carte flash pour la mégadrive. Tout comme la famicom, elle à un port usb pour être branché sur le pc. Très utile quand on développe et qu'on veux tester sur machine réel.

Un Commodore 128
image
L'ultime Commodore 8 bits. Compatible avec le Commodore 64. Une machine que je voulais depuis très longtemps.
C'est je crois un des seul micro ordinateur avec trois processeurs.
Le Z80, le mos, et un intel.

De la megadrive
image
Une belle genesis, alias la version us de la mégadrive.

image
Ah et la version japonaise.

J'ai aussi eu en début d'année une megadrive dite (PAL G) (tous comme sa grand soeur la master system)
Les Pal G sorte du composite ce qui permet de le brancher sur mes télé pro.

Le c16
image
Un commodore 16.

La Phoenix
image
Cette machine embarque un FGPA qui "emule" la colecovision avec des puce amélioration et l'atari 2600. La master system est au programme normalement.

J'ai une autre console arrivé mais pas testé encore faute de TV avec prise antenne.
Une des premières consoles. Le Vidéopac.

Signer du nez ?

Accéder au message sur le forum


Monos - posté le 27/08/2018 à 06:50:04 (57322 messages postés)

❤ 4

Vive le homebrew

image

C'est cool les versions boites...
Semedi j'étais à chauny dans un magasin de jeu vidéo player game pour faire la promo du jeu ! Et me faire connaitre. Il y a eu 3 acheteurs suplémentaire. (A l'heure actuel ça me rembourse juste les composants, le but est juste de tâter le terrain !)

De bonne chose donc, le petit magasin de jeu vidéo de chauny est ok pour être un petit distributeur ! C'est une bonne nouvelle.

Samedi j'ai eu deux surprises, mon premier client est venu me voir, il était heureux de me rencontré, et hâte de me prendre une copie du jeu.
image
On a installé une master system dans une borne de présentoir d'époque même.
Dans l'après midi on a même posé une 2nd master system
image
image
Et pour la première fois j'ai eu le droit à un DRAW dans une partie
image
image

Les gens qui ont eu la manette à la main, se sont amusés comme des petits fous à ma grande surprise.

Voici des photos divers !
image
image
image
image

A l'heure actuel, 14 éditions physiques ont trouvées place sur des étagères ! J'ai d'autre précommande.

Le bilan de cette aventure :
La création d'un jeu vidéo que cela soit homebrew ou pas c'est long même si prisonnier est simple à construire. Mais faire une édition physique mano à mano c'est encore pire mais qu'elle satisfaction aussi. C'est carrément autre chose qu'une publication digitalisé. Le jeu, devient un objet de collection, et non plus du consommable ! Une histoire s'installe et cela est cool.

L'édition de prisonnier II est un peu maladroite, il y a beaucoup mieux à faire, et j'ai appris plein de chose sur la confection d'un objet, et la publicité à faire. (il faut un petit site web qui réunis vos jeux, mon ami, n'a pas ça est à loupé de la publicité à cause de ça ! Hein capitaine !)

Voir des articles sur Mo5 ou indi rétro news, c'est génial. Envoyer une copie physique au programmeur du remake de wonder boy III, c'est une très belle récompense et source de motivation ! Alors c'est vrais que le nombre de copie est faible (je pense atteindre peut être 25/30 copies), mais dans le monde du hombrew cela reste très honorable je pense.

Objectif accomplie pour ce jeu pour moi !

Signer du nez ?

Accéder au message sur le forum


Monos - posté le 26/11/2015 à 06:12:39 (57322 messages postés)

❤ 1

Vive le homebrew

Nom du jeu : Prisonnier
Support : Amiga Classique (Amiga 500/600/1200)
Idée de Base : Capitaine Caverne
Programmeur :Jean Monos
Graphismes : Jean Monos mais aimerais bien trouver une personne pour ça.
Moteur : Programmation avec la Basic Amos Pro
Type : Jeu de plateau
Lien : Fiche du jeu avec lien de téléchargement

Fiou comme dit les indiens, Je le tien mon premier jeu old school rétro sur vrais machine. L'Amiga Classique tournant sous un 68k au niveau proco. M'enfin bref.Les Commodores Amiga sont des vieux ordinateurs 16 / 32 bits des années 90. En duel avec l'atari ST.
Quand j'ai testé un jeu d'un capain (Capitaine Caverne) j'ai beaucoup aimé ce qu'il a fait, et j'ai décidé de le porter sur Amiga en le programmant en Basic Amos. Lui il le fait avec Clickteam Fusion 2.5 sur PC (et peut être Flash). Le jeu se nomme Prisonnier. Il possède un game play simple mais efficace :
Une partie est découpé en tour. Le joueur A se déplace d'une case, puis il pose une brique sur le plateau du jeu. Le joueur B en fait de même, puis des briques peuvent apparaître aléatoirement pour enquiquiné son monde.Au début de son tour, si le joueur ne peux pas se déplacer, il perd la partie.

Une Vidéo



image
Un début de menu (oui le NewS n'existe plus xd)

Une Ia est aussi présente mais à l'heure actuel elle n'est pas au top de sa forme, je dois regarder et programmer une IA qui tien un peu la route. Pour le moment, c'est que de l'aléatoire pour son déplacement, et elle pose juste une brique à coté du joueur.
Je n'ai pas encore de date de sortie de prévu. Il y a tant de chose à faire encore. (Graphismes, Son...) et peut être implémenter un mode tournoi pour voir plusieurs joueurs s'affronter.

Je recherche une personne pour m'aider sur le coté graphisme.

Prisonnier tourne bien sur Emulateur. Je programme le jeu sur PC avec un émulateur Amiga 1200 configuré comme celui que j'ai. Au moment ou j'écris ses lignes, je n'ai pas encore testé en condition réel mais étant donnée que je ne trafique pas directement le coeur de l'hardware, il ne devrais pas y avoir de problème. (Bon ici je doute que beaucoup de monde à des Amiga chez lui)

Voilou, encore pas mal de boulot sur ce petit projet qui est bien avancé et jouable à l'heure actuel. Reste juste les 90% autres pourcent de développement.

Edit Michel
Vous pouvez télécharger une archive avec le jeu.
Lie de la fiche
L'archive contient une disquette ADF avec le programme dessus.
Il faut la lire avec un émulateur Amiga. (Win uae par exemple).
Bon jeu pour les personnes qui si aventure.

Signer du nez ?

Accéder au message sur le forum


Tata-Monos - posté le 31/07/2010 à 12:30:25 (57322 messages postés)

❤ 0

Vive le homebrew

Le Maker : (Corrigé par Kriss)

Le Maker est une chose qui fait style de créativité.
Il est sensé développer des jeux sur un logiciel qui se nomme Rpg Maker, mais préfère passer son temps sur les forums à poster des messages qui n’ont rien à voir avec la création de jeu vidéo, ou pire faire style qu’il s’y connaît dans les topics des nouvelles personnes qui vont devenir : Le Maker.

Les jeux du Maker
Peut-on appeler ça jeu ?
Un jeu est une production qui est complète, la Maker, lui n’achève pas ses productions.
Il préfère bosser 1 mois son projet, proposer une démo sur les forums dont il est inscrit, et s’auto congratuler sur sa démo.
Ensuite le projet est stoppé pour diverses raisons.

La malédiction du Maker
Le Maker est maudit par le sortilège « Crash du Disque dur » .

En réalité c’est la plus grande excuse qui soit inventée par le Maker pour :
-Ne pas continuer à créer son projet.
-Stopper son projet qui sent la poudre.
-Le Maker a une nouvelle idée de projet bien mieux que l’ancien. Il faut trouver une excuse.
-C’est rare, mais des fois c’est vraiment une malédiction, et le disque dur est vraiment mort.

Et enfin pour bien être dans la malédiction, le Maker ne fait pas de copie de sauvegarde de son projet.
Sinon, l’excuse n’a plus lieu de l’être.


Les Écrans Titres
Le Maker débute toujours son projet par la réalisation de son écran titre.
C’est la chose la plus importante pour un Maker.
Comme il connaît le titre de son jeu avant d’avoir réfléchie à un scénario et débuté le projet en question, il a tout le loisir de s’abandonner à la réalisation de cette image.
Et il passe du temps sur ça. Car il sait que les autres Makers préfèrent critiquer sur des pages entières sur un forum sur un écran titre que sur une carte banale.

Les Effets de lumière
Les effets de lumières sur une image, c’est le pêché mignon du Maker.
Il aime ça.
Pour un makleur, un bon screen est proportionnel au tas d'effets de lumière qui sont apportés sur l’image.
A contrario, chipset qui est utilisé sans effet de lumière, c’est Has Been.

Le piratage
Le Maker est radin. Il n’aime vraiment pas donner de l’argent au créateur des logiciels qu’il utilise.
Et surtout au créateur du logiciel qu’il est censé utiliser tous les jours.
Mais comme le Maker finalement passe sur Rm une fois tous les 36 du mois, pourquoi payer alors ?


Les Débats
Les débats c’est un des terrains de jeu préférés du Maker.
C’est la grosse occasion de montrer son point vu, et de bien faire voir qu’il est cultivé.
Même quand le Maker à tord, il ne changera pas d’avis.
Les débats permettent aussi d’avoir le terrain libre pour insulter d’autre maker et de lancer du drame sur les forums (Dit un Drama).
Plusieurs moyens sont bons pour se montrer dans les débats :
Le moyen le plus utilisé c’est les combats de Citations. (Battle Quote en Vo)
La méthode est simple et rodée chez le maker.
On cite une partie d’un texte de son ennemi, et on lui répond sur cette partie de la phrase.
Alors que sortie sur contexte, la phrase prend un autre sens. Mais ce n’est pas grave.

Le maker dans les débats à ses thèmes préférés.

1) -Le Custom / Rip /RTP
Oui, c’est un des plus grand débat sur la communauté.
Savoir ce qui est mieux entre : Réaliser ses propres graphismes. (Oui le maker jure que pour les graphismes, faire des propres musiques par exemple, c’est bien moins important que les graphismes).
Utiliser des graphismes des jeux professionnels.
Ou utiliser les ressources de bases fournis avec le logiciel utilisé.

2)-Le meilleur logiciel à utiliser.
Qu’elle est le meilleur logiciel entre Rpg Maker 2003,Xp,Vx.
C’est aussi un des débats récurant de la communauté.
Mais le maker se fout de savoir qu’elle est le meilleur logiciel vu qu’il ne fini pas ses productions.
Enfin ce thème à des variantes comme par exemple, les scripts est bien ou ça tue le making ?
A noter que sur ce thème, tous le monde est d’accord pour dire que Rpg Maker 95, est le moins bon de tous.

Enfin il faut savoir, que c’est les débats qui font vivre les forums.


La présentation d'un projet d'un Maker
C’est ici que se joue la différence entre un jeune Maker qui arrive, et un vieux Maker qui est là depuis des années.
Le jeune Maker veut montrer au vieux Maker que lui aussi c'est un bon Maker.
Alors voici comment le jeune Maker qui vient d'arriver dans l'arène présente son projet.

1)Le gros pavé pour présenter son univers et son synopsis.
Le maker va montrer qu’il maîtrise bien son univers et va écrire un roman sur le synopsis, l’univers, les personnages, le déroulement du jeu.
Mais les autres makers s’en foutent royalement. Il va juste regarder les images présentes dans le topic de présentation.
C'est plus important et plus facile à critiquer.

2)Présentation des captures d’écrans.

-L’écran titre : C’est le moment de bien re-placer l’écran titre du projet. (L’écran titre a été montré et corrigé, bien avant la présentation du projet. Galerie, topic dédiés à présenter des captures d’écran…)
L’écran titre va re-passer sur Trois pages à des critiques pour s’avoir que la police utilisée n’est pas la bonne par exemple.

-Le Menu : Le maker va montrer ses captures d’écran de son menu. Et pas seulement une.
C’est le festival. Les lecteurs applaudissent plus ou moins suivant si le maker utilise le menu de base, ou si le menu est réalisé en événement ou en script.
En principe le maker nous présente des jolies menus qui sont réalisés avec l’aide des scripts trouvés par ici et par là.

-Système de combat : C’est à l’image du menu. Des tas de scripts, une capture d’écran, pour chaque combattant, de jolis effets de lumière.

-Les ArtWorks : Le makeur aiment foutre des dessins dit Artwork dans sa présentation.
Cela fait pro.

-Les cartes du jeu : si les lecteurs sont sages, nous avons le droit de voir des captures d’écran directement tirée du jeu réalisés avec les ressources fournis avec le logiciel. (RTP/RGSS)

C’est à partir de maintenant que les autres makeurs entre en scène, et critiquent le projet.


Critiques des projets
Le Maker aime critiquer. Il a même l’âme d’un professionnel dans les critiques.
Nous pouvons dégager trois tendances dans les critiques réalisées par le Maker.

1) Les critiques sur les ombres.
Le Maker aime les effets de lumières. Qui dit Lumières, dit ombre.
Pour bien montrer que le Maker c’est un connaisseur de la physique et autre art, il va nous faire un cours de trois page pour bien montrer que les ombres ne sont pas bonnes, ne sont pas réalistes.
Surtout sur des captures d’écran ou le joueur va passer que deux secondes dans le jeu.

2) Les Perspectives :
Le Maker est un architecte de renom. Il aime critiquer sur les perspectives du jeu.


3) L’effet de Vide :
Le Maker, dans la vrai vie, il est seul. Alors quand il aperçoit une image, il n’aime pas cet effet de vide qui lui manque chez lui.
Souvent il balance en critique une phrase du style : Ta map est vide, remplit la.



L'entraide :
L’entraide, c’est l’endroit ou le makeur peut espérer avoir un coup de main.
Et c’est aussi l’endroit pour voir deux générations dans la communauté.
Le jeune maker qui arrive, et le vieux briscard qui a roulé sa bosse dans la communauté.
Et pour le vieux briscard, c’est l’endroit idéal pour se montrer et d’affirmer sa supériorité dans l’utilisation du logiciel qu’il n’a ouvert que 2 fois dans la semaine.

Quand le nouveau Maker arrive avec une question qu'on va dire simple à résoudre. (Comment placer un coffre par exemple)
Le vieux Maker va arriver sur la question pour bien faire comprendre que le jeune Maker doit chercher par lui même. (Et il ne va pas de la main morte).
Ce qui est drôle, c’est que le vieux maker, avait posé cette question quand il était jeune.
Mais le but pour le vieux briscard, c’est de faire comprendre au jeune qu’il a des années de making.
Et il va même faire comprendre au jeune que ce genre de question, il en a ras le bol, il lit toujours les mêmes questions dans l’entraide. Il fait croire qu’il est aigri.
Dans ce cas la, nous pouvons nous poser la question suivante :
Pourquoi le vieux maker traînent dans le topic entraide, si il est aigri de ces questions ?
La réponse est écrite plus haut. C’est pour bien montrer au jeune makeur que c’est un vieux.

Titre des projets, du studio, des équipes...
Le Maker aime les titres de projet, de studio, et d’équipe.
Le Maker quand il réalise un projet, il aime avoir le titre de sa future production qui sera abandonné avant d'avoir réalisé sa 1ere carte. (Il faut bien travailler l'écran titre, c'est important pour faire savoir au autre Maker quel projet on réalise. L'identité du Maker en somme)


La Maker utilise plusieurs stratagèmes pour inventer un titre. Voici des Exemples.
-Mélanger plusieurs titres pro pour faire son titre de jeu, par exemple Final Quest, qui est la contraction de Final Fantasy et de Dragon Quest.
-Utiliser le mot Tales car ça fait penser à Tales of Symphonia par exemple.
Tales of Maker. Ah c'est stylé.
-Traduire un titre Français dans un anglais approximatif voir pire en Japonais phonétique.
Le Maker a beaucoup d'imagination sur les titres des projets.

Le Maker aime aussi donner un nom de "studio" à son projet.
Il reprend la bonne recette des jeux.
Happy Soft
Happu Exix.

Une autre passion pour le maker. La réalisation des noms d'équipe.
La aussi ils ont une super imagination.
C'est le Mot DARK qui est la mode.
Comme par exemple la Dark Shadow Team

Signer du nez ?

Accéder au message sur le forum


Monos - posté le 08/12/2008 à 18:47:33 (57322 messages postés)

❤ 1

Vive le homebrew

L’amour de Rpg Maker 2003

Quel drôle de titre vous allez me dire. Vous avez raison. Mais il fallait que je trouve un titre qui vient de mon cœur pour cet article.

J’ai envie de parler de mon amour de ce logiciel. Car rien à faire, j’adore la version VX de la gamme des Rm (Rpg Maker) mais à chaque fois que je retombe sur des images qui proviennent de la version 2003, (ou 2000 qui pour moi reste le même type de logiciel) je peu pas m’empêcher de penser à ce dernier. Mais pourquoi?

Les graphismes:

C’est beau êtres du 320/240 en 256 couleurs, mais mine de rien, avec toutes les ressources sur le net, il y a du choix dans le style graphique si on n’est pas doué en graphe. Et des doués dans les graphes il y en a pas beaucoup dans le monde du making, car sinon il y aurais de plus beau jeu sur Vx et Xp.

Car oui, Xp et Vx sont des monstres au niveau graphisme, mais pas très utilisé à sa juste valeur. Sur Xp je n’aime pas du tout les graphismes de base, et sur Vx ça commence à saturer. En faite à ce niveau la, j’ai plus envie de me replonger dans la nostalgie des vielles consoles. Et les graphismes des vieux jeux vidéo sont parfaits pour ça. Vu que graphiquement je suis Zéro et que ce n’est pas un truc qui m’intéresse vraiment de faire, prendre des Rips, me convient vraiment bien. La chose difficile c’est harmoniser cela.
Mais utilisant les graphismes d’un seul jeu vidéo, c’est plus facile.

Au final en regardant depuis le début du making, ou se trouve les plus beau jeux graphiquement ?

La petite résolution en 320/240 est t’il vraiment une limitation ?
Moi je dis non. On crache sur cette résolution car les jeux qui sortent, les TV qui sortent, et autre média nous en met plain la vu et nous miroite des résolutions de ouf. C’est la mode. Alors on dénigre les petites résolutions.

Tien chose qui me fais sourire au niveau de  mode . On est tellement enfermé dans des normes au niveau résolutions, (320/640/1024.…..) et des que la Mode et norme ne sont plus respectés, c’est la catastrophe, on hurle au scandale.
Si si, j’ai la preuve, la résolution native de Vx. 544/416 souvent dénigré car c’est pas typé, au norme ou on va plus dire, ça change des habitudes. Alors ça va plus, on est malade de voire ça, Bon dans notre tête c’est quand même bien mieux que le 320/240, mais c’est pas typé, mon dieu .^^

Aller un autre truc que j’ai en tête, c’est bien beau d’avoir des logiciels qui ont de quoi dans le ventre. Comme XP et VX au niveau graphismes. Mais combien de personne sont capables vraiment de produire des belles choses?
Car pour aller je vais dire 90% des makeurs, cette puissance est juste utilisé pour les écrans titre et les games overs. Avec un peu chance les menus et les systèmes de combat. Le reste on se retrouve avec les RTP du logiciel.

Donc au final je vois qu’on crache pas mal sur le 256 couleurs de Rpg Maker 2003, mais au final sur RmXp et Vx on fait pas mieux que des écrans titres et des RTP.


Pas de script que de l’événement:

Au final c’est la meilleur chose, ça fait un an que je travaille sur Vx qui me plait quand même. Mais en retournant un peu sur Rpg Maker 2003 pour réaliser un début de system de combat personnalisé, j’ai pris un de ses plaisirs. De la fierté même.

L’utilisation d’un script quand ce n’est pas réalisé par nous même c’est cool, ça va vite, c’est puissant, souvent un gain temps phénoménal, mais moi qui n’est pas doué en graphe je fais quoi après? Plus rien. Cette liberté de programmer, elle n’y est plus trop. Je bidouille deux trois truc sur le script copier/coller, et hop c’est dans la boite.

Non au final après un an, ça ne me plaît pas, ce n’est pas ce que je recherche non plus dans le monde du making. J’ai besoin de cette partie la, pour prendre plaisir à faire le jeu, prendre plaisir à coder moi-même les systèmes.

Oui je pourrais apprendre le ruby et faire mes propres scripts mais rien à faire, la base du ruby c’est pas compliqué mais une fois avec les classe, les truc hérité, et les machin objet qui sont jamais expliqué correctement pour les débutants, chez moi la mayonnaise ne prend pas. Et ce n’est pas faute d’avoir tenté d’apprendre.

Et sur Vx et Xp, les options d’événements sont biens moins développer que la version 2003. Normal pour les fonctions de base, les scripts sont la.

Bof quoi.
Non ça me manque. Je préfère ma bonne programmation d’un combat ou d’un menu en événement, me casser la tête à réfléchir. Il y a rien de mieux.

Un autre truc que je reproche au script, ou l’abus d’utilisation de script chez les débutants, c’est horrible mais ça leurs fait pas réfléchir. Oui combien de fois je vois de demande de script pour des choses simple faisable en événement. (Vous avez un script pour faire des quêtes?)A croire qu’ils ne connaissent même pas les événements.

De toutes façon les événement c’est Has benn comme mister. Ca ne sert strictement à rien .

Enfin avec Rpg Maker 2003 si tu veux faire un effet super dans ton jeu, tu n’as pas le choix, tu dois apprendre à programmer en événement. C’est pratiquement du Click and points, et les traductions des événements parlent d’eux même. Mais faut aussi avoir le courage de chercher tous seul, et d’explorer le logiciel chose que peux de nouveau font de nos jour.

Si c’est vrai, regardez dans l’entraide. Combien (sans méchanceté je dit ça) de personnes posent de question qui peuvent résoudre eu même ?

Après tous pourquoi ce faire chier à chercher soi même, qu’un con va répondre. Je n’ai pas besoin de me fatiguer.

Adieu mon projet Vx?
Bien sur que non. Enfin je ne le pense pas. J’aime ce projet. J’ai maintenant hâte de le reprendre pour le finir. Car finir un jeu, un premiers jeu est super important. Et j’ai envi que cela soit Saigo Densetsu:Génésia. J’ai le scénario, faut juste que je sois moins fainéant. Je suis sur en travaillant le jeu tranquillement je peux avoir finis vers Mars, mais pour ça, il faut que je reprenne la production du jeu. j’ai tous de même deux heures de jeu. Bon je suis loin des 8h du jeune marié.

Mais après oui je reprends Rpg Maker 2003. C’est pratiquement une certitude.
J’ai pas mal d’idée et d’envie surtout.
Faire un RPG custom dans ses systèmes ou assouvir mon envie de Survival Horror ?

Tant de question que je me pose. Surtout que j’ai débuté la création d’un system de combat pour un jeu type Rpg.

A vrais dire j’ai aussi une envie de faire un Zelda plus pour l’envie de coder son system A/Rpg que pour le Zelda en lui-même. Et surtout que j’ai les graphes à ma disposition.

Enfin Bref.

Mais pourquoi Rpg Maker 2003 reste t’il souvent dans les cœurs des vieux makeurs?
Car c’est un « vieux logiciel » et souvent le logiciel ou les vieux briscards ont commencés leurs apprentissages. Souvent c’est la version 2000. (Chose qui est vrais pour moi) mais passer à la version 2003 est très facile vu que c’est la même chose.

Ensuite comme on le sais très bien, changer ses habitudes c’est pas facile.
Moi j’ai réussis en passant vraiment sur Vx. D’autres personnes ont réussis aussi comme Indy qui est passés de Rm2000 à Xp sans passer par la case 2003. (Il toucheras pas les 20 milles Francs ^^)

Mais peut être aussi que les vieux lourds de mer, ont une habitude de programmation en événement et que sur XP/VX faut utiliser les scripts?

D’autre peut être n’ont pas envie de changer de support tous le temps et ce contente de cette amour de Rm.

Mais ce qui fait la force c’est encore une fois les graphismes et les ressources en abondance sur les sites de Making. Et surtout du choix et de la variété.


Pourquoi Rpg Maker 2003 est la plupart du temps détesté par les jeunes makeurs?

J’ai du réponde à ma question plus haut. Souvent c’est à cause de la résolution du soft qu’ils trouvent pourrie et des 256 couleurs.
Ensuite c’est que souvent dans les têtes c’est dernier logiciel sorti de la gamme, c’est le meilleur et au moment où j’écris cet article c’est le Vx qui deviens roi.
Après il y a des gens neutres, qu’ils ont débuté sur une version et qu’ils ne vont pas non plus changer toutes les 5 minutes.


Note Final:
Au final mon amour de Rm 2003 et je parle un peu de tous dans cette article perso, mais je fais bien comprendre que j’aime ce log même avec ses potentielle défaut.

Je dénigre un peu XP et Vx.(Un peu?) Enfin étant honnête XP et Vx à de la capacité à faire un très bon jeu avec les RTP et sans scripts. Faut pas que je charrie et que je pousse mémé dans les ronces.

La seul chose que je regrette de Xp, c’est qu’il est pas vraiment utilisé à ses pleines capacité, j’aimerais vraiment voir et joué surtout à des jeux Killer en graphes. C’est mon souhait en tous ça.

Et des personnes le manie bien tous de même comme Rock qui rien à dire que les graphes par exemple. Enfin au final, chaque logiciel est la pour que la personne puisse prendre du plaisir à créer un jeu. Même sans compétence graphique, ruby et autre, c’est le plus important. Moi je prends du plaisir vraiment sur la version 2003.
J’ai vraiment tous ce que j’aime dans ce log. Maintenant c’est à moi de me prendre par la main, et de sortir quelque chose de ce log.

Signer du nez ?

Accéder au message sur le forum

Aller à la page 1

Haut de page

Merci de ne pas reproduire le contenu de ce site sans autorisation.
Contacter l'équipe - Mentions légales

Plan du site

Communauté: Accueil | Forum | Chat | Commentaires | News | Flash-news | Screen de la semaine | Sorties | Tests | Gaming-Live | Interviews | Galerie | OST | Blogs | Recherche
Apprendre: Visite guidée | RPG Maker 95 | RPG Maker 2003 | RPG Maker XP | RPG Maker VX | RPG Maker MV | Tutoriels | Guides | Making-of
Télécharger: Programmes | Scripts/Plugins | Ressources graphiques / sonores | Packs de ressources | Midis | Eléments séparés | Sprites
Jeux: Au hasard | Notre sélection | Sélection des membres | Tous les jeux | Jeux complets | Le cimetière | RPG Maker 95 | RPG Maker 2000 | RPG Maker 2003 | RPG Maker XP | RPG Maker VX | RPG Maker VX Ace | RPG Maker MV | Autres | Proposer
Ressources RPG Maker 2000/2003: Chipsets | Charsets | Panoramas | Backdrops | Facesets | Battle anims | Battle charsets | Monstres | Systems | Templates
Ressources RPG Maker XP: Tilesets | Autotiles | Characters | Battlers | Window skins | Icônes | Transitions | Fogs | Templates
Ressources RPG Maker VX: Tilesets | Charsets | Facesets | Systèmes
Ressources RPG Maker MV: Tilesets | Characters | Faces | Systèmes | Title | Battlebacks | Animations | SV/Ennemis
Archives: Palmarès | L'Annuaire | Livre d'or | Le Wiki | Divers