Logicielsmoto.com

Nous sommes le 28 Mar 2024, 22:12

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1 ... 7, 8, 9, 10, 11, 12, 13 ... 40  Suivante
Auteur Message
MessagePosté: 20 Juil 2021, 16:21 
Hors ligne

Inscription: 12 Fév 2021, 15:54
Messages: 78
Localisation: Rennes
Bentoc a écrit:
- Routines d'affichage de texte


Ca me plait bien comme "truc" à faire, j'en ai déjà fait plein sur d'autre plateformes, donc je connais tous les concepts.

Bentoc a écrit:
et plus de bataille avec les LOADM et compagnie ;-)


Ahah, j'adore cette "private" Joke (not so private, anyway).

Bentoc a écrit:
J'espère que tu me rejoindra, ça devrait donner un sérieux coup de fouet au projet.


;-)

Pour l'env de dev Eclipse, je pense que je devrais y arriver ;-) (cf. l'adresse de mon blog en signature sur Java)

_________________
Fan de Atari 2600, Thomson MO5, Thomson TO8, Atari STE.
Retro-Codeur à mes heures perdues. https://www.fxjavadevblog.fr


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Juil 2021, 19:56 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Effectivement ... désolé !

Au passage superbe site bravo !
Du coup j'ai trouvé un peu de lecture pour cet été ;-)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Juil 2021, 20:12 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
C'est marrant moi aussi j'aime bien java...et peut-être qu'un jour sur Thomson on verra >>ça<< ou >>mieux<<.. mais chut! :)

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Juil 2021, 21:09 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Avec quoi vous pensez construire les datas/graphisme des écrans ? genre vous utilisez un tilemaker ?

moi j'avais commencé à faire un script pour pouvoir générer custom comme j'ai besoin un tilemaker, qui est en cours ...
juste tu choisis le tile et tu click/drag pour dessiner et ça génère les datas pour faire un array des id des tiles graphisme 1 = 0 / graphisme 2 = 1 etc...

https://oxustudio.com/to8/tilemaker/02/

bon c'est pas parfait vue que je suis le seul à l'utiliser ...

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Juil 2021, 21:18 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Samuel Devulder a écrit:
C'est marrant moi aussi j'aime bien java...et peut-être qu'un jour sur Thomson on verra >>ça<< ou >>mieux<<.. mais chut! :)


Je me souviens que tu en avais parlé il y a quelque temps ... je trouve ça énorme.
J'imagine que tu vas faire un petit essai ... tu nous fera un retour ;-)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Juil 2021, 21:53 
Hors ligne

Inscription: 12 Fév 2021, 15:54
Messages: 78
Localisation: Rennes
Adnz, il est super ton tilemaker !!

Il faudrait rajouter la notion de calque. En gros pouvoir dire si un tile est du foreground ou background. Foreground : infranchissable (mur).

Typiquement pour 1 tile, on code sur 4 ou 6 bit la référence vers le tile set, et sur 2 bits restants son type, ce qui permet donc 4 valeurs possibles.

Pour le format des data je laisse bentoc nous dire ce qu'il a déjà fait ou envisagé. La compression zx0 pour le stockage des bitmaps me plaît bien, en tt cas.

Et peut être qu'il faudra générer à la volée des compiled sprites, comme pour mission liftoff.

_________________
Fan de Atari 2600, Thomson MO5, Thomson TO8, Atari STE.
Retro-Codeur à mes heures perdues. https://www.fxjavadevblog.fr


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Juil 2021, 22:09 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
adnz a écrit:
Avec quoi vous pensez construire les datas/graphisme des écrans ? genre vous utilisez un tilemaker ?

moi j'avais commencé à faire un script pour pouvoir générer custom comme j'ai besoin un tilemaker, qui est en cours ...
juste tu choisis le tile et tu click/drag pour dessiner et ça génère les datas pour faire un array des id des tiles graphisme 1 = 0 / graphisme 2 = 1 etc...

https://oxustudio.com/to8/tilemaker/02/

bon c'est pas parfait vue que je suis le seul à l'utiliser ...


