Per favore non mi fermate, solo aiutatemi nella mia autodistruzione [BB2]

[saimon69]

• 

@Amig4be

ti diro': da quel poco che ho smastricciato blitz non e' male finora, e la velocita' pare buona
visto che cmq per fare giochi mi serve di "tradurre" concetti e tutorial da altre parti, direi che il mio livello e' ancora troppo prematuro per andare avanti; fammi fare un altra milionata di tutorial (a trovarli pero') poi ti faro' sapere...
...cosa che mi fa inRazzare un po' e' il fatto che i sorgenti dei programmi aggiungono rumenta e non li posso editare sotto PC (al di la' dei problemi di endline) e la vista finestra di winUAE e' lentina sul mio portatile...

Una cosa che avevo capito ai tempi dello spectrum e' che i nemici ed i colpi devono essere trattati come "oggetti" nel senso piu' elementare del termine: aree definite di memoria con parametri come tipo nemico, coordinate, tipo di movimento, target se presente, energia, ecc. ma che non ero riuscito a programmare; ho visto che Blitz offre il comando NEWTYPE, simile alle strutture C per cui se volessi far qualcosa tipo shoot'em up o platform (o anche un clone di bejeweled) lo dovro' usare...

[saimon69]

• 

ok ho trovato un paio di articoli wiki sul pathfinding, ma non riesco a far diventare sta roba una procedura nella mia zucca: temo che l'algebra ferma alla trigonometria elementare faccia sentire il suo peso in codesto caso...
Pathfinding da Wikipedia
Trigonometry for Game Programming

non mi serve certo per il gioghetto tetris ma siccome in futuro avrei qualche ideuccia per platforms o sparatutto ecco che mi pareva cosa interessante risolvere i miei problemi nel non saper come programmare sta roba.

Mi sento come quando il Zuck nel film "the social network" ha l'amico che scrive l'algoritmo per il confronto facce sulla finestra: non ho la capacita' di astrarre a formula matematica un problema, piuttosto ho un approccio schiacciasassi: comincio a pestare le ditine sulla tastiera fino a che ne esce qualcosa... e penso visualmente.

[raistlin77it]

• 

...cosa che mi fa inRazzare un po' e' il fatto che i sorgenti dei programmi aggiungono rumenta e non li posso editare sotto PC (al di la' dei problemi di endline) e la vista finestra di winUAE e' lentina sul mio portatile...

per editarli da pc, devi salvarli in ascii .
Vai in project -> save ascii

così puoi editarli da pc, occhio al lineend e CR vari

Una cosa che avevo capito ai tempi dello spectrum e' che i nemici ed i colpi devono essere trattati come "oggetti" nel senso piu' elementare del termine: aree definite di memoria con parametri come tipo nemico, coordinate, tipo di movimento, target se presente, energia, ecc. ma che non ero riuscito a programmare; ho visto che Blitz offre il comando NEWTYPE, simile alle strutture C per cui se volessi far qualcosa tipo shoot'em up o platform (o anche un clone di bejeweled) lo dovro' usare...

eh si, sopratutto per i platform è meglio ragionare a rettangoli, uno per il giocatore, un'altro per il nemico etc etc .
una volta che tutto funziona a dovere, togli i rettangoli e ci piazzi gli sprite/bob .


ti posto un link con un sacco di tutorial però per actionscript

http://www.tonypa.pri.ee/tbw/start.html
oppure qua, anche se non ci sono sorgenti
http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/
od anche qua:
https://sites.google.com/site/palibwiki/tutorials/day-13





tieni presente che ad esempio una struttura in c tipo :

typedef struct player_ {

      float x,y;
      int alive;
}player_;

player_ p1;


diventa in blitz


NEWTYPE .player_
     x.q
     y.q
     alive.b
End NEWTYPE


DEFTYPE .player_ p1

io in particolare mi trovo bene a fare degli esperimenti veloci in c+sdl ed una volta che tutto funziona, li trasporto in blitz2 e testo su winuae

purtroppo ormai non ci sono moltissimi tutorial che possano andare bene per i vecchi amiga, perchè i tool più in voga hanno tutti un qualche motore fisico alle spalle, quindi box2d, ode, un sacco di vettori e matrici. Quando per programmare un gioco 2d "old school" basta veramente poco ed una manciata di calcoli "spannometrici"

[saimon69]

• 

...cosa che mi fa inRazzare un po' e' il fatto che i sorgenti dei programmi aggiungono rumenta e non li posso editare sotto PC (al di la' dei problemi di endline) e la vista finestra di winUAE e' lentina sul mio portatile...

per editarli da pc, devi salvarli in ascii .
Vai in project -> save ascii

così puoi editarli da pc, occhio al lineend e CR vari

Sclero, soprattutto notepad++ mi mostra una selva di caratteri nascosti! Poi che TED [l'editor linkato a BB] usare? io penso di usarne uno che e' a meta' tra blitz2.1 e amiblitz2

ti posto un link con un sacco di tutorial però per actionscript

http://www.tonypa.pri.ee/tbw/start.html

Questo me lo ricordavo, me lo son perso nella marea di link!
Appena riesco a portare piu' avanti i tutorial mi mettero' a tradurre un po' di esperimenti da li un possibile G'n'G in BB si avvicina... (da 10 parsec di distanza, a 30 km/h pero'...)

[aggiunta]

hmm l'approccio di Flash per le mappe e' quello -chiaramente- di avere ogni tile come istanza swf con la sua variabile walkable; in un gioghetto Amiga questo approccio e' imo deleterio e rallenterebbe tutto, che alternative? Maschera con un bitplane extra? E come si gestisce?

[/aggiunta]

[raistlin77it]

• 

Sclero, soprattutto notepad++ mi mostra una selva di caratteri nascosti! Poi che TED [l'editor linkato a BB] usare? io penso di usarne uno che e' a meta' tra blitz2.1 e amiblitz2

io ho PED v2.44 04.15.2006 (dovrebbe esere il superTED)

ti posto un link con un sacco di tutorial però per actionscript

http://www.tonypa.pri.ee/tbw/start.html

Questo me lo ricordavo, me lo son perso nella marea di link!
Appena riesco a portare piu' avanti i tutorial mi mettero' a tradurre un po' di esperimenti da li un possibile G'n'G in BB si avvicina... (da 10 parsec di distanza, a 30 km/h pero'...)

[aggiunta]

hmm l'approccio di Flash per le mappe e' quello -chiaramente- di avere ogni tile come istanza swf con la sua variabile walkable; in un gioghetto Amiga questo approccio e' imo deleterio e rallenterebbe tutto, che alternative? Maschera con un bitplane extra? E come si gestisce?

[/aggiunta]

la cosa più semplice come inizio è crearti un array (y*x) di valori ad esempio  (questo in c):

int level[5][5]={{1, 1, 1, 1, 1},
                        {1, 0, 0, 0, 1},
                        {1, 0, 0, 0, 1},
                        {1, 0, 0, 0, 1},
                        {1, 1, 1, 1, 1}};

in questo caso gli 0 sono i tile vuoti e gli uno quelli pieni e quando muovi il tuo "omino" controlli se alla posizione x/tilesize,y/tilesize (se i tuoi tiles sono di 16 pixels x/tilesize -> x/16) sbatte contro un tile pieno oppure vuoto

se stasera ho un po' di tempo ti faccio un programmino commentato in bliz da provare ^^'

perchè fai prima a vedere che io a spiegarti

[saimon69]

• 

@raistlin77it

potrebbe fuinzonare per mappe piccole ma per giochi alla G'n'G la vedo tosta, eccop perche' in stile spectrum volevo far fare il "lavoro sporco" agli attributi...

[Amig4be]

• 

@Amig4be

ti diro': da quel poco che ho smastricciato blitz non e' male finora, e la velocita' pare buona

è questo?
http://amiblitz3.sourceforge.net/

[raistlin77it]

• 

@Amig4be

ti diro': da quel poco che ho smastricciato blitz non e' male finora, e la velocita' pare buona

è questo?
http://amiblitz3.sourceforge.net/

no quello è la versione 3 che funziona meglio sugli amigaNG/amiga con acceleratrici+scheda video

quello vecchio, che funziona su classic lo trovi qua ad esempio http://www.david-mcminn.co.uk/blitz-2000/archives/bb2/

[raistlin77it]

• 

@raistlin77it

potrebbe fuinzonare per mappe piccole ma per giochi alla G'n'G la vedo tosta, eccop perche' in stile spectrum volevo far fare il "lavoro sporco" agli attributi...

bhè certo con gli attributi fai prima,però devi "embeddare" gli attributi insieme alla mappa e fare un qualcosa del tipo (ad esempio ) : tile 220 = solido, 220-128 =92 = solido che rallenta il player

per fare una cosa del genere conviene lavoare in binario e shiftare i vari bit per beccare le varie opzioni del tile, sennò non ti bastano un mega per una mappa grande

e visto che ad esempio il tipo byte del blitz va da -127 a +127  è un po' un casino perchè ti tocca usare long nel blitz, ma se salvi da pc le mappe poi devi swappare i byte
insomma prima di Ghost 'n Goblins parti da bubble bobble (che non è semplicissimo lo stesso )

domani mattina finisco il listato e te lo passo

edit eccolo qua :

https://www.sendspace.com/file/pdoeuf

[cdimauro]

• 

Dipende da quanto dev'essere grande la mappa. Per USA Racing occupavano 128K e lo schermo virtuale era di 8192x65536 pixel, usando 1 byte (unsigned: 0..255) per ogni tile.

Per cui Simone non dovrebbe avere alcun problema ad adottare una soluzione simile. Anzi, la mappa DEVE essere più ridotta, altrimenti il giocatore impiegherà una vita per visitarne interamente una, e a lui ne servirebbero 100 per disegnarla.

A ogni tile sarà poi possibile associare una tabellina con gli attributi per definirne le caratteristiche (libera, bloccata, parzialmente bloccata, ecc.).

[Allanon]

• 

Sono d'accordo con Cesare, una tabella per la mappa e una tabella per le tile, e ad ogni tile un byte di attributi bitmasked.
Non sono esperto di bb2 ho pistolato solo con BlitzMax, l'erede di bb2 su Windows, credo che i concetti base siano i medesimi quindi dovresti essere in grado di creare strutture dati agevolmente.

Tanto per ragionare assieme:
supponiamo che per ogni mappa al massimo hai 256 tipi di tile differenti e che le tile siano 16x16 pixel, una mappa di 4096x4096 sarebbe memorizzata in una tabella di 4096/16 x 4096/16 = 256x256 byte = 65k
Poi hai la tabella delle tile, supponiamo che ne utilizzi tutte e 256 avresti una tabella di 256 elementi dove ogni elemento ha:
- un brush per la tile di 16x16 = 256 byte x bitplane, supponendo che ne usi 4 avresti 1k per ogni tile
- un byte bitmasked per gli attributi:
--- 00000000 = tile normale
--- 00000001 = tile bloccante
--- 00000010 = tile che rallenta il player
--- 00000100 = tile che fa morire il player
--- ecc...
Quindi al massimo avresti altri 65k per la mappa + 256k+256b per le tile, ma 256 tile diverse per ogni mappa sono veramente tante

[saimon69]

• 

@allanon

Chiaro che avere il dual playfield aiuta in sti casi penso, tieni le tiles di background dietro e gli elementi di contatto davanti, poi ci perde in colorazione pero' - a meno che non si usi primi 16 colori per le tiles visive e gli altri 16 per personaggi e tiles di collisione si che il quinto bitplane fa da maschera (puramente ipotetico)

[cdimauro]

• 

Non c'è nessun quinto bitplane se hai intenzione di usare il dual-playfield: nei hai 4 (16 colori) per lo schermo dello sfondo, e altrettanti (ma 15 colori) per quello davanti. A questi si aggiungono poi gli sprite, che normalmente condividono la stessa palette del secondo schermo (davanti), ma che si possono "spostare" in altre zone della palette dei 256 colori. Questo per l'AGA.
Per l'ECS hai 3 bitplane per ogni schermo, quindi 8 + 7 colori, mentre gli sprite hanno una palette a sé stante.

Comunque dovresti definire intanto che tipo di gioco vuoi utilizzare (e da questo si capisce pure se deve andare a 50 oppure a 25Hz), e valutare se è il caso di usare il dual playfield, perché la qualità visiva si riduce drasticamente. Devi anche definire se vuoi realizzare un gioco per ECS o per AGA.

Fissati questi elementi, si può capire quanto spazio sarà a disposizione, e di conseguenza fare le prime valutazioni sul numero di tile, la loro dimensione, numero di colori, ecc.

[saimon69]

• 

@cdimauro

Chiaro che tutte ste cose per un tetris non servono ma in futuro volevo mettermi a fare anche qualche cosa platform based - solo che piu vado avanti piu' riconosco che ne ho un sacco di strada da fare...

[cdimauro]

• 

Per un Tetris abbiamo discusso anche troppo. Troppissimo!

Buttati e cominciare a scrivere codice: schermo unico, niente dual-playfield, e niente tile.