NSA - Non Solo Amiga
SOFTWARE => Sistemi Operativi => AmigaOS 1.0 - 3.x => Topic aperto da: saimon69 - 13 Febbraio 2015, 19:53:35
-
Ho un paio di idee semplici che vorrei finalmente dopo anni vedere incarnate in un gioco per Amiga classic, e quindi per farlo sto cercando di imparare Blitz Basic 2. Purtroppo tutorial ben esplicativi mancano; nessuno ha delle risorse cui puntarmi?
-
come ti dicevo su eab io ho scaricato a suo tempo i sorgenti di "red wizard island" se vuoi te li mando via mail :)
altri sorgenti/tutorial è molto difficile trovarli, tocca scavare in siti morti con waybackmachine.
se proprio sei autolesionista (come me che stò smanettando col blitz) ti passo un po' di doc esempi che nel tempo ho raccolto nei posti più svariati :)
-
Se hai qualche sorgente per un programma che crea un Tetris mi aiuta immensamente :)
-
purtroppo non c'è nulla negli esempi che riguardi il tetris.
ho trovato però questa pagina che offre sorgenti in c , flex, sdl , per creare un clone di tetris :)
è quanto di più vicino ad un tutorial sul tetris che abbia trovato.
ovviamnete và adattato al blitz basic :)
http://www.developerfusion.com/project/34549/simpletetrisclone/
-
@saimon69
Questi link li hai già visti?
Click (http://www.amigacoding.com/index.php/BlitzBasic:Resources)
-
@allanon
si li ci son passato, piuttosto mi ero imbattuto in questo tutorial in portoghese che da alcune basi ma e' incompleto senno' spiega al livello che mi serve:
Tutorials di Labritcho per Blitz quattro parti (https://labritcho.wordpress.com/)
-
@raistlin77
Un tre/quattro anni fa avevo modificato un clone di tetris in flash in modo da comportarsi come volevo: ovvero ricreare il gioco Flashpoint (se non lo avete mai visto e' una variante di tetris dove si devono eliminare punti lampeggianti per vincere) ed e' quello che vorrei rifare: se ritrovo il .fla lo metto in linea.
Poi magari dopo aver creato il gioghetto di base trovo anche il modo di aggiungerci le varie features come velocita', bonus, e farlo a due giocatori :)
FlashPoint - Sega (https://www.youtube.com/watch?v=GW1_pr2vJeY)
-
ok ravanata la rete per tutorials e simili, trovato poco altro; questo sito (http://dragotech.net/tutorials/) dove ci sono diversi tutorial non solo blitz in pdf archiviato in rar dovrebbero aiutare.
Ho fatto ieri sera il primo tutorial di Amiga format: Blitz out (clone scrauso di Arkanoid) - allora: lo shapemaker non funzionava ed ho dovuto trovare un altro tutorial piu avanti che mi insegnasse come catturare le shapes. Inoltre alcuni bachi e una scansione di non buona qualita' mi han fatto perder del tempo, oltre a piantoni del debugger.
-
In assenza di Python + libreria PyGame, perché non provi con Hollywood? E' più moderno, e pure multipiattaforma.
-
@saimon69
Se decidi di utilizzare Hollywood posso dare una mano, tra l'altro ho anche molte librerie che ho sviluppato in questi anni pronte per essere utilizzate :)
-
Io sto cercando di fare retrogames su piattaforma classic OCS/ECS (usando winuae) e per ora sti strumenti mi van bene, per progetti piu' avanzati vedro'...
Hollywood non mi spiacerebbe per progetti NG e RTG, ed ha una sintassi lua-like ma ha il contro di esser commerciale pero' mentre io soffro della sindrome da braccino corto :/
Ma veramente a voi leggere la rivista non vi ha fatto pensare come mai ci son tanti nuovi giochi retro per 64 e spectrum (vedi il nuovo castlevania) mentre per amiga sta roba si conta sulle ditine delle mani?
Ho diverese ideucce che volevo realizzare con i five stars e che ai tempi sono state messe da parte; visto che gli altri frega gnente del retro ho deciso di provare a farle da me: alla fine potranno anche far schifo ma visto che lo fo per hobby non ci son grandi pretese...
...e parte dell'hobby e' farlo per sistemi retro come le macchine OCS ed ECS, vedi Gabriele che sta rifacendo robba su imagine
-
Io sto facendo a tempo perso un remake di Moon Patrol, tanto per testare e ampliare una libreria che sto finendo :)
Dovrebbe compilare su tutto.
-
@Simone: ci vuole troppo tempo per tirare fuori qualcosa d'interessante per le macchine ECS/AGA. Meglio impiegare il proprio tempo per AROS.
-
io ho iniziato a smanettare un po' con SAS/C su Amiga4000 e WinUAE, ma non ho intenzione di sviluppare niente di particolare, solo passatempo per quei pochi minuti che riesco a dedicarvi :)
-
dimmi un po', come e' ? cosa permette di fare in scioltezza ?
Tutto quello che vuoi su Amiga, parliamo pur sempre di un compiler ANSI C89 in ambiente NON posix.
Ergo, non è roba per te che sei unixaro :D
-
la sola opzione per creare giochi sugli amiga, senza passare dall'assembler è il blitz basic 2. (l'amos è lento, hollywood vuole almeno una RTG, purebasic parte dal wb ed il c se vuoi essere veloce lo devi usare come front-end dell'assembler)
io ti consiglio di scaricarti il blitz basic 2.qualcosa, non l'amiblitz perchè è pensato per i sistemi ppc o winuae.
BippyM su eab aveva messo un'archivio da decomprimere che conteneva il blitz2+patch fino all'ultima versione funzionante sulle macchune 68x00.
-
Amos è lento si... però permette di fare le cose con enorme semplicità. Per giochi che non puntano sull'impatto tecnico potrebbe andare bene.
Il professional con tutti gli strumenti e il compilatore ora è free...
-
Beh, io sto studiando anche l'Amiga Hardware Reference Manual, che spiega come usare i registri hardware dell'OCS per fare grafica low level. Gli esempi sono in ASM, ma si possono tradurre in C volendo (magari non tutto, alcune cose meglio lasciarle in ASM).
Non penso che ci farò nulla di interessante, ma è una bella lettura serale da tenere sul comodino, smanettando con gli esempi sopra WinUAE :D
-
ma a parte cio', dicevi dei builder script, come sono ?
tipo automakefile, autoconfig, automagic, o roba + golosa ?
Nope. Molto più elementare.
generano il makefile in automatico ? e sempre in automatico interfacce private e pubbliche ?
si smazzano la dipendenza intra modulo come fa il builder objC di nextStep ?
nope. Semplicemente ci sono dei makefile di default che compilano tutto ciò che è *.c e amen.
e per la parte di interfaccia uomo macchina, grafica
generano form automatici tipo visualC (e na roba simile la fa anche project builder di nextStep) ?
Su Amiga? Ma dai :D
Niente di tutto questo, molto più elementare. Codice a manella e pedalare! :D
cmq dal book che diceva Cesare, e che finalmente mi e' arrivato
amiga non sarebbe amiga se non avesse sotto m68k e power chips custom
c'e' scritto in grassetto che molta roba e' in asm e punta direttamente al low level
molta parte di amiga/OS, e in minima parte e' scritto in C
per cui e' troppo legato a faccende di basso livello per poterla astrarre altrove
anche se qualcosa di sicuro scavo, estraggo, e porto via :D
al contrario Risc/OS ha una minima parte in assembly, e molta parte in C
e grava quasi tutto sulla CPU, eccetto la video unit integrata nell'arm chip
e qualche altra faccenda DMA esterna con trucchetti anche osceni tipo per le acquisitrici
tutto sommato si fa un gran bel bottino, mi riempio il sacco tipo babbo natale, tanti bei regali :D
Yep, Amiga ti da molte astrazioni di alto livello (tutta la struttura GUI è Object Oriented, anche se in C), ma se non vuoi usarle ti consente di toccare l'hardware come si fa sulle console da gioco (e qui si vede il tocco di Jay Miner, che era il designer dell'Atari 2600, un uomo abituato a progettare console da gioco appunto).
-
Chissà il mio kit di sviluppo GameSmith che fine ha fatto... dettagli (http://www.amigareport.com/ar231/p2-2-3.html)
-
@cdimauro e gli altri
azz facevano cloni di tetris in AMOS come se piovesse, faccio forse il male del mondo se creo il mio in blitz? ^^
(poi posso fare anche il resto in altri linguaggi ma intanto fatemi iniziare a fare giochi scarsi e scrausi cosi ci riprendo la mano)
-
Tutto quello che vuoi su Amiga, parliamo pur sempre di un compiler ANSI C89 in ambiente NON posix.
Ergo, non è roba per te che sei unixaro :D
mi rifaro', forse, su Risc/OS
c'e' una bella e simpatica libreria di compatibilità unix
nemmeno a farlo apposta mi e' cascata sui piedi X___X
Che te ne fai? Bah :-\
ma a parte cio', dicevi dei builder script, come sono ?
tipo automakefile, autoconfig, automagic, o roba + golosa ?
generano il makefile in automatico ? e sempre in automatico interfacce private e pubbliche ?
si smazzano la dipendenza intra modulo come fa il builder objC di nextStep ?
e per la parte di interfaccia uomo macchina, grafica
generano form automatici tipo visualC (e na roba simile la fa anche project builder di nextStep) ?
robe cosi' ?
All'epoca non esisteva roba del genere. Io scrivevo & riempivo a manina le strutture dati per creare i widget (chiamati gadget in gergo amighista).
Però qualche editor di GUI è sicuramente stato sviluppato, ma non mi sono mai interessato, perché ormai il mio AIDS (Amiga Integrated Development System) l'avevo già scritto (tutto in assembly).
cmq dal book che diceva Cesare, e che finalmente mi e' arrivato
amiga non sarebbe amiga se non avesse sotto m68k e power chips custom
c'e' scritto in grassetto che molta roba e' in asm e punta direttamente al low level
Mi fa piacere che ti sia arrivato. Vedrai che sarà una goduria smazzartelo.
Concordo con quello che hai scritto.
molta parte di amiga/OS, e in minima parte e' scritto in C
per cui e' troppo legato a faccende di basso livello per poterla astrarre altrove
Considera che quel libro è vecchio e copre soltanto il chipset OCS, l'Amiga 1000, e il Kickstart fino all'1.2 (mi pare), per cui è vero quanto è riportato.
Però dalla versione 2.0 la maggior parte del s.o. è stata riscritta in C, e soltanto una piccola parte è rimasta in assembly. Non ricordo di preciso adesso, ma mi pare che il rapporto fosse 90/10.
anche se qualcosa di sicuro scavo, estraggo, e porto via :D
Facci sapere. :P
al contrario Risc/OS ha una minima parte in assembly, e molta parte in C
Hum. Mi pare molto, molto strano, perché so che l'architetto della CPU scrisse pure parecchio codice assembly per il software dell'Archimedes.
e grava quasi tutto sulla CPU, eccetto la video unit integrata nell'arm chip
e qualche altra faccenda DMA esterna con trucchetti anche osceni tipo per le acquisitrici
In realtà la VDU non fa altro che visualizzare la grafica, quindi non aiuta la CPU. Inoltre, se non ricordo male, per l'audio digitale c'è un solo canale DMA (o due per lo stereo? Boh) che viene utilizzato per leggere i dati di tutti i canali audio (che erano 8 in totale: meglio dell'Amiga; ma è arrivato anche ben dopo, eh! Come l'Apple II GS), per cui la CPU si deve occupare di riempire opportunamente il buffer che viene mandato al canale DMA che si smazza poi l'audio, mentre su Amiga ci sono 4 canali DMA totalmente indipendenti, per cui la CPU ne imposta i registri una volta, e poi se ne dimentica.
Dunque praticamente tutto è a carico della CPU. E va benissimo così, perché era il suo punto forte.
L'Amiga non aveva una CPU così potente, ma in compenso possedeva un meraviglioso chipset che è stato una goduria spremere come un limone, inventando tanti trucchetti.
tutto sommato si fa un gran bel bottino, mi riempio il sacco tipo babbo natale, tanti bei regali :D
Mah. Lo so che ARM & RISCOS = UK, ma francamente come sviluppatore non mi attira nessuno dei due. Poi RISCOS è veramente scarso come s.o..
Chissà il mio kit di sviluppo GameSmith che fine ha fatto... dettagli (http://www.amigareport.com/ar231/p2-2-3.html)
Dalla descrizione sembra molto interessante, specialmente per chi non vuole sporcarsi le mani a basso livello.
@cdimauro e gli altri
azz facevano cloni di tetris in AMOS come se piovesse, faccio forse il male del mondo se creo il mio in blitz? ^^
Ma no, anzi ti sbrigherai lo stesso rispetto a lavorare in C o, peggio, in assembly.
(poi posso fare anche il resto in altri linguaggi ma intanto fatemi iniziare a fare giochi scarsi e scrausi cosi ci riprendo la mano)
Francamente non ne ho più voglia. Poi ho così poco tempo a disposizione, che preferisco impiegarlo in qualcosa di più utile.
Ti faccio un piccolo esempio di come potresti impiegare più utilmente il tuo tempo, pur divertendoti ugualmente (almeno spero; per me lo sarebbe). Ti sei lamentato dei problemi di validazione spuntano fuori ogni tanto in AROS con SFS? Perché intanto non cominci a crearti uno scriptino Python che ti legge la struttura del filesystem? Python ha una bellissima libreria, chiamata struct, che ti consente di mappare (decodifica, e pure codifica ovviamente) velocemente e semplicemente le strutture utilizzate dal filesystem. Un primo piccolo passo per arrivare poi a fare cose più interessanti, come appunto il fix del filesystem sistemando la roba errata che hai trovato. E così via, perché di idee ce ne sono tantissime su roba realmente utile, e che ad AROS serve come il pane.
Poi, lo so: de gustibus. A magari a te piace fare tutt'altro.
-
[snippone totale]
Francamente non ne ho più voglia. Poi ho così poco tempo a disposizione, che preferisco impiegarlo in qualcosa di più utile.
Ti faccio un piccolo esempio di come potresti impiegare più utilmente il tuo tempo, pur divertendoti ugualmente (almeno spero; per me lo sarebbe). Ti sei lamentato dei problemi di validazione spuntano fuori ogni tanto in AROS con SFS? Perché intanto non cominci a crearti uno scriptino Python che ti legge la struttura del filesystem? Python ha una bellissima libreria, chiamata struct, che ti consente di mappare (decodifica, e pure codifica ovviamente) velocemente e semplicemente le strutture utilizzate dal filesystem. Un primo piccolo passo per arrivare poi a fare cose più interessanti, come appunto il fix del filesystem sistemando la roba errata che hai trovato. E così via, perché di idee ce ne sono tantissime su roba realmente utile, e che ad AROS serve come il pane.
Poi, lo so: de gustibus. A magari a te piace fare tutt'altro.
Dopo anni di linguaggi di scripting ritornare a lavorare con aree di memoria e' duro: di solito questi le maneggiano per te,e ho forti deficienze tipo niente puntatori e simili: io per ora mi ci voglio divertire con la programmazione (far giochini mi divertiva); quando avro' ripreso piu' confidenza tanto da voler imparare roba "seria" poi vedro' di diventare piu' utile
pero' quando dico "non mi fermate" nel subject intendevo proprio fatemi fare le cose come dico io, datemi solo dritte per farle...
(riarrangiato che mi si era perso il quote)
-
Francamente non ne ho più voglia. Poi ho così poco tempo a disposizione, che preferisco impiegarlo in qualcosa di più utile.
Eh si. Vedi home vs personal computer. ;D ;D ;D
-
Francamente non ne ho più voglia. Poi ho così poco tempo a disposizione, che preferisco impiegarlo in qualcosa di più utile.
Eh si. Vedi home vs personal computer. ;D ;D ;D
High Five!
-
Francamente non ne ho più voglia. Poi ho così poco tempo a disposizione, che preferisco impiegarlo in qualcosa di più utile.
Eh si. Vedi home vs personal computer. ;D ;D ;D
Il forum è cazzeggio, relax. Non si può passare l'intera giornata a lavorare. ;)
Che te ne fai?
con gcc-sdk + quella libreria + una scheda di rete + qualche piccola modifica
ho pronto in un paio di settimane, tutto il porting di un paio di cose che adesso girano su linux
piccoli server e la stessa tap-machine
poi, con il porting che han fatto di VIM, posso tirare fuori qualcosa per supplire ad ncurses
ed ho pronta anche l'interfaccia testo :D
GLOM. E' quando legga roba come questa che penso che siamo diametralmente opposti. IO ODIO VIM!!!!! Infatti faccio installare o installo joe quando sono costretto a lavorare in ambiente Linux, a costo che mi scarico i sorgenti e me lo compilo da solo. :'(
Hum. Mi pare molto, molto strano, perché so che l'architetto della CPU scrisse pure parecchio codice assembly per il software dell'Archimedes.
io noto che gran parte dei sistemi di sviluppo sono stati pensati appositamente per il C
difatti c'e' anche un apposito debugger con un formato creato proprio per lo scopo
e mi va bene, perche' i debugger sono cose che mi interessano :D
Sì, ma poi bisogna vedere quanti hanno usato il C, e quanti l'assembly. E il BASIC, che era pure molto gettonato.
In realtà la VDU non fa altro che visualizzare la grafica
hanno integrato il Video Controller VIDC20 (http://en.wikipedia.org/wiki/VIDC20) :D
Visto tutto, ma come puoi notare tu stesso, non c'è alcuna funzione di accelerazione hardware. E' la CPU che deve smazzarsi tutto il lavoro. Il VIDC pensa esclusivamente a visualizzare la grafica, più il classico sprite utilizzato per il puntatore del mouse. La gestione del sonoro è all'incirca come ricordavo, ma un po' più limitata visto che devi scegliere per forza fra 1, 2, 4 o 8 voci.
Niente da fare: con l'Archimedes devi pensare a fare tutto da solo. Niente aiuti.
-
@legacy
Te come smanettone professionista lo sai che certi smanettamenti hanno tutto un'altro sapore in salsa retro... guardate queio giochetti che portano su AROS cloni di giochi vecchi amiga, purtroppo l'alta risoluzione li fa sembrare scialbi, anche perche' poi la grafica in alta necessita di ben altre skills di quelle del pixelatore...
-
Ma perché non fai un clone di Blitzkrieg?
perche' con le mie "skills" se verrebbe fuori cosi' (https://www.youtube.com/watch?v=ahr9iMB7TYQ&index=8&list=EL6dMcJGmYyko) sarebbe gia' un miracolo :/
-
Onestamente quando facevo i giochini in basic su spectrum raramente ero riuscito a far muovere piu' di un nemico (ok max 4), e non parliamo di cose tipo pathfiniding e inseguimenti che non siano alle coordinate... cio' un sacco da lavorare li - i miei nemici non avevano AI ma AD*
*AD=Artificial Deficiency o Deficienza Artificiale
-
io credo che l'amos professional sia l'ideale visto che a priori escludi la possibilità di giochi con un impianto tecnico di primo ordine. L'Amos ti permette di sfruttare decentemente l'hardware con poche istruzioni, poi alla fine compili tutto. Il sistema di debug era molto bello (attenzione ti parlo avendolo usato da giovanissimo molti anni fa), importi grafica facilmente dai formati classici amiga. Una valanga di extras, tutorial ed esempi molto utili.
Purtroppo non c'è l'aga... quella è la fregatura.
-
@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...
-
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 (http://en.wikipedia.org/wiki/Pathfinding)
Trigonometry for Game Programming (http://www.raywenderlich.com/35866/trigonometry-for-game-programming-part-1)
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.
-
...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"
-
...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]
-
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 :)
-
@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
ti diro': da quel poco che ho smastricciato blitz non e' male finora, e la velocita' pare buona
è questo?
http://amiblitz3.sourceforge.net/
-
@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
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
-
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.).
-
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
-
@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)
-
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.
-
@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...
-
Per un Tetris abbiamo discusso anche troppo. Troppissimo! ;D
Buttati e cominciare a scrivere codice: schermo unico, niente dual-playfield, e niente tile.
-
sto lavorando a portare un sorgente dal blitz pc con l'aiuto di qualcuno su EAB, ma ho perso la manina quindi le cose vanno a rilento - la sintassi non-ECMA del blitz non aiuta...
-
Sai, compare, per ora mi diverto a mandare a massa qualche porta nastrando i cavi e cercando di capire come funzionano le PCB dei pad.. sono all'inizio, non sono un genio e neanche fingo di esserlo.. però mi piace creare qualcosa di mio, soprattutto creare quello che normalmente in commercio non c'è per le mie esigenze (ad esempio il BovinGear).. diciamo che mi sto preparando la roba per continuare a videogiocare anche l'estate ;D
E poi, le bovinate, mi tengono lontano dal cibo.. che con la mia malattia è una cosa fondamentale ;D
sta zitto che cio la sciura in pre-diabete :( ed io con colesterolo alto che ho dovuto tagliare la maggioranza della roba fritta :(
-
in effetti da quando si è verificato quel problema di salute, l'esplosione creativa è stata senza precedenti... e lo dico io che quando mi coglie il parossismo creativo sono rovinato (tipo che non si dorme e non riesco più a fare altre cose con la necessaria attenzione)
-
Dopo diversi smanettamenti e MOLTO aiuto da parte dy Cylon sono riuscito a far sorta funzionare quel clone di tetris; adesso devo lavorare per adattarlo alle mie esigenze.
-
Cerco di portare una immagine dal thread su EAB: e' ancora ancorato a una risoluzione PC (800x600) e ridisegna tutto ogni volta, ma spero di imparare a fare il double buffering per accelerarlo; il mio (sognato) risultato finale dovrebbe essere in bassa a 32 colori e usare grafica bitmap;
Attualmente la versione corrente di cui non ho screenshots e' meglio: testi nella posizione giusta, next pulito e l'aggiunta del pezzo a T che per un bug non veniva scelto.
(https://binarydoodles.files.wordpress.com/2015/05/blitztetris34.jpg)
-
@raistlin77
Tu hai niente che mi possa indicare come fare double buffering? Il manuale e' un po' fumoso a riguardo;
Oltre ad avere uno scheletro di platform da usare per cercare di fare test, chiaro :)
-
Guarda, in realtà è una stupidata, ed è una tecnica che va bene per qualsiasi gioco :)
Ora ti spiego.
Prima di tutto ti crei 2 bitmap identici.
Visto che l'amiga non è molto veloce nel disegnare la grafica, devi ridurre il più possibile le cose da disegnare a schermo ogni 50 secondi.
perciò come prima cosa disegni su tutti e 2 i bitmap quelle parti dello schermo del gioco che di sicuro non cambiano mai, come ad esempiol'area di gioco, la parte col prossimo pezzo, la scritta score etc etc.
Ti ho fatto un mockup con immagini prese da internet :)
(http://s29.postimg.org/5v01ulodz/sfondo.png) (http://postimage.org/)
una volta che hai i 2 bitmap uguali, mostri l'uno e disegni sull'altro :)
con questo codice :)
Buffer 0,16384
Buffer 1,16384
bm.b=0
---------------- loop ---------------
DisplayBitMap 0,bm,0,0
bm=1-bm
UnBuffer bm
Use BitMap bm
Gosub logica_del_gioco
Gosub disegna_qualcosa
------------- end loop -------------
Allora cosa succede, prima di tutto ti crei 2 buffer (rispettivamente lo zero e l'uno) dove il blitz andrà a salvare la parte del bitmap che andrai a coprire con quello che disegnerai, in modo poi da poter cancellare le modifice e tornare al bitmap originale .
Dopodichè ti crei una variabile bm che indica il bitmap che vuoi mostrare ( da notare che 1-bm oscilla tra 0 e 1 e quindi a turno ti mostra la bitmap 0 o 1)
nel loop:
al momento 0 :
- mostri la bitmap bm ( in questo caso la zero) -----> DisplayBitMap 0,bm,0,0
- cambi la bitmap sulla quale disegni -----> bm=1-bm (quindi sulla bitmap 1 )
- cancelli tutte le cose disegnate precedentemente nel buffer -------> UnBuffer bm (quindi sul buffer 1 anche se non abbiamo disegnato ancora niente perchè siamo al momento zero)
- usi la nuova bitmap (la 1 per disegnare ) -----> Use BitMap bm
- vai alla routine di logica e poi a quella di disegno
al momento 1 :
- mostri la bitmap bm ( ora è diventato uno ) -----> DisplayBitMap 0,bm,0,0
- cambi la bitmap sulla quale disegni -----> bm=1-bm (quindi ora sulla bitmap zero )
- cancelli tutte le cose disegnate precedentemente nel buffer -------> UnBuffer bm (quindi sul buffer 0 )
- usi la nuova bitmap (la zero per disegnare ) -----> Use BitMap bm
- vai alla routine di logica e poi a quella di disegno
al momento 2 :
- mostri la bitmap bm ( ora la zero ) -----> DisplayBitMap 0,bm,0,0
- cambi la bitmap sulla quale disegni -----> bm=1-bm (quindi ora sulla bitmap uno )
- cancelli tutte le cose disegnate precedentemente nel buffer -------> UnBuffer bm (quindi sul buffer 1 perchè poi ci andrai a disegnare e ti serve lo schermo pulito dalle mosse precedenti )
- usi la nuova bitmap (ora la uno per disegnare ) -----> Use BitMap bm
- vai alla routine di logica e poi a quella di disegno
e così all'infinito
in pratica, mentre mostri una schermata in quella nascosta prima cancelli le modifiche precedenti, poi ridisegni le modifiche attuali.
(http://s7.postimg.org/4pziufkiz/sfondo.png) (http://postimage.org/)
Edit: nell'immagine naturalmente la parte sinistra è quella che si vede a schermo, mentre la destra è la parte nascosta
spero di essermi spiegato abbastanza bene ^^', al massimo chiedi :)
Edit 2 : ci saranno poi altri problemi da risolvere + in là, perchè ad esempio i pezzi che cadono sul fondo, non dovresti ridisegnarli sempre, ma solo quelli in movimento :)
ma prima vedi se funziona il doublebuffer ;)
-
E se io disegno sempre su BG0 poi cambio su BG1? funziona?
-
eh no :)
devi disegnare prima su una bitmap e poi sull'altra, perchè sennò che double-buffer sarebbe ?
anche perchè se disegni sempre su una bitmap, l'altra sarebbe vuota ;)
l'idea del double-buffering è proprio che mentre mostri una cosa, ne disegni un'altra dall'altra parte, in modo che non vedi il "flickering" del ridisegno, sennò non avrebbe senso :)
-
Non conosco Blitz Basic (stai usando questo, no?), ma se il linguaggio supporta gli array di oggetti potresti fare così:
// Pseudocodice
int current = 0;
const int num_of_buffers = 2;
Buffer bg[num_of_buffers]; // Un array con 2 buffers
draw() {
while(true) {
// Disegno roba
drawCircle(x, y, r, bg[current]);
drawLine(x1, x2, y1, y2, bg[current]);
drawSprite(sprite1, x, y, bg[current]);
// Mostro a schermo
setScreenBuffer(bg[current]);
// Ruoto i bg
current = (current + 1) % num_of_buffers;
}
}
puoi usare 2 o 3 buffer tipicamente, non conviene andare oltre.
-
per rafforzare l'importanza del double buffering, viene usato tutt'ora , è uno degli "ABC" della programmazione :)
i vari SDL_Flip o glSwapBuffers sono il pane quotidiano di chi programma qualsiasi cosa coinvolga la grafica.
Fidati, una volta imparato ad usarlo non ne farai più a meno ( che sia blitzbasic, opengl,sdl, freebasic, etceteramila linguaggi che coinvolgono un qualsiasi tipo di disegno grafico che viene aggiornato in tempo reale ), è proprio la "base" minima per poter lavorare :) (addirittura ora spesso si usano 3 buffer al posto di 2 per dare una sensazione + fluida al gioco/animazione)
-
Ok a proposito di programmazione io sto ragionando ancora a livello Spectrum 48k e BASIC, quando il linguaggio era cosi leeeeento che non conveniva controllare tutti gli elementi sullo schermo ma solo alcuni (magari avrebbe ancora senso facendo uin platform); mi sono immaginato un pseudocodice del genere per come implementare il double buffering in quel tetris:
initialize bitmap 0 and 1
a var that points the bitmap id
id=0
first cycle
write on 0
show 0
id+=1
write on 1
show 1
id = 0
write on 0
etc.
-
Guarda, per non complicarti la vita ti conviene ridisegnare tutti gli oggetti a ogni frame, così fai un codice molto più piccolo.
Poi quando ci prenderai la mano potrai fare cose più sofisticate, ma se provi adesso a fare queste ottimizzazioni potresti impelagarti in una situazione fastidiosa.
-
Ok a proposito di programmazione io sto ragionando ancora a livello Spectrum 48k e BASIC, quando il linguaggio era cosi leeeeento che non conveniva controllare tutti gli elementi sullo schermo ma solo alcuni (magari avrebbe ancora senso facendo uin platform); mi sono immaginato un pseudocodice del genere per come implementare il double buffering in quel tetris:
initialize bitmap 0 and 1
a var that points the bitmap id
id=0
first cycle
write on 0
show 0
id+=1
write on 1
show 1
id = 0
write on 0
etc.
si si l'idea è quella :)
-
Guarda, per non complicarti la vita ti conviene ridisegnare tutti gli oggetti a ogni frame, così fai un codice molto più piccolo.
Poi quando ci prenderai la mano potrai fare cose più sofisticate, ma se provi adesso a fare queste ottimizzazioni potresti impelagarti in una situazione fastidiosa.
lo sta gia' facendo ed e' lento come la fame, come visibile qui (https://youtu.be/SbJf1sAT6VU) :(
Ecco che allora mi serve di migliorare il framerate: potrei disegnare in 0 poi swappare con 1
-
Ok a proposito di programmazione io sto ragionando ancora a livello Spectrum 48k e BASIC, quando il linguaggio era cosi leeeeento che non conveniva controllare tutti gli elementi sullo schermo ma solo alcuni (magari avrebbe ancora senso facendo uin platform); mi sono immaginato un pseudocodice del genere per come implementare il double buffering in quel tetris:
initialize bitmap 0 and 1
a var that points the bitmap id
id=0
first cycle
write on 0
show 0
id+=1
write on 1
show 1
id = 0
write on 0
etc.
articolando un po...
buffer = 0
Gosub DisegnaSchermo
GameLoop:
Gosub MostraBuffer
Gosub CambiaBuffer
Gosub ControllaInput
Gosub DisegnaSchermo
Goto GameLoop
MostraBuffer:
...mostra la bitmap <buffer>...
CambiaBuffer:
buffer = buffer + 1
If buffer > 1 Then buffer = 0
Return
DisegnaSchermo:
...disegna nella bitmap <buffer>...
ControllaInput:
...verifica input utente...
-
Sarei curioso di provarlo sul mio 1200. Se vuoi posso offrirmi come beta tester. Gli sviluppatori vanno incentivati :)
Quando riesco ad aggiustarlo un po' sarai il benvenuto
-
Sono ancora mentalmente incastrato nel cercare di fare double buffering e passare da grafica plottata a bitmap; mi han passato una routinetta per double buffering ma usa il blitz mode mentre il giochetto su cui sto lavorando ancora no: ho trovato grazie ad un amico il Ultimate Blitz Basic CD (https://archive.org/details/ultimate-blitz-basic-v2_1) e tramite un altra persona su facebook il PDF dei manuali cartacei di Blitz Basic (http://amiga-manuals.xiik.net/manuals/eBooks/Blitz_Basic_2___ebook_ENG.rar) e sto cercando di capirci qualcosa... e' tosta pero'
-
Da allora il mio laptop principale é defunto ed il sostituto (il mio vecchio asus pentium III/900) puó usare solo versioni archeologiche di WinUAE che han la tendenza a piantarsi quando compilo. Ma non ho intenzione di demordere: appena trovo un hw decente é mia intenzione continuare!
-
Grande! NON MOLLARE! :D
-
Da allora il mio laptop principale é defunto ed il sostituto (il mio vecchio asus pentium III/900) puó usare solo versioni archeologiche di WinUAE che han la tendenza a piantarsi quando compilo. Ma non ho intenzione di demordere: appena trovo un hw decente é mia intenzione continuare!
Compare, ti serve hardware decente?
-
Piú che altro mi serve hardware. Anche appena sotto la soglia della decenza aiuta, a prezzi da rottamaro...
-
Com'è finita la storia dell'autodistruzione?
;D
-
Ho trovato un netbook a prezzo buonissimo; appena ho la voglia di mettermi a fare tutte le configurazioni magari si ricomncia :)
-
Non mollare! :D