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. A workflow for a hobby developer is different than a professional. Professionals are focused on a single area, their area of expertise. A map artist is not going to be writing code. A programmer is not a map artist, etc. But when you're working alone, or in a small team, you generally have to take on multiple roles. "everything" is rather broad. Your computer seems fine. The rest is really down to just doing the work. Stop waiting for slow tasks that you don't need to. Building a playable game is about more than pretty lighting, although lighting is part of that. Instead of baking, try doing your work and testing it without a bake. Long running tasks are things that should happen when you're pushing more towards a release or finalizing a level and such. Some processes take a long time. Baking is one of those. If you want to bake quickly then you need to offload it to a cloud. Alternatively, learn to bake when you need to (i.e. before smoking your release), that way you can keep working without waiting for bakes. Generally speaking, any long running task should be saved until after you've completed your actual work building something and testing it out. Your setup seems fine to me. Get and use source control software. Git is free and fairly easy to use. Perforce is also free for under 5 users and works quite well with binary files (such as art). You should be regularly committing your work. Break things down into folders, the exact organization is up to you though. Generally speaking you want to organize assets into logical groupings that make sense... for instance your various NPC armies might all be grouped by army and then with more general terms such as "commander", "captain", "grunt", etc. The same is true of code, group things by modules, and maybe further by public vs private implementation bits. Or by namespace. Alright, now we get to the main thing I wanted to talk about... Workflows are not really a "thing" so much as a combination of many things. Additionally, most professional workflows are oriented about the task that the person is trying to accomplish, and is usually reinforced by their tools. An example workflow might be taking a map artist: Initially, they will have some concept art, along with a look and feel that will be worked out together with the game director, map designer, concept artist, etc. A map artist will take a set of concept art that gives a look and feel for the map and translate that into a grey box rough outline of the actual map in an editor. Then they would work with the designer who will be building the content for the map to determine the playable space and any additional requirements. Defining these bits gives the map artist an idea of where they can and cannot put detail, the kind of mood that the content of the map is looking for, etc. The grey box also allows a designer to start working out gameplay mechanics for the map. Then the map artist can go back and start adding in detail. Since they know the design space of the map they know where they can and cannot add in blocking geometry, where they might need to place invisible walls, pathing components, and such. This can also help to guide some of the theming of the map. For instance, maybe it's a night time map but the concept art was brighter. Or perhaps the map is set in a reclaimed ancient magical ruin, so you're expecting lots of tall trees, grasses, and mysterious ruins that could be walls, floors or ceilings with glowing crystals and such. Maybe some mysterious giant C shaped ruin that could be climbable, etc. As you can see, this workflow is very much focused on doing one specific thing... building a map to meet some design goals. If you're working solo then your workflow is much more oriented around combining multiple tasks together to do things. If you are the map artist and the designer then you obviously don't need to collaborate with someone else on that. But many of the same parts of that workflow are very useful. For example, while you might not need to collaborate with the designer to figure out the playable space (if you are the designer as well), the goal of that task is the same. Figure out where the player will be, and what they will be doing so that you can work out what you can put where... In general, each person will customize their workflow for themselves.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. Well, alright.
  12. This is not the tentacle monster you are looking for...
  13. Washu

    Frustum Culling

    I would also like to add a good reference: http://www.frostbite.com/wp-content/uploads/2013/05/CullingTheBattlefield.pdf
  14. Washu

    What are you working on?

    Day Job: Guild Wars 2 Side Projects: Many, mostly private.
  15. @[member=Nypyren] hacker.
  • 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!