Messages

46

Network / NPC/AI, How!?

« on: September 12, 2011, 08:20:26 pm »

get that the server probably is the best "client" for these AI-controlled guys, but that would mean that I'd have to check collisions etc on every friggin map on the server, for every npc/enemy, as well as actually load the maps into memory on the server(wich I do not do atm). That would be very performance-costly and I can't seem to wrap my head around on how to fix this.

While I understand that this might be a significant problem in terms of performance, it is generally considered that - at least in other types of programs - one should assume that the client can not be trusted. Otherwise, the games might become too easy to hack(e.g. to have better scores).
I know it might be problematic and I didn't really suggest any solutions, but I thought this is the kind of stuff that needs to be said.

If this risk is O.K. for you(if having a bunch of people artificially inflate their records is no big deal), then go ahead with client-side checks and just perform the minimum required server-side stuff(to avoid SQL injections and friends)

47

General discussions / The new graphics API in SFML 2

« on: September 12, 2011, 03:59:47 pm »

Or rather define a Draw function in all of them so that we would write "sprite.Draw(window)"?

I like this idea. Besides, even if SFML 2 were to remove the equivalent functionality, the effective end-result would be that people would re-implement these classes themselves.

Also, if you dislike adding junk to the core, you could add a separate library SFML-SimpleGraphics, or something like that, where these extra high-level functions would be.

sf::Point. It's very simple, it contains 3 public members (Position, Color, TexCoords) as well as a bunch of constructors to easily construct points with 1, 2 or 3 of these attributes.

What if I want to pass extra-data per-Point to the shader.

48

Graphics / RenderTexture problems

« on: September 08, 2011, 08:59:51 pm »

I'm in a system with an Intel GMA without FBO.
RenderTextures seem to mostly work on my .NET game but I'm having two issues:

1. When I close the application, it crashes. This ONLY happens if I create at least one RenderTexture.
2. Occasionally, the screen stops rendering(so either freezes or goes all black). Sometimes resizing the window makes it go back to normal(and if that happens I can see that the texture was rendered correctly), but not always.

Here's my C# code for texture creation:

Code: [Select]


        public void GenerateCardTexture(GameContext info, CardType card)
        {
            RenderTexture t = new RenderTexture(256, 384);

            t.Clear(new Color(0, 0, 0, 0));

            //Some code to Render Stuff to texture

            t.Display();

            cardRendering[card] = new Texture(t.Texture);
            t.Dispose();
        }


The "new Texture(t.Texture)" is there because I'm unsure about what Dispose() actually disposes, so I played it safe. In fact, if I make it just "= t.Texture;" and remove the Dispose, I get exceptions later on sfSprite_SetTexture.

Note that if I comment the code that calls Draw(), but still create the texture, call Clear() and Display(), then these problems do not happen. So I'm guessing the problem really is in Draw() functions.
I'm not using shaders, since my card doesn't support those anyway.

Am I doing something wrong? If not, is there any workaround for this issue(aside from not using RenderTexture)?

49

Graphics / Speeding up rendering

« on: September 06, 2011, 09:45:02 pm »

You're right. I just checked and it does work. I was under the impression that it required FBO to work but it seems that's just not the case.

I'll see if I can accelerate the game with RenderTextures.

EDIT:
Ok, so RenderTextures work but the results are kind of buggy. While I can have my cards appear on screen and due to heavily caching achieve good framerates(at very least comparable to the ones I had, possibly better), the game becomes much less stable.
My idea is to generate card textures as new cards show up. This works fine, ensuring each card texture is only generated when needed, no redundant copies, etc.
However, every time I generate a new card texture, there's a chance the rendering will stop working. In that case, sometimes resizing the window helps restoring the game to its working state(and the cards appear correcty rendered), other times the game just ends up a completely black window.

In addition, if even one single card has been generated(therefore one RenderTexture has been created), when the game closes, it crashes.

Am I doing something wrong or is this one of those Intel bugs?
One thing that may perhaps be worth noting is that I'm having is RenderWindow.Draw calls, then RenderTexture.Draw, and then RenderWindow.Draw back again. Not sure if that makes a difference.

Here's my code:

