Messages

226

General / No executable ?

« on: April 15, 2010, 06:36:34 pm »

It should be in your bin/debug or bin/release folder

227

General / Anyone need automatisation for putting sprites in 1 file?

« on: April 15, 2010, 03:25:28 pm »

Sprite Packing
===================
Image packer:
http://homepage.ntlworld.com/config/imagepacker/

Java webstart version for win/linux/mac os:
http://slick.cokeandcode.com/demos/packer.jnlp


Fonts
===================
Angel BMF:
http://www.angelcode.com/products/bmfont/

Java webstart version for win/linux/mac os:
http://slick.cokeandcode.com/demos/hiero.jnlp


Particles
====================
PEDIGREE

Java webstart version for win/linux/mac os:
http://slick.cokeandcode.com/demos/pedigree.jnlp

228

Graphics / Working with LoadFromPixels

« on: April 15, 2010, 02:31:29 am »

Well, as for wasting your time--quake 3 is a free and fast engine, I don't know what rendering it in 2D is for...

Drawing the image isn't the problem, it's rendering fast enough to build up a stack. SMFL was built for managing many images like sprites, but if you are not going to take advantage of it you are basically using it like a video player.

You seem pretty adamant on using SFML this way so the only other advice I have is to write a shader to do the rendering.

229

Graphics / Working with LoadFromPixels

« on: April 15, 2010, 12:43:59 am »

What's your blitting algorithm?

When you are in 3D the entire screen is usually changing every frame.

It seems like the renderer is the bottleneck, not the blitting.

230

Graphics / Working with LoadFromPixels

« on: April 14, 2010, 11:52:17 pm »

I'd have to see a demo before I can really comment.

Off the top of my head you can prerender a lot of that as sprites and use a speedy raycaster. Pngs and blendmodes can do lighting effects, or even faster--you can bake most of it straight in with prepainting your images.

True 3D rendering should be reserved for anything that is not a box or primitive that can be faked--which is just about everything--especially with shaders.

231

Graphics / Working with LoadFromPixels

« on: April 14, 2010, 11:16:25 pm »

Hi, I'm curious, are you blitting your entire screen as a 640x480 image?

232

General discussions / Benchmark : SDL vs SFML

« on: April 14, 2010, 07:20:53 pm »

As for the benefits, I was rather thinking of the benefits of using XNA, not of making a port for Xbox 360, even if both are linked. So.. ok as far as the benefits of a Xbox 360 port, even if I don't know whether it's achievable.

Yeah, I prefer OpenGL/C++ over DirextX and C#, but I know XNA is integrated with Visual Studio.NET so I don't know if that helps.

But as for the benefit of XNA is summed up as:

"XNA Indie Games

Xbox 360 games written in XNA Game Studio can be submitted to the Creators Club community, for which premium membership is required, this costs US$49 for 4 months or US$99/year. All games submitted to the community are subjected to peer review by other creators. If the game passes review then it is listed on Xbox Live Marketplace. Creators can set a price of 80, 240 or 400 points for their game. The creator is paid 70% of the total revenue from their game sales as a baseline."

233

Feature requests / Sending 3D Vector to Sprite's Position

« on: April 14, 2010, 07:03:58 pm »

I can see why depth sorting would not be enabled for sprites because of how the rendering is optimized for 2D.

What were you planning on using for collision, 'cubes' (or pseudo cubes)?

234

General discussions / Benchmark : SDL vs SFML

« on: April 14, 2010, 06:46:44 pm »

I thought  an XNA port of SFML would be cool.

I don't think "cool" is good reason for Laurent to implement a XNA backend  :lol: . Moreover it'd be a huge work, it's not portable, and benefits still need to be demonstrated. Thus Laurent might keep using OpenGL .

I wasn't proposing Laurent make an XNA backend, but as for the benefits--XNA seems to be the most open and easy way to get a game onto the xbox360.

Xbox Live! has a large 2D fanbase where many people actually still purchase 2D games (even retro ones). PSN's markeshare doesn't even compare. You have to go to handhelds for the next biggest market and good luck breaking into that.

