Messages

31

Graphics / Getting Angles

« on: September 15, 2008, 09:33:00 pm »

here is an article on gamasutra that describes how to collide pool balls corectly .. it might be a bit advanced .. and have abit much math in it .. but it might help you

http://www.gamasutra.com/features/20020118/vandenhuevel_01.htm

But if you are doing a pong clone you could go the ultra cheap way and just set the ricocheting angel depending on the offset from the paddles middle point

the best lesson one can learn when making games is to cheat as much as possible

32

Graphics / Re: Optimization/ particle system/ rendering mode spin-off t

« on: September 15, 2008, 09:41:45 am »

First of all, you should almost be certainly be using GL Point Sprites here and not quads.  That alone should get you massive performance increases.  Point Sprites are in OpenGL 1.2 and OpenGL ES, so it's old and safe to use.
As for z-ordering, I generally doubt you'd be able to notice or care since all the particles are the same texture, right?

i have thought about using PointSprites.. but then all my oparticles would have to be perfect squares ... plus i belive ther are a size limit to PointSprites.
the z ordering issue would appear if i started adding up regular sprites in a VBO sprites that are not particles

33

Graphics / Re: Optimization/ particle system/ rendering mode spin-off t

« on: September 14, 2008, 09:26:50 pm »

Although I haven't specifically touched particles yet.  (It's on the list though...)  My first thought would be to make a vertex buffer of every pixel in some arbitrary box representing the max size of a particle system.  This single buffer could be statically referenced in every instance of the particle system class.  Then you'd have a local index buffer with each index being a particle.  Update each index as necessary as a "lookup" into your vertex buffer, then you just have to send one index buffer.
The static vertex buffer would always be referenced from the origin, but you'd just translate the modelview based on the particle system's position before the render.

I am not entirely sure i understand you. But what i'm currently looking into is to allow every emitter to have one vertex buffer in which it will push all of it's particles(a particle is at the moment a quad with 4 vertices and texture coordinates).

Something i also would very much like to test is if there would be anything to gain from using VBOs in rendering normal sprites .. since they are only 4 vertices it seams like it could be a mayor waste of time.. a better solution might be some kind of batch class where you can add a bunch of sprites and have them added to a VBO and drawn.. but then we get to the question Z ordering ...

34

Graphics / How do I undraw text

« on: September 14, 2008, 07:43:49 pm »

Fair enough.  As I said, using non-optimal techniques at first is fine for learning, but I still like to mention stuff like this so they know it's something to think about later.
As for immediate mode rendering, I've thought about that myself I'm not sure how big of a deal that is for 2D rendering in most cases.  Display lists make sense for 3D models with tons of verts to send, but the majority of 2D rendering is tile-based so you only have 4 verts per "model."
I did a quick and admittedly non-scientific test and found no read gains to rendering tiles with display lists.  You probably loose just as much time setting a transformation before each tile then just sending the offset verts.
Although I have used display lists for certain drawables I've made that contain many verts.
Is there a reason you think SFML would benefit from display lists in tile (sprite) rendering?
As for pixel-perfect collision detection, yes I'd just make it the final collision stage if I had to.  But I can't imagine a situation where that would be needed over a poly approximation.  If you needed a super-accurate simulation for some reason, you probably wouldn't even bother with the pixel data for collision; but use some internal spacial representation.

Edit:  I guess you could do something where you chopped static elements of a map into chunks and rendered chunks as display lists, but I doubt that would get you anywhere since I seriously doubt vertex bandwidth is ever going to be a bottleneck in a reasonable situation.  In fact that approach might even hurt you due to the extra drawing it would entail.  I'd image most 2D games are almost always going to be CPU-limited unless you are doing something silly like not culling for large maps.

this could probably be a whole new thread in it's own since this discussion has severely drifted from the scope of the original question

