Messages

31

Graphics / My problem with frame time and it's blurriness...

« on: October 10, 2008, 07:08:23 am »

That's what I figured I would have to do, but that would mean widening the speed gap between systems.

Wut?  You're worried about the speed of rounding floats?  If that made an "extreme difference" in FPS you're almost certainly doing something wrong or have some off-the-wall not-real-world corner case for your test.  And deriving a new drawable won't accomplish anything.  You still have to round at some point if you want objects on a whole number position.

32

Graphics / My problem with frame time and it's blurriness...

« on: October 09, 2008, 04:06:02 pm »

What's hard about calculating a camera pos as a float and then rounding to an int before setting the actual position?

Edit:  Also, that "blur" can make things in motion look smoother.  You probably only notice it when you stop moving.  So you might consider not rounding while the screen is scrolling.  (See what looks better to you)

33

Feature requests / Vectors and scalar operators

« on: October 09, 2008, 12:05:57 am »

I'd also imagine the intersection of people who would find implementing a DotProduct function difficult and people who would know what to do with a dot product to be very small set.

I know how to write cross-platform image loading and displaying, but instead, i use SFML

I think, not going crazy, but just having some something funcs would be nice.

I know how to do a lot of thing I don't plan on doing because someone else already has...

34

Graphics / does it makes sense to have a lot sprites of the same image?

« on: October 08, 2008, 11:09:39 pm »

having only one sprite that represents all the "tiles" you see on the screen won't increase the performance of your program one bit. you still have to write the same amount of if()'s . ok, it decreases memory usage a bit, but that doesn't matter anyways since sprites themselfs are not big at all. calling methods from different objects doesn't make a single performance difference, look up wikipedia or something how c++ is translated into machine code.

also only having one sprite completely messes up the most design patterns. you should keep the idea of object oriented design (you know, you try to program stuff like you think about it in real life). when you see 20 balls on the ground, do you see 20 different balls or just the same ball that is rendered 20 times?

zoning is better. split up your map into different zones. every zone knows which objects are currently in it. in addition, every zone knows which zone is next to it. it makes sure that objects are correctly translatet between zones.

you just have to make sure that only the zone which the player can currently see is calculated.

of course thats just the standard idea. if you try to program a more complex game or something you'll end up having to adapt this whole idea a lot.

This is all correct, but that doesn't change the fact that there are certainly cases when you don't want a million sprites of the same image.
There's always a trade-off between CPU and memory.  Usually several sprites is not a problem, but there is certainly an extreme case where the size of a sprite will become significant.
And as for "correct OOP," good game programmers know when OOP paradigms are good for code maintainability and when it's time to throw them out the window because the performance trade-off is too much.  If games were all about making the most beautiful code possible, we wouldn't even be using C++.  Sometimes you optimize the hell out of a critical loop to the point where the code is nearly incomprehensible without an essay in comments, but sometimes that's what you need to do.  Sometimes you declare and calculate on variables in weird orders to optimize for a console's pipelining.  Sometimes it's really, really ugly code.  But it's fast, and ultimately that's what matters.  Also, you can always (and should) comment stuff like this.

35

Feature requests / Vectors and scalar operators

« on: October 08, 2008, 10:59:18 pm »

I think part of the idea is to keep it simple so it's easily approachable.  I mean, look at some of the questions on this forum and ask yourself how many people would be intimidated by having to use a math construct with a bunch of functions they've never heard of.

36

Feature requests / Color Palette Manipulation

« on: October 08, 2008, 10:51:11 pm »

Once the image is loaded by SOIL, it's stored locally and handed off to OpenGL's internal format.  The original image format is irrelevant.  You may think of what you're trying to do as optimization, but it's not.  In the way-back days, graphics were displayed with pallets that could be edited.  Now they're not.  So you'd literally have to iterate through the pixels looking for ones to swap out.  A shader would be the a way to do this, but perhaps not the best one for speed and compatibility purposes...
Now if you're doing this as a feature that you actually want, the way to do it would be (probably) to create multiple images at load time.  Load the original, then in C++ code, make whatever mods you want and save each mod as a new image.

37

Graphics / does it makes sense to have a lot sprites of the same image?

« on: October 02, 2008, 07:18:56 pm »

For just messing around, you're not going to run into issues with tons of sprites.
But if you have a large, scrollable map, this could become a problem.  Even with off-screen culling, you could still end up way too many sprites.  In that case, just have one sprite per image and have some loop where you change the position then draw for each on-screen tile of that image.
Another (possibly more efficient) method is to make your own class that directly uses OpenGL to draw the same image over and over at different positions.

38

General / bouncing

« on: September 28, 2008, 07:02:01 pm »

is there any possibilty that a certain function cannot be called in 2 following frames, i think about a bool bounce

when the ball bounced its 1
if bounce == 1, the function cannot be called

and bounce = 0 again

does it sound like a good plan?

_____________________________________________________________

i hate collisions

Something like that would work, but before you start making new variables and making your code more complicated, look at what you already have.  Is there something in the data you already have (position, speed, dir, etc.) that would tell you if you've already bounced and shouldn't do it again?

39

General / bouncing

« on: September 28, 2008, 06:34:16 pm »

sry quasius, ill tell u a bit more:

my vector dir can be (-1|-1) (1|-1) (-1|1) or (1|1)

i do not have to normalize the vector because only 45° appear

i think my problem is following:

let´s take the top of my window: the ball reaches a negative y-coord and then there is the order: bounce() which changes the y-value of dir , and now it seems that the ball does not reach a positive y-coord in the next frame and the ball bounces so long until it reaches a positive y-coord again

i hope my thoughts are not too far from truth, if u have a solution for this , pls tell me

thanks your raven

That sounds like it could be a problem.  If that's the case, you need to test something else before calling bounce.  (Use &&)

40

General / bouncing

« on: September 28, 2008, 04:16:32 pm »

What do you think is special about when dir.y == 1 that's making you test against that?

Edit:  Also, I hope you are normalizing dir or you're going to get some weird movement calculations.

41

Window / A time question

« on: September 26, 2008, 08:09:04 pm »

Ok, here is most of my code (left out the unnecessary code, collision checking etc.), why isen't this fps-independent?

From a quick look, probably because you're not multiplying all relevant variables by the frame time.  You have the right idea of calculating movement variables, but you missed one.  Look again...  :wink:

42

General / some day u´ll hate me =)

« on: September 26, 2008, 08:04:56 pm »

Sorry...  :p  Ok, real answer:

Where you're setting the keypress bools is not in your main loop.  You need to move them there.  Think about how your program is flowing.  Also, did you try using the debugger?

43

General / Re: some day u´ll hate me =)

« on: September 26, 2008, 08:03:47 pm »

so, why doesnt this code not work, i think about the movement - Input

I'm not sure, but just dividing by 0 or something should be a quick fix.

44

Feature requests / Vectors and scalar operators

« on: September 26, 2008, 04:57:54 pm »

Believe me, implementing a dot product or even more is not difficult. It might be a good practice

I'd also imagine the intersection of people who would find implementing a DotProduct function difficult and people who would know what to do with a dot product to be very small set.

45

Feature requests / Vectors and scalar operators

« on: September 26, 2008, 01:47:38 am »

You're probably right.