Re: [BASIC QB64] le topic officiel du meilleur basic au monde ?

[F.L]

demande sur le forum de qb64, tu auras tes reponses  (en anglais)

[rendomizer]

je n'arrive pas a me logger sur QB64! je croyais que le site était fermé.
sinon j'ai essayé blitzbasic et bien il ne reconnait pas mon clavier avec keyhit, keydown et getkey vous croyez ça !!!

sinon BEX c'est quoi ???




                                             amicalement sergio

[ocin]

Salut, je teste QB64, mais ma SUB n'a pas l'air de fonctionner. Pourtant je n'ai pas d'erreur de syntaxe... J'ai oublié un truc ?

Code:

REM $INCLUDE:'spritetop.bi'

CLS
SCREEN 7
SCREEN _LOADIMAGE("dekor.jpg")
DIM bksheet%
DIM ball%
DIM mario%
x = 20: bx = 0: by = 50
bksheet% = SPRITESHEETLOAD("dekor.jpg", 16, 16, _RGB(255, 0, 0))
raket% = SPRITENEW(bksheet%, 3, SAVE)
bksheet% = SPRITESHEETLOAD("dekor.jpg", 4, 4, _RGB(255, 0, 0))
ball% = SPRITENEW(bksheet%, 1, SAVE)

DO
    _LIMIT 60
    touches
    SPRITEPUT x, 100, raket%
    SPRITEPUT bx, by, ball%
    bx = bx + 1
    IF bx = 120 THEN bx = 0

    _DISPLAY
LOOP
SUB touches
IF _KEYDOWN(19712) THEN x = x + 4
IF _KEYDOWN(19200) THEN x = x - 4

END SUB

[drfloyd]

sinon BEX c'est quoi ???

un langage basic pour Megadrive, avec des resultats de fou (voir Papi Commando)

Le basic en lui meme est très standard, sauf qu'il faut de la motivation pour les graphismes, c'est pas simple comme sur PC

[nemokantio]

Salut, je teste QB64, mais ma SUB n'a pas l'air de fonctionner. Pourtant je n'ai pas d'erreur de syntaxe... J'ai oublié un truc ?

Code:

REM $INCLUDE:'spritetop.bi'

CLS
SCREEN 7
SCREEN _LOADIMAGE("dekor.jpg")
DIM bksheet%
DIM ball%
DIM mario%
x = 20: bx = 0: by = 50
bksheet% = SPRITESHEETLOAD("dekor.jpg", 16, 16, _RGB(255, 0, 0))
raket% = SPRITENEW(bksheet%, 3, SAVE)
bksheet% = SPRITESHEETLOAD("dekor.jpg", 4, 4, _RGB(255, 0, 0))
ball% = SPRITENEW(bksheet%, 1, SAVE)

DO
    _LIMIT 60
    touches
    SPRITEPUT x, 100, raket%
    SPRITEPUT bx, by, ball%
    bx = bx + 1
    IF bx = 120 THEN bx = 0

    _DISPLAY
LOOP
SUB touches
IF _KEYDOWN(19712) THEN x = x + 4
IF _KEYDOWN(19200) THEN x = x - 4

END SUB

Salut,

Dim shared x
Si tu veux utiliser x en variable globale, visible dans ta sub.

[ocin]

Mais oui !! La portée des variables ! Merci nemo

[ocin]

Voilà ma sub fonctionne. J'essaie de faire un breakout (on peut le deviner). Je teste pas à pas les différentes choses dont j'ai besoin.
Pour le moment, la balle rebondit sur les bords de l'écran et la raquette bouge horizontalement.
Par contre, quand la balle et la raquette se croisent, il reste quelques pixels de la raquette sur le fond, après le passage des deux sprites.
Curieux ?

Code:

REM $INCLUDE:'spritetop.bi'

CLS
SCREEN 7
SCREEN _LOADIMAGE("fond.jpg")
DIM bksheet%
DIM ball%
DIM SHARED x, bx, by, hspeed, vspeed
DIM SHARED array(14, 14)