Code: [Select]


        public void GenerateCardTexture(GameContext info, CardType card)
        {
            RenderTexture t = new RenderTexture(256, 384);

            t.Clear(new Color(0, 0, 0, 0));

            //Some rendering instructions come here.

            t.Display();

            cardRendering[card] = new Texture(t.Texture);
            t.Dispose();
        }


50

Graphics / Speeding up rendering

« on: September 06, 2011, 04:34:29 pm »

I don't think my lame Intel GPU supports RenderTexture.

Also, I thought text drawing was essentially a combination of multiple sprite drawings in SFML. So how come that wouldn't work with text?

Even so, I suppose about half of my rendering time is spent on sprites, and another half on text. If the framerate doubled, I guess I would be pretty satisfied. So either way, it is a significant improvement.

51

Graphics / Bug?: Polygon drawing + outline fail

« on: September 06, 2011, 04:04:25 pm »

okay... I removed std::cout... and it's instant....

Generally, I/O can be a LOT slower than writing to memory, so if you do it for every pixel of your image it'll definitively slow things down. And since endl is being used, tricks to make things faster like buffers can't be used here.

If flood-fill is still too slow for you, there are other algorithms you could try such as scanline fill. But if in release mode it is "instant", then I'm not sure you should even bother.

52

Graphics / Speeding up rendering

« on: September 06, 2011, 03:57:12 pm »

No VSync, no framerate limit. Eventually, I might enable those if I see the need, but not for now.

If it's just a single sprite, then it's really slow

No. Each card has several draws associated.
Typically, a card will have at least 4 sprite draws, sometimes as many as 10, plus a few text draws(usually at least 6 text draws per card)

53

Graphics / Speeding up rendering

« on: September 06, 2011, 05:01:27 am »

Can you tell me more about your "unrealistic situation"

My game is essentially a card game(like a TCG in some ways) with a board and dices. So each player has a deck and a hand.
Now, the decks on my game are unusually big. They can go over 100 cards. And, because of how the game works, the player will typically end up having different paradigms over the game. This of course means the deck has to offer a wide variety of cards, very useful in some cases and completely worthless in others.

As a consequence, the "hand" of a player will tend to get very big. How big? I don't know.  I probably will only find out on near-final versions of the game.
The framerate problem seems to be more serious the more cards I have in my hand and the more "filled" the board is. Also, the zooming level of the board also seems to have some effect. Probably because I try to avoid drawing tiles that aren't visible.
At around 10 cards in hand, the framerate is between 30-50FPS, which is perfectly fine.
At around 50 cards, the framerate is between 15-25 FPS.
As the number of cards nears the 100, the framerate is having trouble going above 15FPS.

I say unrealistic because I understand that the player will rarely have that many cards on his/her hands, but I suppose it's possible.
Also, this is on *my* computer, maybe slower systems will perform worse. And this is a WIP, so the final game may have a few more stuff that will slow the game further(you know, eye candy and stuff)

One thing I admit is that these cards in the hand are partially hidden,(by the other cards) and I could do a much better job at not drawing the parts that won't be visible, though that certainly would prevent me from doing translucent cards(which I probably won't do anyway).
I certainly would like to go lazy and have SFML detect and handle this automatically

Also, not sure how much this matters, but my game textures have pretty good resolutions. The smallest textures have 64x64 and some ones go up to 256x384. While in some cases I admit I didn't really need so much resolution, the fact is this game looks really neat compared to my previous "pixelated" projects because of that. In the final version, I guess I could reduce the resolution in some cases(such as 64x64 images that always get rendered as 24x24), if that would significantly improve the framerates.

It should be ready soon.

I like collecting unusual use cases, to make sure that the new API is flexible enough.

Good to hear. Great fan of SFML and I recently had to tell someone I know to stick with SDL+SDL additions because of something the SFML 2D drawing API doesn't seem to support(at least not that I know of). Having a more flexible API would pretty mean I'd never have to do that again.
That project was a pseudo-3D game that relied on stuff like stretching textures at runtime, which AFAIK SFML doesn't currently support in its Sprite API.

54

Graphics / Speeding up rendering

« on: September 05, 2011, 09:31:42 pm »

