Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

238 Neutral

About Icefox

  • Rank
  1. Okay, so I'm working on the Meshomatic project (http://www.opentk.com/project/Meshomatic), which is hopefully going to be useful to someone out there as a general .NET mesh file loader. I actually bothered to get it into a usable state last weekend, and it successfully loads and textures .obj and .ms3d files and generally has an API that I'm okay with. However, I'm not really a guru in the field of 3d art and programming, so I ask those out there, what else should this library do? Collada file support was on the list of things I wanted at the beginning, but right now Meshomatic only loads geometry, while Collada can hold scene data, lighting, shaders, skeletons and so on. Would it still be worth it to only load geometry out of these? So... main feedback I suppose I'm looking for: 1. File formats. It loads .obj and Milkshape, what else would be most useful? Collada? Lightwave? 2. Features. Are materials worth loading? Most games I've seen use textures to define specularity and such, rather than materials. What about skeletons? Problem here is that, for instance, .obj does not include skeleton or animation data. So what's the common subset of features that most people want? It's rough in general because I either have to implement a million features slightly differently, or only implement some features that are most commonly shared, or try to find some vague middle ground in a field I'm not an expert in. It might honestly be best to remove any common format from the thing, and instead just have a collection of entirely separate loaders in one package. Thoughts?
  2. Icefox

    Frame Rate Independent Article

    Well, here's what I'm doing for interpolation in my game. The game logic runs at 20 frames per second, and the display runs at whatever rate it feels like. So far it works really well, though it would work less well if the game ever lagged below 20 FPS. But even in that case, the calculation would proceed at some rate <20 FPS in a uniform way; it would act slower but consistently so (things would not lag through each other, etc), which I consider a simple and robust solution to a pretty hard problem. function doMainLoop(gamestate) while gamestate.continue do local now = Sdltimer.get_ticks() doCalc(now, gamestate) doDrawing(now, gamestate) end end -- calcInterval = 50 milliseconds, 1/20th of a second. function doCalc(now, gamestate) if (now - gamestate.lastCalc) >= calcInterval then -- Do stuff here... end end function doDrawing(now, gamestate) local dt = now - gamestate.lastCalc drawStuff(dt, gamestate) -- Do other stuff like center view, and so on end -- thing is the new thing, oldThing is the saved thing from the last calc event, -- dt is the time since the last calc event function drawSomething(thing, oldThing, dt) local location = lerp(thing.loc, oldThing.loc, dt) doABunchOfDrawing(location, thing) end function lerp(newvec, oldvec, dt) local difference = newvec - oldvec return (oldvec + ((difference * dt) / calcInterval)) end You will notice that if we have the latest Thing, Thing0, and the Thing from the last calculation tick, Thing1, then where we actually draw on the screen is somewhere between Thing0 and Thing1. This has yet to matter in a fairly fast-paced arcade-y game. If it does... well, I need to increase the calculation rate. Hope this helps.
  3. Icefox


    I am not a pro on the topic, but I know that many use a data structure called Markov Chains, which basically makes conversation based on how it sees other people making conversation. This might also lead you in an interesting direction: http://en.wikipedia.org/wiki/Jabberwacky
  4. Icefox

    color collison detection?

    This sort of thing is generally called "Pixel-perfect collision detection", and is often still done in 2D games. However, it's faster and easier to use bounding boxes or tile-based collision detection in cases like this, though it is less precise. Usually you use bounding boxes or tiles to find out if your object MIGHT collide with something, then pixel-based collision detection to determine if it DOES collide with something. The basic idea is sound though, yes. You find out what portion of your two images overlaps, then loop through that area checking to see if any of the pixels occupy the same space. Keywords: Axis-aligned bounding boxes, tile-based collision, pixel-perfect collision. Happy googling!
  5. There is a LITTLE info on http://c2.com/cgi/wiki?AntiObject ... I'm afraid it's not an idea I've encountered before. For games, I would worry that it would work well for very simple things and very badly for things with more complex interactions... That's just a guess, though. It might be worth coming up with some simple sims to experiment with it.
  6. Icefox

    Sort Button not working

    "Implement" means "write", essentially. :) The Inventory object needs a method "int compareTo(Inventory)". This method should return -1, 0 or 1 depending on whether one object is less than, equal to, or greater than the other. How this method determines "less than", "equal to" and "greater than" is entirely up to you; it could be by string comparison of the names, or by inventory number, or however. For more info, see http://www.java-samples.com/showtutorial.php?tutorialid=220
  7. Icefox

    Game Design Basic Help

    Well, I dunno much about the genre I fear, but I've played Stars! and EVE which are pretty much spreadsheets in disguise anyway... By "Online" do you mean "Web based"? Because if so, you're probably best off using javascript and some back-end CGI (which can be anything). "On the fly" is also pretty vague; could you clarify? Note that multiplayer games are an order of magnitude more difficult than single-player games, almost by definition... Just something you should know. I think that the first place you need to begin is with a design document. Write up a detailed spec of what you want the game to do, how it works, and the math behind it. Once you have that, at least some firmer requirements should present themselves.
  8. Icefox

    Has anybody else had this problem?

    As people have been saying, you don't need to know every single function; you need to know how the system as a whole works. As in assembly, you don't need to memorize every opcode, but you need to know how the stack, registers, FPU and so on work. You need to understand how DirectX does things, and how it "thinks" about the world. As for how to do this... That's tricky. I'm afraid that the only way I've found is to keep practicing. You don't necessarily have to make big fancy things, or understand the whole thing at once, but keep plugging away incrementally. Good luck.
  9. Icefox

    need help on first big project...

    That sounds like a decent approach in general. There are two gotchas that you are going to want to look out for: One, figuring out what info should be in the level file and what shouldn't can be tricky. The main reason to have a config file instead of compiling the values into the program is so that they're easy to change, so the values in the file should be the ones that will be tweaked a lot, and differ from level to level. Two, make sure you don't spend too much time making it instead of making the game itself (unless you're doing it to learn how, of course). Config files are actually fairly tricky to do well, so you might want to look for a library that does this for you.
  10. Icefox

    scripting/programming languages

    Yep! Lots of languages tend to blur the line though, especially newer ones like C# and Java. Scripting languages can be compiled, and programming languages can be interpreted. There's no firm definition, mainly an issue of what the language is designed to do.
  11. Icefox

    Does anyone still even use NeHe

    Yes. Yesterday, in fact. The topics NeHe covers are somewhat scattered, but to my knowledge, every piece of code there is still valid. OpenGL doesn't change much, and the basics tend to stay the same. :)
  12. Icefox

    Regular expression problem

    Something I read somewhere: "You have a problem. You decide to solve it using regular expressions. You now have two problems." I think that this applies to your problem... Regexps are really powerful, and I don't doubt that they can do what you want. But something simpler might be better, especially with all the powerful string-handling javascript has. I'd do something more along the lines of: 1) Split the string along space boundaries 2) Split it again on double-quotes 3) Loop through the list, match each word against the word you're looking for, and make sure it's not in double-quotes when you do so.
  13. Icefox

    SDL 3D

    I've found the NeHe tutorials (http://nehe.gamedev.net) to be a very good starting point for 3D OpenGL programming, and most of them have SDL versions of the code avaliable for download. Just ignore all the ugly Windows stuff. :)
  14. Icefox

    [SDL_ttf] Blit multiply lines?

    Not to my knowledge. Sorry. SDL_ttf is a text rendering engine, not a text layout engine. However, it shouldn't be too hard write your own function to return to a set point plus a certain offset on each newline. :) And, be careful with TTF_RenderText_Solid(). It allocates a new surface, that has to be freed with SDL_FreeSurface() once you're done with it.
  15. Icefox

    float number precision

    Yes! ...sort of. A "double" floating point number in C/C++ is 64 bits... It can represent numbers up to about +-1.8*10^308. That's a REALLY big number, 308 digits. However, it's not precise; it only stores a limited number of significant digits. I really wouldn't suggest it; it'd probably be better to either find a way to use smaller numbers, or use some bignum library like the one linked above. It depends on what you're doing with them; can you tell us more about it? Either way, more information on the details of floating point numbers can be found here: http://en.wikipedia.org/wiki/IEEE_754
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!