x = 20: bx = 0: by = 50: hspeed = 1: vspeed = 1
bksheet% = SPRITESHEETLOAD("dekor.jpg", 16, 4, _RGB(255, 0, 0))
raket% = SPRITENEW(bksheet%, 2, SAVE)
brick% = SPRITENEW(bksheet%, 3, SAVE)
bksheet% = SPRITESHEETLOAD("dekor.jpg", 4, 4, _RGB(255, 0, 0))
ball% = SPRITENEW(bksheet%, 1, SAVE)


DO
    _LIMIT 60
    touches
    SPRITEPUT x, 100, raket%
    SPRITEPUT bx, by, ball%
    limits_ball
    bx = bx + hspeed
    by = by + vspeed
    _DISPLAY
LOOP
SUB touches
IF _KEYDOWN(19712) THEN x = x + 4
IF _KEYDOWN(19200) THEN x = x - 4

END SUB
SUB limits_ball
IF bx = 320 THEN hspeed = -1
IF by = 200 THEN vspeed = -1
IF by = 0 THEN vspeed = 1
IF bx = 0 THEN hspeed = 1
END SUB

REM $include:'sprite.bi'



[ocin]

Petit up. (dsl)
Pas d'idée sur ces kk de pixels à la rencontre des deux sprites ?

[65c02]

Tu n'as pas mis de cls dans la boucle de jeu, donc la raquette s'efface probablement avec les pixels noirs qui sont à gauche et à droite de ton sprite.
J'imagine même que si tu déplace la raquette très très vite, elle va laisser des morceaux derrière.
Sans CLS pour effacer l'écran, chaque frame est dessiné par dessus la précédente.
Mets un CLS après le _LIMIT 60

[drfloyd]

ah oui toujours effacer l'ecran à chaque boucle.

[65c02]

ah oui toujours effacer l'ecran à chaque boucle.

pas forcement toujours
dans le shake que j'ai fait pour les deukilos je n'efface pas volontairement l'écran pour "optimiser" 

[drfloyd]

oui ca dépend ce qu'on veut faire, et si on veut optimiser à mort.

Attention aussi avec les sprites lors de leur création de ne pas laisser trainer des pixels quasi invisibles proches de la couleur du masque.

[ocin]

Bah oui le CLS ! quel idiot lol.
Merci les dudes. Je vais pouvoir finir arkanoid 2015 !!

[F.L]

avec qb64, le cls ralentit pas mal....
il y a une solution, que j'avais utilisé pour barbarian qb64, c'est de re-d'afficher à chaque boucle la partie de l'ecran concerné, ça bouffe beaucoup moins de ressources qu'un CLS 

[ocin]

avec qb64, le cls ralentit pas mal....
il y a une solution, que j'avais utilisé pour barbarian qb64, c'est de re-d'afficher à chaque boucle la partie de l'ecran concerné, ça bouffe beaucoup moins de ressources qu'un CLS 

Ouf, dans le principe ça à l'air séduisant, mais dans la pratique: 1 je commence à peine (qb64 version locomotive ça serait top), donc je ne saurais pas faire.
Et 2, j'ai du mal à comprendre ce principe sur un casse brique. Cls autour de la balle et de la raquette ?

C'est vrai que parfois ça ralentis légèrement un court instant, mais c'est peut être mon eeePC qui est un peu juste ?

[ocin]

En fait c'est la balle qui "sautille" quand elle avance. C'est pas fluide quoi
Mon code cloche ?

Code:

REM $INCLUDE:'spritetop.bi'

CLS
SCREEN 7
SCREEN _NEWIMAGE(320, 200, 32)
DIM SHARED bksheet%
DIM SHARED ball%, raket%
DIM SHARED x, bx, by, hspeed, vspeed
DIM SHARED array(14, 14)

x = 20: bx = 0: by = 50: hspeed = 1: vspeed = 1
bksheet% = SPRITESHEETLOAD("breakout.png", 16, 4, _RGB(255, 0, 0))
raket% = SPRITENEW(bksheet%, 2, SAVE)
brick% = SPRITENEW(bksheet%, 3, SAVE)
bksheet% = SPRITESHEETLOAD("breakout.png", 4, 4, _RGB(255, 0, 0))
ball% = SPRITENEW(bksheet%, 1, SAVE)
bckg = _LOADIMAGE("sky.png")
SPRITECOLLIDETYPE raket%, BOXDETECT%
SPRITECOLLIDETYPE ball%, BOXDETECT%


