Newsgroup: it.comp.programmare
Titolo: si può creare un gioco in pasc. (risp.)

Grazie a tutti ragazzi, seguiremo tutti i vostri consigli, e ci
informeremo sul delphi, grazie ancora.

 ha scritto nel messaggio
news:451287f1.02091...@posting.google.com...


 si ma giochi del tipo tetris e battaglia navale tutti giochin a 2 d
???
In Delphi puoi anche sviluppare giochi tridimensionali molto complessi.
--------------------------------
Inviato via 
http://usenet.libero.it

 In Delphi puoi anche sviluppare giochi tridimensionali molto complessi.
Auguri. :|
 Raffaello

 Auguri. :|
Okkio che si inca**a. Non toccategli il "giocattolo".
;-)
-- 
Luc.

 Raffaello
Sarebbe bene restare zitti, se non si conosce cio' di cui si parla ;)
Purtroppo questa e' una pratica non comune tra molte persone, Luc per primo,
che parla di "giocattolo" relativamente a qualcosa che sicuramente
giocattolo NON e'.
E' un peccato che ci sia gente che parla cosi' a sproposito ;)


 Okkio che si inca**a. Non toccategli il "giocattolo".
Per tua informazione, e' un "giocattolo" che fa guadagnare un bel po' di
soldini ;)
E' un peccato che si venga istigati a rispondere a messaggi cosi' insulsi...


> si ma giochi del tipo tetris e battaglia navale tutti giochin >a 2 d
Questa è un imprecisione.
Se parliamo di Pascal standard, non esiste nessun compilatore Pascal
Standard e quindi non ci puoi fare niente, nessun programma di nessuna
natura.
Se Parliamo di compilatori specifici, allora la musica cambia.
Caso 1) Turbo Pascal.
Si può fare tutto, e quando dico tutto, intendo tutto!
Infatti il Turbo Pascal permette di utilizzare anche file obj semicompilati
con altri compilatori (compilatori Assembler)
Inoltre il Turbo Pascal permette di utilizzare l'assembly e quindi è anche
un compilatore Assembler.
Quindi se parliamo del Turbo Pascal si possono fare:
Giochi semplici e complessi, virus, tsr, sistemi operativi senza nessun
problema! E' ovvio che bisogna saperlo usare.
Io ho utilizzato con TP, istruzioni del Pentium e del Coprocessore non
inserite nel compilatore del TP, ma l'ho potuto fare perchè il TP possiede
anche la possibilità di usare codice macchina direttamente e con questo
penso di avere chiarito tutto.
Quindi la questione non è se è possibile o non è possibile.
La questione è quanto tempo ci vuole?
Con il TP ci vuole molto più tempo rispetto ad un compilatore C, ma solo
perchè non esistono librerie buone (tranne la mia) per fare videogames già
implementate.
Sottolineo che volendo si può usare anche la memoria estesa, tramite XMS, e
tutta la memoria video, è ovvio che questo non cosa da tutti.
Io ho scritto routine per gestire la grafica anche a risoluzioni quali la
1024x768x16 Milioni, routine per gestire le sound blaster compatibili,
mouse.
Routine per leggere file .bmp, .pcx, .tif, .fli (animazioni), .3ds (3D
Studio) .voc (sonoro) e .wav (sonoro)
Con TP7.
Caso 2) Free Pascal
Anche in questo caso si possono fare giochi semplici e complessi, tra
l'altro il Free Pascal ha anche delle librerie per utilizzare le OpenGL, ed
ha il vantaggio rispetto al TP di compilare per la modalità protetta, quindi
già supporta tutta la memoria senza dover ricorrere quindi ai drivers XMS.
Con questo non si può fare tutto però, siccome è già un compilatore più
avanzato.
Altri compilatori sarebbero da valutare a parte.
Passiamo a Delphi. Con Delphi è possibile fare qualsiasi applicazione per
Windows, e quindi anche giochi semplici e complessi. Se qualcuno è scettico
a riguardo, è consigliabile che vada in giro sui vari siti dedicati a Delphi
e ai Videogames per rendersi conto che la potenza di Delphi e dell'Object
Pascal non ha nulla da invidiare ad altri linguaggi.
Con Delphi è possibile usare qualsiasi estensione presente su Windows sotto
forma di dll, quindi anche DirectX oppure OpenGL, o altre diavolerie per
facilitare lo sviluppo di videogames.
E' ovvio che in Delphi si è svantaggiati perchè esistono poche traduzioni di
queste librerie, ma se uno si mette con la buona volontà può anche farsele
da solo queste traduzioni in un paio di giorni, anche perchè con Delphi è
più semplice ed immediato interfacciarsi alle DLL, basta guardare sul
manuale per rendersi conto di questo.
In conclusione, la domanda "è possibile...?" è sbagliata, perchè è quasi
sempre possibile fare tutto.
La domanda dovrebbe essere "quanto tempo in più ci vuole con...?"

 Okkio che si inca**a. Non toccategli il "giocattolo".
