It works with Internet Explorer for me but Opera refuses something to do to store the positions 
Last edited by Messiah, .
Reason : disabled the plain stupid emoticon -.-
Heh.. yeps.. I like the RSC one much more than this <insert the GREY biggrin here, the GREY one from RSC not the yellow thingie over here> forum's :/
You are going to code in C# <insert GREY biggrin here>? I bet you got your pistol ready to shoot with pointers :]
See.. when I'm reading through the thread and all about the problems you got and design decisions to make.. it's not only complicated for you but also for other users. Especially who are not familiar with C or DLLs. It may work like a charm for C/C++ programmers because they have no work with "translating" datatypes because it's the same language.
As far as I know, yes. VB's "Type" is similar to a struct, and like C, no forward references. The only datatype missing, afaik, is the signed byte that may be put into a signed 2-byte integer datatype.
.NET can also manage the precise order of structs. I personally barely use structs and prefer classes. There's a major difference between structs in C and C#. For example, they can yield performance gain if the data chunk is <= 16 bytes in size (by Microsoft).
I think .NET programmers are somewhat spoiled. They have been given a huge framework. It may be the same like an old fashioned C/C++ programmer who got his includes ready at all times and everything works fine for him. We got our framework ready and it also works fine for us
Implementing .NET Assemblies (same like DLLs) is a lot more comfortable for us. We got intellisense providing us with all available classes, structs and their methods (even with parameters to pass) and properties to access. We don't explicitly need a list of what we can do/call and not. That's handy.
I can either provide your with support and contribute to a .NET assembly if you're going to create one or a descent article about what someone should know when moving from a C major to a C sharp ^_^ (musician joke :P). And I bet sdether would contribute as well if he got the time to do so
Otherwise I'd wrap the DLL into a C# class rather than using the DLL directly with all programs. Because you'd still need to convert the returned data into proper C# datatypes. It's less work than porting the whole functions but I guess it needs maintenance as well if the DLL changes. <insert :scratch: here>
You are going to code in C# <insert GREY biggrin here>? I bet you got your pistol ready to shoot with pointers :]
See.. when I'm reading through the thread and all about the problems you got and design decisions to make.. it's not only complicated for you but also for other users. Especially who are not familiar with C or DLLs. It may work like a charm for C/C++ programmers because they have no work with "translating" datatypes because it's the same language.
As far as I know, yes. VB's "Type" is similar to a struct, and like C, no forward references. The only datatype missing, afaik, is the signed byte that may be put into a signed 2-byte integer datatype.
.NET can also manage the precise order of structs. I personally barely use structs and prefer classes. There's a major difference between structs in C and C#. For example, they can yield performance gain if the data chunk is <= 16 bytes in size (by Microsoft).
I think .NET programmers are somewhat spoiled. They have been given a huge framework. It may be the same like an old fashioned C/C++ programmer who got his includes ready at all times and everything works fine for him. We got our framework ready and it also works fine for us
Implementing .NET Assemblies (same like DLLs) is a lot more comfortable for us. We got intellisense providing us with all available classes, structs and their methods (even with parameters to pass) and properties to access. We don't explicitly need a list of what we can do/call and not. That's handy.
I can either provide your with support and contribute to a .NET assembly if you're going to create one or a descent article about what someone should know when moving from a C major to a C sharp ^_^ (musician joke :P). And I bet sdether would contribute as well if he got the time to do so
Otherwise I'd wrap the DLL into a C# class rather than using the DLL directly with all programs. Because you'd still need to convert the returned data into proper C# datatypes. It's less work than porting the whole functions but I guess it needs maintenance as well if the DLL changes. <insert :scratch: here>
Last edited by Messiah, .
Yes, in fact there "should be" on problems but there is. Unfortunately the .NET Framework 1.1 lacks major features and support. I had really simple functions to import once, but anything I tried failed. Not at least because you don't really need "real" pointers anywhere in C# since instances of classes are passed as reference already, function returns are rather used than pointers or the ref keyword on value types (like int, double, etc).
I have asked a handful of C# programmers for advice, they were using C# nearly since it was released but didn't have a clue why it didn't work. I even had the source of the C dll :/
If I ever was using it, I had problems. The major lack I have spoken of is the reponses of the .NET Framework. For example it just gives you a NullReference Exception (Guess it's equal to null pointer exception) instead of telling you that you have used a wrong parameter while calling the function or whatelse you did just wrong. All that makes it very hard to debug. I even tried to trick the whole call with just giving a pointer to an address with only a byte array where I would be able to convert the data in their proper datatypes.
It's probably possible to use native DLLs flawlessly but it requires someone to have lots of experience with using them and using pointers and the proper datatypes. Unfortunately I lack the experience for that with C#
I don't know if that has been fixed with the .NET Framework 2.0 but I tend to doubt it, while it needs another bunch of hours to learn working with the new framework
And... there IS a banana when you write a posting, in the small window "Smilies" and it sucks as much as the "modern"-Emoticon :P
I have asked a handful of C# programmers for advice, they were using C# nearly since it was released but didn't have a clue why it didn't work. I even had the source of the C dll :/
If I ever was using it, I had problems. The major lack I have spoken of is the reponses of the .NET Framework. For example it just gives you a NullReference Exception (Guess it's equal to null pointer exception) instead of telling you that you have used a wrong parameter while calling the function or whatelse you did just wrong. All that makes it very hard to debug. I even tried to trick the whole call with just giving a pointer to an address with only a byte array where I would be able to convert the data in their proper datatypes.
It's probably possible to use native DLLs flawlessly but it requires someone to have lots of experience with using them and using pointers and the proper datatypes. Unfortunately I lack the experience for that with C#
I don't know if that has been fixed with the .NET Framework 2.0 but I tend to doubt it, while it needs another bunch of hours to learn working with the new framework
And... there IS a banana when you write a posting, in the small window "Smilies" and it sucks as much as the "modern"
-Emoticon :P
Last edited by Messiah, .
Reason : disabled emoticons because too many of them are PLAIN STUPID! ;)
LOL the cam crash was nice ^_^
Neat video! I don't found it really exciting, neither did I really like the music but .. quality, editing and cut with the music .. outstanding work! Therefore a 5 stars rating for very good quality work
Neat video! I don't found it really exciting, neither did I really like the music but .. quality, editing and cut with the music .. outstanding work! Therefore a 5 stars rating for very good quality work
Last edited by Messiah, .
Reason : I really hate the stupid looking emotions, therefore I disabled it >_<
I won't use it tbh :/
IMHO C++ sucks anyway. Furthermore, whenever I was importing functions from dll written in c or c++ or some other outside-.net language by someone, it caused problems or didn't even work at all. €0.02
If that wasn't enough, that stupid dancing banana on the right is driving me crazy... I WANT RSC BACK :E
Weeeee.... awesome! 
May be an idea for the FZF50 with teh engine in its nose ^_^ but then there's no space for "everything" you need. I got there a 1000/100/10 MBit/s 24 Port, Server, Wheel, Cables, ... ;]
So chances are bad if you've not being asked yet *edit*
o m g .... I just noticed the small smilies box ..... can someone please kill that dancing dildo?
And have a look at that one:
*bangs head on table* it looks so awful! stupid! ghey! Where's all the stuff gone we all like... like :woohoo: and :static: (: static :? it's : cheerl :!) and... awww... I gonna miss RSC. The collection (except for the flower) was soo nice, they also had a sorted full list, and they had PHP access violations and stuff *sniff*
PS: Also big grin is no big grin if it's yellowish :|
o m g .... I just noticed the small smilies box ..... can someone please kill that dancing dildo?
And have a look at that one:
*bangs head on table* it looks so awful! stupid! ghey! Where's all the stuff gone we all like... like :woohoo: and :static: (: static :? it's : cheerl :!) and... awww... I gonna miss RSC. The collection (except for the flower) was soo nice, they also had a sorted full list, and they had PHP access violations and stuff *sniff*
PS: Also big grin is no big grin if it's yellowish :|
Last edited by Messiah, .
Hm.. at least the LX6 race_1 setup is *VERY* stable for oval (boring) racing. My tweak was faster though, I think 0.5 secs because you could go faster through the turns and come out faster. But it was also more challenging to drive because it tended to oversteer. Anyway.. for normal tracks the race_1 is not that stable as in the oval, as well as the RAC and FZ5 setups, agreed
*lol* :P
Yea.. I mean.. it's neither a ferrari nor a porsche.. not even a Porrari, it's a FZ50, thus it should have the FZ50 engine! (Ferarsche Engine maybe...)
Yea.. I mean.. it's neither a ferrari nor a porsche.. not even a Porrari, it's a FZ50, thus it should have the FZ50 engine! (Ferarsche Engine maybe...)
"Oval" is just a synonym for "boring". The LX6 was no competition for the FZ5 and RAC so I tried to stay high in the turns for being lapped what turned out to work quite good, I hope the other's found it easy to lap. Beside my three small faults, many blue flags and some yellow flags the race was quite oval and now I go to Fern Bay for some surfing
Last edited by Messiah, .
Reason : om gomg... disabled smileys... omg.............
FGED GREDG RDFGDR GSFDG