Jump to content
  • Advertisement

True_Krogoth

Member
  • Content Count

    31
  • Joined

  • Last visited

Community Reputation

140 Neutral

About True_Krogoth

  • Rank
    Member
  1. True_Krogoth

    Do My Swordsmen Look Like Cyborgs?

    Thank you all ^__^ Your tips are great I am focused on progamming now. Shall resume on graphics after some time.
  2. True_Krogoth

    Do My Swordsmen Look Like Cyborgs?

    Seems to be a next level for me ^_^   (Still need to work on armor pads back)
  3. True_Krogoth

    Do My Swordsmen Look Like Cyborgs?

    This is simplification same as Warcraft 2 has, 5 direction sprites instead of 8. I will get rid of that in future, but for now it seems to make things a little bit easier   What I have now: Here are UI changes, it now looks less sci-fi, I guess As I am getting experience I can now understand that I shall make a better torso armor. It should have a little more volume and shades.
  4. True_Krogoth

    Do My Swordsmen Look Like Cyborgs?

      Is it much better or not really? (No UI changes yet)   Added: I have to do something with this back also
  5. True_Krogoth

    Do My Swordsmen Look Like Cyborgs?

    Thank you all, you helped me a lot ^_^ I'm convinced now that the 3d model needs details. The style approaches Warcraft II but the quality isn't. I should remake armor pads, add details to sword, change selection and healthbar, though it must have breaks, but I will search for suitable design   I shall come back soon with a better version
  6. True_Krogoth

    Do My Swordsmen Look Like Cyborgs?

    Look: [attachment=32631:swordsmen.jpg] These guys are meant to be some mid-age swordsmen (The sprites are right from 3ds Max render)   Do they look like cyborgs? Is it more like a Starcraft terran with a.. sword?   Or is everything fine?   Or you could give some advices how to make them look more human? With not much 3d modeling, I'll be very thankful The sprite (just a stand animation yet) png is attached   Added later: Version 2: [attachment=32634:swordsmen2.jpg]   Added later: Version 3 (with UI changes): [attachment=32641:swordsmen3.jpg]   Added later: Version 4: [attachment=32643:swordsmen4.jpg]
  7. True_Krogoth

    My graphic objects (Gfx)

    1, 2. You are right. I am not sure of how much translucency there should be. As I imagine currently, there is a lot of translucency. Translucent environment, translucent cursor, translucent effects, roofs being translucent, units being translucent to make you able to see units that are behind other units, etc. I am feeling translucency paranoia right now. (But there is some right feeling behind this paranoia, as I will blame myself once I need much translucency at game making stage, and I didn't implement it well enough)   3. I trust you that it is indeed nearly free, but still, if I do not use batching (as it makes no sense to batch translucent objects), I would better clip them myself, as it's not as nearly free in drawing case as it's with batching. (Because in non-batching approach for translucent objects I have my sprite objects and pass through them. Even if it doesn't draw anything outside of screen, I still call "empty" methods, that are better to avoid if it's possible, and it doesn't require much resource to actually do it)   Edit: Btw, all these methods are inlined! There should be just a loop with switch in the result code.       I have another one question! Seems a bit dumb but still.   Objects are good to put together, so you don't jump far in memory. As I did, gfx container is a vector of blablabla of gfxs, not pointers. I did it because I was thinking about passing speed: passing through objects is faster than through pointers. The minus is that I have to swap the whole content in this case, not just a pointer. But how much significant is the difference between passing through objects and through pointers if the objects themselves are located close each to other (not close to a point where loop starts, but still each to other)? For example, if I create all my objects on stacks, so they are local. And then my container is of gfx pointers, not gfxs themselves. This means that every time that I go through array it jumps to stack and back. The main question is, how much slower is this compared to direct object vector?   If objects would be created not in stack, but scattered throughout all the memory, that might happen by allocating objects 1 by 1, this would have significant speed loss for sure. This would be really bad implementation. But about creating objects at a stack, I am not sure. Is it what I really would like to do in this case? Is it a solution to create objects at stack and have pointers to them? Or it's better to keep it as it is, and just deal with slowness at objects swapping?
  8. True_Krogoth

    My graphic objects (Gfx)

    But it loses somewhat that I would call "nicety". )))   Edit: Sorry for double posting.
  9. True_Krogoth

    My graphic objects (Gfx)

    Let me repeat some of my (some rhetoric) questions.   1. The concept considers enough translucent objects, so I have to make own ordering, right? There are very possible translucent objects over other translucent objects, so what I am doing actually makes sense.   2. If my approach to translucent objects is okay, at this phase it can suffice other purpose, as work with opaque objects. I ignore zBuffer, but I do not create an algorithm to replace zBuffer. I use already existing algorithm that has to exist, as zBuffer isn't compatible with translucency.   3. I need to separate visible objects from not visible, to avoid possibly many meaningless render calls, don't I? This is what my vectors inside order indexed vector easily do.
  10. True_Krogoth

    My graphic objects (Gfx)

    Doesn't it work only for .0f and 1.0f alpha values?
  11. True_Krogoth

    My graphic objects (Gfx)

    But how to do with transparency? I am not blankly defending my concept, but I don't see a solution w/o making my own ordering. Am I right, translucent objects can't be done with zBuffer. So I have to make my own ordering! (Am I indeed right?) Even "non-obviously-translucent" sprites need to be translucent to "look nice", otherwise they are sharp-edged. (It needs more than just .0f and 1.0f alpha values to "look nice" at the edge) Edge translucency is like free anti-aliasing. :-o (Please, don't beat me for saying such things )) I am just trying to explain it easy )       This is a very good point. But batching is real only when zBuffer is ready.   Again, translucent objects.   No zBuffer.   No batching.   I have to draw each sprite in certain order.       I will give you few examples in addition, why I am defending my translucency support!   Let's take any unit, for example, footman! Footman can go inside a castle or go outside. If this is some turn-based RPG, I would like some appear/disappear effect. Let's say, footman's alpha goes from .0f to 1.0f when it comes out! Logically, EVERY unit has to be able to go transparent, as they all can go inside/outside of castle.   Another example. I would like to see a house with translucent roof so I can know from the top perspective what is going on inside, keeping some realism.   I am thinking of a game where translucency is not a rare thing. On the other hand, such game isn't as much complicated in terms of objects that using own ordering, which is not as efficient as zBuffer, is performance-critical. At the first place, I implement more-or-less efficient translucent objects, then use it for everything, including opaque. If this will ever get performance-critical issues, I am gonna distinct translucent and opaque objects and apply zBuffer to opaque indeed. But why do you need a 2D game so much complicated that you need only zBuffer to work well? If your game has billions objects drawn you probably need a special engine for this. This is logical to choose the engine that is the best suitable for your purpose. My engine, or engine, as it's not gonna be something much complicated, is for common (90+%) 2D game. So I see no reason to distinct translucent and opaque objects at least at this phase.   I think, this post explains my logics the best.   I would like to get as much useful feedback as it's possible, as I am tired of coding things that do not make real sense. (Like, I could already write 1 inefficiently-made game at this all time that I am trying just to organize my objects, reworking nearly the same code over and over again, as I can't get rid of feeling trash approach. This all comes from no game making experience. I am certainly able to make a game just to make it work somehow, but I would like to be patient and collect more experience.)
  12. True_Krogoth

    My graphic objects (Gfx)

    It is nearly same   https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Constructor       The point is how often you swap your objects.   Usually the most frequent operation is passing through objects and updating/rendering them. Passing through objects is faster than through pointers. If objects aren't too large, it looks fine to swap their content (or it isn't?).   What I do is exchange faster swap ability for faster object passing. If some objects are meant to be very active in terms of moving across container, I will do separate implementation for them, where pointers figure. But common aren't.     Because the class is unfinished. This is what I have at the moment: union { int spriteset; // sprite gfx_container_t* gfx_container; // base int size; // point }; union { int x; // sprite / base / point }; union { int y; // sprite / base / point }; union { int spriteset_x; // sprite int color_r; // point }; union { int spriteset_y; // sprite int color_g; // point }; union { int mirror_x; // sprite int color_b; // point }; union { int mirror_y; // sprite int color_a; // point }; union { float scale; // sprite / base };   I presumably know what objects I am gonna work with. For example, I am working on simple 2D strategy. I know that I am gonna have some interface, ground tanks, aircrafts, healthbars and cursor. This might require 5 order indexes, as aircrafts are over tanks, healthbars are over aircrafts, etc. So I will init my gfx to have just 5 orders. If I need more, I can add it at any point. But for a simple purpose like I described it's unneeded.
  13. True_Krogoth

    My graphic objects (Gfx)

    Ty, especially for VBO. Me noob, didn't even "hear" about that, lol.)))   Let's suppose, I am not stubborn, but I would like to implement my own render ordering efficient enough, at least for good practice.   This is how my "gfx container" (of Base) can look: [attachment=28657:container.png]   - Column is an order index. - Row is a gfx's index in a vector of certain order index. - First go all blue gfxs, then all red ones. - Blue gfx is a gfx that is visible thus rendered. - Red gfx is a gfx that is not visible thus not rendered (for example, out of screen bounds). - Blue part size, or the first red gfx index is well-known (marked with yellow dash).   - Gfxs have update and render phases. - Blue gfxs pass through update and render phase, red ones - update only.   - If a blue gfx becomes not visible, it is swapped with the last blue gfx and becomes red (blue part size decreases by 1). - If a red gfx becomes visible, it is swapped with the first red gfx and becomes blue (blue part size increases by 1).   - The whole container is an order indexed vector of pointers to vector of gfx (thus render orders can be easily swapped or moved).   Few additional statements, related to how such gfx is meant to use: - There aren't much empty orders, that's why I let to pass through all empty ones, not caring much of efficiency. - There aren't much active orders at all. If more orders are needed, they can be inserted between existing ones (modifying few existing order indexes). It might have to move nearly all existing orders, but it's fine as it's rare operation.   Why I personally think this all is fine: - At the certain order index it passes through objects, not pointers to objects. - When it goes through all order indexes, it passes through pointers to objects, not directly objects, but, compared to object count, order index count is meant to be little. - At render phase it does not go through objects that do not render (does no check frequently).   It will work regardless all this requirements, but may go inefficient.   What do you think, please?  :-o
  14. If all the animations are quite simple, I would make such arrays like SpritesheetX[animation][frame] and SpritesheetY[animation][frame], then init all them and go through each frame. (So you can make them loop, non-loop, or like any short enough algorithm (This makes sense when the same sheet is used differently, that is quite common situation I guess)) This doesn't work well for slow animations though just like that. For a case of slow animations I would make some counter that calls PerformSlowAnimation every, let's say, 10 ticks. If the game is simple enough (in terms of animations), it might not matter if all animations are synchronized or not (they will be if you do so), and you can divide all animations onto fast, slow, very slow, etc.   If animation has very different frame rate during its life, you can always do a special method for this case. If there aren't much objects with "unstable" animations, you can design its behavior as just an additional functionality, so it doesn't have to work as fast as main method (so you can make if statements for that, switches, virtual calls or calls by pointers, whatever).
  15. Graphic objects (Gfx) are objects like: Point Sprite Base that are created at graphic objects of Base type at specified position, to be able to make all things rendered in right order. (Trying to avoid sorting here)   As there aren't much types of objects, and the majority of objects are sprites, I decided to implement all these special types in 1 class. At first look Cons: More members, Few short switches Pros: Collections of direct objects (not pointers), No virtual methods   While writing my code I was thinking that: 1) I must highly support transparent objects, so I do not use zBuffer at this particular approach. 2) Collections of direct objects work pleasantly faster than pointers. 3) Switch is efficiently implemented by compiler, so it can be either branches or jump table whichever is better. 4) Unions is a way to not just alternate data types, but also name members in appropriate, readable way. (This is not intended union usage though) 5) Special types are good to sort in order of use frequency, this is why Sprite must go everywhere first (as the majority of objects are sprites). (Might be incorrect at any point)   GFX.HPP (raw): #ifndef GFX_HPP_INCLUDED #define GFX_HPP_INCLUDED #include <vector> namespace keng { class gfx { public: // types enum types { sprite, base, point }; static const int base_default_size = 10; private: // default base static gfx* const default_base; public: // special construct methods static gfx* create_sprite( int position = 0, int map = 0, int x = 0, int y = 0, float scale = 1.0f, gfx* base = default_base ); static gfx* create_base( int position = 0, int size = 0, float scale = 1.0f, gfx* base = default_base ); static gfx* create_point( int position = 0, int x = 0, int y = 0, float scale = 1.0f, gfx* base = default_base ); public: // switching methods void render(); ~gfx(); private: // untitled special constructors // sprite gfx( int map, int x, int y, float scale ); // base gfx( int size, float scale ); // point gfx( int x, int y, float scale ); private: // help typedef std::vector<std::vector<gfx>> gfx_container_t; template<typename... Args> static gfx* construct(gfx* base, int position, Args... args); private: // type data int type; private: // switching data union { int map; // sprite gfx_container_t* gfx_container; // base }; union { int x; // sprite / point }; union { int y; // sprite / point }; union { float scale; // sprite / base / point }; union { int map_x; // sprite }; union { int map_y; // sprite }; union { bool mirror_x; // sprite }; union { bool mirror_y; // sprite }; }; // class gfx } // namespace keng #include "gfx.hh" #endif // GFX_HPP_INCLUDED There are named constructors for each special type. If you need to create an object at just screen you call one of them with no Base parameter specified. It uses Default Base that is highly related to screen then. If you need to make something like window with its own render order, you create a Base at Default Base, and then create objects with itself specified as the base. Then also translation, scaling, filtering, etc are applied to Base's sub-objects.   Graphic objects are vector of vectors. The first coordinate is a rendering order (or also position).   This is where I would like to stop my introduction and ask a question.   Let's say, I planned 10 possible rendering orders, so my vector consists of 10 vectors. But sometimes there are vectors that are empty, because there is no single object of this particular rendering order, so I go through missing rendering orders every ~.025 sec loop. Is it worth to do some optimization, like 1) make an array of indexes and pass through indexes, but this requires a lot of work with indexes upon creation/deletion, 2) make a list of vectors instead of vector of vectors, but this may work even slower, or ?, or better put things in user's hands and force him to use orders wisely, not setting too large bounds and adapting order indexes himself? Or maybe just 1 vector for all orders that is sorted (despite all my tries to avoid sorting) every creation/deletion is still overall better?
  • 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!