Newsgroup: it.comp.grafica
Titolo: GAME DEVELOPING - cercasi programmatore

Cerchiamo   sviluppatori   aggiuntivi  per  lo  sviluppo  di  DRONES,
videogioco  multipiattaforma  (PC/Dreamcast/Alpha) in uscita nel '99 e
realizzato con il supporto di Digital e Compaq.
Requisiti necessari:
  Conoscenza approfondita del C++.
  Disponibilità a trasferirsi a Parigi per i prossimi 10/12 mesi.
Requisiti preferenziali:
  Conoscenza della programmazione grafica 3D.
  Conoscenza di DirectX.
La programmazione utilizzera` i seguenti ambienti:
  Microsoft Visual C++ (Windows NT, Windows 9x, Windows CE)
  Borland C++ Builder 3 (Windows NT, Windows 9x)
  MEL (Maya Embedded Language by Alias|Wavefront)
Lo sviluppo avra` luogo presso la nostra sede di Parigi, dove
ci occuperemo di fornire alloggio agli sviluppatori.
Per ulteriori riferimenti:
http://www.nigma.it/drones/
 (in lavorazione)
http://www.segadreamcast.net/previews/previews_drones.htm
http://www.sega-otaku.com/interviews/nigma.html
http://www.segadc.com/previews/drones/drones.htm
http://www.infiniteplanes.net/segaworld/previews/drones.htm
http://www.videogamers.com/meta/dec.htm
http://www.players-online.com/dcarea/drones-preview.htm
http://www.gecip.fr/katana/html/preview/drone.htm
Rispondete esclusivamente in email a 
soft...@nigma.it
.
Bye, DeathStar::CDS
*3d-coder*
c...@nigma.it
           [email]
www.nigma.it/deathstar
 [DeathStar HomePaGe]
www.nigma.it/trip99
    [The Real Italian Party 99]
www.nigma.it/drones
    [Drones Homepage]







Ciao CDS/DeathStar .
In un msg del 13-Oct-98, CDS/DeathStar diceva a All'
in riguardo a GAME DEVELOPING - cercasi programmatore
 C> Cerchiamoaa sviluppatoriaa aggiuntivia pera loa sviluppoa dia
 C> DRONES, videogiocoa multipiattaformaa (PC/Dreamcast/Alpha) in
 C> uscita nel '99 e realizzato con il supporto di Digital e Compaq.
 C> Requisiti necessari: a Conoscenza approfondita del C++.
                                                ^^^^^^^^^^^
Mi chiedo come alle soglie del 2000
gente come voi possa cercare programmatori per programmare
con un linguaggio a oggetti cosi' limitato.
Ma ditemi un po' ....offre per caso programmazione concorrente (ironico) ?
_  _ __ __  __ ___ ___ __ __
\\// || ||  || ||- ||  || ||\
 \/  || ||  ||_||_ ||_]|| ||_\
 Seibte Legion - Septima Legio
... F**k 'em up and RIOT !

 Ma ditemi un po' ....offre per caso programmazione concorrente (ironico) ?
No, ma in ogni caso non penso sia un paradigma molto utile per programmare una
Dreamcast.
                                                            Blade / Absurd

Ciao Simone Freato.
In un msg del 26-Oct-98, Simone Freato diceva a All'
in riguardo a Re: GAME DEVELOPING - cercasi programmatore
 SF> Dimmi un po'. Tu che sei un coder proiettato verso il futuro per
 SF> programmare un gioco che linguaggio useresti ?  Java ? Eiffel ?
 SF> Visual Basic ? Turbo Prolog ? >
Oberon (meglio) o Ada95...ci sono versioni freeware per quasi tutte le
piattaforme.
Oppure opterei per l' ANSI-ISO Modula-2 (che e' pero' e' objectbased)
 ...tipo l' XDS o GPM modula-2 (che uso).
Tutti i linguaggi che ho citato offrono programmazione concorrente.
_  _ __ __  __ ___ ___ __ __
\\// || ||  || ||- ||  || ||\
 \/  || ||  ||_||_ ||_]|| ||_\
 Seibte Legion - Septima Legio
... Cio' che non e' retto,non lo consideravamo nemmeno come utile

Tutti i linguaggi che ho citato offrono programmazione concorrente.
Si', e che me ne faccio su una dreamcast ? 
Mah.


