Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

499 Neutral

About nox_pp

  • Rank
  1.   I feel you, I do the same thing from time to time.     I do, extensively. I sometimes have to change things, for instance to account for new dependencies or changes to the way they need to be linked as new versions are released. And really, in practice, your directory structure is probably not as fixed as you'd like it to be. Also, new platforms are not as straightforward as they should be, and generally require at least a little bit of custom code. I can deploy new clean projects using my game engine to Windows, Linux, iOS (simulator AND hardware), and OSX with my current build scripts, but getting to that point was not at all trivial...although that is the intention of CMake. I gather that adding support for Android will be another big hassle.     Your approach could work, but you might as well just let them parameterize your tool in the first place with their desired settings. I use the same script to generate slightly different builds for the iOS simulator and iOS hardware: cmake -DIOS_PLATFORM=SIMULATOR vs.  cmake -DIOS_PLATFORM=OS Of course, I can put these in different build trees, and I can rerun cmake to update those trees as project settings change, which certainly happens. It's not so hard to add basic command line arguments. I don't know enough about your exact use case to comment further. I've found CMake to be tremendously obtuse, so I have a hard time recommending it, it's just that at some point you might realize that your tool is just reinventing the wheel and have to concede defeat anyway (I'm not saying that that's the case here, yet :p)
  2. Greetings from Purple Pwny Studios, it is with great pride that I announce Between Scylla and Charybdis, a physics-based game of aquatic avoidance and survival.    [media]http:[/media]   If you would please take a moment to like, share, and subscribe for future updates, I would be forever in your debt. I'm finding it otherwise difficult to rise above the noise of other promotional venues.   This is definitely the most serious I've been about any single game yet, serious enough to stop taking on new contracts and pursue this with everything I've got. I'm taking a very refined and artistic approach to the design, as I tend to in all of my work. I'm purposely avoiding common overused game tropes like points, lives, leveling, guns, etc. because I think they're anachronistic crap that can give a bad game enough structure and familiarity to seem like it's actually good. This is a risky move, I know, but I'm not interested in doing it any differently. There are enough crappy games out there, the world doesn't need another.   Of course, BSAC would be nothing without the other half of Purple Pwny Studios, our artist, Lux. As a fan of classic Disney films, her interest lies in juicy traditional animations and carefully hand-painted backdrops and other assets. Here are some of her works in progress:       See more: http://imgur.com/a/iNNbg   I've also been taking screenshots from the first day of the project until now, which represents roughly 2 months of constant work. Of course, I started with quick programmer art, and plenty still remains:       I've compiled these screenshots, and others, into a gallery.    In closing, here's a piece of concept from another of the projects that we've been working on behind the scenes. Check out Lux's Deviant Art for more like this, and please tweet and otherwise share our work so that we can continue making such nice things without fear of going broke. Thanks so much, and feel free to ask me anything!  
  3. Sounds like something that can be easily accomplished with any build system. CMake comes to mind. It sucks, but perhaps less than the alternatives. Anyway, you would just write a CMakeLists.txt that will create your given directory structure as necessary and create properly configured project files with your pre and post-build hooks, compilation arguments, dependencies, library/include paths, a stub codebase, and whatever else you want.    Keep this CMakeLists somewhere handy, copy it to your new project root, and then just run something like:  cmake -DPROJECT_NAME=GameX whenever you want to generate a new project. This all depends on how you write your CMake script...it can be quite powerful if you so choose. Doing it with CMake would also grant you some key features like automatic dependency resolution, minimal rebuilds/reconfiguration, and some degree of reproducability and platform independence. If you write a script on your own, it probably won't be general enough to work anywhere but your exact environment...cross-platform or otherwise.
  4. nox_pp

    Programming Music

    The bulk of the crowd sounds to me like streaming the sound of the entire crowd while opening/closing a low-pass filter over the sound depending on the "excitement" level. There might also be some random little one-shot cheers for "color," and probably gain modulation running in tandem with the filter.   As far as the dynamic music goes, this wouldn't be too hard to do on your own, but you'd have to make a sequencer that can synchronize clips to some clock at a given tempo. Take a look at Ableton Live's session view. It allows you to arbitrarily cue clips synchronized to a global clock. This keeps everything running in time, all you've got to do is make clips that work together.   This little demo is OK:     He's swapping out entire songs/sections of differing granularity in real time, but if you try it yourself you'll better understand what's going on. I'm not saying to use Ableton, just copy the way that it works.
  5. If you're using C++, and not using the STL, you're doing something wrong. Yes yes, there are exceptions to this rule, but if you're in a position to ask a question like this, you are not the exception. Anyway, as zacaj said, use an std::vector. Or, perhaps an std::map if you want more convenient and potentially faster lookup.
  6. nox_pp

    Voxel Levitation and Rain

    Shit, man, this looks sick. I like the aesthetic way more than most voxel based games these days. Good work! [url="http://youtu.be/7h_hObwKjNw"]Here's a gameplay video[/url] for anyone interested.
  7. It's not quite that complicated. What you want is luaL_dofile. No need to manage the file streams yourself.
  8. Sure, if you sorround yourself with dickheads. It doesn't have to be this way.
  9. Unless you generate the graphics on the fly, you're not going to be able to scale them infinitely. What Xanather mentioned is the standard way of achieving scalability for rasterized rectangles. Other than that, I would render to an OpenGL surface or image file using Cairo (or similar): So why would you want to mix vector-graphics rendering, provided by cairo, with OpenGL in the first place?... - Create pristine texture-maps, which are resolution-independent and combine those with your custom mip-mapping. - Have animated vector-graphics as head-up-displays or overlays in your OpenGL-program. [/quote]
  10. nox_pp

    Library for playing Vorbis files with SDL2?

    I don't know about PhysicsFS, but I've used stb_vorbis to decode a vorbis file kept in memory. It's written in C and in the public domain. EDIT: I see that now that you want to play Vorbis files, not just decode them. To that end, vorbisfile is not a replacement for SDL_Mixer, nor is stb_vorbis. For output, you can use PortAudio or OpenAL, among other things. For decoding, you can use anything--vorbisfile, SDL_Sound, stb_vorbis, or ALURE.
  11. FWIW, the component based approach is only more difficult while you're wrapping your head around how it works. I think it's easier after that, but I feel where you're coming from anyway. Is it otherwise impossible for Entities to contain other Entities? It's not uncommon to want a parent-child relationship between entities in a game. Say, there's a knife on the ground, and your character goes and picks it up. You could just "attach" the knife to the character, if you had that capability. Both solutions are reasonable, but if you're starting out by saying that Widgets are fundamentally different than Entities--by putting them in separate trees--then you can't expect to handle them as if they are the same. You could maintain your WidgetSpace separately from your Scene. In WidgetSpace things are oriented and positioned with normalized coordinates relative to the screen, in the Scene things are positioned in absolute coordinates relative to the world. WidgetSpace can forward input for Widgets to handle on their own, while Scenes can handle input for Entities.
  12. What is a Widget? What inextricable properties does Widget possess? If it's synonymous with Entity, like Sprite was, then the answer is probably "nothing." A Widget on its own carries no inherent properties. You're almost always going to end up having an invisible Widget, or a Widget that doesn't care about input, or that can't move, or has no position, or has a position in 2-space instead of 3-space, etc. etc. To me, this just says that trying to fit your game objects into a hierarchy is a bad idea, they're not concrete enough. That's why the component based approach has caught on so well, it fits the problem space much better than a more vanilla approach to OOP. If you broke your current mental concept of Widget out into a class that could be contained and used by any game "Entity", then you could share the provided functionality between both typical "game entities" and GUI elements with none of the troubles of making this work via inheritance. For instance, an in game character and a button could both be Entities that contain a "Clickable" or "Inputtable" component. Some InputDispatcher class is aware of these components, and dispatches input events to them, possibly after filtering the input into some nice format or sending only events that a particular component has said that its interested in. I've faced the same problem. What I did is model Button as an entity that contains Drawable, Inputtable, and Positionable. Some properties set in Inputtable say that it's only interested in hearing about click events, and some properties set in Drawable say that it should be drawn relative to the screen, rather than the world, and some properties in Positionable give it a greater z coordinate than anything else in the scene (so that its always drawn on top.) FWIW, I wrote a little about component based entity systems years ago, which might help to point you in the right direction.
  13. Your problem is that you're abusing inheritance. You should favor composition over inheritance unless you have reason to do otherwise. You don't have true IS-A relationships in your hierarchy. Button is not a Sprite, it just contains a sprite. Likewise for Label and Scene. These are all things that CONTAIN sprites, and if your hierarchy were flattened to reflect that truth, you wouldn't have a problem with button, or anything else, containing any arbitrary number of sprites. Sprite shouldn't have children. Sprite is sprite, it's singular. It also does not have means for collecting input--that's far beyond its purview. What you may want instead is some base-class GUIElement. This class could provide default implementations for listening to and forwarding input, as well as adding and removing children. The classes that you derive from GUIElement can hold as many sprites as is appropriate for whatever particular element they are representing.
  14. nox_pp

    Lua troubles

    No, you don't need to pop them off the stack. Anything below the results is automatically discarded by Lua. Your code in spTrWra looks reasonable. However, in the cMap constructor, you call cMap::init, before any Lua code has been run. Therefore, lua_getglobal(L, "init") just pushes nil to the stack. Furthermore, when you call lua_call, you're saying that there are 3 arguments to some function on the top of the stack, presumably the global "init" (which is actually nil here,) but you only push one argument onto the stack, "this." You probably intend to call luaL_dofile(L, "map.lua") before you call cMap::init, assuming that that is where you define the lua function "init." I find it helpful to annotate my Lua C API usage, like this: void cMap::init() { lua_getglobal(L,"init"); // nil lua_pushlightuserdata(L,this); // this nil const int s = -1; if(!lua_isfunction(L,s)) { //another buggy cout } const int a = 3; const int r = 0; lua_call(L,a,r); // } I track the state of the stack in comments next to any functions that modify the stack. Also, I've found this site to be an invaluable reference.
  15. Variadic templates are ridiculously powerful, and antiquate a lot of redundant C++03 template metaprogramming. Initializer lists are a much needed addition to the language. They add the ability to make classes feel more like POD's, even when they aren't. std::vector<int> ivec = {1, 2, 3, 4}; //vs. std::vector<int> ivec; ivec.push_back(1); ivec.push_back(2); ivec.push_back(3); ivec.push_back(4);
  • 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!