Space Invaders Tutorial

Started by thaaks, April 18, 2006, 03:33:47 PM

Previous topic - Next topic

Big C.

sry tommy... one more pic... I got this after i was killed by the aliens and i restart the game with space... this pic is repeatable...

but i've no hint for u why  ???

Big C.

[attachment deleted by admin]

thaaks

Damned! That was the bug I thought that was fixed...

Sometimes it happens that although there is still one alien left the aliencounter in UpdateAliens() finds zero aliens and so a bunch of new aliens is created for the next level. And this single alien somehow survives...

I even delete all aliens in a PSub iterating over the Aliens() list when I start the next level...

Hmm, beats me.

Will investigate...

thaaks

Still searching for the bug.
It does not happen for bullets so I assume it's somewhere in my alien code.

If I shoot the "last but one" alien my UpdateAliens() method is convinced that there is no alien left anymore...
so either my UpdateAliens() code does something bad or the way I destroy dead aliens.

I will give it another try tonight to find the buggy code...

kevin

#33
 You have to be careful with flushing a list within a For/Next, as it's possible for the current link to be stepped over. So a while structure is probably a better solution for fall back compatibly (PB1.59)


function DestroyAllAliens()
ResetList Aliens()
While EndofList(aliens())=false
    DestroyAlien(Aliens())
                    StepList Aliens()
endwhile
EndFunction


thaaks

Is this a general recommendation?
I would change the sample code and the tutorial to use the while loop and give some explanation.

But I got the impression that the "For Each Next" loop is the proper way to deal with native type linked lists. And you do use and recommend it in your linked list/sprite hit game framework too (http://www.underwaredesign.com/forums/index.php?topic=2259.0)...

And of course it's much simpler and more user friendly than the manual link list control...

So: What to use? "For Each Next" or "While with manual list control" as mentioned in your other thread http://www.underwaredesign.com/forums/index.php?topic=2273.0?

Currently the tutorial assumes a PB version 1.63...

Cheers,
Tommy

kevin

#35
     
QuoteBut I got the impression that the "For Each Next" loop is the proper way to deal with native type linked lists. And you do use and recommend it in your linked list/sprite hit game framework too (http://www.underwaredesign.com/forums/index.php?topic=2259.0)...

        That example was merely to demonstrate that you don't need to search for sprites upon collisions, you can use a reverse look ups.     In  terms of maintaining a list,  If you look around the forums you'll see there's any number of ways to creating them.   From Cell links, UDT pointers, etc etc.   Take your pick.         

        The ForEach/Next behavior is only noticeable in your example because of the how the program is structured.   But that I mean, the code relies upon the all objects being reclaimed within the DeleteAllAliens(), DeleteAllBullets().    Those functions could just as easily flip the state of the objects (to DEAD and release the sprite) and allow them to be freed during the next frames of the games refresh (since they'll be at the end of the list).

         Or it could collect garage during main.  Which removes the potential step over problem from the update functions.   

         
             Repeat
                     UpdateAliens()
                     UpdateBullets()
                     UpdatePlayer()             
                     RenderScene()
                     CollectGarbage()
             until GameState=GameOver
         
   

         or...or.... etc

         It doesn't fuss me what approach is used really.  As long as i don't have to give user support for it ! :)


       
QuoteCurrently the tutorial assumes a PB version 1.63...

          Why ? - There are sites still offering PB1.62 demo. 

thaaks

Quote from: kevin on February 14, 2008, 07:31:35 PM
         Or it could collect garage during main.  Which removes the potential step over problem from the update functions.
         
             Repeat
                     UpdateAliens()
                     UpdateBullets()
                     UpdatePlayer()             
                     RenderScene()
                     CollectGarbage()
             until GameState=GameOver
         
   
I like that idea and will work that approach into the tutorial and the source code.

Quote
          Why ? - There are sites still offering PB1.62 demo. 

Simply because you mentioned here that native link lists are available in version 1.63 and above  ::)

If they are already working for 1.62 then I'm fine and change the code accordingly.

kevin


    For clarification sake,  Lists were added in the 1.59 -> 1.60 update.    I don't recall if the implementation changed since then, apart from the 1.63t2 revision the other day. 

   While the tutorials runs as is under 1.63t2,  for compatibility sake (since there's lots of editions of 1.63 even)  it'd be better to structure the code in such a way that it'll operate correctly both from the latest release and older editions.   Since i'd assume that all version of PB from 1.59 to 1.63t include skipping behavior from within a ForEach/next structure.

    Other things you could look at are using inheritance for the object types.    This way you could rescue the size of the code and even remove some list bound functions.

    Also  I notice that scene is rendering through a camera, but the Z depths appear to be same for all objects in the scene ?   To correctly bias the draw order, the objects need to be on different z levels.   If there all at the same Z then it's almost pot luck if they're in order.


kevin


Here's a rehash of the code

thaaks

Thanks  ;)

Looks pretty similar to what I have currently as a WIP. But you did some more code refactorings (MakeSprite() for example and the Hide stuff) which I like and will put into the tutorial if you don't mind.

And of course calling the CollectGarbage() every frame simplifies the list handling a lot.

Thanks for your help and efforts!

Cheers,
Tommy

kevin


   The removing objects outside of the updating  post displaying, ensures the visual logic errors don't occur. While not a big issue in a frame Dependant examples like this, it's critical in games where  logic and rendering aren't interleaved.  (ie time based)

thaaks

Okay, I declare the tutorial finished  ;D

Here's the direct link: Space Invaders Tutorial

If you detect bugs (I am sure Big C. will dig through the code until he finds something  ;)) please tell me so I can fix it.

Have fun with it,

Tommy

ATLUS

Big Thx for tutorial!!!!!!!!!!!!

thaaks