but as for drawing. i noticed when profiling my particle system that when i had ~1000 particles in a system 50% of my CPU time was spent in the Draw function .. (you can try this yourself by downloading the particle system code(wiki) and running it through AMDs codeanalyst)the only thing that function does is first set states and texture then iterate through all particles and drawing their vertices using immediate mode. This really shows that you get a very large CPU overhead when using immediate mode. as for display lists they are only faster when working with static data. and are probably slower when working with dynamic data . I am in no way an expert in graphics/rendering techniques(I usually stay as far away as possible from that particular subject when it comes to making games) but it would definitely be worth checking out vertex arrays / Vertex Buffer Objects and the like. I have tried to learn how to use them and how to apply them to particles but i have thus far failed to make it work (mostly because the motivation isn't really there)

and as for the never ending collision question. i agree with you but i think it is important to point out that it is in fact possible it's just very hard to make it work well ( and your time is probably better spent making actual games (unless of course you are looking for a career in physics programing))

hmm if i use any more parentheses people are going to start thinking i am a lisp programmer :S

35

Graphics / How do I undraw text

« on: September 14, 2008, 06:58:52 pm »

Re: moving stuff off-screen:
If that's common in flash, I'd suspect it has automatic off-screen culling.  Otherwise, it's not a good idea.  (SFML / OpenGL don't auto-cull.)  The goal is to have checks to make sure you don't draw things off screen, not to intentionally move things off screen and draw them anyway because you can't be bothered to just not draw it.
And how is that even simpler from a coding perspective?  If you have some sort of test to move it off-screen, you already know you don't want it; so why don't you just not draw it?

Re: Collision detection:
I really, really want to know where all this (brute force) "pixel perfect collision detection is fine" stuff comes from.  Yes, you can probably get it to work on a small scale if you're only doing a few collisions, and the sprites are small, and you don't mind artificially inflating system requirements, and you're not doing other silly things to burn your CPU.
Effective and efficient collision detection is an important part of game dev.  If you want to ignore the topic to focus on learning other things with the intent to come back later, that's fine (and probably even a good idea).  But stop pretending such code laziness is ok just because the game is 2D.

Edit:  Although with some of the unbelievably-slow flash stuff I've seen, I'm not surprised if this type of thinking is out there.


Edit Edit:  Real-world example:

I'm currently developing what will become a commercial product using (slightly) modified/added-on SFML.  The following optimizations are in place:

1) Map objects arranged in small blocks using hash tables for rapid searching and access based on location.
2) Offscreen-culling based on #1.
2) Intelligent, 3-phase collision detection.  (It even appears "pixel perfect!")

If I disable those, the game drops to slide-show framerates on a computer that run the likes of Bioshock beautifully.  The game is 2D.
Stop pretending this stuff doesn't matter.

RE: RE: moving off screen
well it is all a matter of size. for your run-of-the-mill space invaders clone you do not need to worry much about culling or stuff like that. but ofcource it becomes an issue when you start making bigger stuff. and i think it would be better to start with optimising how you render before looking in to culling. SFML as of now uses immediate mode.. which in it self is horribly slow.

RE: RE: collision
I agree with you pixel perfect collision is in no way a sane approch.. your best bet for good collision would probably be convex polygon shapes wrapping the object snuggly (this is what 3d games do today). But (and this is the point im trying to make) it is possible to get pixel perfect collision if you put enough time into designing the collision engine.
If i had to implement it today (not saying that i whant to )i would probably make a system quite similar to your approch with the last step being the pixel perfect check. and it would most likely not be used by every object.. just important ones. and as a final step id check if the pixel checking algorithmn could be speed up with SIMD extensions or something like it.

36

Graphics / How do I undraw text

« on: September 14, 2008, 11:54:47 am »

but there must be a better solution, lets pretend theres a missile shot from a starship, the missile is created should be drwn and if it hits something it should disappear...
there a two problems for me now:
first of al how can i do exact collisionmanagement (without bounding boxes),
2nd: i wanna call the destructor of the missilie if it hit something

can u explain me how to do it?- thanks

