Pure1945 !!!

[KarLKoX]

Je viens d'essayer, tres sympas (à part la zizik mais bon ^_^).
Je suis toujours aussi nul : 925 points à la première partie

[Marcus]

tres bien fait , felicitation

vraiment dommage le mode windows

[hackotedelaplaque]

Selon vos conseils, petite mise à jour avec au choix mode fenêtré ou plein écran.

Sinon je réinstalle linux ce soir (mon HDD m'a lâché pendant les vacances, près de 90% de bad sectors .. vous devinez ce que le père noël m'a porté ? euh non les gars, pas seulement une poupée gonflable ) et je m'occupe du portage sous linux (je sens déjà que ça va me prendre la tête !!)

je rappelle ici le lien pour le téléchargement :

http://membres.lycos.fr/hackotedelaplaque/jeux/

[Marcus]

Bien mieux en plein ecran , mais y'a un probleme c'est pas fluide

une insulte au Pure .

[raven]

salut a tous

je me suis permis de modifier la fluidité de ton jeu hakotedelaplaque

http://raven.perso.cegetel.net/Pure1945.rar

[hackotedelaplaque]

je le dis et le répète comme plus haut, si le jeu n'est pas fluide c'est parce que c'est une COPIE DE L'ORGINAL qui est comme ça.
Bref pour me la péter, je peux dire que c'est du "reverse engineering"

Je ne suis pas un handicapé du Pure, et mes réalisations personnelles seront quant à elles fluides !!!

Excusez moi, mais quand je lis le "c'est une insulte au pure" j'ai du mal à digérer alors que je viens ici pour partager mes (certes mediocres) sources.

[filperj]

salut a tous

je me suis permis de modifier la fluidité de ton jeu hakotedelaplaque

http://raven.perso.cegetel.net/Pure1945.rar

Tu as juste augmenté la vitesse

[Marcus]

quand je lis le "c'est une insulte au pure" j'ai du mal à digérer

ne le prend pas mal , je dis pas cela pour te vexer --- une simple setrefreshrate suffit à le rendre lisse .
Mes critiques ne sont que constructives .

Disons plutot qu'avec ces saccades l'on dirait plutot un jeu fait avec The Game Factory qu'en Pure

sinon bravo tres belle realisation

si le jeu n'est pas fluide c'est parce que c'est une COPIE DE L'ORGINAL qui est comme ça

en emulation avec MAME32 peut etre , mais le vrai 1941 en borne arcade etait fluide

pour y jouer sans avoir la nausée j'ai simplement modifie l'ouverture de ton écran :

Code : Tout sélectionner