Septima Legio (
Septim...@antispam.nwo.bbs.comune.roma.it
) wrote:
:  SF> Dimmi un po'. Tu che sei un coder proiettato verso il futuro per
:  SF> programmare un gioco che linguaggio useresti ?  Java ? Eiffel ?
:  SF> Visual Basic ? Turbo Prolog ? >
: Oberon (meglio) o Ada95...ci sono versioni freeware per quasi tutte le
: piattaforme.
In giappone usano dire "ma non dire goldonate" ad una simile asserzione.
Oberon e' poco piu' di un giocattolo per bambini.
Per Ada (qualunque versione) alzo le mani... del tutto rispettabile. Ma
ad ottimizzabilita' come stiamo ?
: Oppure opterei per l' ANSI-ISO Modula-2 (che e' pero' e' objectbased)
:  ...tipo l' XDS o GPM modula-2 (che uso).
: Tutti i linguaggi che ho citato offrono programmazione concorrente.
Sai com'e'... della programmazione concorrente te ne fai poco o niente
quando hai bisogno di altro (doti come "ottimizzabilita'" e "velocita'"
non esistono, forse ?).
Sono d'accordo con te nell'affermare che la programmazione concorrente e'
il futuro della programmazione (ormai non si puo' andare ancora molto
su di frequenza, quindi bisogna trovare altri trucchi), ma ora i tempi
non sono maturi e non esistono strumenti almeno DECENTI per utilizzarla.
Leggi anche: Trovami un compilatore veramente ottimizzato di Oberon, Ada,
Modula2. Suddetti compilatori e' gia' tanto se sono bug-free (ed, essendo
freeware, di solito non e' neppure assicurato il bug-fix).
Non so che tu faccia di lavoro (o studio), ma il discorso che hai fatto sa
molto di studente/ricercatore, ovvero di persona che non ha mai utilizzato
un compilatore per farci qualcosa di "pagato".
--
							*PaN!*

Ma ditemi un po' ....offre per caso programmazione concorrente (ironico) ?
eccome.
semafori,messaggi,memoria condivisa.
se non e' "programmazione concorrente" come la chiami tu questa....
friolame

se non e' "programmazione concorrente" come la chiami tu questa....
Nessuno di questi e` purtroppo un costrutto del linguaggio C++; si
tratta invece di primitive messe a disposizione, in modo naturalmente
diverso in ogni caso, dai diversi sistemi operativi (non da tutti).
Il linguaggio C++ contiene la deliberata scelta di progetto di NON
offrire, come linguaggio, un modello di multi-threading; in sostanza
perche`, offrendo specifiche semantiche di threading, si puo`
facilmente "andare contropelo" alla semantica di threading di un
particolare sistema, rendendo impossibile una implementazione di
massima efficienza su quel sistema (la versione originale di Ada,
con la sua semantica di "rendez-vous", soffriva spesso di questo).
Le decisioni di progetto del C++ sono ben presentate e difese
nel testo "Design and Evolution of the C++ Programming Language",
B. Stroustrup, ed. Addison Wesley.
Alex

grazie a Unix ...ma che vale solo 1/3 dei linguaggi che avevo citato.
veramente sarebbe unix a dover ringraziare il c,visto che e' il
linguaggio in cui e' stato scritto.....
bah
friolame

funzioni per gestire i processi?
Infatti, nello standard del linguaggio C (e, d'altronde, del C++), non
sono previsti, ne` semafori, ne` processi, ne` funzioni per gestirle.
Nulla, naturalmente, impedisce a qualsiasi implementazione di questi
linguaggi, come estensione dello standard, di introdurre questi costrutti;
ma si trattera` appunto di una estensione.
E` una scelta filosofica dei linguaggi in questione (sicuramente, e
in modo molto deliberato, del C++; cfr. Stroustrup, "Design and
Evolution of the C++ Programming Language", Addison-Wesley),
quella di NON introdurre nel linguaggio uno specifico modello di
concorrenza -- proprio per garantire che qualsiasi modello venga
imposto "da fuori" (tipicamente, da un dato sistema operativo)
non sara` mai in _contrasto_ con gli standard del linguaggio.  Il
riferimento e` ad Ada, prima versione, il cui esplicito, ricco, e
sofisticato modello "a rendez-vous" non e` un buon match, dal
punto di vista semantico, per quel che effettivamente offrono i
sistemi operativi piu` diffusi (Unix in vari sapori, Win32) -- il che
pone l'implementatore di questo linguaggio davanti a un dilemma.
Certo, fra le semplici coroutine di Modula-2 (o, se e` per questo,
Icon, dove possono, piu` elegantemente, essere "sottintese" dal
backtracking), e lo specificissimo meccanismo dei rendez-vous di
Ada (o, se e` per questo, i Monitor di Concurrent Pascal!), ce ne
sono di spazi intermedi (fra cui, ad esempio, quello in cui Java ha
incastrato la propria semantica dei thread), e si potrebbe anche
sostenere che C++ "avrebbe dovuto" fare una qualche scelta nel
mezzo invece di "tirarsi indietro"... resta vero che, se cosi` avesse
fatto, non potrebbe essere usato per implementare _con la massima
efficienza_ il multithreading nei sistemi operativi piu` diversi e
disparati.
Non mi pare che abbia "diritto" di discutere di questo, chi non si
sia dato la briga (briga molto relativa, trattandosi di libro assai
leggibile e piacevole, per i patiti dell'argomento:-) di studiare bene
il testo di Stroustrup succitato; non ha proprio senso, e, direi,
squalifica la persona come interlocutore tecnico credibile, mettersi
a "sparare critiche" ad un linguaggio senza aver voluto sentire
"la campana" dell'inventore del linguaggio stesso su questo!
Alex