Canardia
-
Posts
4,127 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Canardia
-
-
Of course for those cases you have to do the same. Doesn't really make a difference if it's a class or a function.
-
Infinity isn't a number
It is, it's just not absolute, althought its definition is absolute.
It's the highest number any given system can represent, so it's the "same" number on all systems: the highest.
We can't reach the true meaning of infinity on systems which have limitations, but nature has not. Nature is truly infinite up and down.
-
Wrong, you can have library with shelves which a are infinitely long, and you can have infite amount of shelves, so infinity is also scalable. It just represents the magnitute of growth. Nothing in nature is an error, errors are only a hypocritical illusion of weak minds.
-
STL containers work kinda like BASIC: they make sure the zero element exists, is initialized. That's why they take up initial memory, but it's totally meaningless because you actually want to populate the container, and if not, then don't declare it.
Where STL really comes to play is in the speed. Even an ineffective iteration through a vector is faster than an native Fortran linked list. I don't know how they do it, but it's insane fast.
Windows cleans up all leaked memory, but it doesn't do it immediately. That's why it's kinda "OK" to not call delete, but just let windows clean the memory up. I mean in the sense that your game reserves the memory what it needs, so there is no harm done to the game itself.
-
Mathematics is wrong. Division by zero means infinity. So on any system a division by zero should return the maximum number possible.
-
With my method you can get the real memory usage, and on all platforms.
-
The only accurate way to measure memory consumption in C++, is to make a #ifdef into each class constructor which increases a global memory usage counter, based of sizeof(ClassName), and an #ifdef for the counter itself in the class attributes, and and #ifdef in the destructor to reduce the same amount.
-
I think the cat is trying to show you that you have a programming mistake in that line where she points her paw at.
-
There are no real alternatives to ISO date format (which I have invented btw., so nobody likes it):
2012-12-21
It sorts correctly when expressed as plain text, which no other date format on this planet does.
It's intuitive, nobody hates it because it's not tied to any country.
There is no better date format, and never will be.
Of course the time format can be appended to that, making it even more detailed, and no, you don't need the 'T' between, just a space will do. It must remain human readable and enjoyable.
-
Interesting, somehow I could not include general .a files, perhaps because they were not compiled with the -static linker option into BlitzMax. I could use my own C++ as a .a file in BlitzMax, but as soon I called embedded .a files, BlitzMax behaved very wierdly, while the same program in C++ only complained that for example ws2_32.a was not linked (=undefined references).
-
I have been working every day a bit on Fastnet, because I want to finish it. Yesterday I found out that including the .a file into BlitzMax works only half-way. So now I'm first finishing the C/C++ version, and then I have to do it with native BlitzMax commands, which unfortunately needs a DLL too. So no single exe fun for BlitzMax users, like for C++ users.
That's actually the same pattern how Leadwerks3D will be. Single exe for C++, DLLs for any other language.
-
There are times when you feel that using mouse is nerving and using keyboard is a bliss, and sometimes the other way around. It depends also a lot on the application, and how comfortable the mouse or keyboard handling is (application/hardware wise).
Of course there should be only C++, but sometimes you need C also when you need maximum speed, and sometimes even Fortran if you want overmaximum speed. Of course you need PHP also, and JavaScript, and SQL. But not much more, and those languages are not alternatives to eachother, they are made for their purpose, where no other language would work.
-
This thread is so toast, so let's have at least some final joy of it:
-
I'm going to complain to Josh soon, all talk about DirectX should be banned from this forum. It's ****, no need to discuss
-
Guys, you can easily solve all the problems with DirectX by just downloading the Debian 6.0.5 DVD, putting it in your PC drive, and suddenly your PC hardware actually works! Everything what Microsoft has done is BAD, very bad, except WinSock, which is also cross-platform. They kinda made a "mistake" by making something good.
I bet the developer of WinSock was fired long time ago, because I think the employment policy in Microsoft is something like this: Never make anything good or useful, only make bad, slow, buggy and bloated programs (hey, that's why we invented C# and SharePoint in first place), because that's where we get the money from, since each "bug report" costs the customers 500€. Then we fix it, but of course not for everyone, since we want the money from all other customers too.
-
OpenGL is better than DirectX, case closed.
-
Well, game design is about optimizing things. That particular situation could be optimized by sending more frequent packets in close combat, or implement a game logic which prevents from exploiting the network heartbeat. For example god would kill a player who is jumping and running around for no apparent reason. I wish they had that in WoW
-
Yes, to maximize speed via data queing, multithreading is a must, so I will implement that too. POSIX threads are great, especially when using MUTEX. I don't think games need that often data updates, I mean not like 60 times per second. A one second interval should be just fine even for the fastest actions games (I just imagined a massive FPS combat scene, where players move around and shoot at eachother, everything moves all the time, but every 1 second things are updated, if there is even a need to update, because non-changing directions and speed don't need any data to send), since the movements are done with MoveEntity/PointEntity commands anyway, which implements interpolation.
My real concern is the amount of players. With a smart packet queing it should be possible to have thousands of players on a indie server (just a normal tower PC connected to 8/3 landline ADSL).
Just imagine a stable and constant 1s heartbeat of the earth. You have a LOT of time to collect differential data to send, and the action will never seem laggy, because it beats hard with that 1s interval. Forever, and ever.
-
That doens't explain why I can send 14 bytes or 114 bytes with send(), and get not a millisecond difference in transfer speed. It would mean, that I have to manage when I call the send() function, after I have a big enough string to send (or binary data).
Obviously, it's not very effective to send small packets, because each sending takes FPS, and it would be much more efficient to send larger packets, since the FPS drop is the same.
Or lets look at it the other way around: if send() was doing packet queing, then it would show much faster speed with 14 byte strings than with 114 byte strings, because the total amount of data transferred is much bigger. That means send() does not really do the packet queing right, if it does it at all, because if it did it right, then there would a huge time difference in sending the total amount of data from 100 repeated send() commands.
-
That's the default for winsock TCP sockets...
If you want to disable that, and send instantly:
BOOL bOptVal = TRUE; int bOptLen = sizeof(BOOL); int iResult = setsockopt(/*Your socket handle*/,IPPROTO_TCP,TCP_NODELAY,(char *)&bOptVal,bOptLen);
pinched straight out of the MSDN...
I presume those silly capitalised BOOL and TRUE are defined in winsock2.h. However intellisense seems to be having one of those days for me where it doesn't want to tell me
How do you send packets so that they go into the packet queue? From my tests, each message was delivered at once when I did
retval = send(conn_socket,Buffer,strlen(Buffer),0);
-
I had been thinking about how to do networking
Others have done it before, but it was never my thing
I read their experiences and ideas
And thought sdl_net was the way to go, but alas
It needed SDL, which needed DirectX
If I don't strictly stay with OpenGL, I will never have sex
Then I remembered Mumbles, who talked about her own WinSock library
First I thought, she's crazy, to do things that arbitrary
But since there is nothing else on the market than RakNet and sdl_net
I looked up on some hardcore WinSock examples, which I found on Microsoft's site, you bet
They were amazingly clear and worked almost out of the box with MinGW
So I started to compile them with different flavors and test every possible situation, you see
Now all tests are done, and I have a clear picture how to make the fastest possible networking ever
Of course it will be free, and have additional options in the pro version, I think that's clever
Additional options could be encryption, mail and phone support, all things which game developers don't need
But for which enterprises have enough money and requirements as opposed to the version which is free
-
See, you used the word "you" again. Learn to form intelligent sentences. See, I didn't say "you", but generalized it
-
Hey guys, do you know that only idiots talk about people, and intelligent people talk about what they said. I think Paulo Coelho said that.
So please don't use "you" or "me" in sentences, but only what they said and comment on that.
-
Another interesting test I made: it seems that with WinSock TCP it doens't matter even one millisecond, if you send 14 bytes or 114 bytes, while with AJAX it raises the time a few seconds.
Now I think I have all tests done, and can make a super fast network library. Apparently it needs a send queue, where it collects data for a packet before it sends it, to maximize the speed.
divide by zero
in Tech Talk
Posted