RPG OpenWorld Online
Posté le 17/02/2023 00:34
Bonjour tout le monde !
Ça faisait longtemps n'est-ce pas ? Je me suis absenté pendant un moment et je reviens vers vous avec du lourd ! Du très très lourd !
aparté
Cliquer pour enrouler
Petite aparté, non, le projet ParticuleEngine n'est pas mort. J'y travaille toujours, mais avec mes études qui prennent tout mon temps, c'est compliqué d'avancer dessus. Mais dites-vous qu'il y a eu pas mal de travail dessus, c'est juste que je n'ai rien montré pour l'instant. Mais revenons au cœur de ce projet.
Je vais commencer mon introduction en vous injectant une idée toute simple :
Et si on pouvait créer un jeu où tout le monde pourrait le modifier, rajouter des quêtes en temps réel, éditer la carte et jouer en multijoueur dessus, etc. En gros, un Zelda/Dofus/World of Warcraft modifiable par la communauté et validé par la communauté. Autrement dit : un RPG Maker Online.
Pour couronner le tout, imaginons que ce jeu soit multiplateforme, compatible avec les Casio, la Nintendo DS, 3DS, WII, Switch, PSP, Windows, Linux, Android, etc., afin de créer la fusion entre toutes les communautés existantes et de donner une seconde vie à ces anciennes consoles (et aussi les récentes).
Vous en pensez quoi ? Trop ambitieux ? Laissez-moi vous montrer que ce n'est pas si compliqué que ça si tout le monde rajoute sa pierre à l'édifice.
Vous voulez des preuves que c'est faisable, n'est-ce pas ? Et bien, je vais vous en donner !
Il y a un moment, j'ai créé un topic où j'ai montré que j'avais recréé RPG Maker
ici. Vous vous en doutez, c'est sur cette base que ce projet repose. Car j'ai refait 80% de RPG Maker, ça m'a pris du temps, mais ça fonctionne !
De plus, j'ai non seulement créé le mode « joueur » mais aussi le mode éditeur ! Ce qui veut dire qu'on peut techniquement créer des cartes sur Casio (même si pour l'instant je l'ai fait que sur Windows, mais bon tkt).
Et enfin, est-ce que vous connaissez devkitpro ? En gros, c'est une giga librairie qui permet de créer des programmes pour la DS, 3DS, Switch, wii, etc. Et il y a aussi pspsdk pour la PSP. Bref ! Vous avez compris là où je voulais en venir… Mais vous savez quoi ? Bah en fait, j'ai adapté ParticuleEngine pour qu'il puisse compiler sur tous ces supports. C'est bon pour vous ? (En vrai, il me reste à faire quelques ajustements, mais c'est bon trql).
Grosso modo, t'as un code source, mais genre un seul vraiment, et ça compile pour toutes les versions. Miam ! La petite dose de dopamine de satisfaction !
Mais là, vous vous dites : « Mais Farhi ! Comment vas-tu faire pour le mode Online sur Casio ? »
Sur ce, je vais vous répondre : Le port 3-pin ! (En vérité, j'ai prévu d'autres alternatives aussi).
Revenons un peu plus en détail sur l'idée. Ce projet est en d'autres termes une sorte de GitHub version jeu vidéo, c'est-à-dire que si tu veux créer une quête, étendre la carte, créer des donjons, etc., et bien tu peux ! Cela créera une sorte de branche dans le projet principal. Cependant, pour éviter que les gens fassent n'importe quoi, un vote sera organisé, par exemple tous les mois, pour valider une modification et ainsi fusionner ta branche avec la branche principale du projet. C'est donc un projet fait par la communauté pour la communauté et validé par celle-ci !
C'est donc, vous l'aurez compris, un jeu open world (puisque l'on peut étendre la carte). C'est le « nouveau Minecraft » version RPG.
Voilà ! Toutefois, ce que je vais dire est très important. Ce projet est un très gros projet. Je vous le dis directement, je ne pourrai pas le faire seul. Donc soit il y a des gens qui sont motivés pour faire naître ce projet, soit je l'enterre directement. Car seul, ce n'est pas possible, et de plus, c'est un projet communautaire. De plus, je vais publier toutes les sources du projet. Il sera donc open source.
Par exemple, j'aurais besoin de personnes qui m'aident à refaire les Tilesets de RPG Maker pour qu'on n'ait pas de problème de copyright et que le jeu ait sa propre identité. J'aurais aussi besoin de personnes qui m'aident pour la partie « serveur » et « fusion » (fusion des branches et structure d'envoi des modifications/push).
Moi, je m'engage à faire la partie programmation du jeu lui-même, c'est-à-dire ses mécaniques, compatibilité, système de base, mode éditeur, etc. Mais pour tout le reste, j'aurai besoin d'aide.
De plus, n'hésitez pas à ramener des gens venant des communautés de dev DS, 3DS, etc.
Voilà ! J'ai terminé d'expliquer mon idée,
j'attends vos retours pour savoir si ce projet peut naître
ou si je l'enterre dès maintenant
.
Citer : Posté le 27/02/2023 14:52 | #
rgb565 c'est du 16-bit classique. rgb565a c'est pareil mais une couleur est réservée pour la transparence.
p8_rgb565 c'est une image avec une palette 8 bits (ie. un octet par pixel, 256 couleurs max), qui une fois décodée donne du rgb565. p8_rgb565a c'est pareil mais après décodage il peut y avoir de la transparence.
Enfin, p4_* c'est pareil que p8_* sauf que c'est une palette de 4 bits (ie. un demi-octet par pixel, 16 couleurs max).
Effectivement y'a pas beaucoup d'infos bien organisées à ce sujet, hmm...
Citer : Posté le 27/02/2023 15:05 | #
Du coup c'est correct comme ça ?
Albert Einstein
Citer : Posté le 27/02/2023 15:10 | #
Ça devrait être plutôt :
Après je finirai par mettre un mode "auto" où il prend automatiquement le bon format vu qu'en général c'est toujours mieux de prendre la plus petite palette possible et de ne pas mettre la transparence si elle n'est pas absolument nécessaire.
Citer : Posté le 27/02/2023 16:31 | #
Il me reste 2 fonctions pour assurer la compatibilité totale de la Casio avec mon support.
Le soucis c'est que j'aurais besoin de toi Lephenixnoir car les fonctions que je dois faire c'est :
void PC_DrawSubTextureSize(PC_Texture* texture, int x, int y, int sx, int sy, int sw, int sh, int w, int h)
et
void PC_DrawSubTextureSizeColored(PC_Texture* texture, int x, int y, int sx, int sy, int sw, int sh, int w, int h, PC_Color color)
PC_DrawSubTextureSize c'est comme dsubimage(x, y,texture->texture, sx, sy, sw, sh, DIMAGE_NONE); sauf qu'il y a les paramètre int w, int h, autrement dit, ce que fait la fonction c'est qu'elle va découper avec int sx, int sy, int sw, int sh et redimensionner le cette découpe au dimension w et h.
Quant à PC_DrawSubTextureSizeColored c'est comme PC_DrawSubTextureSize sauf que ça rajoute une teinte (multiplication)
Le souci c'est qu'avec les différents profils d'images je m'en sors pas.
Albert Einstein
Citer : Posté le 01/03/2023 09:10 | #
Aïe, c'est assez difficile tout ça. Tu peux le faire sur Graph 90+E mais avec gint tu es obligé de créer ue nouvelle image pour redimensionner ou modifier les couleurs. Tu peux redimensionner une image avec image_scale() suivi de image_linear(). Par contre P4 est trop casse-pieds pour ce genre de modifications compliquées donc si tu veux le supporter il faudra convertir en P8 d'abord. La fonction va être assez lente...
Citer : Posté le 03/03/2023 15:03 | #
Il n'y a pas moyen de lire les pixels de la texture et d'afficher 4 fois le même pixels si par exemple on fait un ×2 ?Genre un truc dans ce style là :
for(int y = 0; y < h*2; y++)
{
for(int x = 0; x<w*2; x++)
{
int i = (x/2)+((y/2)*w);
dpixel(texture[i],x,y);
}
}
Albert Einstein
Citer : Posté le 03/03/2023 15:10 | #
Tu peux accéder aux pixels individuels avec image_get_pixel() et les décoder avec image_decode_pixel(). Mais ce sera lent.
Je croyais avoir codé une fonction tout simple pour les multiples entiers (plutôt que le combo image_scale() / image_linear() dont je parlais l'autre jour) mais apparemment elle n'existait que dans libimg...
Citer : Posté le 03/03/2023 20:40 | #
Si je veux print une image en 2 fois plus grand par exemple, cela signifie qu'en théorie le coût "normal" de ce print serait de 4 fois le coût de l'image non agrandi. Mais est-ce qu'en utilisant image_get_pixel() le coût sera supérieur à 4 print ?
Albert Einstein
Citer : Posté le 03/03/2023 21:13 | #
Ta théorie repose sur l'hypothèse que le coût c'est en gros la surface de dessin (le nombre de pixels). C'est une hypothèse raisonnable mais c'est assez rarement le cas. Ici sur la calculatrice dessiner un pixel ça va modérément vite (un accès à la VRAM) et donc la question qu'on se pose c'est est-ce qu'on est capables de débiter des pixels aussi vite que la VRAM est capable d'accepter des écritures. La réponse dépend de combien de travail tu fais pour aller obtenir la couleur d'un pixel. Si tu accèdes direct au tableau pixels dans l'image ça peut aller assez vite. Mais si tu fais deux appels de fonction c'est plus lent ça commence à devenir un problème.
Donc pour répondre à ta question : utiliser image_get_pixel() sera lent par rapport à accéder au tableau de pixels à la main. C'est un bon début et tu pourras voir plus tard, mais ne t'attends pas à des miracles.
Notons qu'en plus avec les effets de cache etc. en réalité le coût du dessin en x2 (fait intelligemment) ce sera moins que 4 fois le coût du dessin normal.
Citer : Posté le 03/03/2023 21:19 | #
Ok, je vois... J'y reviendrais dessus un peu plus tard.
J'ai une autre question sinon, est-ce qu'il existe un keyup() et un keysHeld() dans gint ? Car je me suis balader dans les sources et j'ai pas vu.
Albert Einstein
Citer : Posté le 03/03/2023 21:24 | #
Well keyup() ce serait !keydown(). Mais pour obtenir une liste des touches pressées instantanément, actuellement il n'y a rien.
Citer : Posté le 03/03/2023 21:32 | #
keyup() n'est pas vraiment !keydown(), car keyup c'est l'instant de quand la touche est remonté, avec !keydown ça le fait en continue.
Mais en gros keydown() c'est keysHeld et je dois bidouiller pour créé les vrai keydown() et keyup()
Albert Einstein
Citer : Posté le 03/03/2023 21:33 | #
Raah les fronts montants et descendants (instant de pression/relâchement) c'est les événéments.
Citer : Posté le 03/03/2023 22:14 | #
Si j'ai fait un gestionnaire adhoc pour les keypressed et keyreleased pour le Shmup.
Fahri, si tu veux, je peux te le passer.
Citer : Posté le 03/03/2023 22:17 | #
Par contre c'est en C++, je sais pas si toi tu es en C ou en C++.
Ca fait appel aux Class
Citer : Posté le 03/03/2023 22:25 | #
Tu trouveras tout cela dans : https://gitea.planet-casio.com/Slyvtt/Shmup/src/branch/master/src
Ce sont les fichiers extrakeyboard.h et extrakeyboard.cpp
Tu trouveras un exemple d'utilisation ici : https://gitea.planet-casio.com/Slyvtt/Shmup/src/branch/master/src/main.cpp#L259-L303
Citer : Posté le 03/03/2023 23:21 | #
Merci Slyvtt, mais mon code est en C, je vais donc l'adapter.
Albert Einstein
Citer : Posté le 04/03/2023 00:13 | #
C'est bon j'ai réussi à récupérer les évènements grâce à ton code Slyvtt.
Sinon pour image_get_pixel() comment on fait pour détecter si la couleur c'est du alpha ? Et j'ai pas très bien compris à quoi sert image_decode_pixel()
Albert Einstein
Citer : Posté le 04/03/2023 02:54 | #
Bon finalement j'ai trouvé une autre solution pas très propre mais qui marche bien :
void PC_DrawSubTextureSize(PC_Texture* texture, int x, int y, int sx, int sy, int sw, int sh, int w, int h)
{
for (int i = 0; i < w; i++)
{
for (int j = 0; j < h; j++)
{
int x2 = x + i;
int y2 = y + j;
int sx2 = sx + (i * sw) / w;
int sy2 = sy + (j * sh) / h;
dsubimage(x2, y2,texture->texture, sx2, sy2, 1, 1, DIMAGE_NONE);
}
}
}
Du coup là j'essaye de faire celle ci
void PC_DrawSubTextureSizeColored(PC_Texture* texture, int x, int y, int sx, int sy, int sw, int sh, int w, int h, PC_Color color)
Cependant je ne parvient pas à rajouter la teinte. J'ai beau me balader dans les sources de gint j'ai trouvé dsubimage_effect mais je ne parviens pas à l'utiliser.
Albert Einstein
Citer : Posté le 04/03/2023 08:56 | #
Sinon pour image_get_pixel() comment on fait pour détecter si la couleur c'est du alpha ? Et j'ai pas très bien compris à quoi sert image_decode_pixel()
Tu peux comparer si c'est égal à image_alpha(). Quant à image_decode_pixel(), son utilité c'est que pour les formats P4/P8 la valeur de retour de image_get_pixel() c'est un indice de palette, et le décodage ça va chercher la couleur qui va bien dans la palette.
Au passage toujours boucler sur y dans la première boucle et x dans la seconde, ça va plus vite grâce au cache.
{
for (int row = 0; row < h; row ++)
{
for (int col = 0; col < w; col++)
{
int sx2 = sx + (col * sw) / w;
int sy2 = sy + (row * sh) / h;
int pixel = image_get_pixel(texture->texture, sx+col, sy+row);
if(pixel != image_alpha(texture->texture->format)) {
int color = image_decode_pixel(texture->texture, pixel);
dpixel(x + col, y + row, color);
}
}
}
}
On peut faire beaucoup plus rapide mais bon tant que la division est là on peut pas faire des miracles. Maintenant que j'y pense je pourrais faire une fonction propre qui supporte aussi les facteurs non entiers.
La teinte c'est supposé marcher comment exactement ? Il y a plein de façon de "teinter".
Citer : Posté le 04/03/2023 13:07 | #
D'accord j'ai changé la boucle.
La teinte est simplement une multiplication de couleur avec le pixel de l'image et la couleur passé en paramètre.
Albert Einstein