Messages

136

SFML projects / NetGore - C# open source MORPG engine

« on: April 17, 2010, 01:16:49 am »

Cross-platform was just a bonus. I can't think of all the reasons off the top of my head, but in brief, the big ones were:

• Content pipeline - XNA pretty much forces you to compile your content. Loading bmps/pngs directly isn't very pretty, gives you assets that aren't able to be added to the ContentManager, and I believe is even deprecated now. While I like the idea of it, it made build times quite horrible. I didn't want people to have to manually add assets to the solution, so to even get them to build I had to create a custom msbuild project to do a "search and build". Even when content was already built, it took a good 4 seconds for just about 100 files. When they had to build, it took a good 20 seconds. Now, I just run a program in post-build that does a threaded compare/copy, and is nearly instant.
• ContentManager - I didn't like having to unload all content in one call, nor did I like having to maintain multiple ContentManagers. However, altering the ContentManager is brutal in XNA. Even just loading content without it is rough, so you can't just "roll your own" easily.
• Music - You HAVE to have Windows Media Player installed to use music in XNA, which was more just annoying. Playing music for the first time also resulted in a like 3 second stall on the calling thread, so I had to make a hack to create a background thread to just "prepare" the music.
• Portability - I never really cared if the client was cross-platform, but the server needs to be. This engine is focused at indy developers, and Linux VPSes are almost always significantly cheaper than Windows ones. Grabbing primitives like Vector2 and Rectangle and using those without referencing XNA got quite ugly and required some reference-juggling via msbuild hacks.
• Distribution - SFML is tiny. XNA isn't too big (a few MB), but the installation can be quite long for such a tiny thing.
• Text input - There just isn't any of it in XNA. It was annoying enough to get EN-US keyboard text to work. To support other keyboard layouts, it was looking like it would require some Windows API calls to transform the real keys into virtual keys to get the text.
• "The XNA way" - XNA pretty much forces you to use "their way". Usually, this wan't a problem. But at times, it became quite annoying (see ContentManager above). SFML isn't perfect either, nor is really any other engine (absolute flexibility just isn't really realistic), but at least SFML is open source so I can just change the engine. And this has turned out incredibly useful.

XNA isn't bad, it just wasn't suiting my needs.

137

Graphics / PBO Drawbacks and Implementation ?

« on: April 16, 2010, 06:09:31 pm »

The main problem I see to PBOs for sprite images is that the GPU will be too busy for shaders, right?

Look at what your game is doing. Then look at what modern games are doing. If you're using SFML, you probably just have a bunch of 2D shapes drawn on the screen. Modern games are drawing complex 3D models, smoothing them, applying lighting and shadows, creating reflective surfaces, and tons of other shader effects. To make the GPU "too busy", you have to give it more to do than just draw rectangles. The max amount you can draw in SFML is more likely going to be determined by maxing out the bus or too much overhead from OpenGL calls, not actually maxing out the GPU.

138

General discussions / Benchmark : SDL vs SFML

« on: April 14, 2010, 05:49:37 pm »

Yeah, I gave up on XNA after using it for about 2 years. I like SFML a lot more for 2d.

139

General discussions / Benchmark : SDL vs SFML

« on: April 14, 2010, 02:57:39 am »

Speaking of performance, how is xna/directx working for 2d?

Xna actually has surprisingly great support for 2D. Its not as simple as SFML, but one big thing they have going for them is their SpriteBatch class. There are 5 sorting methods:
1. Immediate: Draw whenever the state (texture) changes.
2. Texture: Draw everything at once, ordered by texture (for when stuff doesn't overlap).
3. Deferred: Draw all at once in the same order called (same as Immediate, but delayed, I believe - its so you can build up multiple batches at once without messing up the drawing).
4. Front-to-back: Deferred, but sorted by depth.
5. Back-to-front: Deferred, but sorted by depth (other direction).

I personally only really used Immediate, since I find it easy enough to handle the ordering myself. I assume this is pretty much like the batching Laurent added to SFML 2.0. If a call to draw uses the same state as the last call, you queue it into the batch. If the state changes, you flush the queue, clear it, then place the newest call in the front of the batch. Combined with texture atlases, I was able to render my whole scenes in under 30-or-so batches.

However, with XNA, you are in a load of hurt if you try to do things your own way. One reason I switch from XNA to SFML for my project was since I didn't like how XNA's ContentManager worked. Switching to SFML, I had a robust content manager that supports lazy-loading, only loading one instance of each asset, and automatic asset reloading (if you call an asset that has been disposed, it reloads from file transparently) done very quickly. Trying to do this with XNA, I gave up after about a full day of working on it, and tons of hacking with reflection.

In my project, since I just replaced XNA with SFML, things are being used pretty much the same way. From what I can see, the only real performance hits are coming from the fact that I no longer have any batching. But even still, I am hitting 60 FPS no sweat. I think the SFML version is running about 50%* slower while doing the exact same stuff (even using texture atlases still), but again, we're comparing no batching to batching, and I am still using SFML 1.5. And my rendering is still written with XNA in mind, not SFML.

*This is a complete guess from memory based purely on approximate numbers I remember when looking at the Task Manager. In no way have I EVER actually measured it.

As far as simplicity goes, SFML beats XNA hands-down for 2D. Its quite scary how simple SFML is. And at least when you don't like how something works in SFML, you can roll your own without a fight.

140

General discussions / Benchmark : SDL vs SFML

« on: April 13, 2010, 07:03:23 pm »

As long as SFML is "around SDL" in terms of performance, anything more is just a bonus to me. I use SFML for its design, very active development, and great 2d support. Any speed improvements are just a bonus. How many of you are actually 1) hitting a frame rate limit, 2) have a reasonable amount of rendering being done, and 3) have already optimized your rendering? There is a huge amount of stuff you can do to optimize rendering on the user side. From what I can see, SFML is pretty much bottlenecked by the drawing calls, which is usually what happens with most 2d engines. So there likely isn't a whole lot SFML can do besides batching, but even then I have had mixed results when it comes to that since batching in 2d isn't always so beneficial.

