   My first game :)
  Ive just finished my first game, or, finished is the wrong word, ive finished version 0.1, its a playable breakout clone game.and i want you guys to try it i know the game sucks, but im sending the code to, so please give feedback on my code, what i can improve and so on, thanks allot.http://www.geocities.com/muppi_mupp/index.html[edited by - Mupp on February 16, 2004 5:41:36 AM][edited by - Mupp on February 16, 2004 8:35:27 AM]
  I''d say that you''ve done a pretty good job for a first game. I did have a problem with it though. I don''t know why but the screen is stretched out on my display.Its the right size in the verticle but horizontally it looks stretched out to 1280 (640*2). I don''t think this is a problem with your code though. I''ve had this happen with other things that run at 640x480. Probably my LCD that causes it (Strangely 1280x1024 is its native res).Also in the area where you initialize SDL video subsystem your are explicitly using software surfaces. Why not try initializing with hardware surfaces (SDL_HWSURFACE) first and then fall back to software if it doens''t work.  SDL_Surface *screen;screen = SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE | SDL_FULLSCREEN);if (screen == NULL){    screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE | SDL_FULLSCREEN);    if (screen == NULL)    {   exit(1);    }}I''m not all that familiar with SDL but I would assume that hardware surfaces would be faster than software.Also you may want to comment your code a little more frequently. I find your coding style to be clear and easy to follow but comments are always nice to have especially for yourself when you go back to some old code six months from now.Great job, keep it up.And you can make a link with regular HTML code. Here I made one for you:Game & CodeYou can press edit on this reply to see how I did that. ;  <a href="url">text</a>. ;  reaptide thanks for those words i tried changing to hwsurface, and i also had to add doublebuf, dont know why, but without it, the screen kinda, "pumped" between being painted and not being painted really fast, and everything goes slower with hwsurface, i mean, the balls speed and the paddles speed  ;  Hmm, oh well I was just taking a guess with the hardware surfaces. I come from a Direct Draw background where you usually tried to create all your surfaces in video memory.Keep experimenting and trying out new techniques. Learning is half the fun of programming. ;  I just got a really strange problem changing to SDL_HWSURFACE,since my ball moves slower, i changed its speed, and when i change its speed, it doesnt detect collisions on "the way down" so collisions that hit the block on their top, what might be wrong?ive checked my detection code and i cant find anything wrong  it works if i use speed 1, but then the ball moves slowedit:if i change the speed to even more, it dont detect on the way up either, is it moving to fast for my detection code to make it? how can i change this so it will be fast enough?   [edited by - Mupp on February 16, 2004 4:38:15 AM];  I''m thinking that maybe hardware surfaces don''t work at all like I thought they would. If software surfaces are working better then maybe is would be best to stick with them rather than hardware surfaces.I can''t find any info in the SDL Docs describing the difference between the two flags other than the short blurbs on this page. ;quote:Original post by Mupp  I just got a really strange problem changing to SDL_HWSURFACE,since my ball moves slower, i changed its speed, and when i change its speed, it doesnt detect collisions on "the way down" so collisions that hit the block on their top, what might be wrong?ive checked my detection code and i cant find anything wrong  it works if i use speed 1, but then the ball moves slowedit:if i change the speed to even more, it dont detect on the way up either, is it moving to fast for my detection code to make it? how can i change this so it will be fast enough?   [edited by - Mupp on February 16, 2004 4:38:15 AM]Are you using a method to calculate the movement of the ball that isn''t dependant on the frame rate? I''m sorry but I didn''t save a copy of your source to take a look and the Geocities site isn''t working right now.If you aren''t using frame rate independant movement you might want to take a look at this article.Well then, I''m off to bed. Its entirely too early to be up at this time in the morning. Good luck with your game. ;  dont think i am im just checking, every time my game loop loops, it checks, if the balls xposition and yposition compared to blocks positions, walls and paddle''s position, it still responds to the paddle ;  With your movement and collision code based off the game''s frame rate I''d imagine you would experience some rather erratic behavior if the frame rate is different than what you need. You could always use SDL_GetTicks() to implement a simple frame limiter. Only draw the next frame after x amount of time has passed. For example, freezing your drawing for 33 milliseconds every frame would give you a steady 30 frame per second. // Example Frame Rate LimiterUint32 TickCount= 0;Uint32 LastTickCount = 0;// Get the current timeTickCount = SDL_GetTicks();// Only loop if 33 milliseconds have passedif ((TickCount - LastTickCount) == 33){    UpdateGame();    DrawScreen();    SwapBuffers();}// Get the time after frame drawingLastTickCount = SDL_GetTicks();Of course a frame rate limiter is not the best solution (Though its perfectly acceptable solution). I''ve included a link to an article in my post above that explains a better way to handle variable frame rates.Alright I''m going to bed for real now. Damn caffee keeping me up all night. 