I'm using SFML 2(.NET) and my game is in some cases a bit too slow. In some admittedly not very realistic - although certainly possible -situations, the framerate actually goes below 20FPS and I would like to speed things up.

So I decided to do some profiling and I got to the conclusion that most of the elapsed time is spent on RenderWindow.Draw and RenderWindow.Display.
My profiler is suggesting that 37% of the time on my main thread is spent on RenderWindow.Display alone. And at least 29% of the total time(probably more since I didn't finish counting and I rounded the number down on a few calculations) is spent on RenderWindow.Draw.
The system monitor shows one of my CPU cores is very busy, so I guess my bottleneck is more specifically the software side of these functions, but to be honest I'm on an Intel system with OpenGL<2.0 so I'm not even sure my OpenGL is hardware accelerated. But even considering my hardware situation, I still think this is kind of slow.

So I was wondering, is there anything I can do aside from reducing the number of drawing calls to speed things up?

55

Graphics / Bug?: Polygon drawing + outline fail

« on: September 03, 2011, 09:39:11 pm »

SFML Shape documentation states that it represents *convex* shapes.
Your example uses a concave shape

56

DotNet / SFML.Net 2 for linux download?

« on: August 26, 2011, 04:56:44 pm »

In my case I compiled libcsfml/SFML/SFML.NET on my own and added:

libsfml-audio.so.2
libsfml-graphics.so.2
libsfml-window.so.2
libsfml-system.so.2
libcsfml-audio.so
libcsfml-graphics.so
libcsfml-window.so
libcsfml-system.so (not sure if it's needed)

to the folder of the .NET executable.
Then I created dll.config files to allow the same EXE to work on both Windows and Linux:

For instance, my sfmlnet-graphics-2.dll.config:

Code: [Select]


 <configuration>
    <dllmap dll="csfml-graphics-2" target="libcsfml-graphics.so.2" />
 </configuration>


I did the same for window and audio.

I hope this helps.

57

DotNet / Problems with SFML.NET (Version 2.0)

« on: August 17, 2011, 05:11:56 pm »

For the garbage after the text, I discovered that if I append "\0" at the end of the string(normally not needed in C#), the problem goes away.

Code: [Select]


var fps = new Text("some fps counter" + "\0", FontManager.Font16px, 16); //works


58

DotNet / Problems with SFML.NET (Version 2.0)

« on: August 17, 2011, 04:06:17 am »

EDIT: Somehow, I managed to screw up and post this on the wrong category. Could somebody move this?

I've been using SFML.NET (based on SFML 2) for a bit and, although I eventually got the Windows version to mostly work, I'm encountering some issues on Linux:

1. On Linux, The RenderWindow title gets weird for characters like é and ç. Perhaps an encoding-related issue? If the window title is composed entirely of "common" characters, then it looks ok.
2. On Linux, when the program draws text on the screen, there seems to be garbage at the end of the string(usually one square character, although different sequences appear ocasionally).

Code: [Select]


            using (var fps = new Text("some fps counter", FontManager.Font16px, 16))

            {

                fps.Position = new Vector2f(0, 580);
 //Window size (800, 600)
                fps.Color = Color.Black;

                target.Draw(fps);
 //where target is a RenderWindow
            }

3. On both Windows AND Linux, using the string constructor in Font(rather than the Stream one) causes a NullReferenceException on SFML.Graphics.Font.Destroy when the font is disposed. This seems to be due to a null Stream being disposed. A simple workaround for this is to simply use:

Code: [Select]


new Font(new FileStream(filename, FileMode.Open));


Aside from that, SFML 2 looks generally solid, although it took me quite some time to get the *.dll.config files to work on Linux.
Also, although my system is x64 and as such sfml/csfml were probably compiled as x64. However, the sfmlnet-*.dll were compiled as x86(because they were compiled on Windows x86 and I was too lazy to compile them again on Linux x64). Not sure if that makes a difference, since aside from fonts SFML seems to be working great(haven't tested audio, though)
The font I'm using on both OS is arial.ttf taken from Windows 7.

Looking forward to information on these potential bugs, especially the second one(since it's the one I haven't found a workaround for). Aside from that, thank you for designing a great library like SFML. Looking forward for the official SFML 2 release.