Messages

46

General / Help *lol*

« on: September 25, 2008, 10:38:23 pm »

as far as i know

new and delete are for dynamic memory;

im sorry bur i dont have any clue how i should use it in my class

when i create a bat

bat x;;
do i need to add some code concerning destruction?

and when i creat it by pointer?

bat *x = new bat;
do i have do add something like

~bat(){ x = NULL);  ?

Whenever you use new, you have to use delete at some point to free that memory.  And yes, that's for dynamic memory allocated at run time (what you're calling "create by pointer.")  If you just declare variables without new, you don't need to call delete.

47

General / Help *lol*

« on: September 25, 2008, 09:03:07 pm »

what should the funtion ~bat() look like ? somehow i should set the memory free how do i do that?

You need to delete any objects you new'd, or you get a memory leak.  If that doesn't make sense, google "c++ new delete."

48

Feature requests / Vectors and scalar operators

« on: September 25, 2008, 02:31:18 am »

Only normalize is missing (really), and I don't know why you'd need those in SFML.

No, others are missing as well.  Including at least dot and cross products.  And you'd need those if you're using the vector classes to do useful maths.  Stuff other then just using them to pass parameters around.
The needed functions are not hard to add.  The only reason I'd see not adding them would be to keep SFML "simple" to not scare off the "omg numbers!" people (which I could understand), but that's Laurent's call.
My personal thought would tend to be if your going to ship vector classes with a library, they should handle such things.

49

Graphics / SetBackgroundColor in SVN version

« on: September 23, 2008, 04:30:33 pm »

Perfect..  now is better with clear.  

but it appears as a Fill function rater than clear. :roll:

for me is Ok, good work, byebye

Thanks  

That's exactly how openGL handles it.  You set a "clear color" (formerly called BG color by SFML) and when you flip the buffers, the clean buffer comes in filled with the clear color.

50

Window / A time question

« on: September 19, 2008, 12:25:47 am »

I doubt he is running at ~800 Hz. :?

I can easily get 1500+ FPS on my machine in  my engine if not much is going on.

51

Window / Re: A time question

« on: September 15, 2008, 11:51:45 pm »

Hi, using the GetFrameTime() method correctly the hero in my game should move and jump the same no matter the FPS right? Right now he jumps higher in release mode than in debug mode. I'm suppose to use GetFrameTime() for every new calculation of the x- and y-positions of my hero right?

Haven't used time before as you can see

If you're getting different action speeds based on FPS, you're doing something wrong.
Basically, every game action should have a "speed" in some reasonable units.  In the case of your hero, it might be in pixels per second.
Then each frame you'd simply multiply his speed times the number of seconds for that frame.  Make sense?

52

Graphics / Getting Angles

« on: September 15, 2008, 10:15:10 pm »

There's no "function" for what you want to do.  What you're working with is collision detection and handling which is an advanced topic.  But you just said you didn't want "expert" posts.  You need to make up your mind.
If you're expecting someone to post a few lines of code to solve your problem, it's just not going to happen.
You have a few choices here:

1) Just use a bounding box and deflect based on offset from the center of the paddle or something (as previously suggested).  It won't look awesome, but it's simple and good for learning.  You could also just draw the paddle as a sharp box without rounded corners and then it would look correct too.

2)  Mess around with "pixel perfect" stuff and try and fake it.  I see no point in going down this road since doing an iterative pixel alpha compare will only give you a yes/no on collision with no other useful information, such as a penetration vector (which is what you need in this case).  By the time you got that working, you'll be very close to implementing correct collision detection anyway.
This is just an inherent problem with this type of collision detection.  You get nothing but a yes/no out of it.

3)  Do it "right."  This is not necessarily the best option if you are just trying to make a game and want to avoid advanced topics.  If that's the case, go for option #1.
The correct way involves breaking your collision volume up into shape primitives.  (For a rounded paddle, probably a box and 2 circles on the ends.)  Then you do separate collision testing functions for each possible primitive interaction (probably just sphere-to-box and sphere-to-sphere in your case.)
In those functions, you'll be able to calculate exact overlaps and get other useful information.  (For example the shortest path back out of a collided state which could be used for figuring out a "bounce angle.")
Also, if you were treating the ends of the paddles as circles and not pixel arrays, the information in that gamasutra article would probably be far more relevant.  (Although I haven't actually read it.)

Let me know what you want to do and I can try to help you.

53

SFML website / Peerguardian block SFML site

« on: September 15, 2008, 07:42:53 pm »

SFML is a mighty tool for pirates, apparently.

54

Graphics / How do I undraw text

« on: September 15, 2008, 04:57:46 pm »

ok now for a beginner as far as i have understood, i should not move things out of screen, or should i just not draw them outta screen?

and when i should not move them out of screen, what should i do then and please no more experts discussions

If the only time you don't want to draw something is when it's offscreen and you only have a few objects (not a large map, for example), just drawing off-screen should be ok.
If you are not drawing for other reasons such as detonation or whatever, just don't draw it.  You already have a test to know when you need to draw and not, so there's no reason to move it way off-screen when you can just not draw it.

55

General / Implement Collision Detection

« on: September 15, 2008, 03:51:44 am »

Just an update on this approach,

With 20 objects with pixel perfect collision as implemented above in a debug build of Flash it takes up to 2 milliseconds to test the collisions (out of a total of 16-20 millseconds per frame, with Flash locked at 24 frames per second anyways).

That doesn't really mean anything without your machine specs.

56

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

« on: September 15, 2008, 03:48:53 am »

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 ...

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?

57

Graphics / Optimization/ particle system/ rendering mode spin-off thred

« on: September 14, 2008, 08:06:46 pm »

This has almost nothing to do with the thread (http://www.sfml-dev.org/forum/viewtopic.php?t=626) it came from anymore; but it's still interesting so...

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 Smile

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 Smile. 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 Smile (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 Smile ( 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

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.

58

Graphics / How do I undraw text

« on: September 14, 2008, 07:12:32 pm »

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.

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.

59

Graphics / How do I undraw text

« on: September 14, 2008, 02:21:20 pm »

One thing I meant to say in my original post...

The "sprite manager" was a high-powered solution suggestion.  If you are going for something simpler, you were actually on the right track.  Each frame, you'd either need to do some test to see if it should is draw.  Something like...

Code: [Select]


if (missile.IsOnScreen())
    missile.Draw();


Or just set a bool flag as you were doing when the missile is destroyed/offscreen/detonated/whatever.  Then check that each frame.  Then when the missile sprite is recycled, just re-enable it.

60

Graphics / How do I undraw text

« on: September 14, 2008, 02:05:29 pm »

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

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.