Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - lezebulon

Pages: 1 [2] 3
16
Graphics / Animated tiles without looping ?
« on: December 24, 2014, 04:34:52 pm »
Hi guys

I'm making a 2D overhead game where the world is made of 32x32 tiles.
Some tiles are just a picture, some tiles are animated ie they cycle through a few frames during gameplay.

For now, each tile in my 2D map is a sprite. Now let's say that at a given frame, the animated tile frame should change. All I could manage to do for this effect was to call setTextureRect() on every animated tile and manually change the texture rectangle for each sprite, so that it matches the current frame. This works fine but it seems to me that I'm doing something wrong with editing manually *each* sprite's texture rectangle.
Is there a more logical way to do this that avoid looping over all the tiles ? Like doing some work directly on the texture itself?
Also, if I intend to change things later to a vertex array instead of a 2D table of sprites, would my concerns still apply ? what would be the solution then?

Thanks!

17
...and no demo was ever posted =)

18
General / question about the main loop in the sfml book sample
« on: June 07, 2014, 01:24:44 am »
Hi
the main loop in the sfml sample from the book is like so :
        sf::Clock clock;
        sf::Time timeSinceLastUpdate = sf::Time::Zero;

        while (mWindow.isOpen())
        {
                sf::Time dt = clock.restart();
                timeSinceLastUpdate += dt;
                while (timeSinceLastUpdate > TimePerFrame)
                {
                        timeSinceLastUpdate -= TimePerFrame;
                        processInput();
                        update(TimePerFrame);

                        // Check inside this loop, because stack might be empty before update() call
                        if (mStateStack.isEmpty())
                                mWindow.close();
                }

                updateStatistics(dt);
                render();
        }

what's the point of the inner while() loop ? If I understand correctly this will potentially call the input / process functions several times if the previous frame was rendered too slowly... but shouldn't this be handled by the input function who will poll all the queued events anyway ? Also the input / process block can be skipped if timeSinceLastUpdate <= TimePerFrame, but I don't understand what is the point of this.


19
Graphics / Re: Can i link VertexArray for drawing in one call?
« on: June 06, 2014, 09:05:07 pm »
I'm pretty sure PC can handle 2500 draw calls if it's done right, I remember that in 2011 I made something similar and it was on an old laptop with an integrated graphics card.

Anyway, from the desription the problem you are facing is mainly because you have defined no hard-rule on what you are doing. Obviously the more things you allow to happen, the more sprites you will need, and since you don't define coupling between things everything can happen independently so you need indeed need a lot of sprites.

But consider this : do you actually expect to have 2500 sprites moving, in different ways, at every frame? Probably not, so I think you need to define some hard-rule about what you are going to do, and use this to reduce the overall level of complexity.

20
General / Re: Framework Design Advice
« on: June 06, 2014, 12:36:33 am »
I assume with the 2D matrix you're referring to the setting where entities are columns and components are rows? Well, you needn't poll through all the entries and check whether they're there. An entity can hold a list of its components, so you only iterate through those that actually exist.
They it's exactly what I'm referring to. I think the original upside of the implementation is to be able to tell in constant time if a given entity has a given component, so it basically requires the entity to hold a bitset of the size of the total number of components possible (cf https://github.com/alecthomas/entityx).
Anyway I really don't understand the point of it all, except for prototyping maybe. You have a powerful language and you end up just structuring it such that all the elements are int, who hold a set of int, and the actual logic is just delayed "whenever". This really feels like it's "design for primary schoolers"

21
General / Re: Framework Design Advice
« on: June 05, 2014, 07:51:56 pm »
A bit off-topic, butI keep reading all over the web about how entity system is so great and useful, but tbh it seems like total BS to me. All you are basically  doing is creating a giant matrix of tickable boxes, then constantly poll aller over the place to see what is ticked. Also they never explain how the logic to actually exécuté action is supposed to work at all. To me it seems l'île this concept was popularized by people who are awful at programming and who think they can solve every issue by using a big 2d table and checking all the combinations...

22
thanks for the image! but it's exactly what I thought, it doesn't look very convincing, here all I can see is that the objects are floating above the grass and that we see their reflection in the grass (and not their shadow)

Unfortunately I don't think there's any solution to do convincing 2D shadows for just the sprite data

23
I'm not really sure I understand... do you have a picture of how it actually project 2D sprites on the "ground"?

24
how does the "shadow map" work for 2D stuff ? what does it actually draw?

25
Graphics / Re: question about RenderTextures, and co
« on: June 01, 2014, 06:32:54 pm »
how would I stuff them in a 2D texture with SFML?

26
Graphics / Re: question about RenderTextures, and co
« on: June 01, 2014, 06:03:57 pm »
thanks!
I have a similar question about 2D graphics and SFML:
what is the fastest way to send info from the CPU to the GPU ?
I'm planning to do fog of war through a shader, which would mean sending ~400 bools each frame to the shader (20 x 20 tiles at each frame on screen), through any means possible.
I don't think I can actually send that many shader parameters in real time, what would you guys advise?

27
Graphics / Re: question about RenderTextures, and co
« on: May 31, 2014, 03:03:00 am »
alright thanks!
I have another question:
let's say I want to draw a 100x100 sprite on a 1000x1000 RenderTexture , with a shader.
We are sure that the shader will loop over the sprite pixels and not over the whole range of the RenderTexture right ?

28
Graphics / Re: question about RenderTextures, and co
« on: May 30, 2014, 09:17:58 pm »
alright, but then how do games like Baldur's Gate 1 (from 1999), managed to have very huge maps with no texture repetition and apparently no streaming from disk?
I'm basically looking at different texture management strategies here... the fact that SFML is simple doesn't mean we can't have discussions about how to manage ressources :)

29
Graphics / question about RenderTextures, and co
« on: May 30, 2014, 01:34:30 am »
Hi!

let's say for example I intend to make a game like Age of Empires 2 ie overhead view, huge map and potentially lots of different sprites intersecting with the current view.
What is the optimal way to do something like this, in terms of RenderTextures ? I admit I'm a bit confused.

The simple solution would be :
- have single rendtexture of the size of the view
- redraw at each frame everything that is viewable

Now, let's assume for instance that the ground texture takes a significative amount of time to draw (for instance, because shaders, or could be tons of textures blended), and that I somehow want to cache it. The same problem would also happen if I wanted to make a game like Baldur's Gate, where the whole map (maybe 10k*10k pixels) is apparently a huge image with no repetitions, and I wouldn't want to load from disk chunks of the map at each frame, when the camera is moving.

I was thinking of doing something like that :
- split the whole map into RenderTextures of 512x512 pixels that would have the cached ground texture
- depending on the current view, draw first the correct cached textures, then draw on top the sprites

My question is : how is that approach scalable with respect to the map size ? I don't really understand how RenderTextures are actually working: is the data stored on GPU ? what's the max number of RenderTextures I can cache? How to compute this max number ?

Basically, what would your advice be for this specific use case ?

30
17 pages and not even anything to show.... I don't get it
who do you think will use this ? I can't even tell what are the key feature that are not utility stuff

Pages: 1 [2] 3
anything