Zittisci miscredente  ::  
http://www.sulaco.co.za/
Guardati col giocattolo cosa si può fare.
Esistono centinaia di siti come quello pieni di esempi di quello che può
fare "il giocattolo" come lo chiami te.
Bisognerebbe informarsi prima di parlare.

 La domanda dovrebbe essere "quanto tempo in più ci vuole con...?"
Hai ragione, ed io intendevo comunque questo. So benissimo che si può 
fare tutto con (quasi) tutto... Sono i tempi/comodità che scoraggiano, 
eventualmente, l'utilizzo di qualche linguaggio rispetto ad un altro...
-- 
Luc.

 E' un peccato che si venga istigati a rispondere a messaggi cosi' insulsi...
Take it easy.... Se tu dici che il C++ fa schifo io mica mi inalbero!
-- 
Luc.

 Take it easy.... Se tu dici che il C++ fa schifo io mica mi inalbero!
A parte che non ho mai detto una cosa del genere, cio' che irrita e'
l'insulso giudizio su qualcosa che non si conosce. Io il C++ lo conosco e lo
posso giudicare, tu Delphi non lo conosci e non lo puoi giudicare. Capisco
che vivi il complesso del "programmatore C++" (parole grosse) che deve per
forza far credere di utilizzare il linguaggio migliore per lo sviluppo di
certi software, ma poi, come in questo caso, rischi di prendere delle enormi
bastonate sulle orecchie. Non capisco perche', poi, tu ti senta il paladino
del C++, qui nessuno e' contrario a questo linguaggio.


 Hai ragione, ed io intendevo comunque questo.
"Intendevi" ? dove ? in quale messaggio ? in che punto del tuo messaggio ?
Hai per caso esposto il tuo punto di vista ?
Illuminaci, non siamo cosi' intelligenti dal desumere dei punti di vista
dalle tue denigrazioni.


 del C++, qui nessuno e' contrario a questo linguaggio.
Lo so, lo so. Pensa che se qualcuno scrive che vuole creare un gioco gli 
suggerisco anche di vedere 
www.blitzbasic.com
 , specialemente se non 
molto avvezzo alla programmazione hi-end... 
-- 
Luc.

 dalle tue denigrazioni.
Ok, ho esagerato a scrivere "giocattolo". Deformazione professionale. ;)
-- 
Luc.

soldini ;)
come mai hai usato la forma impersonale? :)
tu non sei nella lista?
--
Rhymes (rhy...@NOSPAMmyself.com)
http://www26.brinkster.com/rhymes
" ride or die "

 mi son detto "che mi sono perso"....
Contento tu. Anch'io conosco il C++ sufficientemente bene, eppure non mi
entusiasma per molti ambiti. Il C++ e' inadatto, a mio avviso, per molte
applicazioni, visto che esistono linguaggi piu' semplici e diretti per
svolgere determinati compiti.


 tu non sei nella lista?
Delphi (soggetto) fa guadagnare (verbo) un bel po' di soldini (complemento
oggetto).
Questa frase non esclude nessuno dalla lista.


 ObjPascal e non "Object Pascal" posso capire tante cose ;)
