Quote: "I will take that as a personal attack. Thanks much.
...
ok, tell me how to post properly?
"
1) it was one, I was angry. I do apologise for it though, but I wont pretend it wasnt an attack.
2) All I mean is the moment you see something you dont agree with or someone ventures an opinion you appear to reply with "omg stop whining" or something very simular. I -wasnt- whining, to whine about something I dont use would be very very stupid. If I didnt like c# and was being forced to use it THEN I could whine, but as it stands im not forced to use it and dont. But I did start talking about what I dont like about it, as that was on topic, and then I instantly got called a whiner. That made me mad.
Jeku:
I belive I stated in what way my darksdk app was portable, also noting the extra amount of work it would take TO port because of the directx and the fact I would have to write new 3d handling functions including a replacement for the sync. What I did say however is that the bulk of the engine is portable and, although alot of work, the 3d side could be ported without having to touch the actual engine because my darksdk calls are ecapsulated in a class so instead of going around the entire program changign every load object call for example i would just have to go into my model handler and change the one place it loads data and then every single call would be "ported" as it were. Its still alot of work, granted. But most porting is. opengl runs in linux from the start - but if you have a program that runs "out of the box" in both types of OS with a different compile (but same code) then no porting is involved - your code isnt portable it jsut works
Porting is the actual effort into /changing/ something to work with something else. My point is that I can do that in c++ and despite using darksdk because of the way I write my code its not as much work as it COULD be, but its still alot. In c#, ignoring mono for a minute, porting to another OS is of course possiable, but it would mean porting to /another language/. Mono is getting better though, as I said light at the end of the tunnel.
As for the assembler comment - a) I
do - I use inline assembler when I think it will pay off. This was commented on in my, now slightly dusty, Shisaku WIP thread. But I dont use it that often because the point most people seem to overlook is the c++ compiler will generate more optimised asm than most of us can actually write, its very good at that kind of thing
But there are times when a little bit of human inginuity (yes i can program, but not spell) can do the job a few ticks faster, like in shisaku I wrote some asm to parse the vis/portal table at the players current position to discover what could be seen and what couldnt - as the function is ran every frame a few ticks extra speed does count and I managed to get it by writing some asm and using a hashing technique to do some of the fastest array parsing I have ever seen.
But thats neither here or there. We seem to have alot of c# vigilantes here atm, but people like that exist for every language. As I have ALREADY said several times both languages have their good points but c# certainlly isnt sweeping the floor with c++ - yet. For me, c++ is still a faster and more flexiable choice of language. and half the apis that exist really do speed up the dev time by making things less complex and for everything else its either uncommon or I have written my own class to handle it. All im saying is the "draw backs" of c++ really arnt that big, theres usually always something to help you do the job already and if there isnt well, if you are coding right you will only have to write it yourself once and walla. Same with c# really, but c++ has many years up on that. The gap will get smaller and maybe c# will get faster and faster and maybe mono will become just as effcient as the official .net runtime and maybe there will be no poor people who arnt still using win98 so everyone has XP .net able machines and maybe when its all true C# will truely be the king of languages. and maybe the moment it is king no one will try and make a better one causing confusion and changing the standard /again/. Who knows?
But i'm happy with my cpp and I find it a little off that I have to explain that conviction, but there you go.