J'avais envisagé plusieurs possibilités :
- Utiliser Pro Motion NG (j'ai déjà une license), il permet de concevoir les map comme ton outil, et il permet de partir d'une image et de créer le tileset correspondant et la map.
- Développer un outil spécifique
- Utiliser des outils d'édition de niveau de Sonic + un convertisseur custo

Cependant, j'imagine que fxrobin récupèrera les données de map dans une version existante, ça ira plus vite que de tout refaire à la main.
En tout cas merci pour ta proposition, j'apprécie ! c'est une bonne base

Il faut d'abord qu'on définisse les besoins, et puis il y a plusieurs techniques pour gérer les tilesets.
J'avais commencé à réfléchir au sujet en imaginant une solution permettant de gérer de grandes maps,
l'idée est de regrouper les tiles en blocs :

Citation:
La map serait de taille maximum de 128x128 blocs (16ko), chaque bloc a donc une référence sur un octet.

Ces 256 blocs de taille 128x128 pixels sont composés de 8x8 images de 16x16px, chaque définition de bloc fait donc 64 octets (16 ko pour les 256 définitions de blocs). Oui ça fait bien une map de taille maximum de 16384px par 16384px ! :sol:

Enfin l'index image fait 256x3 (un octet page, deux octets adresse) et pointe vers la routine d'affichage qui sera certainement un dérivé de celle des "sprites compilés".

Cette structure sera à multiplier pour chaque plan de tile a afficher (j'en ai prévu deux, un pour le fond, un autre pour les plateformes).
Les éléments en avant plan par rapport aux sprites seront gérés par le moteur de sprites et non par le système de tilemap.

Dernière précision, on pourra afficher la map à l'écran en déplaçant la "caméra" (zone affichée par l'écran) par pas de 16px (taille d'une image tile). Si vous avez bien suivi on perd donc 8 px en hauteur (l'image sera constituée de 20x16px en largeur et 12x16px en hauteur).


J'avais pensé ce modèle pour mes besoins mais du coup c'est intéressant de voir dans un autre contexte si c'est adapté ou pas.
... et rien n'empêche de penser un système "modulaire" qui permette de gérer plusieurs cas de figure, la priorité restant la performance (les tiles seront rendu en sprite compilés)
Dans Sonic il me semble qu'il y a trois niveaux de blocs : 128x128px, 16x16px et des tiles de 8x8px
Il faut trouver le juste milieu entre taille max de la map, taille du tile, performance de la routine d'affichage ...

Dans le cas de Rick Dangerous vous avez des infos sur le nb de niveaux, leur taille, le nb de tiles, gestion de blocs ?

Pour ce qui est de la notion de solidité ce seront des données associées aux tiles, c'est le point le plus complexe, la encore il y a bcp d'options et le moteur de Rick Dangerous sera bcp plus simple de ce coté là par rapport à Sonic ;-) mais réalisons déjà l'affichage, sur cette partie il y a moyen de mettre en commun.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Juil 2021, 22:11 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
foreground ou background

ha oui yep bonne idée
j'y avait pas pensé à le faire dans le tilemaker direct.

Oui je rajouterais un bouton type toggle (foreground/background)
avec genre un petit cercle de couleur ou un signe qui se mettra dans le coin de chaque tile que tu dessine pour montrer si c'est foreground ou background.

Puis après à partir de ça on pourra générer n'importe quel format de array qu'on aura besoin (decimal, hex etc..) ...

mais oui si les datas existant , on peut les recup pour les utiliser c'est du boulot en moins de reconstruction ....

puis en faite dans ce cas ici je sais pas si le dev d'un tilemaker custom est nécessaire du coup !

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Juil 2021, 15:36 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 492
Avez vous pensé a Prince Of Persia ? Si je me rappel bien, il n'y avait aucun scrolling, des tiles d'une grosse taille (pour le background) et pas vraiment en grands nombres, le plus complexe etant l'animation du personnage mais d'apres ce que j'ai vu ici, ca ne semblerait pas non plus un probleme. Peut etre un element nouveau ... certaines tiles sont en foreground (devant le personnage) mais c'est juste un ordre d'affichage sans masquage.

J'ai l'impression que ce moteur de jeu pourrait s'occuper assez facilement de ce jeu. En mode 320x200x4 (CGA), ca pourrait tres bien le faire.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Juil 2021, 16:20 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Oui j'y ai pensé également,
de plus le source Apple II est dispo sur github.

Bon j'ai pas prévu de me lancer dans cette aventure mais j'ai dans ma bibliothèque le document (qui attend ma lecture) :
"Technical Information" rédigé par Jordan Mechner lui même en 1989 à destination des développeurs en charge du portage de Prince of Persia sur les autres supports que l'Apple II.
Je jetterai un coup d'oeil pour voir comment sont gérées les maps.

Après c'est UbiSoft qui détient la licence ... je ne sais pas quelle est leur politique à propos des fan games ou des portages ...
Coté Sega je suis tranquille car ils encouragent cette pratique du moment qu'il n'y a pas de vente de produits.