Ho solo abbreviato, giuro. Il fatto che me lo fai comunque notare mi fa 
capire alcune cose... ;-PPP
 
-- 
Luc.

Questa frase non esclude nessuno dalla lista.
OK che sei arrabbiato con Luc ma la mia era una battuta


 OK che sei arrabbiato con Luc ma la mia era una battuta
ROTFL, io non sono "arrabbiato" con nessuno.... ho argomenti sufficienti per
affrontare discussioni di questo tipo in tutta tranquillita' ;)


Continuate a dire che il tal linguaggio è ottimale per le tali
applicazioni... probabilmente se esplicitaste *quali* applicazioni intendete
scoprireste di star parlando di ambiti *totalmente* diversi... acenni e
frasi smozzicate non aiutano a chiarirsi. "il linguaggio pippo è fatto a
posta per creare i gestionali" è una frase che ha un suo senso, sia essa
corretta o meno. "il linguaggio pippo è il linguaggio definitivo" subodora
di str***ata lontano un miglio.
Rispettosi saluti
       Franco "Belinde"



Nessuno afferma che il linguaggio "pippo" sia il linguaggio definitivo, ma
e' bene considerare che il C++ e Delphi (che Borland ha ribattezzato
"linguaggio"), sono linguaggi cosiddetti "general-purpose", adatti cioe' ad
un ambito di applicazione molto vasto.
La scelta se adottare l'uno o l'altro dipende da molti fattori, non di meno
dal framework (leggi libreria) che si utilizza (e Delphi e' molto ben
fornito, da questo punto di vista).
Personalmente, considero il C++ un linguaggio da tenere chiuso in un
armadietto con scritto sopra "da usare solo in caso di emergenza".
Ho visto programmatori che, convinti di conoscere il C++, hanno combinato
pasticci inenarrabili e non mi spiego perche' la vita di altri programmatori
(vedi me nel mio passato lavoro) debba essere quella di correggere i casini
creati dagli altri.
Il C++ e' un linguaggio potente, molto potente e, come tutte le cose
potenti, va usato con cautela.
Per molti ambiti, in cui tutta la potenza del C++ non serve realmente (e
questi ambiti si ampliano di pari passo all'evoluzione dei pacchetti di
sviluppo come Delphi), non val la pena dedicare troppe energie per il suo
utilizzo.
Personalmente, io bado alla produttivita', non a quanto mi renda uomo usare
VC++.
Conosco bene il C/C++ e ci rimango affezionato, ma non mi piace sbandierarlo
(come, invece, fanno altri) come la panacea per tutti i problemi, visto che
cosi' non e'.
Per tornare all'argomento del thread, io ribatto a chi giudica senza
conoscere.


 Sarebbe bene restare zitti, se non si conosce cio' di cui si parla ;)
Caro, io ho lavorato 1 anno con il tuo Delphi.
E ho fatto anche presto a lasciarlo dov'era.
 Raffaello

E ho fatto anche presto a lasciarlo dov'era.
come mai? per quale motivo?


 come mai? per quale motivo?
Perche' per il mio lavoro (DB modelling/management) il Delphi mi stava un
po' stretto e ho avuto parecchi problemi con WINZOZZ.
Contentissimo con il Delphi quando avevo 2 o 3 unita', ma arrivai a 20 e
il tutto divenne lento e difficile da gestire. Per non parlare dell'editor
di Delphi, non lo sopporto.
Ora lavoro con Oracle e accedo ai dati con Perl. Mi trovo moooooolto bene.
 Raffaello

 E ho fatto anche presto a lasciarlo dov'era.
FI*A!!! LaForge ti ucciderà!!! ;)
 
-- 
Luc.

 E ho fatto anche presto a lasciarlo dov'era.
Eh si' certo, immagino anche il perche' e temo non dipendesse da Delphi ;)


 il tutto divenne lento e difficile da gestire.
