S
- Stato
Ultima modifica:
@Exit93 considerato che xna è un framework lo stavo valutando come base di render, avrei il vantaggio di saltare la parte "noiosa" del render, anche se in realtà l'ho già scritta, ma sono convinto sia ottimizzabile. Ho visto che xna alla fine è un bel pacchetto di dll fatte in C, davvero ben strutturate e ottimizzate. Devo considerarlo.
Siccome io vivo in Windows penso lo farò esclusivamente su DirectX. non potrebbero convivere entrambe, sarebbe più che doppio lavoro. Tra l'altro ammetto che ho ottima esperienza sulle DX in quanto ho fatto diversi lavori, mentre sulle OpenGL partirei da zero.
@St3v se leggi bene non ho descritto il Net come il migliore in tutto
diamo giustamente quel che è di Cesare a Cesare, sopratutto nel multipiattaforma (che ho elencato solo come pregio, ma non come completo porting).
Pero' quando parliamo di prestazioni, tu prova a scrivere codice per un'operazione importante, che ti permetta di fare un benchmark di calcolo, che equivalga in codice C++ e C#, vedrai che sorpresa. Io stesso ho dovuto rivalutare alcuni miei punti di vista. Ho proposto la trasformata di Fourier veloce, perchè è il tipo algoritmo preso dai benchmarker, ma fai pure come preferisci
A fronte di questo dato mi sento di affermare che se uno lavora in Windows o con mono, se deve scegliere tra C++ e C#, sicuramente lavorera' piu' velocemente in C# ottenendo prestazioni equivalenti. Questo è quanto intendevo. Unica cosa non ho benchmark con mono.
Siccome io vivo in Windows penso lo farò esclusivamente su DirectX. non potrebbero convivere entrambe, sarebbe più che doppio lavoro. Tra l'altro ammetto che ho ottima esperienza sulle DX in quanto ho fatto diversi lavori, mentre sulle OpenGL partirei da zero.
@St3v se leggi bene non ho descritto il Net come il migliore in tutto
diamo giustamente quel che è di Cesare a Cesare, sopratutto nel multipiattaforma (che ho elencato solo come pregio, ma non come completo porting). Pero' quando parliamo di prestazioni, tu prova a scrivere codice per un'operazione importante, che ti permetta di fare un benchmark di calcolo, che equivalga in codice C++ e C#, vedrai che sorpresa. Io stesso ho dovuto rivalutare alcuni miei punti di vista. Ho proposto la trasformata di Fourier veloce, perchè è il tipo algoritmo preso dai benchmarker, ma fai pure come preferisci
A fronte di questo dato mi sento di affermare che se uno lavora in Windows o con mono, se deve scegliere tra C++ e C#, sicuramente lavorera' piu' velocemente in C# ottenendo prestazioni equivalenti. Questo è quanto intendevo. Unica cosa non ho benchmark con mono.
Orco cane! Compilato vs. semi-compilato con prestazioni identiche 
Ho scritto un codice per calcolare il più alto numero primo entro un certo range. Per evitare qualsivoglia cambiamento ho evitato ogni tipo di ottimizzazione e ho praticamente riscritto il programma pari pari su entrambi i linguaggi.
Per calcolare il più alto numero primo in un range da 3 (ho usato il 3 per semplificare ancor più il sorgente) a 1.000.000 (che risulta essere 999983) ci impiegano:
C++ -> 169277
C# -> 169511
Il codice in C++ è facilmente convertibile in C, quindi suppongo che anche in C i risultati siano molto molto simili; contando anche un range di tolleranza di 1 secondo, che non è poi tanto su un tempo così lungo e considerando che non ho un pc dedicato ai benchmark. Inoltre durante l'esecuzione del programma avevo altri programmi aperti... quindi 1 secondo ci sta tutto.
L'unica grossa differenza tra i due eseguibili è il consumo della ram, quello in .NET consuma quasi il triplo rispetto quello in C++, ma in velocità sono identici.
Sarebbe interessante conoscere in quali campi il C/C++ è più veloce del C#, perché suppongo che in qualche campo lo sia, altrimenti molte cose non mi tornano; se qualcuno è più informato faccia sapere!
Visto che questa cosa la ritengo interessante vi posto il sorgente e vi allego gli .exe (come potete vedere il sorgente è identico in termini di passaggi)
Sorgente C++
Sorgente C#
Download
Ho scritto un codice per calcolare il più alto numero primo entro un certo range. Per evitare qualsivoglia cambiamento ho evitato ogni tipo di ottimizzazione e ho praticamente riscritto il programma pari pari su entrambi i linguaggi.
Per calcolare il più alto numero primo in un range da 3 (ho usato il 3 per semplificare ancor più il sorgente) a 1.000.000 (che risulta essere 999983) ci impiegano:
C++ -> 169277
C# -> 169511
Il codice in C++ è facilmente convertibile in C, quindi suppongo che anche in C i risultati siano molto molto simili; contando anche un range di tolleranza di 1 secondo, che non è poi tanto su un tempo così lungo e considerando che non ho un pc dedicato ai benchmark. Inoltre durante l'esecuzione del programma avevo altri programmi aperti... quindi 1 secondo ci sta tutto.
L'unica grossa differenza tra i due eseguibili è il consumo della ram, quello in .NET consuma quasi il triplo rispetto quello in C++, ma in velocità sono identici.
Sarebbe interessante conoscere in quali campi il C/C++ è più veloce del C#, perché suppongo che in qualche campo lo sia, altrimenti molte cose non mi tornano; se qualcuno è più informato faccia sapere!
Visto che questa cosa la ritengo interessante vi posto il sorgente e vi allego gli .exe (come potete vedere il sorgente è identico in termini di passaggi)
Sorgente C++
Codice:
#include <iostream>
#include <Windows.h>
int main()
{
unsigned long time = 0;
int max = 0, primo = 2;
std::cout << "Range massimo di numeri primi: ";
std::cin >> max;
time = GetTickCount();
for(int x=3; x<=max; x++)
for(int y=2; y<x; y++)
{
if((x%y)==0)
break;
else if(y==x-1)
primo = x;
}
time = GetTickCount() - time;
std::cout << std::endl << "il numero primo piu' alto in un range massimo di " << max << " e' " << primo << std::endl
<< "tempo d'esecuzione: " << time << " mSec";
std::cin.ignore();
std::cin.get();
return 0;
}Sorgente C#
Codice:
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace benchmark_inforge_csharp
{
class Program
{
static void Main(string[] args)
{
int time = 0;
int max = 0, primo = 2;
Console.Write("Range massimo di numeri primi: ");
max = Convert.ToInt32(Console.ReadLine());
time = Environment.TickCount;
for(int x=3;x<=max;x++)
for (int y = 2; y < x; y++)
{
if((x%y)==0)
break;
else if(y==x-1)
primo = x;
}
time = Environment.TickCount - time;
Console.Write("\nil numero primo piu' alto in un range massimo di " + max + " e' " + primo +
"\ntempo d'esecuzione: " + time + " mSec");
Console.ReadKey();
}
}
}Download
Ultima modifica:
Devo dire che i benchmark fatti da St3ve mi hanno incuriosito parecchio, così ho provato a farli anche io (su Arch Linux x86_64 (64 bit)).
Per il .net ho usato mono
Per il C++ ho eseguito l'exe compilato da St3ve su Wine (un ambiente di emulazione windows ma molto veloce, per esempio alcuni giochi mi girano meglio su wine che su windows)
In più ho provato per curiosità mia a eseguire lo stesso benchmark in java.
I risultati mi hanno stupido:
C# (su mono): 155850 mSec
C++ (su wine): 154107 mSec
Sun Java 6: 170256 mSec
Come CPU ho un Intel I5 750
A parte java che mi aspettavo che sarebbe stato più lento (nonostante giri molto meglio su linux che su windows) mi ha colpito la velocità di mono non essendo un framework ufficioso.
Sarei curioso di provare come giri C++ nativamente ma conoscendolo poco non so che alternativa usare a Windows.h e a GetTickCount()
Vi lascio al sorgente java
@Predator: per interfacciarti più velocemente con le opengl potresti usare OpenTK oppure Agate Lib (che se non sbaglio è un fork di opentk)
Per il .net ho usato mono
Per il C++ ho eseguito l'exe compilato da St3ve su Wine (un ambiente di emulazione windows ma molto veloce, per esempio alcuni giochi mi girano meglio su wine che su windows)
In più ho provato per curiosità mia a eseguire lo stesso benchmark in java.
I risultati mi hanno stupido:
C# (su mono): 155850 mSec
C++ (su wine): 154107 mSec
Sun Java 6: 170256 mSec
Come CPU ho un Intel I5 750
A parte java che mi aspettavo che sarebbe stato più lento (nonostante giri molto meglio su linux che su windows) mi ha colpito la velocità di mono non essendo un framework ufficioso.
Sarei curioso di provare come giri C++ nativamente ma conoscendolo poco non so che alternativa usare a Windows.h e a GetTickCount()
Vi lascio al sorgente java
Codice:
import java.util.Scanner;
public class Main {
/**
* @param args
*/
public static void main(String[] args) {
int time = 0;
int max = 0, primo = 2;
Scanner in = new Scanner(System.in);
System.out.println("Range massimo di numeri primi: ");
max = in.nextInt();
time = (int) System.currentTimeMillis();
for(int x=3;x<=max;x++)
for (int y = 2; y < x; y++)
{
if((x%y)==0)
break;
else if(y==x-1)
primo = x;
}
time = (int) System.currentTimeMillis() - time;
System.out.println("\nil numero primo piu' alto in un range massimo di " + max + " e' " + primo +
"\ntempo d'esecuzione: " + time + " mSec");
}
}@Predator: per interfacciarti più velocemente con le opengl potresti usare OpenTK oppure Agate Lib (che se non sbaglio è un fork di opentk)
D
Deleted member 108576
Ultima modifica:
Fate attenzione che il net non consuma il triplo di ram in termini assoluti 
Cioè piu' l'exe è grosso piu' sottile sara' la differenza, perchè nel net ci sono cose che si caricano indipendentemente dalla dimensione del programma.
Solo nei piccoli exe di qualche kb si nota, in quanto il net utilizza cose che nel codice nativo non ci sono (ovvio altrimenti il dotnet framework che ci sta a fare). Del resto anche il formato PE del net è diverso, possiede sezioni che il PE nativo non ha.
Ma per esempio in un exe da 1 mb il consumo di ram sarà simile
Penso di essermi spiegato, ma dettaglio ulteriormente:
in un exe si caricano:
-Assembly nativo
exe
kernel dll
-Assembly Net:
exe
kernel dll
.net core
perciò quello che vediamo "pesare" sono le dll del net che sono uno "zoccolo" fisso
per quanto riguarda il consumo puro di una funzione puo' essere che il net consuma di piu' perchè svolge una comodissima gestione del garbage code, che in linguaggi piu' low level, come il C vanno fatti a mano
---------- Post added at 09:30 ---------- Previous post was at 09:26 ----------
Cioè piu' l'exe è grosso piu' sottile sara' la differenza, perchè nel net ci sono cose che si caricano indipendentemente dalla dimensione del programma.
Solo nei piccoli exe di qualche kb si nota, in quanto il net utilizza cose che nel codice nativo non ci sono (ovvio altrimenti il dotnet framework che ci sta a fare). Del resto anche il formato PE del net è diverso, possiede sezioni che il PE nativo non ha.
Ma per esempio in un exe da 1 mb il consumo di ram sarà simile
Penso di essermi spiegato, ma dettaglio ulteriormente:
in un exe si caricano:
-Assembly nativo
exe
kernel dll
-Assembly Net:
exe
kernel dll
.net core
perciò quello che vediamo "pesare" sono le dll del net che sono uno "zoccolo" fisso
per quanto riguarda il consumo puro di una funzione puo' essere che il net consuma di piu' perchè svolge una comodissima gestione del garbage code, che in linguaggi piu' low level, come il C vanno fatti a mano
---------- Post added at 09:30 ---------- Previous post was at 09:26 ----------
penso che sabato potrò fare passi avanti, vi tengo aggiornati
il progetto mi piace, mi offro come tester. ho un pc del 2004 (2,6 Ghz pentium 4, 750 GB hard disk, scheda video ati radeon 9200, 2GB di ram)
quindi penso che se il programma gira con il mio pezzo di pietra non dovrebbe avere problemi a girare su computer recenti.
PS: potresti inviarmi PM in caso di novità? grazie.
quindi penso che se il programma gira con il mio pezzo di pietra non dovrebbe avere problemi a girare su computer recenti.
PS: potresti inviarmi PM in caso di novità? grazie.
sinceramnte non ci ho ancora pensato, sicuramente free per utilizzo non commerciale, per utilizzo a scopi commerciali magari ci penso. naturalmente dovra' essere un prodotto maturo
---------- Post added at 19:16 ---------- Previous post was at 17:57 ----------
Mi sono smazzato un sacco di engine grafici (non pensavo ce ne fossero cosi tanti), caratteristiche, pregi e difetti. Sono arrivato alla conclusione che per il mio progetto devo partire dalla cosa quanto più grezza posso trovare e scrivere da zero il più possibile. xna fa al caso mio! Non ha niente dell'engine, è proprio un framework grezzo, offre solo le basi di render e la gestione dei vettori, lasciando qualsiasi tipo di realizzazione al programmatore. E' proprio quello che mi serviva. In questo modo, se lo faccio fatto bene, avro' buone possibilità di fare il porting anche su xbox. Di fatto io ho già scritto questo pezzo di codice, ma a differenza di quello che avevo fatto io xna mi permette l'inizializzazione contemporanea di più schermi e finestre. Non so dove sbagliavo, ma a questo punto non mi importa
---------- Post added at 19:16 ---------- Previous post was at 17:57 ----------
Mi sono smazzato un sacco di engine grafici (non pensavo ce ne fossero cosi tanti), caratteristiche, pregi e difetti. Sono arrivato alla conclusione che per il mio progetto devo partire dalla cosa quanto più grezza posso trovare e scrivere da zero il più possibile. xna fa al caso mio! Non ha niente dell'engine, è proprio un framework grezzo, offre solo le basi di render e la gestione dei vettori, lasciando qualsiasi tipo di realizzazione al programmatore. E' proprio quello che mi serviva. In questo modo, se lo faccio fatto bene, avro' buone possibilità di fare il porting anche su xbox. Di fatto io ho già scritto questo pezzo di codice, ma a differenza di quello che avevo fatto io xna mi permette l'inizializzazione contemporanea di più schermi e finestre. Non so dove sbagliavo, ma a questo punto non mi importa
Ultima modifica:
ah ottimo! ti ringrazio. avevo già iniziato a picchiarmi con la fisica. Ero arrivato a fare algoritmo di: gravità, vento, fiamme e caduta oggetto con collisione. ma ne mancano tantissime di cose nella fisica.
ho visto dei video è mi son commosso
penso che mi sarà utilissimo a dir poco!
---------- Post added at 20:23 ---------- Previous post was at 19:56 ----------
ho testo un po di cose del motore fisico non so quanto difficile possa essere utilizzarlo ma.... FANTASTICOOOOOOOOOO!!!!!
ho visto dei video è mi son commosso
penso che mi sarà utilissimo a dir poco!---------- Post added at 20:23 ---------- Previous post was at 19:56 ----------
ho testo un po di cose del motore fisico non so quanto difficile possa essere utilizzarlo ma.... FANTASTICOOOOOOOOOO!!!!!
vedo che si fanno progressi, spero che uscirà una figata e che il suo consumo di preswtazioni sarà DAVVERO direttamente propozionale alle impostazioni di rendering [per renderizzare un'animazione su blender (palla con pochi poligoni che emette orbs) di 20 secondi ci mette 1 ora e mezza].
PS: ma porca vacca come fai a fare così tanti algoritmi in qualche giorno?
PS: ma porca vacca come fai a fare così tanti algoritmi in qualche giorno?
Io spero solo che lo faccia e lo porti a termine, perché la cosa non è per nulla semplice, ma più che altro ci vuole tempo. Però io mi fido di Predator, speriamo in bene xD.
Ah, Predator, ce anche: 3D physics engine Matali Physics come motore fisico, ma io ti consiglio: Bepu Physics.
Ah, Predator, ce anche: 3D physics engine Matali Physics come motore fisico, ma io ti consiglio: Bepu Physics.
Ultima modifica:
Jacotsu questo non sara' un programma come Blender, nel quale puoi ottenere fotorealismo, qui i render saranno in tempo reale, come nei videogiochi
Ho fatto molto perchè avevo già lavorato tanto tempo fa
---------- Post added at 11:54 ---------- Previous post was at 11:52 ----------
Ho visto, è commerciale. Bepu invce ha già tutto ciò che mi serve, e se dovesse mancare qualcosa preferisco aggiungere codice mio.
Aggiornamento:
mi rendo conto che la partenza sarà molto lunga.
Percorrendo la strada di xna e cercando di dare compatibilità a xbox360 (anche se cosa secondaria) ho creato una soluzione composta da codice vbnet e c#. ho creato un content manager in c# che converte tutte le risorse in formato xnb, gestendo il pipeline e creando un host che conterrà la soluzione in codice vb.
Questo mi permette di utilizzare C# e VBNET nello stesso prodotto.. altrimenti avrei potuto fornire solo C#.
Faticaccia ma tutto ok
mi rendo conto che la partenza sarà molto lunga.
Percorrendo la strada di xna e cercando di dare compatibilità a xbox360 (anche se cosa secondaria) ho creato una soluzione composta da codice vbnet e c#. ho creato un content manager in c# che converte tutte le risorse in formato xnb, gestendo il pipeline e creando un host che conterrà la soluzione in codice vb.
Questo mi permette di utilizzare C# e VBNET nello stesso prodotto.. altrimenti avrei potuto fornire solo C#.
Faticaccia
ma tutto ok
D
Deleted member 108576
Predator pur essendo ancora all'inizio hai in mente di "inserire" qualche "funzione" (Sono 0 in questo campo) che permetta la creazione di giochi "multiplayer online" ??? Per farti capire un po' come FPS Creator, puoi crearti l'host direttamente dal gioco che crei e poi usi lo stesso client può essere usato per connettersi e giocare.
Predator sta scrivendo un motore non un Game Creator: una cosa tipo unity, cry engine, unreal engine, SunBurn.
In pratica è un set di librerie per semplificare e velocizzare la scrittura di un gioco, devi sempre passare dal codice e quindi il metodo di comunicazione di rete lo devi scrivere tu insieme al gioco
Ultima modifica:
bhe Exit93 si e no. In realtà sto cercando di fare una cosa ibrida. Cioè prima di tutto un comodo ambiente visuale di creazione di gioco e allo stesso tempo dar la possibiltà di utilizzare codice. Se facessi solo codice sarebbe una cosa simile a xna, invece vorrei dare strumenti piu' "comodi"
Lux, la gestione del multiplayer è sicuramente una cosa da fare. A tal proposito ho scritto tempo fa una libreria di comunicazione socket, sicuramente avro' già parecchio lavoro da reciclare
Lux, la gestione del multiplayer è sicuramente una cosa da fare. A tal proposito ho scritto tempo fa una libreria di comunicazione socket, sicuramente avro' già parecchio lavoro da reciclare
Ottimo
Comunque, i giochi per xbox per ora non li cagare XD.
Comunque, lasciamo fuori nomi di editor come: Unity3D etc... in quanto per arrivare a quei livelli da solo... è praticamente impossibile, anche in team di esperti la cosa è molto ma molto complessa e lunga, quelli sono editor che sono sul mercato da anni (Unity3D se non erro sta dal 2005 con dietro una società molto ampia e con molti esperti nell'ambito del gaming)
Comunque, i giochi per xbox per ora non li cagare XD.
Comunque, lasciamo fuori nomi di editor come: Unity3D etc... in quanto per arrivare a quei livelli da solo... è praticamente impossibile, anche in team di esperti la cosa è molto ma molto complessa e lunga, quelli sono editor che sono sul mercato da anni (Unity3D se non erro sta dal 2005 con dietro una società molto ampia e con molti esperti nell'ambito del gaming)
non mi interessa se Unity o altri sono in piedi dal 1800, tutti sono nati da zero
io inizio e se il progetto prende il piede giusto, sicuramente ci sara' chi è interessato a collaborare
io inizio e se il progetto prende il piede giusto, sicuramente ci sara' chi è interessato a collaborare
Prima ho scritto ciò, per non dare false speranze a chi lo testa... ovviamente tutti sono partiti da 0, con un edior che aveva poco o nulla e con un team sicuramente più limitato.
Comunque: Mercury Particle Engine
Comunque: Mercury Particle Engine
Ma guarda che l'avevo capito cosi
ah il download... OTTIMO! io avevo scritto la gestione particellare della pioggia/neve/nuovole/fuoco ma questo è fichissimo per fare quegli effetti scia che son tanto belli da vedere! grazie mille!
penso mi verra' molto buono anche per getti d'acqua e cascate
A questo punto vi do un ulteriore aggiornamento. Innanzi tutto devo dire che aver deciso di lavorare su xna è stata la scelta migliore che potevo fare.
i motivi sono innumerevoli: supporto microsoft, utilizzo directx, sviluppo su xbox, engine fisica e particellare ultrafiche che mi ha linkato Magetus, velocità di esecuzione e...perchè... oltre al C# hanno aggiunto il supporto VBNET uhauhauhauhauhauh
ok cestino il wrapper c#/vbnet che avevo fatto, ora che ho il supporto vbnet è inutile.
---------- Post added at 15:31 ---------- Previous post was at 15:24 ----------
A sto punto... vedo un futuro utilizzo anche con l'hardware di Kinetic
ah il download... OTTIMO! io avevo scritto la gestione particellare della pioggia/neve/nuovole/fuoco ma questo è fichissimo per fare quegli effetti scia che son tanto belli da vedere! grazie mille!
penso mi verra' molto buono anche per getti d'acqua e cascate
A questo punto vi do un ulteriore aggiornamento. Innanzi tutto devo dire che aver deciso di lavorare su xna è stata la scelta migliore che potevo fare.
i motivi sono innumerevoli: supporto microsoft, utilizzo directx, sviluppo su xbox, engine fisica e particellare ultrafiche che mi ha linkato Magetus, velocità di esecuzione e...perchè... oltre al C# hanno aggiunto il supporto VBNET uhauhauhauhauhauh
ok cestino il wrapper c#/vbnet che avevo fatto, ora che ho il supporto vbnet è inutile.
---------- Post added at 15:31 ---------- Previous post was at 15:24 ----------
A sto punto... vedo un futuro utilizzo anche con l'hardware di Kinetic
- Stato