http://www.gamasutra.com/view/news/28075/InDepth_Xbox_Live_Arcade_Sales_Analysis_March_2010.php

235

General discussions / Which language to use?

« on: April 14, 2010, 04:43:31 pm »

Asking what language to program SFML in is kinda like moving to Japan and asking what language you should speak.

Yeah, you can speak whatever you want, but depending on who you want to understand and help you is important. It depends on your background and what you want to do.

236

General discussions / Visual Studio 2010

« on: April 14, 2010, 04:24:37 pm »

but isn't an array essentially an indexed list of pointers?

No. Actually, arrays are independent of pointers. The reason why those two concepts are often confused is that there exists an implicit conversion from an array to a pointer to the first element of the array. That's why you can write

Code: [Select]

T array[size];
T* ptr = array;

And also, aren't arrays much faster than vectors, especially for linear iterations?

Static, stack-based arrays are faster, but they're not flexible because the size must be known at compile time and cannot change. For static arrays, the class std::tr1::array is very useful, as it doesn't have the problems of C arrays like out-of-range accesses, non-copyability or the lack of a generic interface.

In practice, you often need dynamically allocated arrays and other data structures. One way is to use new[] and delete[], but in many cases, there are better alternatives. Here, the STL containers (std::vector is one of them) come into play. Some of their advantages are:

• Automatic memory management. You needn't call delete[] nor worry about memory leaks. Your code becomes exception-safe.
• A lot of useful functions (e.g. to erase/insert elements or to get the size). When you use new[], you have to store the number of elements separately and you need tedious loops when inserting an element.
• Uniform interface inside the STL. When you decide to switch from a linear vector to a doubly linked list, just typedef the container type and change one identifier at one place in the code. Imagine the equivalent refactoring using new[] and delete[].
• Support for debugging. The most STL implementations perform runtime checks in debug mode, this means errors like invalid indices are immediately detected.
• Zero abstraction overhead. Thanks to this C++ philosophy, the STL containers are not slower than manually using new[] and delete[] for the very most cases. Why should they be? They use the same functionality in a generic, encapsulated design (classes and templates). The STL may even be faster, since you can 1. choose the best-fitting data structure, 2. provide specific allocator strategies, 3. make use of optimizations like pre-allocations at std::vector.

Well, I figured since I'm using C++ I might as well try to get as low as I can for optimization so I'm currently using arrays and pointers that are manually deleted.

When I have my first tool done that handles thousands of images, I'll convert a copy to std::vector and compare the result of the speeds.

237

General discussions / Which language to use?

« on: April 14, 2010, 03:44:09 pm »

Just use C++ and keep it simple. You don't have to use pointers or anything complex. If you are just making a simple game you can hardcode most things (and that can even make it faster).

The real answer is that you need to make your game simple until you become a better programmer.

IE, make a shmup--there are a bunch of people here making those too.

238

General discussions / Benchmark : SDL vs SFML

« on: April 14, 2010, 03:31:01 pm »

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.

Would be nice to see some benchmarks of XNA vs SFML 2

So are you giving up on XNA?

I thought  an XNA port of SFML would be cool.

239

System / Using sf::Thread to display Animations?

« on: April 13, 2010, 11:26:44 pm »

But... i mean, i think u r on the wrong way, meanin that the fact that if you have sync the event manager with the frame rate, that would mean, that in a low frame rate, you will have less response from the event manager.

PD. Sorry my bad english, just not from english speakin countrys.

There are input buffers that can only hold so much. If the sprite is barely moving, it doesn't matter how many times you tell it to move/do something different.

Otherwise all of a sudden your sprites would start teleporting and everything would be all jerky.

240

System / Using sf::Thread to display Animations?

« on: April 13, 2010, 09:20:25 pm »

I don't think this is correct.

Most games have events/input synched with the frame rate so if time slows down you can keep up with the game. If you had it out of synch it would be all weird. That would create input lags like in online play and would be a pain to manage.