Jump to content
  • Advertisement

Rendaw

Member
  • Content Count

    27
  • Joined

  • Last visited

Community Reputation

150 Neutral

About Rendaw

  • Rank
    Member

Personal Information

  • Interests
    Art
    Audio
    Business
    Programming
  1. Hello, I'm organizing a small game development contest. Is it alright to post about that here? Would that go in the challenges subforum or as a news story in Your Announcements, or is there somewhere else more suited? I didn't see contests specifically listed so I wanted to confirm. I'd like to discuss it here too, I'm not sure if Your Announcements is suitable for that since AFAICT posts are sorted chronologically.
  2. Yeah, I'm using linux. I was thinking about just going with 4-byte wide characters, just because it sounds so much simpler. SDL_ttf is defined to use Uint16's as opposed to some system-specific type; possibly for the portability aspect of SDL? I don't know, but here's a confirmation of that. Just in case anyone is wondering, here's some further information on the gcc mailing list: Compiler options: http://gcc.gnu.org/ml/libstdc++/2005-03/msg00349.html Custom char_traits and stuff for an unsigned-short-based wide character type: http://gcc.gnu.org/ml/libstdc++/2002-08/msg00236.html
  3. Alright, will do. Thanks for the help! If it comes down to being some system error, that's the least I can do I guess. Rendaw
  4. Gah, mistype. I'll fix it in the original post in a second. It should have been wcslen(a.c_str()) as opposed to wcstr(a.c_str() as I had it. Yours does? I recompiled my code several times from the ground up and got the same results. Could your distribution have built the standard libraries with 2-byte wchar_t? My computer could very well be messed up, but according to what I've read and has been said here it shouldn't be working anyway.
  5. Quote:Original post by Bregmabut there's really nothing to stop you from creating a basic_string<uint16_t> (or whatever integral type you can guarantee is 2 bytes). I had seen a couple of people mention this while I was searching, but others seemed to think it was not an ideal solution. Aside from being unable to use the std library non-member string functions, is there any problem with doing that typedef and, say, using "-fshort-wchar" to make L"text" two bytes long? Part of the opposition was the fact that literals were then of no use. Quote:Original post by BregmaYou will have a bit of trouble with localization if you don't also provide specialized locale facets and yo umay have to provide your own std::char_traits specialization, but that's how the standard library is designed.Currently I'm looking for a bare minimum of name entry/display, and possible different translations of stuff in a string table, but if I plan to expand from my current situation I'll definitely keep this in mind. That is, if I am correctly understanding what a facet is (my knowlege comes from this: the cantrip website). I'm not sure exactly why I would need a separate char_traits definition. Would you mind expanding on this? If it comes from the stream interface, I haven't delved too deeply into that. Thanks for the help, I doubt I would be nearly as far without these pointers Rendaw
  6. Ah, thank you. That's not exactly the answer I was hoping for, but I'll cope with that. Just gotta find some alternate method of doing everything now :). Thanks again, Rendaw
  7. Yes, thank you. That wasn't exactly the problem, however. The problem was that the methods of std::wstring and the other wide character functions were still treating wchar_t as a four byte character instead of a two byte character. At least, that is the only explanation I can think of for this. Will wcslen, wcscat, and other wide character functions and methods compiled into system libraries be incompatible with my application if I use -fshort_wchar? That would seem to make the purpose of this flag suggested in the man page almost completely useless, so I would assume gcc/g++ has some way of dealing with it. Thanks again, Rendaw
  8. G++ seems to be choking rather heavily on some of my wide character code. The following: std::wstring a(L"abcdefgh"); printf("%u %u %u\n", a.length(), wcslen(a.c_str()), sizeof(wchar_t)); when compiled with -fshort-wchar displays "54 54 2", when AFAIK it should be "8 8 2". When I add (the supposedly non-neccessary) \0 to the end of the string, it prints "4 4 2". Lastly, when I briefly remove the "-fshort-wchar" from the compilation command line and do not include the \0 in the literal, it prints the correct "8 8 4". What this leads me to believe is that, even with -fshort-wchar, many functions are assuming that the wchar_t length is 4. That would explain why the "4 4 2" is displayed (wchar_t size is assumed to be double, so computed string length is halved), and why the 53 is displayed, assuming that null characters could be missed with the wrong character size. I need to have short wchar's to interface with Unicode in the SDL_ttf library. Is there some obvious problem with what I'm doing, or some place I could look for a solution? I've googled for hours and haven't found anything. Note: I have UNICODE defined. Thanks for any help you can offer! Rendaw [Edited by - Rendaw on July 14, 2006 9:52:41 PM]
  9. Heh, no problem. In OpenGL, at least, enabling alpha testing only draws pixels to the screen that are over a certain opacity. The main problem with API controlled depth sorting in OpenGL and DirectX is that with alpha blended sprites (with various levels of opacity) must be drawn sorted from back to front or else the objects in back will disappear behind the alpha blended sprites in front, even though they're semi-transparent. This is because when the alpha-blended front sprites are drawn, they update the depth buffer and cause the API to cull the sprites behind them. If all you're using depth sorting for is to make alpha masks or something like that work properly, then you can use the alpha test to prevent modification of the z buffer in transparent areas so that the partially hidden sprites still appear. This is a terrible explanation, but if thats what you're doing this for, I reccomend further reasearch in this area. Alpha Testing My best reccomendation is to group objects by location, like room or floor, and then cull/sort out these groups. From there, you can sort the individual objects in the current area in relation to the moveable characters and stuff. Also, for depth sorting, you may wish to consider changing your method a bit. Instead of assigning integer incremental values as you are (1, 2, 3, etc.), make a consistant floating point z scale, and assign values with that. Create some formula to calculate the distance from the screen, and assign every object a z value. If you have a bookshelf, the player, and another bookshelf, they might have the z values of 6, 5.5, and 5, which would take care of the ordering issue. Then just sort by z value and draw. I would let the API handle this, but if you really want to, look into ordered lists, sorting functions, or the STL map.
  10. Assuming that lesser x positions are closer to the screen, then yes, your current method should work. To solve your other problem, I would say that you should include the "bobs" in your sorting of everything else. I may be misunderstanding your problem, however. Why are the "bobs" a problem for you? Have you already tried the method you used on the other objects? Why do you need to manually sort through depths? If you're not planning on using alpha-blending and you're using OpenGL (or DirectX I assume), you can let the API handle the sorting for you and enable an alpha test.
  11. Rendaw

    Player Movement

    Quote:Original post by jyk - Speed is clamped to some maximum value (values may be different for side-to-side, etc.)I guess this is the part that I was most wondering about. Now that I think about it, however, in my experience in Unreal Tournament, the player cannot exceed the maximum running velocity while in contact with the ground. That would simplify the determination of the maximum velocity. I had been thinking that the character could exceed that speed when shot. I think that games like Tribes and Tribes 2 may do it quite a bit differently, however, as I remember falling from quite high in the sky frequently and attaining huge ground velocities upon impact. This would necessitate a different collision scheme, with some sweeping or something, and movement method. What you wrote sounds accurate though for the majority of the FPS's I've played. Thanks for the help. I may try some other things before I resort to some of those kludges, but I'm glad to know them. Rendaw
  12. Rendaw

    Player Movement

    Heh, thanks for the yet again phenomenally quick reply. I don't have much experience with third party physics libraries, but would you mind expanding slightly on the more straightforward control scheme? Would such a scheme involve directly modifying the player's velocity and then instituting a damping effect when the player collides with the ground? With gravity and some ground friction I could see such a solution being acceptable on slight inclines, although it would still not make use of static friction. Thank you, Rendaw Edit: Gah - now I remember my other predicted issue. If I were to directly modify velocities, then I would have to either have a simple nonzero constant velocity or a velocity limit, which could be exceeded by projectiles or various forms of movement. From what I've experienced, some games solve this by making the player only able to accelerate his or herself if his or her velocity is under a certain threshold, but do not reduce the velocity if it exceeded the threshold. This is a solution, but the way it circumvents the problem makes me think it could potentially lead to exploit. [Edited by - Rendaw on June 17, 2006 8:42:22 PM]
  13. Rendaw

    Player Movement

    Objects that are physically simulated in my program have static and dynamic friction. However, since I am planning on using a single collision element, like a capsule or sphere, to represent them, they are always colliding with the ground (unlike a real person which intermittently lifts his or her feet off the ground to move them forward). So, to move the object I could apply a force; however, this would break the static friction, thereby causing erroneous movement when walking along inclines and such.. Like in real life, I could have individual colliding elements in each of the player's feet, for instance, but then player rotation and odd animation could cause interpenetration and such, and would make the collision detection code much worse. So far, I haven't thought of a solution to this problem, and I assume that it has been encountered at least in some other situations, so I was wondering how one would go about doing it. I've also searched the forums here for a while, and I checked the Quake 3 and 2 source code but couldn't make heads or tails of what was happening. If anyone has any solutions to this, I would greatly appreciate them. Thanks for your help! Rendaw
  14. Rendaw

    Space combat prototype - phase 8

    Unfortunately, FMOD isn't free for commercial products. For that, one must obtain a liscense, which, at the cheapest for this sort of project, would probably be around 3000 USD. That'll be handy to keep in mind, though - that OpenAL thing. I've had some problems, due most likely entirely to my ineptitude, but at least I won't be as stumped if I ever encounter that. Rendaw
  15. FOV only applies to perspective views, not orthographic ones. FOV essentially determines the rate at which the clipping planes expand from the center as the distance from the camera increases. In isometric views, and all orthographic views in general, the same amount is clipped, no matter what the distance is. The matricies created by operations like glOrtho and glFrustum are fundamentally different for this reason, and I don't believe that there are any sets of valid values that can make their results equivalent. If you have the capability, the rotations I gave should result in a correct isometric view. However, the result is higly dependant on aliasing artifacts. A small (ex. one pixel) stretch might fix some of the aliasing whithout sacrificing much quality. There are other solutions as well, such as rendering larger and masking (depending on the tile), and creating a custom renderer that positions the object correctly. Rendaw
  • 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!