Jump to content
  • Advertisement

stubble

Member
  • Content Count

    99
  • Joined

  • Last visited

Community Reputation

158 Neutral

About stubble

  • Rank
    Member
  1. stubble

    Problem with recursion with c++

    If your program is crashing because it's recursing too deeply then it will normaly fail because of the stack overflowing. The exception thrown will be 0xC00000FD (Stack Overflow). If you debug the app it should show the exception being thrown - unless you've got a catch {..} in your code (if you have you can tell the debugger to show the exception anyway). Here's an obvious program to create a stack overflow exception: void afunc(long x, long y, long z) { afunc(x,y,z); } int main(int argc, char* argv[]) { afunc(1,2,3); return 0; }
  2. stubble

    Java to C++ - Automatic Migration

    If there isn't a program which will convert it all for you (I don't think it's as straightforward as it initially seems) you could sniff the java code in using a modelling tool like Enterprise architect and then generate it as C++. Obviously this isn't going to do anything with the actual logic but it will give you some classes with member and method declarations.
  3. stubble

    char * to LPCTSTR win32 without stdafx.h

    My reply was really to jeroenb's post - as it seems to confuse LPCTSTR with LPCSTR - which are not the same thing. Also I should apologise as I didn't really answer your question. In answer to your question - you should be able to pass a char* to TextOut, if you are not building a Unicode application, without any conversion. However it will not build if the preprocessor directive _UNICODE is defined (so if you ever decided to switch to a Unicode application your code will not compile).
  4. stubble

    char * to LPCTSTR win32 without stdafx.h

    It's been a while since I've done anything with Unicode on Win32 - but I don't think it's quite a simple as all that. A LPCTSTR is a pointer to a constant string of TCHARS (the important bit here is the T in LPCTSTR - it's not the same as LPCSTR). A _TCHAR* can be a char* - or it can be wchar_t*. This is defined at build time by the value of _UNICODE define. So - if you build with _UNICODE defined (ie. a Unicode build) they will be wide chars so you shouldn't cast the pointers to char*. Odds on you're not building a Unicode application (?) so they will be char*. However I would say it is generally bad practice to treat LPCTSTR as pointers to chars though - even if you aren't building as Unicode..(if you do a unicode version in the future your code wont work) [Edited by - stubble on April 18, 2005 7:51:51 AM]
  5. stubble

    poker- how to compare hands

    Hey AP - I found some code which took this/similar approach and had been hoping to step through it when I had the time/strength - your post should help a lot - thanks!
  6. stubble

    poker- how to compare hands

    Funnily enough I've been thinking about how you'd evaluate a poker hand recently too. There are two separate things here (just to make sure we're all on the same page): (Let's assume we're talking about Texas Holdem) 1) Evaluate a hand based on the cards in play - find out what it (currently) is - eg. Flush, High Card etc and rank it based on this (eg 100%=Royal Flush) 2) Evaluate a hand based on the possibility of improvement. For example you currently have 2 clubs in your hand and 2 clubs from the flop - what is the probability of improvment to a Flush etc Number 2 can also be used to find out what 'the nuts' is - if you just gave it the community cards. I haven't thought too much about number 2 yet - but I have some ideas on number 1. Which are you interested in?
  7. stubble

    hey

    I think you mean: #define WIN32_LEAN_AND_MEAN ; ) As far as I'm aware this just stops certain windows includes which aren't always necessary and reduces the size of others - improving build time only. I'm not convinced it would make any discernable difference to execution speeds.
  8. we did..[smile] well we mentioned flash several times - but I for one don't know much about it so was waiting for someone like yourself to post some info.
  9. You also have to consider the motivations for mapleh writing this game. As I said if mapleh wants this to be a commercial venture then ActiveX is not the best option and the technologies need to be dictated by what best fits the customer and technical requirements. If on the other hand, mapleh wants to learn about developing an online game which is embedded in a browser then I would argue that a key influence on the technologies chosen has to be the skillset mapleh already has. Whatever the technologies used FLASH, Java, Active X, .exe etc the overall architecture will be pretty much the same - so unless mapleh wants to use this project to learn a new language/API then why not stick with familiar ones? All comes down to why mapleh wants to write this game..
  10. The issue of moving from C#/C++ to Java is not so much the language (although there are subtle differences which can cause problems) but the development kits that come with the languages are very different; there is no shortcut to knowing the JDK for example - it takes time. As for the .exe option - this is what I would have originaly suggested - but mapleh wants it running in a browser.
  11. A very a good point by benryves - but the alternative is learning a new language and API. If this is a commercial venture then I would suggest putting the time in to learn Java/FLASH, as he suggests. If this is a project you're doing for experience and is really a learning exercise then I would suggest you stick with the technologies you know and use ActiveX - otherwise the learning curve will be very steep (given you seem quite new to web-based development anyway).
  12. Quote: Thanks for the advice. Can I plug in DirectX technology into ASP (or PHP) to design a better online game? What's the right direction to design a online game? This is my point - although you could probably do directx from ASP it would make NO sense - as it runs on the SERVER - ie the box sitting in server room running your site - not the box sitting in front of the person who wants to play the games. As evolutional points out you can use javascript on your client - but it will be very limited graphically. If you want to do the sort of graphics you've been doing in DirectX you need to pick a slightly more advanced clientside technology.
  13. Hi Mapleh You're using the right words - I just wanted to make sure I understood them! I should point out that I've never written anything like this - however I do have some amateur games experience and a lot of professional web development experience). For the Client: (Based on using the technologies you said you are familiar with and ones able to provide the sort of graphical capabilities you have suggested you want) If you want the games to run in a browser then you are limited inthe technologies you can use. If you want to use C# then you can write an ActiveX control (not sure they're still called this in .NET) and as far as I'm aware you can use DirectX from an ActiveX control - I've never done this but a quick look on google shows some projects where people have done this). This all requires the client - ie the person running your game to be running Windows and to have DirectX installed. Alternatives are FLASH - which I know very little about and a Java applet. The example site you gave runs its embedded games as Java applets. Give what you've said I would suggest looking at the ActiveX Control (or whatever it is called in .NET!) route. For the Game Server: You will also need to develop your server. Depending on how the online games work you'll probably need a server which lets the different instances of the game (running on different people's PC) communicate. I'm not that familiar with the types of online games you've mentioned - but I guess the players compete somehow and information about all the players in a game must be combined and processed centrally for the game to work. You can use anything your webserver (and hosting service) will allow you to use to develop this piece. Given your experience I would suggest .NET. For the Website: Again you'll need some server side stuff to deliver an dynamic bits of your website. I would use something like ASP.NET for this bit. Not that I've kept the Game Server and Website separate - as they are separate applications (or I would keep them so). You could deploy them on the same physical server - but I doubt this is done in the real world (as they will have different performance/scaling requirements and you wouldn't want to put all your eggs in one basket). [Edited by - stubble on January 13, 2005 5:57:09 AM]
  14. Quote:well, as ASP is a client side "semi-programming" language already, you could even do it completely in ASP (although it could be kinda though :D). But as far as I know, you can always start your exe from your site. I even had a little game installed on my old site which was created in c++. Just put it somewhere and use some plain HTML like: a href="game.exe"*something /a (can't put the bracets or the forum takes it as a link. Just thought I'd point out that 1) it is SERVER SIDE not client side (ie it runs on your web server) 2) ASP is not a programming language itself (for example you can use ASP using VBScript, JScript etc as the language and ASP.NET supports 20+ different languages - including c# which I wouldn't consider a "semi-programming language" [wink] ) 3) you couldn't write a multiplayer web-based game using just ASP (unless it was very basic - ie form based) - for the above reasons (ie you need some client side code) Mapleh: When you say you want to make a web based multiplayer came - do you mean you want it running in a browser - like IE - or do you mean you want a game that runs as a .exe (on the client) and communicates with other players running the same game using the internet? [Edited by - stubble on January 13, 2005 4:49:01 AM]
  15. stubble

    Finished game feedback

    I've just tried this on my work PC (which doesn't have Visual Studio on it) and it can't find msvcr71.dll. Gutted as given all the great feedback I wanted to have a go!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!