• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

126 Neutral

About Narcist

  • Rank
  1. Quote:Original post by MrEvil a. nasm b. Free, multiple output formats, including flat-form binary which is useful for making bootloaders/kernels and it doesnt use the bloody evil gnu (at&t?) syntax c. Pay for software? [wink] d. I woudldn't pay for any assembler.
  2. Most of our compilations at work, cpu speed and ram etc make no big difference, the spu is *NEVER* more than about 20/30% (around p4 2ghz some duals some not) during compiles, the biggest problem is disk access for all the headers, SCSI made a *BIG* difference for our projects, halves the compile time between keeping the headers on SCSI or on IDE (everythign else same, same pc, just compared between having the files on the SCSI C:\ or the IDE D:\)
  3. Quote:Original post by Floating Thank you for the very nice explanation Narcist!! If I understand you correctly I should use TCP for fail-safe communication (nothing is lost, even with wireless communication... the system is taking care of resending if no confirmation of reception was received (this happens invisible to the user, right? the user just sends and receives, but doesn't need to send confirmations of reception) Correct Quote:Original post by Floating For sending a picture of a camera, I should use UDP: no guarantee that data was received, but fast. In that case, how should I send the data? In small bits I guess, but where do I know which part of the picture I am receiving? Of course I can always append a little header telling where the data goes, but since there is no guarantee that I will get the header first, I might misunderstand some part of the actual data as the header no? kindof, i'm pretty sure that UDP does have granularity on the entire packet, so either the entire packet goes through "as is" or it doesnt, so you would put the header at the start of the packet, and a block of data at the end of the packet, it is all in one packet so you know the header is always going to be before the data, if however you sent the header in another packet, all bets would be off, you might not get the header before the data, and then you wouldnt know whether a packet was header or data. in your camera example, i would probably still send the pictures by TCP, as they would be too large to fit inside a single UDP packet. However say you wanted to send some kind of state information, (random example) temperature information. I would probably use UDP, each packet you just send the current temperature, if a packet is lost, it doesnt matter, you will still get the temperature from the next packet, you dont actually care about the lost packet because newer information will be available soon enough anyway. For instance in a game, you might sned the position and orientation of the player to the server, now if one of those packets are lost, then a new position and rotation will be sent anyway, you dont want to "hold up" the connection for that now out-dated information. TCP would stop sending any other data through until it had resent that missing packet, at which point it would then contnue sending the "backlog" of data thaqt had built up. Quote:Original post by Floating This might sound stupid questions and I am sorry if it is. Also TCP and UDP are both different types of sockets, right? no worries, not stupid questions :) TCP and UDP use (mostly) the same functions, the difference is in the SOCK_STREAM (TCP) or SOCK_DGRAM (UDP) flags passed when you create the socket. The differences come from the "nature" of the sockets, because TCP is a connection orientated protocol you usually either A) (as Client) call "connect" giving the remote servers address, this performs some handshaking between the 2 machines so they both know there is a connection going, then you just "send" and "recv" data from that socket B) (as Server) "listen" to a specific port/address, when you receive the connection you will be notified and can choose whether to "accept" the connection or not, if you do, the connection will be setup and you can then "send" and "recv" same as the client In UDP there is no connection (its sometimes referred to as a peer-to-peer protocol, note not all peer-to-peer applications are UDP) both machines in effect "listen" to a specific port/adderss, they then use "sendto" and "recvfrom" to read and write data, so with one socket you can actually send and receive data to multiple machines at once, each packet could be sent to different machines if you require, you just specify the address in the call to sendto, and you receive the address of the machine that sent th packet in recvfrom
  4. you seem to be mixing up UDP and TCP there TCP, think of it like a FIFO queue, its a stream. at one end someone is putting data into the stream, at the other end someone else is taking it out. There is no concept of packets at all (at least you have to assume so) They may put 256 bytes in, and then another 256 bytes, but the reader could get it in 512 byte blocks. if you want to handle "packets" you have to handle them yourself, eg send through a size first, read the size and then you know how much data to read to get the rest of the one "packet". TCP is also guarenteed and in order, eg you will never get the second 256 bytes before the first (ignoring OOB data) and you also know that if you send 256 bytes, the receiver has received those 256 bytes (or the connection goes down). UDP is completely different, think of it like (snail)mail, where each packet is a postcard, there is a limit to how much you can send in each postcard, and there is no guarentee that the postcards will arrive in the same order that you posted them in, or even that the postcards will arrive at all. nothing is guarenteed about UDP, however it is a lot quicker as there is nothing going on in the background (TCP already send network packets underneath the hood to say the data has been received, UDP doesnt) now if you just want to send a large amount of data in order, then use TCP, its designed from the ground up to handle it, and is easy to use. However if your writing a game or something similar and are not bothered about *every* packet being received, but care more about the fact those packets are received fast, then use UDP.
  5. there is nothing you can do about stopping hacking of the executable to ignore the key, the most you can do is stop them producing a key-generator. simple method would be to use public key cryptography, simply "sign" the serial number using your private key, and then use the public key stored in the executable to verify it. the executable only stores the public key, all it gives the hacker is information on how to verify keys, not produce them. If your using c# then i was astonished how easy the cryptography was to use there, simply look in System.Security.Cryptography
  6. One guess would be portabilty, not all STL's are equal and by "rolling their own" i guess they wouldnt run into problem with a particular port having a non-standard or buggy STL
  7. Quote:Original post by CProgrammer Maybe I should clarify: Its something like this: class Class1Interface... class Class1 : public Class1Interface.... class Class2Interface : public Class1Interface class Class2 : public Class2Interface, Class1 This doesnt seem to be possible. -CProgrammer That should be no problem, Class 1 implements Class1Interface, Class2 implements Class2Interface so a Class1Interface pointer to a Class2 will have its functions implemented via Class1 a Class2Interface with have its functions implemented via Class2 so long as you arents trying to use Class1 to implement functions in Class2Interface, if you are then Class1 would need to inherit from Class2Interface
  8. are you saying you have something like this ? class MyInterface { public: virtual void SomeFunc(void) = 0; virtual void SomeFunc2(void) = 0; }; class Base { public: virtual void SomeFunc(void) {printf("SomeFunc\n");} virtual void SomeFunc2(void) {printf("SomeFunc2\n");} }; class Derived : public Base, public MyInterface { }; if so, then can you make Base derive from the interface instead of Derived, you might need to use virtual inheritence with multiple bases, i'm not sure i thought a using statement might help but it doesnt seem to
  9. just sharing a variable between 2 threads doesnt require a lock, providing you can read and write the the variable atomicly (in one operation) eg if thread 1 only reads from a global int, and thread 2, writes to it, you dont need a lock providing you take care and dont assume its value cant change at any point if in doubt put a crit section (or whatever) around any data that can be used by multiple threads in your example if Thread A only uses var1 and never var1copy then var1 needs protected but not var1copy
  10. Hashing vertices?

    Dont know about hashing 3 floats, but if you want to compare close values you could always just remove some of the precision from the floats before hasing eg if you wanted to lose 8 bits of precision from the floats then & the DWORD value of the float with ~0xF before hashing eg float f = 1.000001f; unsigned int i = *(unsigned int *)&f; i &= ~0xF; f = *(float*)&i; printf("%f", f); prints out 1.0000 the only problem with this method is the value your rounding to will vary based on the magnitude of your values eg 1.000001f -> 1.0 10.00001f -> 10 100.0001f -> 100 and so on
  11. template function in C++

    Quote:Original post by petewood Quote:Original post by thedevdan Personally, I think "T" is as bad as naming a variable "V". I always use descriptive names. In a template it is a type. It could be any type. What else would you put other than Type or T? eg *** Source Snippet Removed *** What do you suggest using instead of T? Bad example i guess what he means is something like template <typename ReturnType, typename InputType1, typename InputType2> ReturnType Max(InputType1 a, InputType2 b) { return a < b ? ReturnType(b) : ReturnType(a); }
  12. asm question

    question about reading EIP? dont have my docs to hand but from memory you cant read EIP directly, you can however push it onto the stack and then pop it off intot he register of your choice if that doesnt work well you can always call a ffunction and read the RA off of the stack to get it HTH
  13. have you tried deleting the browse information file? sometimes they get corrupt and need to be wiped and rebuilt, though that was more of a vc6 problem
  14. On a related node if b is a power of 2 then a % b = a & (b - 1) but is a lot quicker on most cpus, not relevent to vb of course but nm ;)
  15. asm question

    I may not be following, but what you seem to be saying is you want to CALL a subroutine and the RETurn from it? do you know about the CALL and RET mnemonics? CALL pushes the IP on the stack and then jumps to the address specified, RET pops that IP back off the stack and jumps to the popped value I dont know the eaxct machine code values for those but you should can get them from the intel manual on the intel website HTH
  • Advertisement