Per la cronaca, io ho sviluppato un programma a cui accedono, in rete,
mediante, 60/70 persone contemporaneamente. Fila tutto liscio come l'olio.
E' noto a tutti che c'e' modo e modo di programmare ;)




Leggendo le sue risposte mi aspettavo di peggio,
ho trovato persone ben piu' arroganti sui NG ...
Il mondo e' bello perche' e' vario.
 Raffaello

 Eh si' certo, immagino anche il perche' e temo non dipendesse da Delphi ;)
Prova qualche altro linguaggio almeno ... non ti fossilizzare.
Ogni linguaggio ha vantaggi e svantaggi ...
 Raffaello

Ora lavoro con Oracle e accedo ai dati con Perl. Mi trovo moooooolto bene.
Boh!


Ogni linguaggio ha vantaggi e svantaggi ...
Vero, ma non puoi escludere Delphi perchè 20 unit non interagivano :)


 Ogni linguaggio ha vantaggi e svantaggi ...
Caro amico, io di linguaggi ne conosco una decina... quindi so bene che cosa
sto dicendo.
Fidati ;)


 Vero, ma non puoi escludere Delphi perchè 20 unit non interagivano :)
Anche perche' non e' detto che la colpa sia delle 20 unit ;)
Nel progetto caricato tuttora in Delphi, sul mio desktop, ne conto 48 ;)


 Vero, ma non puoi escludere Delphi perchè 20 unit non interagivano :)
Ora ho una quarantina di CGIs scritte in perl che interagiscono alla
perfezione.
 Raffaello

Nel progetto caricato tuttora in Delphi, sul mio desktop, ne conto 48 ;)
Io non scrivo una riga di codice Delphi da circa un anno ormai...
ps. lo so che faccio male :P


perfezione.
Bhé forse per i programmi come il tuo perl è un linguaggio più adatto.
Però potresti allora provare Python...
-- 
Marco Barisione (ICQ 84277092)

 Fidati ;)
Ma hai mai provato a usare Delphi con Oracle e Linux ?
Se si' sei un genio!
 Raffaello

 Se si' sei un genio!
Non sono un genio, probabilmente sei tu che non ti sei sforzato abbastanza.
La cosa buffa e' che sei realmente convinto di cio' che dici.
Delphi interagisce benissimo con qualsiasi DB e Oracle e' uno dei tanti.
L'accesso a Oracle da Delphi, specie se fatto tramite componenti appositi
come i DOA (
www.allroundautomations.com
) o gli ODAC (
http://www.crlab.com/
)
funziona perfettamente ed e' molto performante.


 funziona perfettamente ed e' molto performante.
Puo' darsi. Ma mi spieghi perche' dovrei fare installare Delphi a tutti i
PC del "Max-Planck-Institut fuer Molekulare Genetik" anziche' permettere
loro di accedere ai dati tramite un browser qualsiasi ?
E quelli che usano un MAC ?
E quelli che lavorano direttamente sulle workstation ?
 Raffaello
/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\
Raffaello Galli
Database Administrator (Lehrach department DB)
Max-Planck-Institut fuer Molekulare Genetik
Abteilung Lehrach
Ihnestrasse 73          D-14195 Berlin-Dahlem
Email: 
Ga...@molgen.mpg.de
/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\

 E quelli che lavorano direttamente sulle workstation ?
Spiega il concetto di "lavorare direttamente sulla workstation", perche' i
programmi Delphi girano normalmente su qualcosa chiamato "workstation", e si
usano per "lavorare".


 Ma hai mai provato a usare Delphi con Oracle e Linux ?