Really it depends on how much "solution" you want.  A good way to do it would be to make a separate "sprite manager" (or text manager) class that would hold and organize all sprites/text.  You would be able to add or remove sprites as needed.  Then you just iterate and render all sprites in the manager each frame.
As for "exact collision management..."  I've answered this question before, but some people don't seem to like the answer: http://www.sfml-dev.org/forum/viewtopic.php?t=589
The short answer is that "pixel perfect collision detection" is a fantasy not used in any serious project.  Instead you use various approximation techniques of various complexities to achieve what appears to be "pixel-perfect."
But if you're just getting started, I'd recommend ignoring that for now since collision detection and handling is a *very* complicated topic.  Just use bounding boxes.
Also, if you want to brute-force "pixel perfect collision detection" for learning purposes, I suppose you can iterate through every pixel of 2 sprites with overlapping bounding boxes looking for alpha overlaps.  But expect this to be slow for any reasonable application.

The simplest way of solving that problem is to simply move the object off screen that is a well tested way of doing things.. especialy in flash / shockwave games

And as for pixel perfect collision detection i belive you could have fast enough pixel perfect collision detection for a 2d game.. but it will take a lot of work.. the simplest solution is to use bounding boxes and try to keep them as small as possible. this will be enough for most simple games

37

Graphics / sf::WindowSettings access violation

« on: September 10, 2008, 05:29:10 pm »

what kind of graphics card do you use ? ... he does invoke an ARB function .. which could possibly be NULL since i belive it depends on your graphics driver ...

38

Graphics / Beginners Quest

« on: September 09, 2008, 04:51:10 pm »

is there some time when no events come in? otherwise the 2nd while loop could never be left, or is there any logical mistake in my head?

Code: [Select]


    Event Event;
    while (App.GetEvent(Event))
    {

    }
    App.Draw(Polygon);
    App.Display();


if there are no events (or all events that occurred this frame have been processed) App.GetEvent(Event) will return false meaning the loop will exit. which will execute your draw calls.

and another problem: now i want the polygon to move when the mouse is moved is , what is wrong with this:

if (Event.Type == Event.MouseMoved)
{
Polygon.Move( Event.MouseMove.X,Event.MouseMove.Y);
}

Polygon.Move uses relative positions while Event.MouseMove.X is an absolute position try using Polygon.SetPosition insteed (it works with absolute positions)[/quote]

39

SFML projects / Particles!

« on: September 04, 2008, 10:10:58 am »

Wow, funny enough I just did this exact same thing about a month ago.
I based it off of Ogre3D's system as well.

I wrote Squirrel bindings for mine so you could have scripts like:


Particle systems are too much fun.
I've spent so many hours just staring at cool particle effects.

P.S: I wish your screenshots would load.  

Cool in the version i use i have made a particle definition language where you can give initial params to the system (this also quite heavily based on how ogre does it ). But i to have had plans to use squirrel for adding scriptable emitters/affectors

hmm the imagehost i used must have deleted the pictures.. il see if i can find another one and upload some pics  

40

Graphics / Draw Missing!?

« on: September 01, 2008, 10:56:25 am »

i still cant figure out how to be able to use std::strings in GetModuleFileName() or convert TCHARS to std::strings

These are WIN32 API function i guess? .. you should look them up on MSDN or something and i believe there might be another win32 function which can convert TCHAR to a char*

41

General discussions / SFML 1.3 and OS X

« on: August 22, 2008, 10:29:01 am »

excellent .. now i got something to entertain myself with during the weekend

42

SFML projects / Particles!

« on: August 17, 2008, 09:20:30 pm »

I finally got it working, nice job!

I used to get a stack overflow error. The reason was that the path to the font was wrong.

ah yes, the code assumes you have the "bin" folder as working directory

43

General discussions / [Solved] 100% CPU - no matter what code I use.

« on: August 11, 2008, 10:19:06 am »

Code: [Select]


int main()
{
    while(1) { }
    return 0;
}


this code will also make your CPU spike at 100% (if you have a single core)

44

Graphics / Draw Missing!?

« on: August 10, 2008, 10:18:58 am »

how would i get the path of where the exe is? that way i can load images and music even if the name of the folders change

if you have a folder structure like this:

Code: [Select]


game_folder
| - exe
| - data_folder
     | - img.png

you could in your code write img.LoadFromFile("data_folder/img.png");

This will work on most operating systems(at least windows, linux and mac OS) and is how most people do it

45

SFML projects / Particles!

« on: August 10, 2008, 09:54:59 am »

zlib/libpng so it's the same as SFML

EDIT: This is now also stated in the wiki page