DO
    _LIMIT 60
    CLS

    touches
    bx = bx + hspeed
    by = by + vspeed
    limits_ball
    bounce

    _PUTIMAGE (0, 0), bckg
    SPRITEPUT x, 100, raket%
    SPRITEPUT bx, by, ball%



    _DISPLAY
LOOP
SUB touches
IF _KEYDOWN(19712) THEN x = x + 4
IF _KEYDOWN(19200) THEN x = x - 4

END SUB
SUB limits_ball
IF bx = 320 THEN hspeed = -1
IF by = 200 THEN vspeed = -1
IF by = 0 THEN vspeed = 1
IF bx = 0 THEN hspeed = 1
END SUB
SUB bounce
IF SPRITECOLLIDE(raket%, ball%) THEN vspeed = -1
END SUB

REM $include:'sprite.bi'


[F.L]

oula, je n'avais pas vu que tu utilisais la librairie de pete pour gerer tes sprites....
pour commencer avec qb64 ça n'est pas du tout le top pour deux raisons :
- tu alourdis et complexifie ton code
- tu ralenti ton jeu
en utilisant cette librairie, tu est bien loin du locomotive basic !
pour commencer avec qb64, il vaut mieux commencer de maniere simple
pour afficher un sprite avec qb64, il te suffit de faire

Code:

monsprite = _LOADIMAGE("monsprite.png") ' charge en memoire une image
do
cls
_PUTIMAGE (x,y), monsprite ' coordonnée de l'image dans la boucle
_display ' affiche tout se qui sera à l'ecran
_limit 60 ' limite à 60 fps
loop

puisque tu utilisera un cls, ton image deviendra un sprite quand tu modifiera x et y
c'est tout bete et tu vas voir que ton programme sera deja plus leger et rapide !
en esperant que cela te serve

[drfloyd]

Oui, il ne faut pas utiliser de librairies, et en rester à du code classique.

[ocin]

Ok ok, exit la lib.
J'ai remis du code de base.
La balle sautille toujours...

Code:

SCREEN 7

DIM ball%
DIM SHARED x, bx, by, hspeed, vspeed

x = 20: bx = 0: by = 50: hspeed = 1: vspeed = 1
ball% = _LOADIMAGE("balle.png")

SCREEN _NEWIMAGE(320, 200, 32)

DO

    CLS
    touches
    _PUTIMAGE (bx, by), ball%
    limits_ball
    bx = bx + hspeed
    by = by + vspeed
    _DISPLAY
    _LIMIT 60
LOOP
SUB touches
IF _KEYDOWN(19712) THEN x = x + 4
IF _KEYDOWN(19200) THEN x = x - 4

END SUB
SUB limits_ball
IF bx = 320 THEN hspeed = -1
IF by = 200 THEN vspeed = -1
IF by = 0 THEN vspeed = 1
IF bx = 0 THEN hspeed = 1
END SUB


[drfloyd]

désolé je n'ai pas de PC sous la main, sinon j'aurai regardé (mon Mac ne fait pas tourner QB64)

Tiens, c'est peut etre ca :
passer par des SUB ca ne fait pas merder l'affichage en 60FPS ? (à voir)

[F.L]

j'ai regardé ton code. ça saccade aussi chez moi.
ça ne vient pas du cls car j'ai essayé de le remplacer et c'est toujours pareil
voici un petit exemple tres simple, de comment remplacer le cls

Code:

SCREEN 7
_FULLSCREEN
bx = 160
by = 100
DO
    LINE (bx, by)-(bx + 10, by + 10), _RGB(0, 0, 0), BF ' efface la balle par un carre noir
    IF _KEYDOWN(19712) THEN bx = bx + 1
    IF _KEYDOWN(19200) THEN bx = bx - 1
    IF _KEYDOWN(18432) THEN by = by - 1
    IF _KEYDOWN(20480) THEN by = by + 1
    IF _KEYDOWN(27) THEN END
    LINE (bx, by)-(bx + 10, by + 10), _RGB(255, 255, 255), BF ' affiche une "balle" blanche
    _DISPLAY
    _LIMIT 60
