For the last 2 months I've been taking a little break from Chunky Pixel Collision. I felt that I needed to step away from it a little bit as I was feeling burnout approaching!
Anyway, to relax(!!!) I had a go at creating something I've wanted to do for a long time: A full-screen, character-based, tile engine with parallax scrolling.
It has 4 layers of parallax: a static "wallpaper" layer for things that are really far away, a background layer, the playfield layer, and a foreground layer. The background layer moves at half the speed of the playfield, while the foreground layer moves at twice the speed of the playfield.
I've used some simple graphics based on the arcade version of Pacland. Makes me wonder what the CPC version of Pacland could have been like (even though it is still very playable).
When the program loads, it lets you decide how big to make the 4 borders around the screen. Leaving them at default will make the program run at full-screen. For a spectrum sized screen, use top=0, bottom=1, left=4, right=4. Don't use "impossible" borders, as the program will crash (ie. make sure that (top+bottom) is less than 25, and (left+right) is less than 40).
Use the arrow keys to move the camera in any direction. The parallax works vertically as well, though I have built in the ability to lock any axis (this facility isn't demonstrated in the attached dsk file).
I wrote this using the wonderful ccz80 compiler, with assembler for the speed-critical bits, like processing the sprite data, and printing the tiles to the screen.
I've used adaptive screen refresh, only printing tiles that change from frame to frame. Objects can be placed anywhere in a play area of 65536 x 65536 tiles, and when the camera reaches the edges of the play area, it wraps around correctly (I hope!). The number of objects is limited by RAM (I'm only using the base 64K), though the number of tiles is (at the moment) limited to 255. The tile limit problem is already solved in my brain, but I don't know if I'll end up putting it into the program...
I don't know if I'll do any more work on this - it was just something I needed to get out of my system. I hope you all enjoy it (what little there is of it, anyway)!
vous trouverez le lien sur place dans son premier post.
Bon je l'ai essayé vite fait sous Winape.
C'est en 64K, pour le moment y'a aucun masque, pas de "sprites" ni de collisions.
c'et aussi limité a 256 tuiles (la liste des tuiles est en 8 bit).
Il est possible de réduire l'écran de base 16K aux dimensions ZX Spectrum (128x192... en mode0) histoire de réduire le poids.
C'est très simple, mais très fluide et rapide, du moins en émulateur pour le moment. Il y a 4 plans, ce qui est assez chouette.
Sinon bin c'est sûr ça perd un poil en fluidité si on fait un mouvement/défilement diagonal aussi.
Rien que de mettre un set de tuile un peu mieux conçu peut sans doute permettre de vite faire un truc assez chouette je pense, pour peu que l'on garde des formes carrées (style AMC) histoire de ne pas avoir trop d'artéfacts de caractères non masqués.
Après faut voir si vous avez pas mieux en réserve ou si le moteur laisse assez de place CPU pour subir pleins d'ajouts divers.
à voire aussi si l'auteur va released le source code ou pas (il faudrait lui demander je pense).
Citer :
When the program loads, it lets you decide how big to make the 4 borders around the screen. Leaving them at default will make the program run at full-screen. For a spectrum sized screen, use top=0, bottom=1, left=4, right=4.
En gros il faut indiquer le nombre de caractères que l'on souhaite "enlever" à chaque côté de l'écran standard CPC, donc pour du spectrum -1 caractère vertical (en bas ici) et 4 de chaques cotés (64 pixels type mode1, 320-64 = 256...).
Ce genre de truc ça pourrait être sympa dans une optique verticale, en 256x256 peut être (128x256 mode0) histoire de faire du paralaxe vertical.
Si il y avait moyen d'inclure quelques masques standards pour faire des angles coupés ça et là, ou enlever une couche et en remplacer une par du sprite... y'a un fort potentiel...
le truc c'est que ça bouge au character donc en fait ça vise un scrolling rapide.
comme certaines layers bougent tout le temps (plus rapide) celles qui bougent moins souvent donnent relativement peu l'impression de faire du "pas à pas" je trouve.
Je me demande si c'est possible de faire ce genre de truc avec des implémentations de genre 1/2 caractère de mode1 (donc 2 pixels de mode0, soit 1 octet)
De plus le coup des caractères ça laisse les angles bien visible, il est vrai que le style de tuiles utilisées ici (PacLand) ne sont absolument pas adaptées à la grille des Caractères.
Ceci dit, un peu de masques ça et là, donc en gros permettre sporadiquement quelques tuiles coupée de moitié pourrait casser largement le rendu full carré classique (voir AMC, l'un des rares jeux a bien exploiter ce genre de moteur... On est en mode0 après tout, pas besoin de formes de masque trop complexes) suffiraient largement à offrir un rendu pseudo masqué.
Mais bon ça doit être assez lourd au final.
là j'avais un peu fait une pseudo liste des masques suffisant... en gros 16 serait bien (là j'ai fait ça à l'arrache) mais moins suffirait aussi.
En gros il faudrait surtout 4 tuiles de masque pour gommer chaque "coin" de caractère possible.
en LMasquage on a en général 2 type de méthode.
=Sacrifier une couleur qui sert de masque.
=Appliquer un masque codé séparément en 1bpp en général... comme sur les portages spectrum en monochrome.
En général de telles masques "speccy" sont assez lourds, les sprites étant complètement doublés par un masque. Et c'est vrai que ça peut être utile en théorie en Mode1 (peu de couleurs) mais c'est plus un relicat des limitations du ZX spectrum en fait.
Que là, avec des tuiles en "4x8" car mode0, j'ai un peu du mal a voir comment un masque de 4x8 peut se faire. c'est possible de n'utiliser qu'un demi octet ?
D'après Fano, qui travaillait sur un moteur au caractère sur R-Type, ajouter une "layer" de transparence c'est vraiment chaud en fait.
la solution ne serait elle pas de faire des caractères de taille Mode2 ?
Seulement ok, ça double tout les addressages des tuiles et le poid du TileMap/levelMap.
De plus il faudrait sans doute donner une couche en plus pour définir une tilemap des tuiles qui seraient masquées (donc en fait plus petites en gros ou de formes à la con.
Pas simple.
Citer :
J'ai regardé aussi sa preview hier,et c'est tres prometteur,apres le gars voulais juste faire un test ou il compte en faire un jeu ?
bin si d'autres sont motivés, il pourrait (laisser) faire quelque chose avec, de toute manière il a très gracieusement fournis les Sources.
C'est une sorte de C avec des "pointes" d'assembleur même pas spécialement CPC me semble t'il.
Citer :
Un AMC en effet serais sympa.Un beat'em'all ou un jeu de plateforme a la great giana sister serais sympa aussi !
un Xénon2 mégablast pourrait très bien faire de bonnes choses aussi.
ça ne serait pas plus simple de faire le vertical un poil plus smooth d'ailleurs ? vu que justement le CPC est capable de scrolling vertical relativement smooth.
Là il faut bien voir que c'est du multiscroll, horizontal et vertical... faudrait y mettre les tuiles de AMC justement pour mieux tester le moteur avec des tuiles prévue pour ce genre de chose, me semble t'il.
Satan aussi utilisait un moteur aux caractères me semble t'il.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 8 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum