• Content count

  • Joined

  • Last visited

Community Reputation

564 Good

About Solias

  • Rank
  1. I haven't done dual contouring before, but this seems similar to how my voxel engine works. At each voxel I store 3 values representing the x, y, and z potential displacement of the surface from that sample point. The special case of 0, 0, 0 represents an empty voxel. When building the mesh, I use a variant of marching cubes and consider each cubic cell with 8 voxels at the corners. Any cell which has a mix of 0 and non-0 voxels will contain a surface. Any cell edge connecting a 0 and non-0 voxel will contain a vertex of the mesh, and the position of the vertex along the edge is equal to the x, y, or z displacement from the non-zero voxel. This makes it very easy to calculate the vertex locations and gives me a lot of control over the surface, but still gives a lot of surface variability. To dig a a "hole", I set a voxel to 0,0,0, and set its neighbors associated x, y, or z displacement to a random value within a controlled range. If you want straight edges, you can also get that effect by choosing consistent displacements for the neighbors.
  2. Why are you doing the -x, -y translation? I assume the verts in the VBO are in object space already?
  3. Motion capture for indie game developers?

    This might be an option: CMU motion capture library.
  4. Skinable Flash MMO's?

    Metaplace went into open beta recently.
  5. Well it's a fairly standard rpg setup to have the player randomly go around helping people. Of course they mostly help out by killing monsters, looting their lairs, and delivering packages. I don't think issue 1 is really that big a problem, if you can solve the other issues. As an aside, consider the main concept of ultima 4. The goal of the player was to adhere to an ethical system defined by the game. There really wasn't a lot of plot or a real villain in that game. The bigger issue in my mind is creating an interesting challenge to replace combat (issue 2). Combat, if done well, provides interesting tactical choices. For an RPG there is also the strategic element of developing a character or party that can do well in combat. For action games, you can also have hand eye coordination and timing elements to combat, although those are probably the easiest parts to bring over to another system. How do you make "save the old lady" or "throw back the ball" into interesting gameplay? You could have a bunch of simple minigames, maybe mario party kind of stuff. That doesn't really seem to have a lot of depth to it though. Is there a way to map the tactical decisions of a combat system onto a different presentation? It seems like combat is fundamentally dependent on having an "opponent", which is lacking here. Puzzles are another option, but I don't really feel the connection between playing bejeweled and "save the old lady". It worked for me in Puzzlequest though. A really easy option would be to make an adventure game. The puzzles in those games are mostly combat free anyway, and could map well to this theme. Maybe with a deep conversation system. Choose the right conversation options to talk people into doing something rather than fighting them.
  6. Post some (relevant) code, otherwise it's hard to guess at the problem. In general you want to set some game state to restart the level and then return from the menu event handler. You don't want to call the display code itself from the handler. It's been a while since I used glut, but post redisplay sounds like the right way to queue up a redraw event. How is it not working? Do you return from the menu handler, but then the draw is never processed? Are other events going through? Another option is to just redraw the window at a fixed interval. Glut has a timer callback for doing this. I think they call it an "idle" event if I remember right, check your glut docs. If you are always redrawing the display anyway, then you can just reset the state and wait till the next cycle for it to get picked up. If all else fails, glut is open source, fire it up in your favorite debugger and see what is going on. Good luck.
  7. Hidden variables

    In many MMO games, important game mechanics are not fully documented. This means that optimizing gameplay requires experimentation to determine how the underlying mechanics work. There are a few responses to this: Some players (seems like a small part of the overall population) put a lot of work into determining the formulas. They run experiments with different gameplay choices in different situations and even write scripts to gather and analyze the results. This is an interesting challenge, and this group enjoys this aspect of the game. As a side note, this is really meta game activity, and can include out of game stuff like reverse engineering data files or discussing results on message boards. Another (larger) group of players is interested in the results of the first group, but not in the process of obtaining those results. They will generally go outside the game to guides and web sites to find the hidden mechanics. This group would probably be just as happy if the hidden information was available in game, with the exception that they may enjoy an advantage over other players that do not have the hidden information. That advantage is mostly only a factor for a multi-player game, so for single player games this group would probably prefer in game information. The final group is less interested in the details of the game mechanics in general. They make their own guesses and assumptions about the game rules, which are often wrong or at least suboptimal. As long as these incorrect decisions don't cause them to become frustrated, they probably don't care if the rules are hidden. A subset of this group will even say this adds to their "immersion". This last group will be happy with hidden information as long as it does not have a large impact on the game (so they don't fail because of their mistakes), and as long as the underlying system is fairly simple (so they are less likely to be wrong). Even with a game system that is not hidden, this group would probably like the systems to be simple. They aren't as interested in the game mechanics anyway and focus more on other aspects of the game. So there is one example of this type of game play. I think in the end, it's going to depend on the target market of the game. It's probably very important not to hide information in a game that is targeting group 2 if they don't have access to the research done by group 1.
  8. Walkable Tiles

    If you don't ever need the flexibility of assigning walkability separately from the tile appearance, then #2 is probably easiest to implement. If you do need that flexibility though, I'm not clear why #3 would be better than #4. You are going to need to store that override information in a way which can be easily queried, which means some kind of spatial structure (probably either a straight 2d map or a quad tree). In that case, storing the information for both the override and the default seems more complex. For dynamic collision, you may want to store that information separately from the static walkability data.
  9. a better GUI

    I haven't used QT, so I can't comment on that one. I have been using wxwidgets to make simple GUIs for hobby projects recently. So far I'm pretty impressed with it. It's got plenty of pre-made components to use, and it's pretty quick to wire everything up for a simple UI.
  10. Threads and cores

    Quote:Original post by shurcool On the other hand, it's very easy to write a real-time ray-tracer that will use all N avaliable cores and use them at 100% utilization. :p Just create as many ray-tracing threads as there are cores, and feed each one a different region of pixels that still need to be calculated. 100% paralleism for the win. P.S. I know I'm oversimplifying things a lot, but the idea sure is elegant. Of course you can get pretty close to that with a software rasterizer too. Graphics has a lot of inherent parallelism. It seems like it's relatively easy to find parallelism within many common game tasks: collision detection, pathfinding, graphics, etc. It's harder to try and run different tasks at the same time.
  11. I didn't read the linked post, so this may not apply. Within a single draw call you can use both targets, but not on the same texture unit at the same time. So, for example, unit 0 could be a 2d texture while unit 1 is a rectangle texture. You could not use both targets on unit 0 at the same time however. Between draw calls you can change the target used by a texture unit. So you could draw one batch of triangles using a rect texture on unit 0 and then draw another batch of triangles using a 2d texture on unit 0. You will have to make a separate draw call for each batch.
  12. At least in Windows, you have to create a window in order to get a OGL context. I don't think the window needs to be visible in order to use an FBO, but I haven't tried that before. The error you are getting seems odd however. OGL calls made without an active context should fail silently.
  13. glTexImage2D question

    You might try using getTexImage to read back the texture. Then at least you could be sure the problem was in the texture upload.
  14. If you are going to use shaders, GLSL supports 3x3 matrices. Just create a mat3 uniform and load you matrix in there.
  15. OpenGL Importing 3D models of human body

    Human readable (text) formats take more space than more compact formats. For small models that fact that you can open and modify them in a text editor makes them easier to work with. For large models this advantage goes away, because they are too complex to understand in text. If space is a concern, then use a more compact format. Or support both, and then convert your OBJs (or whatever) when you release. One common approach is to use a human readable format in the art pipeline and then dump to a binary representation that is very close to what is used directly by your graphics engine. This format may change during development, but the art assets are preserved in the stable format.