Advertisement Jump to content
  • Advertisement


Senior Moderator
  • Content Count

  • Joined

  • Last visited

Community Reputation

7836 Excellent

About Washu

  • Rank
    Curiously Tentacled Community Manager and .Net Forum Moderator

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That vector is allocated on the stack. As soon as your function returns it will no longer exist. In addition, your assignment of p will not do what you expect.
  2. Why do you have multiple render loops? You should have a single render loop and all of your tabs are just viewports which that renderloop handles. You could then have some basic logic in your tabs to simply enable/disable those instances from rendering when they're not visible.
  3. C++ is generic. If you're writing code using the window's APIs then that code will need to be modified to use platform agnostic APIs or separated out and rewritten per platform you desire to support. Regarding resources: OS-X applications have a bundling method, and basically it just uses directories. that are hidden under an application folder. Installation is usually just copying said folder (whose name is usually the name of your application) into the applications folder. For many games, resources are packaged up into binary bundles which are frequently compressed simply to shrink download sizes and or to "pretend-encrypt" the files. For general development purposes I wouldn't bother until you're actually deciding to ship, but you should definitely be able to use said code paths during development simply for testing. It is also useful as a means of providing demos during development, as you can bundle all of the assets necessary for the demo.
  4. Your C# server is rather broken. Your loop keeps attempting to accept connections every time it iterates, meanwhile it also attempts to read from the same socket, which as soon as the initial read is complete will result in some data being printed and the server back at the "accept" line. You need to keep track of your clients that have connected and respond to them sending you data, not throw them away.
  5. You do realize that mov [ebx], eax will move the value IN eax to the block of memory ebx points to, right? Meanwhile, memcpy will copy the memory pointed at by f into the memory pointed at by p. Lastly, your integer solution has the same problem as the memcpy one. I'm not going to give you the solution, because figuring this out is an important step in understanding pointers.
  6. Unless your DLLs contain nothing but pure logic code, that's not really going to help much, honestly. Unloading then reloading everything isn't really going to improve your iteration times. Plus for any decent amount of code, you'll eventually find that linking will simply be more expensive (and your DLLs are going to have dependencies, you'll end up with dependencies all over). If you really want to break things up for this purpose, it would be better to break it down into different modules that you can reload at runtime. You still have problems though, such as tracking all the different objects from a DLL that have been allocated, and then releasing those. Persisting their state in some manner, perhaps by breaking apart data and code or using some sort of fixup mechanism. Even with a fixup mechanism you have to deal with data versioning, as the changes applied to a DLL might very well be to add a new field. Breaking up each individual bit of gameplay into a bunch of different DLLs will be hell to maintain, you'll end up with versions all over the place, you'll have to manage tracking of the different pieces and ensure that you don't end up with compatibility conflicts when dependencies change. Honestly, for something like gameplay logic... putting it all into one DLL would be fine. Alternatively, scripting solutions work just fine, and there's really no reason to not use them.
  7. There's nothing wrong with using DLLs and writing it in C++. In fact, this is the method that is used in HL and HL2 for modding purposes. Some things to be aware of: Hot reloading gets harder, you still have to deal with all those DLLs, you have to have a mechanism to detect when a new DLL is ready to be loaded, and then do the "swapping." You also have to figure out what you're going to do with all of the existing loaded objects from the DLL you desire to replace. All of these are solvable problems, they just require some level of effort to implement.
  8. Washu

    SDL Mouse Movement High CPU Usage

    I see more sleeps in there, that probably shouldn't be there. If you have an issue where you're not properly handling mouse up and down, introducing a sleep is not the way to fix it. Additionally, looking at the SDL documentation, SDL_WaitEvent should be called on the thread that initialized the graphics subsystem and not some other thread. Regarding mouse move events... the chances of you being able to move your mouse fast enough that any decent plain old event handling loop cannot handle them is highly unlikely.
  9. Washu

    SDL Mouse Movement High CPU Usage

    SDL_Delay is a sleep. Additionally, without seeing the rest of your loop, it's hard to see what else you're doing that could be wrong. For instance, you should process all outstanding events before moving on to your game update. Alternatively, spin up another thread to handle input.
  10. Well, alright.
  11. This is not the tentacle monster you are looking for...
  12. Washu

    Frustum Culling

    I would also like to add a good reference:
  13. Washu

    What are you working on?

    Day Job: Guild Wars 2 Side Projects: Many, mostly private.
  14. @[member=Nypyren] hacker.
  15. Washu

    the dreaded "escort" quest

      in this particular case, its a stone age setting so the society is not that organized. picture about 35,000 bands, average of 6-12 cavemen each, spread over a 2500 x 2500 mile area (about the size of the nothern hemisphere of the new world).    but the game does track actions against friendlies. actions against friendlies will cause all nearby friendlies to become hostile - but you can still attempt to yield.  and all cavemen you encounter are persistent in the world even when not nearby and an active target in the simulation. so if you kill a friendly and they turn hostile, assuming you get away somehow, the next time you encounter them, they'll remember.      You might be amazed at what stone age societies were capable of. Just because reading/writing wasn't a thing doesn't mean such information as crime cannot be reported (word of mouth, etc.)   We have plenty of evidence of prehistoric man trading between tribes, etc. So communications definitely existed, even if you didn't have wanted posters.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!