Focus on designing your game. If by the time you finish, and your game isn't running fast enough, optimize the way you are rendering and add some support for toggling effects/quality. If that still isn't enough, then you can consider SFML's performance. Until then, its just "an interesting statistic".

141

Graphics / dynamic shadows

« on: April 11, 2010, 06:12:42 am »

Oh, so you mean something more like this? The approach given there, even though it is for XNA, can easily be translated to SFML since it uses something similar to what I mentioned. Though it will start to be slow VERY quickly as you increase the number of light sources and objects.

142

Graphics / Shape with a hole

« on: April 11, 2010, 06:08:59 am »

Since it looks like this is for a tower-defense game, I assume you won't have many different sizes. In which case, just create an image by drawing the whole circle, than drawing over the inner area with another circle the same color as the background. Save that to a new image, then simply draw it like you would any other sprite.

143

Graphics / dynamic shadows

« on: April 10, 2010, 10:18:48 pm »

For 2d lighting, you can just draw a lightmap every frame.

1. Create an image equal to the size of the backbuffer (create only once during initialization)
2. Clear the screen with black
3. Use additive blending to draw on light sprites (stretch to increase size, increase color closer to 255/255/255 to increase intensity)
4. Draw all the lights
5. Copy the backbuffer to your lightmap image
6. Clear the screen, draw as normal
7. After you finish drawing, draw your lightmap on top of the screen using Multiply blending

Very simple but versatile 2d lighting using just SFML.

144

DotNet / Setting up Visual Studio 2008

« on: April 10, 2010, 10:14:55 pm »

Fair enough. Most people will just use Any CPU, too, until something breaks. After all, it is the best of all the options.

With Any CPU selected, .NET will use x86-64 if its a 64-bit OS. Otherwise, it will use x86. So anyone with a 32-bit OS won't be noticing this error when using the .NET bindings. When a user with a 64-bit OS runs the program, the .NET framework will end up looking the 64-bit version of the CSFML libraries. And this is why people get InvalidImageFormatException or whatever it is - since the program is trying to load a 32-bit library as 64-bit.

So yes, please use x86.

145

DotNet / Setting up Visual Studio 2008

« on: April 10, 2010, 01:25:02 am »

Or maybe it the .NET bindings should be x86 by default. I don't see why Any CPU should be used for the samples when the sample build doesn't support x64.

146

Graphics / Move, stretch, and draw sprites without modifying its pos?

« on: April 08, 2010, 06:49:06 pm »

And what about "RenderStretch" function equivalent in SFML?

Looks like it'd be the same as setting Sprite.Position, Sprite.Width, and Sprite.Height.

147

SFML projects / NetGore - C# open source MORPG engine

« on: April 08, 2010, 06:06:03 pm »

NetGore is a free, open-source 2D online RPG engine written in C#. It is cross-platform and supports both top-down and sidescroller games. NetGore comes with a large amount of the fundamental MMORPG components built in which allows you to focus more on designing your game.


(view more images)

Purpose: The idea behind NetGore is to provide a strong foundation to build a game off of, and to provide the implementation of all the fundamental components involved in 2D online games. That way, people can spend their time with what makes their game unique and stand apart from the rest. For the past few years, the focus has been on performance, flexibility, and advanced features. Recently, the focus has shifted to making it even easier and faster to create your own game with NetGore.

Target audience: NetGore is intended for online multiplayer 2D games only. Although the focus is mainly on real-time RPGs, most any kind of multiplayer 2D game is fine. Some users have already implemented shooters and turn-based combat. We also focus especially on indie developers in numerous ways, such as by including a lot of the features for you and providing a fully-functional base game to work off of.

Features: A detailed list of features can be found on the about page, but in short, most of the basic (and some more advanced) MMORPG features are built in to the engine. More features are always being added as well based on the demand for them.

Links:
Home page
Screenshots
Download page

Any feedback is appreciated, either here or through the NetGore forums.

148

Graphics / SFML 1.6 graphic bug

« on: April 08, 2010, 05:39:08 pm »

Can you narrow down to where the error is happening? Better yet, can you produce a cut-down working project that creates this issue?

Also, are you by any chance changing the OpenGL state manually? If so, are you also sure you set RenderWindow.PreserveOpenGLStates() to true?

If you can't produce a minimalist example, would you mind posting your full project (code + all dependencies)?

149

DotNet / Setting up Visual Studio 2008

« on: April 07, 2010, 09:02:26 am »

If you are on 64-bit Windows, you will have to recompile. Easiest thing to do is just rebuild the SFML .NET bindings, and your program you are using SFML in, as x86 instead of Any CPU. This way you can bypass recompiling SFML itself for the time being.

150

Graphics / Drawing just an sf::Image?

« on: April 06, 2010, 04:52:26 am »

That is what I am currently doing. The way my rendering system was already set up before using SFML kinda required it. Same goes for drawing text. I just create a single Sprite and String2D and set it up before each draw. Very simple and low overhead.