Jump to content
  • Advertisement

Management

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

251 Neutral

About Management

  • Rank
    Newbie
  1.   Not a big deal. Many people already have it installed, and if not, it's quite easy to install.     Java requires a virtual machine to run. But there may be some alternatives such as launch4j http://launch4j.sourceforge.net/.     Are you planning on making 3D games? Making a 3D game in Java is much more difficult than in Unity.     They accept Java games. And it really doesn't matter. Nobody is going to refuse to buy a game because they don't want to install Java. Minecraft requires it, and it didn't seem to stop that game from selling really well.
  2. Management

    Criticism of C++

      Not really a big deal.   Firstly, because most similar platforms have very similar primitive sizes (i.e. int is almost always 32 bit on at least desktop platforms).   Secondly, you can simply do something like: typedef int32_t I32; typedef uint32_t U32; //Other typedefs here Which will save you from constantly typing long type names. You can now easily write functions like so: U32 SomeFunction(const U8 *bytes) { U32 r = 0; U8 *ptr = bytes; while ((*(ptr++)) != 0) r++; return r; } Now you can guarantee that your code will always use specific size variables.
  3.   Thanks for the tips! But a few questions:   1. Your solution was to use an "immediate" rendering system, where entities submit themselves. A lot of example I've seen use a "retained" mode where the entities simply modifies the information as needed, but the scene remains the same each frame otherwise. Is there any reason why you decided to go with the "immediate" system? Any benefits to it? And how did you manage things like lighting? 2. You mention how you split rendering into two functions, but I'm not quite sure what the purpose of the "draw" function/callback is used for. Can you please elaborate?
  4. I'm trying to design a relatively simple 3D scene rendering engine. I'm trying to also make it fairly high-level, so it's easy to just specify things like the position of a light, where an object should be, etc.   The problem is that I'm finding it difficult to design and implement this. More specifically, managing the relationship between the resources and the in-game objects I'm drawing.   I can, at the moment, load a mesh, a texture, a shader, specify the transform, and then draw. But that doesn't really solve much. If I want to create an entity, X, and draw it at a given position (by inserting it into the scene data), how should the rendering engine know X's mesh and texture? How do I specify what X is? Who manages it's resources (and said resources' lifetimes)? And how do I cleanly decouple what knows what "visual assets" X should be composed of, what actually draws X, and the gameplay code?   I was thinking that maybe a solution would be to create a "SceneRenderer" class that takes a scene, a renderer, and some information on what X is composed of, and ties everything together. But then I may run into trouble, since such a class in ambitious, I'm not sure how I'd "define what X is", and I would still need to deal with the resource management thing.   Sorry if what I'm saying is a bit confusing. But I'm not really sure how to explain what I wanting to achieve. I don't want something that can draw an asset, I want something that can draw based off of scene data managed by the gameplay code, which wouldn't contain actual information on how to draw, just what to draw and where. And I'm not too sure how to implement it. Or if I'm just going in the wrong direction with my thinking.   Just to be a bit more clear, I'm asking about architectural decisions on creating a rendering engine, not actual code (code examples are welcome, though).
  5. Management

    AngelScript and PImpl

    True. But AngelScript as a plugin? Does it even work as a plugin? I haven't ventured beyond the C++ binding API, so correct me if I'm wrong, but wouldn't the application require knowledge of AngelScript before hand to bind it? It wouldn't really be a plugin if the application needs it. It would just be a dynamically-loaded library.   I hadn't thought about that.   I don't mean to come off as rude, but would you mind giving me an example of AngelScript saving the day with PImpl? The library seems virtually exclusive to game engines, which  certainly don't dynamically load modules as important as the scripting libraries. I know the library's usages can extend beyond just games, but it makes it that much harder to understand a true scenario where PImpl is important. It just seems like a very weird scenario to plan for given how the library is typically used. Lua uses a form of PImpl (or whatever it's called in C), it's used well beyond just games, yet the only scenario I've heard about it benefiting (I say benefiting loosely, because re-compiling wouldn't be that much of a hassle) from it's PImpl-like interface was to simply update the library's DLL without re-compiling while maintaining the ABI.     I don't mean to sound like this is some astronomical issue. I don't believe using pointers and a bit of dynamically-allocated memory makes much of a different either (it's a scripting language that's much slower than C++, tuning for best cache performance is a relatively minor issue). As I said, Lua uses it too, I only don't care because it's written in C so it saves me from typing &s everywhere (that and Lua goes crazy with dynamically allocated memory anyhow) . It's just something that I don't quite get given the syntax of C++ would allow for clean code and stack-allocated objects.   Also, just because it's stack-allocated doesn't mean it isn't practical to just throw it in the game loop function (or even just main, like you said, if the application is not a game) and just use references. My issue is where it's allocated, not how it's referenced.
  6. Management

    AngelScript and PImpl

    asIScriptEngine *engine = asCreateScriptEngine(ANGELSCRIPT_VERSION); This line of code demonstrates something that I greatly dislike about the AngelScript API (though, aside from this the API is excellent for C++ bindings). Maybe I'm missing something here, but I don't understand why something like this: asScriptEngine engine; Couldn't have been implemented. What's the purpose of using PImpl? Seems like a waste of performance if you ask me (not to mention the ANGELSCRIPT_VERSION is finally gone, what exactly does that do, anyways? seems like a redundant macro to be passing to the library).   Some other examples include asIScriptEngine::GetModule and asIScriptModule::GetFunctionByDecl which both return PImpl's.   I'd like to see a version where pointers aren't just thrown everywhere. Not only does dynamic memory come with a performance cost (maybe performance and scripting don't go hand-and-hand, but I feel this is still a concern), but they make it unclear who owns what object, the object's lifetime, and not to mention the lack of RAII to automatically call any cleanup functions (unless the library does it for you somehow, then you can ignore the last one).   Unless there is a reason for them, but that's why I'm asking.   - Management
  • 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!