Au passage pour cet été (si vous ne l'avez pas déjà lu) je vous recommande : "La création de Prince of Persia" chez Third éditions.
Il s'agit du Journal de Jordan Mechner durant les années de création de Prince of Persia.
J'ai adoré lire ce livre ...


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Juil 2021, 17:20 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
ça peut être sympa avec le mode bitmap 4 couleurs, yep

https://www.youtube.com/watch?v=_gMYcna5OiA

mais faut déjà voir comment on utilise le framework, la procédure pour créer la bibliothèques de tiles, puis faire les écrans, puis le plaçage des écrans de quels bords on passe vers quel écrans et les directions et anim du player...

l'idéal serait donc d'avoir tous ces mêmes process pareils pour n'importes quels jeux de ce type .... prince OP ou rickD (sans scrolling)

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Juil 2021, 22:25 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Pour le moment le cœur de l'outillage met en œuvre le mode BM16 uniquement.
Pour Prince of Persia le jeu d'origine est en 140x192 de mémoire et 6 couleurs (Apple II).
Il existe d'ailleurs un level editor ici : https://www.norbertdejonge.nl/leapop/
Fichier(s) joint(s):
leapop.png
leapop.png [ 118.21 Kio | Vu 5111 fois ]


Sur Rick Dangerous j'ai regardé la forme des levels pour avoir une idée, effectivement une map rectangulaire n'est pas adaptée vu la forme globale.
Fichier(s) joint(s):
Rick.png
Rick.png [ 149.45 Kio | Vu 5111 fois ]


=> Comme tu le dis un système de lien entre écrans serait plus adapté sur un jeu sans scroll.

Les tiles en sprite compilés sont de forme et de taille libre, on n'a aucune contrainte de ce point de vue.
De même leur affichage peut se superposer (par exemple pour de la 3D isométrique ou comme dans Prince of persia ou il y a un recoupement des tiles).
C'est la page et l'adresse de la routine de sprite compilée qui est indexée, les données ne sont pas en tableau comme pour des données de tiles classiques.

Ce qui va varier c'est le fait d'indexer un seul tile dans une map ou d'indexer un groupe de tiles.
De ce point de vue il faudra développer des variantes du code et le développeur choisira la routine qu'il veut utiliser.
- Une routine sans gestion de groupe (type Prince of Persia)
- Une routine avec gestion de groupes (type Rick Dangerous)
- Une routine avec gestion de 2 groupes imbriqués (type Sonic)

Le nombre de tiles par groupe sera dynamique si tout va bien.

Juste un aparté sur une animation de type scroll entre deux écrans :
Le seul réel problème est le dépassement des bordures, car en Sprite compilé on ne sait pas s'arrêter net sur les bordures écran.
Je vois trois solutions :
- il faut compléter le dessin avec une routine standard qui écrit pixel par pixel et donc avoir en plus les tiles en bitmap classique
- ne rien dessiner, ce qui fait des bordures noires de taille variables ... pas top
- scroller de la taille d'un tile ... c'est bien ça non ? a défaut d'être fluide ce sera rapide ;-)

Dernier truc, comme l'a dit Yoann ce qui est le plus adapté (et le plus efficace) ce sont de gros tiles, c'est là que le sprite compilé est le plus efficace (dans la limite de 16Ko ;-))
L'ennemi c'est la taille du code, pour chaque projet il faudra donc calibrer la taille des tiles au plus gros et découper en groupes si ce n'est pas tenable du point de vue taille du code pour les sprites compilés.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 22 Juil 2021, 07:29 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Ne pourrais-tu-pas découper les grosses tiles en tiles plus petites et ainsi réduire la taille du scroll ?

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 22 Juil 2021, 07:34 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Oui c'est possible avec la notion de groupe de tiles, un groupe à cheval sur la bordure serait rendu partiellement.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 22 Juil 2021, 08:30 
Hors ligne

Inscription: 12 Fév 2021, 15:54
Messages: 78
Localisation: Rennes
quelques éléments sur Rick Dangerous le jeu d'orgine (320x200) : si un scroll vertical peut intervenir, il le fait sur un bloc de 8 tiles de haut, c'est à dire sur 64px et pendant ce scroll tout est figé.
En revanche, il n'y a jamais de scroll horizontal (apparemment).

_________________
Fan de Atari 2600, Thomson MO5, Thomson TO8, Atari STE.
Retro-Codeur à mes heures perdues. https://www.fxjavadevblog.fr


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1 ... 7, 8, 9, 10, 11, 12, 13 ... 40  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 47 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com