• Advertisement


Senior Moderator
  • Content count

  • Joined

  • Last visited

Community Reputation

7833 Excellent

About Washu

  • Rank
    Curiously Tentacled Community Manager and .Net Forum Moderator

Personal Information

  • Interests
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 2D 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.
  6. 2D 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.
  7. Well, alright.
  8. This is not the tentacle monster you are looking for...
  9. Frustum Culling

    I would also like to add a good reference: http://www.frostbite.com/wp-content/uploads/2013/05/CullingTheBattlefield.pdf
  10. What are you working on?

    Day Job: [url=https://www.guildwars2.com/en/]Guild Wars 2[/url] Side Projects: Many, mostly private.
  11. @[member=Nypyren] hacker.
  12. 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.
  13. the dreaded "escort" quest

      all very good plot twists. i'm finding that the possible plot twists are almost endless. i don't think any of the 30-40-50? quest generators planner so far is based around a plot twist. they're all more of less straightforward quests so far. once the various possible types of straightforward quests are well covered, i may go back and make "twisted sister" versions of them. that way you never know if it a straight or twisted quest.  ; )   last night i finished up a first cut at both the sacred animals and the escort quest. both are straightforward, but they work.  using regular badguys did the trick for the sacred animals quest, although the herd is still just a random animal encounter that might kill both hunters and player alike. making the NPC a follower made the escort quest pretty trivial to code up.   One simple way to deal with applying consequences to escort quests is to simply have a registry / adventure's guild where you pick up the quest. If you're registered as the escort for someone, and that someone fails to arrive, well.. you fail the quest. Be careful of things like on death hooks, because often they don't make sense. For instance there have been times when playing Elder Scrolls games where I've killed someone and was witnessed by someone else, who I then killed, but yet you still get reported.   If you're going to have reporting mechanics, then you should spend the effort to make them work well with the rest of the gameplay. If I exterminate all of the witnesses before they can get to a guard, I should not have a bounty taken out on me, unless somehow my name is registered with regards to the people in question (i.e. I was hired for an escort)
  14. the dreaded "escort" quest

    If an escort quest doesn't have a start point and an end point, then why is there a quest?   If you have a living world, then there's no reason why you could not simply encounter an NPC who is going from A to B at some point between A and B and get "hired" to escort them.
  15. the dreaded "escort" quest

      hmm....   un-fail-able quests aren't much of a challenge...   To be clear, many escort quests in Gw2 can be failed. For instance, if the NPC is not ressed within some timespan then the quest can fail.     Yes, and if you're escotring a trade caravan that has to remain on the roads, what then? Making the NPCs simply follow the player has always been one of those things that irritated me about some escort quests. Sometimes you just need to bite the bullet and realize that some escorts must run on a rail. Others can be a bit more freeform, but there still needs to be some sort of a gating concern to prevent the player from simply escorting the NPC to Timbuktu and back again, I.e. if I'm going from Divinity's Reach to Lion's arch, going via the Black Citadel is taking the long way round, and might not be the method most appreciated by the NPC. On the other hand, emergent gameplay can result when you allow arbitrary escort paths, such as assassin's on the way never being encountered, which can trigger other quest dialog (or future quest entries... such as lowing their guard because they weren't ambushed and thus thinking they're safer on the pot.)
  • Advertisement