If MessageRequester("Config", "Jouer en Mode plein Ecran ?", #PB_MessageRequester_YesNo) = 6
SetRefreshRate(60)
  OpenScreen(640, 480, 32, "Pure1945")
Else
  OpenWindow(#PB_Any, 0, 0, 640, 480, #PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_TitleBar | #PB_Window_ScreenCentered, "Pure1945")
  OpenWindowedScreen(WindowID(), 0, 0, 640, 480, 0, 0, 0)  
SetFrameRate(60)
EndIf

c'est plus rapide car on peu pas syncroniser en dessous de 60 . faudrait /2 tous les deplacements pour retomber à la même vitesse qu'avec ton SetFrameRate(30)

tres amusant , j'ai refais un

[comtois]

Marcus , si c'est cette méthode que tu utilises dans ton puckman , je peux te dire que ça ne marche pas toujours , si j'enlève la synchro de mon écran , ton jeu s'emballe et devient injouable , pour bien gérer le temps dans les jeux , je te conseille de jeter un oeil ici :

http://www.nofrag.com/2004/oct/23/14529/

je te mets ici l'extrait qui concerne la gestion du temps :

Le temps

La gestion du temps est un aspect beaucoup plus complexe qu'il n'y parait. C'est en effet à la charge du programmeur de gérer le "World Stepping" : l'avancée du temps dans le monde. Il faut, à chaque image, expliquer au moteur physique de combien d'unités de temps il doit avancer les objets. Et là, ça se complique...

La première idée qui vient, c'est de mesurer le temps de rendu de la dernière frame et d'avancer le temps d'autant. Par exemple, si on a un rendu à 100FPS, la dernière frame durera 10ms et il faudra faire avancer le temps de 0.01s. Si on a un rendu de 10FPS (une frame toutes les 100ms), on avancera de 0.1 seconde. Malheureusement, cette méthode ne fonctionne pas :

Avancer le temps de une unité de 0.1s n'est pas du tout la même chose que d'avancer le temps de dix unités de 0.01s chacune. En effet, la détection de collision n'est effectuée qu'une fois pour l'ensemble d'une incrémenation du temps, quelle soit de 10ms ou de 100ms. Les collisions seraient donc dix fois moins précises lorsque le jeu tourne à 10 FPS qu'à 100 FPS. En fonction de votre nombre de FPS, les balles vont traverser les murs ou non : si la détection de collision est précise, la collision balle-mur va être détectée alors que si le jeu rame, elle ne le sera pas. Les balles sont très sensibles à ce genre de problèmes car ce sont des objets TRES véloces et aussi très petits. Bref, ça ne peut pas fonctionner.

L'astuce consiste à choisir un "timestep" fixe et à répeter l'avancée du temps autant de fois qu'il le faut entre chaque frame. Fixons par exemple le timestep 0,01s. Si le jeu tourne à 100 FPS, il affiche une image toutes les 0,01s donc entre chaque image il suffit de faire avancer le temps d'une unité (un step). Si le jeu ralenti à 10 FPS et qu'il ne calcule plus qu'une image toutes les 0.1s, il faudra par contre faire avancer le temps de 10 steps entre deux images.

On arrive alors à un système logique : l'avancée du temps est synchronisée sur le temps réel. Dans notre exemple, on simulera les physiques à un fréquence de 100 Hz quelque soit le framerate du jeu. Il est bien sur possible de changer cette fréquence pour créer des effets de ralentis ou geler le jeu pendant un moment.

J'ai lu , et utilisé cet article récemment ,maintenant j'adopte ce principe dans tous mes codes.
Je suis en train de réécrire Sokoban3D , j'avais eu des remarques que la vitesse n'était pas toujours adaptée sur certaines configs.
Avec cette méthode , c'est très simple de l'ajuster.
Et puis ça m'oblige à réorganiser le code autrement , c'est pas un mal .

[raven]

salut a tous

je me suis permis de modifier la fluidité de ton jeu hakotedelaplaque

http://raven.perso.cegetel.net/Pure1945.rar

Tu as juste augmenté la vitesse

j'ai juste remplacer setframerate par SetRefreshRate

[Marcus]

Comtois
je connais ce principe j'ai m^m fais un tut sur ce sujet:
http://purebasic.hmt-forum.com/viewtopi ... 008f507a8f
mon exemple etait sous windows , mais marche pareil en plein ecran .
Maintenat c'est chiant à utiliser , lourd a trainer et farcis de flottants

si j'enlève la synchro de mon écran , ton jeu s'emballe et devient injouable

bé non !
Pour le plein ecran rien de plus simple que :

Code : Tout sélectionner

SetRefreshRate(75)
If OpenScreen(1024,768,32,"") = 0 :SetRefreshRate(0): OpenScreen(1024,768,16,"") :SetFrameRate(75):EndIf

si ton ecran refuse le 75hz le framerate limitera quant même à 75 en perdant la fluidité bien sur .
Et puis les LCD envahissant le marché, du 75hz on va en bouffer !

[comtois]

je viens d'aller sur ton lien , il me manque deux trucs WaitForVSync() et GetMonitorFreq() pour voir comment fonctionne ton prog.

tu devrais afficher le FPS sur ton puckman , je te dirai à combien je monte , sûrement plus que 75

[Marcus]

il me manque deux trucs WaitForVSync() et GetMonitorFreq()

Effectivement ce bout de code date d'un an et ces commandes etaient en fait des dll , une pour le wait vbl et l'autre pour retourner la valeur de la sync .
Depuis le Pure a evolué et Fred nous à sorti ces 2 commandes direct dans le pure . le wait vbl est maintenant inclu dans flipbuffers() et la commande DesktopFrequency() retour la syncro de l'ecran .

tu devrais afficher le FPS sur ton puckman , je te dirais à combien je monte , sûrement plus que 75

normalement avec :

Code : Tout sélectionner

SetRefreshRate(75) 
If OpenScreen(1024,768,32,"") = 0 :SetRefreshRate(0): OpenScreen(1024,768,16,"") :SetFrameRate(75):EndIf

t'es obligé d'avoir un fps de 75 .

[Le Soldat Inconnu]

et de toute façon, FlipBuffer() attendant la synchro de l'écran, le FPS ne peut pas être supérieur à la fréquence de l'écran.

donc si tu as un écran en 85 hz, ton fps max est de 85. de même pour un écran de 60 ou un écran de 100hz, on obtient, un FPS de 60 ou de 100 au max

Après, pour monter plus haut, faut retirer la synchro avec l'écran.

L'avantage du SetRefreshRate, c'est de limiter la vitesse de manière à avoir la même vitesse de jeu sur un rave que sur un avion

Au dela de 60 de FPS, on voit plus la différence (un film, c'est 25 image/s je signale)

[Marcus]

Soldat Inconnu.

FlipBuffer() attendant la synchro de l'écran

En plein ecran Oui bien sur , mais sous windows simplement depuis la version 3.91 ou 3.92 sais plus .

Comtois .
j'ai retrouvé le bon tut
http://perso.wanadoo.fr/marcus.zone/fic ... o_sync.zip

C'est des tuts que j'avais fait en BLITZ et PURE pour rester fluide et à la même vitesse quelle que soit la syncro .( sans utiliser SetRefreshRate(75) )