Non c'era un robo chiamato Kylyx che dovrebbe essere appunto
un prodotto Borland che implementa Delphi su Linux?  Quanto a
Oracle, non dovrebbero comunque esserci problemi.
Piuttosto, se come acenni altrove un'applicazione deve girare
anche su Macintosh e workstation con Unix proprietari, allora
in effetti la scelta di ambienti di sviluppo viene molto, ma
molto limitata da questi vincoli.  Penso che Qt come framework
(GUI, ma non solo: offre anche approcci cross-platform per la
stampa, l'accesso ai DB, la rete, e cosi` via) sia la scelta
migliore con questi vincoli.  Come linguaggi, C++ e Python sono
quelli che Qt supporta meglio (non so se ve ne sono altri che
permettano un lavoro perfettamente cross-platform con Qt).  A
mio parere (come esperto di C++ [MVP di Brainbech per C++] e
di Python [autore di libri, articoli, ecc]), Python per il 99%
delle problematiche applicative, con eventuale C++ (con Boost
Python) per l'eventuale 1% non altrimenti coperto, e` una scelta
ottima per lo sviluppo di applicazioni (particolarmente con Qt,
ma non e` certo l'unico framework usabile -- solo quello meglio
supportato per applicazioni professional MOLTO x-platform).
I prodotti del mio principale cliente attuale (la AB Strakt
di Gothenburg, Svezia) usano Python e Qt (e dal lato server
vari possibili DB, principalmente PostgreSQL ma anche Oracle
e` previsto) e girano su Linux, Windows, Solaris, Macintosh.
Sono previsti anche port su Zaurus (Qt gira anche sul detto
palmare, anzi e` LA interfaccia grafica principale, senza X
Windows sotto che troppa memoria costerebbe:-), BSD di vari
gusti, Plan/9, e chi piu` ne ha piu` ne metta, ma in ciascun
caso molto dipende dall'avere clienti che richiedono supporto
della specifica piattaforma (ad esempio, Solaris e` gestito,
ma non per ora altri Unix proprietari come HPUX o AIX, perche`
la Chalmers University, cliente di AB Strakt, usa alcune
workstation Solaris per i prodotti di AB Strakt, ma almeno
per ora non workstation HPUX ne` AIX -- quindi AB Strakt, a
oggi, non ha neppure bisogno di comprarsi un paio di WS delle
varie marche proprietarie per verificare i port, salvo che
per Solaris).  Le caratteristiche cross-platform di Qt e
Python sembrano essere impeccabili per queste esigenze, almeno
giudicando dal primo annetto scarso di esperienza con Qt (nei
precedenti prototipi AB Strakt usava Tk, sempre con Python,
ma Qt e` di gran lunga piu` ricco e meglio supportato).
Una volta avrei proposto un rapporto 90-10, non 99-1, ma col
passar del tempo la necessita` di scrivere estension in C++ (o
C) per Python continua a calare.  Oggi c'e` Pyrex (Python piu`
dichiarazioni dei tipi elementari alla C, che viene compilato
producendo codice macchina nativo), OK per molte estensioni,
e Weave per il "codice in linea" (con Weave.Blitz, puoi in
particolare scrivere espressioni su array in Python/Numeric,
e decidere poi di compilare a "C++ in linea" quelle che non
ti offrono ancora prestazioni sufficienti) allo specifico
scopo di accelerare eventuali bottleneck troppo "tenaci" per
cedere agli strumenti piu` abituali.
L'1% che resta e` sostanzialmente costituito da librerie C++
esistenti di ricca funzionalita`, non pensate (o comunque
troppo scomode) per l'interfaccia da altri linguaggi (come
C o Pyrex).  Presumibilmente 'sip', lo strumento usato da
PyQt per generare le interfacce Python per il C++ delle Qt,
potrebbe farne un solo boccone, ma purtroppo non e` ben
documentato (e, credo, non professionalmente supportato per
generiche librerie C++).  In pratica, dunque, se uno ad
esempio sceglie di usare ICU per l'internazionalizzazione
dei suoi programmi (e avendo analizzato a fondo la questione,
anche sulla base di tanti anni di esperienza precedente --
col mio precedente datore di lavoro, rilasciammo applicazioni 
per Giappone e Corea gia` oltre 10 anni or sono -- mi pare che 
ICU sia oggi senza eguali per questo arduo compito) gli conviene 
probabilmente scrivere le 500-600 righe di C++/Boost Python 
necessarie, piuttosto che non rompersi la testa sui livelli 
C di ICU e delle C API di Python.  (C'e` anche SWIG, che, mi 
dicono, nel release attuale e` finalmente in grado di fare un 
ottimo lavoro nel produrre interfacce da C++ per Python: la mia 
esperienza con SWIG pero` e` limitata al release precedente, 
che su questo non era tanto forte, anche se bisogna ammettere 
che Hammond e` riuscito a usarlo per tutte le interfacce a 
Python delle API di Win/32 e delle MFC... ma sono interfacce 
che non fanno uso di template o altri aspetti di C++ avanzato...).
Alex

 permettano un lavoro perfettamente cross-platform con Qt).
La libreria CLX di Delphi/Kylix e' basata su Qt.


 La libreria CLX di Delphi/Kylix e' basata su Qt.
Peccato allora che non abbiano scelto di approfittare dell'assai piu`
ampia gamma di piattaforme che Qt supporta rispetto a Kylix.  Se
devi essere perfettamente cross-platform, come appunto dico nel
paragrafo qui citato, C++ puoi usarlo (ma non so se puoi far conto
sulla CLX su, che so, Solaris, Zaurus, OpenBSD, ...?), ma Object
Pascal mi pare che non sia un'opzione.  (Per fortuna che c'e`
Python... se no starei ancora a programmare _applicazioni_ in
C++... <shudder!> [di questi tempi mi pare che anche Andrew
Koenig posti circa altrettanto su 
c.l.py
 e c.l.c++...:-)]).
Alex

 Koenig posti circa altrettanto su 
c.l.py
 e c.l.c++...:-)]).
Python e' davvero un bel linguaggio, mi ci sto appassionando.
Mi piace perche' e' semplice e come tutte le cose semplici, a mio avviso,
nasconde una grande potenza. E' per questo che l'ho consigliato a mio nipote
di 14 anni ;)


di 14 anni ;)
Bella scelta! L'unica cosa di cui sento la mancanza è un IDE/RAD
facile da usare e stabile come quello di Delphi. Il problema è che in
Python esistono + librerie per creare GUI ma si può sopperire con
QTDesigner e pyQT :)


 facile da usare e stabile come quello di Delphi.
Be', si potrebbe scrivere ;)
Comunque Delphi for .NET (nome in codice Galileo), il prossimo passo di
Borland tutt'ora in costruzione, sara' un IDE per Delphi, C# e 
VB.NET
(almeno questo e' quanto si dice).
Sarebbe bello se anche Python fosse tra i linguaggi supportati.
Tutto questo, finquando Microsoft non inventera' qualche sistema operativo
chiamato Apollo, che uccidera' Python e abbandonera' Delphi (come la
mitologia insegna ;)


mitologia insegna ;)
:-)


mitologia insegna ;)
........LOL


ascoltando il vento dell'est udii Giovanni Ceglia che diceva queste parole
|| si ma giochi del tipo tetris e battaglia navale tutti giochin >a 2 d
|
| Questa è un imprecisione.
|
| Se parliamo di Pascal standard, non esiste nessun compilatore Pascal
| Standard e quindi non ci puoi fare niente, nessun programma di nessuna
| natura.
|
| Se Parliamo di compilatori specifici, allora la musica cambia.
|
| Caso 1) Turbo Pascal.
sei sempre il solito malato eh? :-P
Dai scherzo, cmq sono d'accordo con te completamente al 50 %! :)
PS: W Rosa.Salerno!

 mitologia insegna ;)
Ah ma come Rowan Atkinson insegna, BlackAdder torna sempre fuori
comunque (con l'immancabile Baldrick, nome che suggerisco a chiunque
volesse cimentarsi in un qualche programma di supporto allo sviluppo
complementare a BlackAdder, ovviamente).  Al peggio passero` a
Mister Bean (il nome rende ovvio che si trattera` di un ambiente
per lo sviluppo in Jython, naturalmente).
Alex

 nipote di 14 anni ;)
Si`, la forza della semplicita` e` facile da trascurare.  In
particolar modo, la stessa semplicita` che rende Python adatto
al principiante e` la chiave della sua potenza per il guru...
Alex