Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


ultramailman

Member Since 13 Oct 2012
Offline Last Active Aug 09 2015 08:27 PM

#5119985 Advice to lock frame rate

Posted by ultramailman on 30 December 2013 - 01:47 AM


I think I'm doing pretty much the same

 

I think yours and eduardo's are different. Your algo will update, render and wait some time as filler to make it 16 millisec per frame (1 update per render with waiting), while eduardo's will update multiple times until 16 millisecs or more has passed before rendering (one or more updates per render without waiting).

 

For more information, look at the article Fix your timestep! on the internet, it talks about various kinds of game loops.




#5119958 Advice to lock frame rate

Posted by ultramailman on 29 December 2013 - 10:33 PM

On any platform you could control the rate of update and render with this simple algorithm

...

Can somebody explain why this is downvoted?




#5115208 Did you know you can define functions like that in C?

Posted by ultramailman on 07 December 2013 - 03:14 PM

Yeah, it would be cool to be able to do closures in c. When i saw that function typedef (not the function pointer typedef), it almost looked like one could declare a variable of a function type, and assign some value to it. Then I recall variables need a size, and have no answer to that.

 

So in c, other than declaring a variable as a pointer to a function type, there doesn't seem to be much use for a function type (it does look nice though, I like function_type * more than function_type_ptr).

 

edit:

Seems like it can be used to replace a forward declaration too, like this

#include <stdio.h>
typedef int main_func_t(void);
main_func_t test_func;
int main(void) {
    main_func_t * test_func2 = &test_func;
    test_func();
    (*test_func2)();
    return 0;
}
int test_func(void){
    puts("hello");
    return 0;
}



#5115048 Did you know you can define functions like that in C?

Posted by ultramailman on 07 December 2013 - 12:39 AM

I've typedefed function pointers before, but never a function type. What can one do with the type of a function?




#5111485 Is this thread safe?

Posted by ultramailman on 23 November 2013 - 01:59 PM

The new loop looks like this now:

next = (reader_seq + 1) % DATA_SIZE;
do __sync_synchronize();
while(next == writer_seq);
reader_seq = next;

But now I can see atomics are much simpler to work with.

 

@Noctumus

Sounds like atomics were what you needed.

 

@Dynamo_Maestro

Well, I knew volatile wasn't anything to help with thread safety (in c). In c it's only for disabling optimizations for a variable, and keeping the order of writes between two volatile variables (in the code). What I didn't know was that the CPU itself can execute writes out of order, even if the code has them in order. But I've rid of the code of all volatile now, it seems like what I needed was either atomics or memory barriers.

 

Writing thread safe code without mutex is hard, I just realized. There can be a deadlock that happens with a very rarely. So if I don't know what I'm doing, I can only think it is thread safe until I encounter a deadlock. Even now, I'm not sure if just that one memory barrier in both loops is all I need.

 

edit: Testing on gnu/linux showed that deadlocks still happen with this placement of memory barrier.

 

edit 2:

The polling loop now looks like this:

next = (reader_seq + 1) % DATA_SIZE;
unsigned tmp;
do{
__sync_synchronize();
tmp = writer_seq;
__sync_synchronize();
}while(next == tmp);
reader_seq = next;

edit 3:

The one in edit 2 worked, but it can be reduced to only one barrier in the loop:

next = (reader_seq + 1) % DATA_SIZE;
do __sync_synchronize(); // this barrier makes sure writer_seq is up-to-date before checking against "next"
while(next == writer_seq);
 
__sync_synchronize(); // this barrier makes sure reader_seq is updated only after the polling loop
reader_seq = next;



#5110651 Looking for criticism for my game, harsh is okay to

Posted by ultramailman on 19 November 2013 - 07:39 PM

The intro screen and the moving background made me a little dizzy, but I think overall it was ok. It was messing up the music I was listening to (music became noisy and hard to hear).




#5109030 Having problems with collision detection in 2d platformer

Posted by ultramailman on 13 November 2013 - 01:11 PM


draw_sprite(buffer, ring_images[rings[n]->curframe], rings[n]->x - mapxoff, rings[n]->y-mapyoff);

 

You are drawing using object position minus the camera position. That's good. But for collision detection, the real position should be used, so simply remove mapxoff and mapyoff from your collision detection, because collision shouldn't have anything to do with the camera. (what kamen said)




#5108986 Having problems with collision detection in 2d platformer

Posted by ultramailman on 13 November 2013 - 10:14 AM


mapxoff/mapyoff are my camera variables. They move along with my player and yes the position of the rings depend on them. If they are not in range of my camera, they don't render, heres the code in case:

 

 

kamen is right, positions of objects should not depend on the camera. A good way to do what you want (render only what's in the camera) is simply use a rectangle for the camera. Then if objects are in the camera rectangle, render them. When rendering, use object position - camera position.




#5108905 Having problems with collision detection in 2d platformer

Posted by ultramailman on 13 November 2013 - 01:33 AM

What's mapxoff and mapyoff? Can they change? Do the position of the rings depend on them? Also, there's a shorter way to write your "inside" function.




#5107829 Such code. Wow. So Shibe. Very doge.

Posted by ultramailman on 08 November 2013 - 02:35 AM

This reminds me of lolcode.




#5103412 Unmaintainable code

Posted by ultramailman on 22 October 2013 - 10:21 AM

The code is hard to read. But I think it's quite an achievement if it compiles and the game plays as expected.




#5100850 Logical sequence of making games to learn

Posted by ultramailman on 12 October 2013 - 01:09 PM

I think you just have to post your code in this forum (the Beginners forum) and ask for a code review.




#5100842 Logical sequence of making games to learn

Posted by ultramailman on 12 October 2013 - 12:34 PM

This? http://www.gamedev.net/page/resources/_/technical/game-programming/your-first-step-to-game-development-starts-here-r2976




#5097637 Object tries to eat potatoeses

Posted by ultramailman on 29 September 2013 - 12:22 PM

I don't think it's good to use malloc with objects in c++. If you want to pre-allocate a fixed chunk of memory, consider using new[] POD objects.




#5087962 collisions? n^2 checks?

Posted by ultramailman on 21 August 2013 - 07:13 PM

A better way is to split your map into smaller pieces, and do the collision checks of one object against every other object that is in the same piece of map. For example, a 2d rectangular map can be split into a grid.






PARTNERS