LOOP

pour avoir plus fluide ça va etre dur avec qb64
faut pas trop lui en demander. meme en javascript, deplacer un sprite pixel par pixel sur fond noir sans saccade,c'est pas evident 
@+

[ocin]

Ah oui pas la technique du carré. J'imaginais un truc comme ça.
Quoi ? Quoi ? Un super basic qui fait saccader une baballe en 2015 ?? Shame !!
C'est dommage, le STOS, de mémoire, ne saccadait sur son casse brique demo.
Et on parlait d'un simple 520 ste !
Sinon je vais faire un jeu d'exploration toue simple façon zelda (ecran par ecran). Les saccades seront moins gênantes sur les sentinelles.

[F.L]

j'ai essayé ton programme avec un background, et les saccades sont moins visibles qu'avec un fond noir

[drfloyd]

je pige pas trop le probleme de Ocin

quand je fais un jeu avec double scrolling sur tout l'ecran + plein de de sprites à l'ecran, c'est fluide....

Celui là par exemple :

Télécharger Crash Time Plumber Deluxe Edition

[drfloyd]

Apres si tu es fan du STOS sur Atari ST, je te conseille BLITZ 3D MAX.... c'est quasiment la meme chose... et c'est beaucoup plus convivial

Perso j'ai abandonné QB64 pour BLITZ, sans regret (meme si j'ai adoré QB64)

[65c02]

peut être un effet du limit 60
si son écran n'est pas à 60hz, il doit louper la frame de temps en temps

[tfdi]

65c02:Oui, je pense aussi que c'est la raison.

Si QB64 permet de selectionner la taux de rafraichissement quand on change la resolution, il faut choisir un resolution en 60hz, si tu veux avoir un maximum de fluidité avec ton _limit 60.

Sinon, tu peux aussi tester sans le _limit 60 pour voir ce que ca donne.

Après hein ... c'est du PC ... le terme "fluide" quand on parle de deplacement de sprite ou de scrolling n'est pour moi pas très adapté au pc .... ... ^^

[rendomizer]

Completement hs... mais je vous propose de bosser sur du php  (a)

qu'y a t'il de plus en php ? connais tu le basic? je cherche un langage puissant et pas compliqué

[ocin]

J'ai viré le limit 60, pour être fluide c'est fluide lol, on voit à peine le sprite !! Vitesse lumière !! J'ai mis un Delay dans la boucle pour ralentir un peu, et ça sautille toujours
Mon ecran est en 60hz (peut aller jusqu'à 75)
Bon je vais tester blitz alors

@tfdi " le terme "fluide" quand on parle de deplacement de sprite ou de scrolling n'est pour moi pas très adapté au pc .... ... ^^"
Bah avec un I7, je m'attendais à...mieux ?

[65c02]

Si tu mets ton limit à 5 au lieu de 60, tu verra l'animation au ralenti (hors les effets de synchro vbl)
Et si là ça saccade encore, c'est que tu as un problème d'algo.

[tfdi]

J'ai viré le limit 60, pour être fluide c'est fluide lol, on voit à peine le sprite !! Vitesse lumière !!

 
  ... 



Essaye avec blitz3D telechargeable sur le site officiel (je crois qu'il faut que tu crées un compte, puis tu vas dans Account (quand tu es connecté), et Register product pour voir ce que tu peux telecharger :

http://www.blitzbasic.com/Home/_index_.php

C'est gratos, et teste ce petit prog;

Code:

Graphics 640,480
SetBuffer BackBuffer()

box_x = -20
box_y = 100
While Not KeyHit(1)
Cls
Rect box_x,box_y,20,20,1
Flip
box_x = box_x + 1
If box_x = 640 Then box_x=-20
Wend


Chez moi c'est fluide ... enfin ... pour un PC .... ^^

C'est pas une question de processeur, le fait que t'es un CoreI7 ne te donnera pas un meilleur résultat là dessus que si t'avais un CoreI3 ou un Atom, c'est une question d'architecture.

Les PC sont mauvais en 2D ... faut pas leur demander des trucs fluides, ils ne savent pas faire ..