Michalson

Members
  • Content count

    7847
  • Joined

  • Last visited

Community Reputation

1657 Excellent

1 Follower

About Michalson

  • Rank
    Staff
  1. Quote:Original post by Driv3MeFar Quote:Original post by Ramsess 1) Dont worry about packet size. OS automaticaly split "big data" into several IP packets. Ummm, I'm fairly certain that this doesn't happen with UDP packets. It does, so long as you don't go over the limit of the UDP protocol itself (~64K, though I wouldn't try to use a payload of more then 62KB to avoid overflowing at a routing point). That's what the the Don't Fragment and Fragment Offset flags are for. The difference between IP level fragmenting of packets and TCP fragmenting of streams is that IP fragmenting dramatically raises the chance of the packet being dropped (there is no resend, if the packets don't come in correctly they just get dropped). So you can let packets be automatically fragmented by the IP stack on the rare instance that they are bigger then the discovered network MTU - if you are constantly sending packets bigger then that though you probably want to be switching to TCP, as you'll need to reinvent it anyway.
  2. Print preview requires some information from the printer driver (it's much worse in some WYSIWYG print applications like Access, where entire parts of the program don't work because they can't start without a printer). At best you can install a file printer (like the Microsoft Document Imaging printer) to work around the problem, otherwise you're stuck making your own approximation of a print preview if you want to preview the results for a printer that doesn't exist.
  3. [web] Security Question

    Clarification: PHP is built on top of HTTP, and thus any issue that affects HTTP, affects PHP. Or ASP. Or JSP. Or whatever server side language is being used to interpret the data from the HTTP level. A PHP "session" is built on top of an HTTP session or long term cookie (unless you change your config to pass a session id in the url, which is rarely done). When someone is building a script to repeat actions over HTTP, they rarely go to the trouble of maintaining the HTTP session variables (cookie value) any more then they have to. The idea of "logging off" reseting their counter is exactly what is going to happen if someone doesn't go to all the trouble of maintaining a persistent session over multiple actions.
  4. [web] Security Question

    Your solution is the right direction (implimenting flood limits), however there are holes. The big one is that such scripted actions are not guaranteed to be nice, well maintained HTTP calls. That is to say that instead of remembering cookie information (session_id) between calls, the script may be much simplier and only establish a connection, feed login and an action, and then never bother to maintain the session. As a result the script may be establishing a session for each action taken, instead of taking all actions within a well defined session. To block that, you'd need to start tracking hits based on IP.
  5. databases..

    Using a database for real time storage (i.e. storing regular variables or quickly changing game data) is not recommended. A database should be treated like a more advanced data file - something you can easily store and retrieve many discrete pieces of data from with a wide range of criteria. If you are writing a game server, a database is an ideal place to save persistent information. On the client side you could use a database as a more advanced pak file, though most databases are of a server-client design, meaning users would have to install and be running a seperate database program. A good alternative is SQLite, an extremely compact embedded database, which allows you to have a single database file that it manipulated by your program (if SQLite is compiled in) or by the SQLite DLL.
  6. Real-time MMORPG Combat

    Quote:Original post by hplus0603 There are MMOs that have semi-real-time components. Try out the EverQuest 2 demo, with their timed specials. Buy a copy of GuildWars and go play it for a while. That will give you a flavor of what CAN be done in real-time. In fact, GuildWars sounds like it'd be a pretty good starting-off point for the kind of game you describe. You can't do real-time as in a fighting game (DOA, Street Fighter, etc) over the Internet, because latencies won't allow you to see the move and block soon enough -- or the move will be too slow and uninteresting to the attacker. You will have to very carefully design and tune your gameplay and specific semi-real-time mechanics to allow for varying latency, while still being cheat resistant. It's all in the game design! Guildwars isn't "real-time", it's more or less the same implimentation as the other click based MMO systems (show some real time animation on the client side while actually doing it as an almost turn based system on the server side), it just has really nice translation of both user input (the optional keyboard movement controls being translated into similar data as clicks) and the incoming movement information from the server. Play it with a laggy connection or with two computers side by side and you can see the seams of it's method as it where. However it does show that it is not impossible to simulate something close to real time interaction. You just need to tweak your gameplay design to remove twitch controls (like having hits based on actual player reaction time and aiming) while at the same time adding interpolating data recieved on the client side to hide jerkyness. Overall keep this in mind: The game does not have to look the same on all computers in the same area, only the key events (damage from hits, spell effects, deaths) need to happen correctly and in order. This benefits both the server, which can focus on handling just those key events instead of small details like individual steps (there is a reason a single MMO server can handle 1000+ players, while a dedicated FPS server usually tops out at 100), and the client, which is free to basically make up the animation and movement of objects in order to make the client side experience seem as smooth and real time as possible.
  7. Real-time MMORPG Combat

    MMO and real time interaction simply don't mix well. Most MMO's do a good job of hiding this fact with creative interfaces (i.e. the reason so many have "click on enemy to attack"), while other games (like RTS games) don't even need to go this far, because there isn't really any time sensitive stuff going on, it just looks like there is on screen. This is because networks have lag. Even with a high speed connection a user often has a ping of 100ms or more, and that doesn't include the round trip to other players (you swing your sword at someone, but at the same time they are moving to right - you end up seeing that movement 200ms later, after your sword swing is complete, because it took 100ms to reach the server, and another 100ms to be relayed to you). Now you've probably played a lot of games like fps's where you can get twitch speed real time interaction with a limited number of players in one "area". The problem is non-MMO multiplayer games that need fast timing cheat: they use extensive client side prediction, and more importantly, the clients are semi-authoritarian. The result is the appearance of real time interaction, but it makes it a foregone conclusion that it will be possible to cheat. With a non-persistent game this isn't a huge problem. Cheat protection that is constantly patched can be used, server admins can kick players suspected of cheating from their server, and ultimately there is no long term consequences of someone cheating in a match. With an MMO that's not the case. Instead of a cheater ruining one match, they can mess up the entire persistent game world. And unlike many games, a player may be able to cheat off in the wilderness where no human player will see them, and then bring the spoils of that back to the city (where it destroys the game's economy). Basically MMO's can't tolerate cheating the way normal multiplayer games can. They need to run on an explicit thin-client model, where the server decides how player actions should actually be interpretted. To make this not seem laggy, the game is intentionally designed to hide it.
  8. Stargate SG-1

    Quote:Original post by RivieraKid i quite liked the end. But its not the end. There is a feature length episode being made to finish it like fascape. There is also at least 1 stand alone film set in the SG universe planned, like the star trek films. And there is a 3rd show on the way. I think they should leave a bigger gap though - Too much too fast can burn the show out. The last season of sg-1 was bloody hilarious. The hostage episode had me in stitches. 200 was also great. Really a comedy season. The acting has always been pretty weak imo. I dont think Richard Dean Anderson was all that. Mitchel was a good idea but the new general was a very silly character, gah. The show was extreemily weak in the first few seasons but when the story arc picked up it was good. Too many crap episodes littered around - trying to milk it. I would like all of the story arc episodes in 1 box set. I couldnt care less about the other episodes. Actually there are two coming. The first will be a wrap up (or at least an attempt to wrap up) the Ori story line (hover your mouse over this for semi-spoiler summary, though not much worse then the episode description you'd see in TV Guide). The second will be more like a self contained feature length episode ()
  9. Get data from a barcode reader in Linux

    There is no standard for barcode reader hardware. There is no barcode reader API or standard driver library to access. You need to make a more computer expert rather then user level analysis of the barcode reader. For example you say that it sends an integer value to where the keyboard has focus. By integer value do you actually mean it sends a string a characters that to an unwashed user would be an "integer"? And is it doing this in Linux, all by itself? Has you looked behind the computer, to see if this barcode reader happens to be plugged straight into the PS/2 port along with the keyboard using a Y-splitter cable of some kind? If that's the case, the barcode reader is just sending exactly the same input as a PS/2 keyboard typing out the barcode (a good number of inexpensive barcode readers do this). Meaning you read the input just like you read input from the keyboard - much as you describe other applications being able to easily do without any special drivers or software.
  10. World Building

    Quote:Original post by capn_midnight Quote:Original post by Talroth You want a WHOLE world? That is a huge amount of Data, and I think an Earth sized planet would require something like 250megabytes if it was gridded out at 4km by 4km on an 8bit height map. There are lots of ways to compress that and cull huge amounts of data (like don't store complex data for the seas). But still, how do you plan to FILL that world for your game? uh, maybe 250MB per 16 square kilometer quadrant. DEM data is huge. But it is available... for a hefty fee. It wouldn't be so big if he used MP3-Beating Compression. DEM File Example DEM File: 250,318,671 Savings: 1,408,940 CAR File: 9,731 Percent: 0.5%
  11. You can easily make a pack file or even compile in resources in a C# or Delphi application. "Scripting languages" is pretty broad, though most scripting languages you could make a game should be flexible enough to do one or both methods.
  12. Delphi Questions

    Well, something that was good doesn't suddenly become "not good" just because something unconnected now exists. However based on a variety of factors, it may not be the best for what you want to do. Some reasons: A) You don't seem to have learned a specific language in depth yet, as a result you don't really have a base of knowledge that will be wasted. B) You want to develop games. C# has up to date support, while Delphi is a business targeted language that has always limped along on 3rd party headers, always struggling with new versions and compatiblity. Frankly I was messing about with DelphiX when Delphi 5 3 (thinking back, I remember that I didn't have class completion at the time, and with my history of Delphi ownership that would put it at Delphi 3) was new. As far as I can tell, DelphiX has barely progressed since then apart from dropping some of the bigger bugs. C) You seem to have a budget of $0. While I think Delphi is a good language, all the free versions of Delphi have major restrictions or missing features, while C# has a fairly well built free Express Edition. While a direct Visual Studio Pro vs Delphi 7/2006 Pro might be more balanced in regards to different advantages and disadvantages, a C# Express vs Turbo Delphi/Delphi 7 Personal is an easy win for C#. Overall of course it's your choice. I can tell you as a Delphi developer that there is a bit of a learning hump to get over in C#, as it isn't quite the inviting drag and drop your first application like Visual Basic and Delphi are. Once you've gotten your teeth into it both are about the same difficulty (though to be honest the clear and concise Delphi 7 help system has yet to be beaten by any IDE, not by MSDN, and certainly not by the horriblely weighed down documentation in more recent versions of Delphi). You should ultimately develop in the language that you are most productive in.
  13. Delphi Questions

    Quote:Original post by dynaemyu I am quite new to programming and thought that Delphi would be an excellent choice.. but I am having a couple problems and want to know some things before i go off downloading Delphi lol. Ok there are 2 free compilers known of right now (i really dont wanna spend money for a compiler lol).. Turbo Delphi and Delphi 7 Personal... My questions are A) Can turbo delphi use DelphiX and graphics/sound/etc libraries for game development? I heard that turbo delphi couldnt use custom components this is why im asking. B) Delphi 7 Personal is free for non-commercial use... and I was hoping to make a game someday and bring it out and sell it to people.. this wouldn't be allowed? OR am I wrong? C) Can I sell products on Turbo Delphi? D) What's the difference between Turbo Delphi and Delphi 7? (Alot of people told me 7 was better, but im havin that problem with non-commercial use, See question B) E) C# is made by the person who made Delphi I think, is this a better programming language than Delphi? And for game development (PC Only, i dont want to make xbox games in the future) Thanks alot! I hope i can understand things more clearly and know which to obtain. I have been a long time user of Delphi (since version 1 actually) and currently use Delphi 7 Pro, Delphi 2006 Pro and Visual Studio Team Suite (C#) professionally for day to day tasks. To try and answer your questions: Quote:A) Can turbo delphi use DelphiX and graphics/sound/etc libraries for game development? I heard that turbo delphi couldnt use custom components this is why im asking. Short answer no, long answer yes. The free version of Turbo Delphi (Explorer edition) has a restriction that prevents you from adding components to the IDEs drag and drop interface. However if you can work without a visual designer, you can manually use and create them at run time (I actually use this method for some custom controls used in projects, so that they can easily be compiled on a fresh or unknown Delphi install without needing to install all the component dependencies into the IDE) Quote:B) Delphi 7 Personal is free for non-commercial use... and I was hoping to make a game someday and bring it out and sell it to people.. this wouldn't be allowed? OR am I wrong? Correct, Delphi 7 Personal is basicly a learning edition, and so you can't use it for commercial purposes (even giving away something could be covered as commercial if you can financially benefit from it). Quote:C) Can I sell products on Turbo Delphi? Yes. Even with Explorer edition. Given this is a short answer, I should point out that a restriction of Turbo Delphi is that you can only have one of the Turbo products installed on each machine: Installing Turbo Delphi prevents you from installing Turbo C#, Turbo Delphi.NET and Turbo C++ (the new one). Quote:D) What's the difference between Turbo Delphi and Delphi 7? (Alot of people told me 7 was better, but im havin that problem with non-commercial use, See question B) It's hard to say. For a long time Delphi 7 has been the "last good" version of Delphi, as it was the last version that stayed true to Delphi's roots as a clean Win32 compiler that didn't create DLL dependency hell on end user machines (though it is going back to that with Delphi 2007, and Delphi 2005/2006 where bareable using the Win32 mode though stability wise they are flaky), rather then being a poor mans Visual Studio .NET clone. Unfortunately I haven't used the Pro version of Turbo Delphi so I can't give a good comparison. The ideal version would be Delphi 7 Pro, as you are getting restricted with Turbo or 7 Personal. Quote:E) C# is made by the person who made Delphi I think, is this a better programming language than Delphi? And for game development (PC Only, i dont want to make xbox games in the future) Yes, Anders Hejlsberg made both Delphi and C#. He is a very notable figure in the world of language design, and is responsible for languages like Turbo Pascal, Delphi, J++ (The Microsoft Java language extension) and C#. He originally worked at Borland (after they bought his Turbo Pascal) but was headhunted by Microsoft to work for them (several other big people at Borland have also gone over to Microsoft, leading to the .NET success at Microsoft and the Delphi decline at Borland). If you where already an experienced Pascal/Delphi programmer, it would be hard to decide which is better, however if you are new to programming I'd suggest C#. Hejlsberg was able to take many of the lessions from Delphi when designing it (It's basically a combination of Delphi type safety and library design, Smalltalk's object design, C++ syntax, and the lessons learned from Java's failings) and generally provides a much more up to date language. Additionally C# gets something that was always a problem for Delphi, support. With Delphi, you always had to rely on header translations and other fan-made libraries like DelphiX instead of being able to just download a standard SDK. While the new CodeGear brand may be able to revive Delphi, for the moment C# would be the choice, especially for games where you want to actually have decent gaming API support (Delphi has always been a business language first).
  14. Image Viewer (From Scratch)

    It's already been said, but it bears repeating. JPEG and PNG, while defined well enough (wotsit, hosted by GameDev.net, is a premiere online source for file format information), are not easy to impliment. They practically require a math degree and you'll write tens of thousands of lines to decode them. Worse is GIF. It doesn't involve heavy math, but it's filled with extensions and interpretations (animated GIFs are even worse). Unless you have years and a wide audience to test with, you can be sure your GIF decoder will fail to load some files. Overall MP3 is probably the easiest to implement. It does require a decent knowledge of math, but it's fairly well documented, and the more difficult files to decode (variable bitrate) are easy to seperate and mark as "unsupported". With the power of todays PCs, it also won't be as much of a problem if your first version is not well optimized (by comparison, a non-optimized JPEG decoder could result in full screen images having a noticable delay in loading)
  15. Tactical FPS

    You'll want to play some games in the Rainbow Six series (perhaps some of the ealier ones). Also, while camouflage is a neat idea, you always end up with two major problems with 3D games: 1) It's very hard/impossible to make an AI that "sees" on a games CPU budget, and so the AI ends up feeling very unhuman (it will seem to randomly switch between blind as a bat and hi-res thermal imaging) 2) Current 3D graphics do not do that great a job of accurately reflecting layers: typically a model is a bunch of flat 1 pixel thick surfaces covered in equally flat textures. While this does a good job most of the time, camouflage relies a lot on shadow and depth; environments simplified for 3D graphics, like grass billboards, don't work well for camouflage. More pressing is graphical settings: Camouflage does nothing if another player is running at the minimum settings where everything looks flat and plastic like (the exact opposite of that shadow and depth), making you stand out like a sore thumb. On the other hand I have seen camouflage work in 2D games since the angle you view depth is fixed. One example is Soldat, where while it is not a key gameplay mechanic, it is possible to "hide" around maps, often requiring the player to hold their gun at a specific angle to prevent it from poking out. As it comes in a free version, you might download Soldat and try it out in realistic mode playing capture the flag or base defense, both of which might give you inspiration for your game.