Pooyan complete game

[ATLUS]

This game is hardcore game =) Thanks micky4fun

[Sir Daniel]

many thanks, mick.
please check the link - i think it's broken
Daniel

[kevin]

works fine here, it links to a page, not a file directly.

[Sir Daniel]

i am sorry, malwarebytes has blocked this site.

[Sir Daniel]

it works very fine.
580400 points and a sprained hand at the first time.
thanks to mick.

[Sigtrygg]

Hello Mick!

Great funny game!  :)
Thank you for posting source code, too!
Every source code is valuable for learning.

Sigtrygg

[micky4fun]

Hi all

it works very fine.
580400 points and a sprained hand at the first time.
thanks to mick.

no problem Daniel , only glad you like the game , one of many i had for the atari 400/800
seems to do the job , a bit of a crude way of putting in pause , but did not want to take to much time adding new features as im getting into my platform game ,
as it happens as my code was so easy to read only took seconds , lol

Great funny game! 
Thank you for posting source code, too!
Every source code is valuable for learning.

thanks Sigtrygg , hope you can follow the code ok ,

mick :)

[Sir Daniel]

Now i have reached 1.575.200 points in Pooyan and must now cooling my hand :-)
What a shame, that points over 1 million turned / vanished to zero.
@all:
i'am looking for playable games on PC like:
Hostages
Defender of the Crown
International Karate
Test Drive
Outrun

anybody still knows them ?

[micky4fun]

hi all

1.575.200 points

is that all , i will have to make it a bit harder , hahah
you certainly like playing this game to get that kinda score , i could add the extra didgit if you wanted me to,
but i would have thought you have played it enough by now , and its a long way from starting from 0 again

loved outrun
and defender of the crown was one of the first games i bought when i got my amiga 500 , that and leaderboard golf

mick :)

[kevin]

  Building a UW version of the Pooyan update ATM.    Just media tweaks and open/closing stuff so far really.    While it runs fine, it's good candidate for the Dirty rectangle based refresh.   Could probably get a 50% reduction in the rendering overhead,  handy if want the game to be playable on  really old clunkers in a window.   Better on battery life also.

[kevin]

   Dropped in some code to convert the image backdrops to maps, had a bit of drama getting the logic right, completely forgotten that the open reveal effect was destructive, so the backdrop picture would have all these black blocks in it.. Funny how fixated on something you can be, when assuming the problem is something, and it turned out to be completely unrelated. 

   The whole game is basically made up of sprites, so rather than patch into the logic routines, i've just added a post process to the entire sprite list.   The routine just runs through and grabs the rectangle around the sprite and copies the original map chunk to the refresh map chunk.

PlayBASIC Code: [Select]

Psub  Update_Sprite_Dirty_Rects(Index,ThisImage)

      rendertoimage thisImage

       Map            =Dirty(Index).MapIndex
       OriginalLevel   =Dirty(Index).OriginalLevel
       RefreshLevel   =Dirty(Index).RefreshLevel


      ThisSprite=GetFirstSprite()

      dim Rect as tSpriteRect pointer
      if int(Rect)=0
            Rect=New tSpriteRect
      endif

      if ThisSprite
         repeat

               if GetSpriteVisible(ThisSprite)

                  Stuff= GetSpriteREct(ThisSprite,rect)
                        
                     x1=Rect.x1
                     y1=Rect.y1
                     
                     x2=Rect.x2
                     y2=Rect.y2

                        // SHow the rect around the sprite on screen  
                     boxc x1,y1,x2,y2,false,$ff00ff
   
                        // Convert Pixels to Tile positions
                     x1/=TileWidth
                     y1/=TileHeight
                     
                     x2/=TileWidth

                     y2/=TileHeight
                     x2++
                     y2++
   

                     // Copy this area from the backdrop level to the refresh level
                     CopyLevel   Map,OriginalLevel,x1,y1,x2,y2,Map,RefreshLevel,x1,y1

               endif
                        
               ThisSprite=GetNExtSprite(ThisSprite)
         until ThisSprite<1      
      endif       

EndPsub

  The original backdrop picture is converted to a map previously with two levels.  One level is the level that represents this original picture, this level is never changed.  The second is transparent version (masking out block zero) level that we need  for restoring the backdrop picture to it's original state after sprite have been drawn on it.   So each frame we start the frame by drawing the blocks that were drawn over last frame with the original blocks.  So each frame the back drop picture is restored as it would be, if you just drawn the original image to the buffer.

  Nothing new, but often a more cost effective method of drawing these types of displays.  Check out Selective Tile Map Refreshing 

  The pic's bellow just show the game scene with the rects showing.  There's a redraw percentage under the score on the right hand side.  During the intro there's about a 70% redraw, but during the game that drops to about 45-50%.   Which in frame terms on my system is about 10-20 fps.   There does seem to be some nested collision checking going on though,  I suspect with a little tweaking, we might be able to peel a few milliseconds off the refresh.   

[kevin]

   The conversion to dirty rectangles  has gone pretty seamlessly really apart from the logic error.   The game uses fixed foreground sprites that sit over the background, ended up writing a little in game editor to tag blocks that are never visible to the player as always off.   So the actual picture versions of the background have these conceptual chunks removed from it.  You can't see this in game as the foreground sprites are occluding the background.   Pre-computing the occluded tiles just gives us free performance.   Not that it desperately needs optimization, but might as well make the game as accessible possible.

   Apart from the dirty rect stuff, the only changes would be a open/close effect, high score saving and a the usual dimmed pause screen (attached).   Was going to release it at this point, but found an issue with PB when building the release, where the PBCompileMode constant wasn't being set during exe building.   The constant is used so the compiler and include or exclude sections of code depending on how your compiling the program.   In a normal compile and run process the flag will be zero, when you build an exe it's meant to be one.   But wasn't  in PB1.64N3 (and i suspect old versions too) 

    Eg.
 

PlayBASIC Code: [Select]

      #if PbCompileMode=0
               Print "Program built and running from IDE"
      #else
               Print "Running EXE version of program "
      #endif

  

     When the compile see's such a snippet,  the compile evaluates the #IF directive.   So it check if the PBCompileMode value equals =0 or not.   If it's zero.. It includes the code between the #If and #Else statements in the program.  The Code between #Else and #ENDIF  is ignored.     When PBCompileMode isn't zero, the code between #Else and #ENdif is includes and the other section ignored.        Normally stuff like is used when we want to include some debug/info materials in our game when writing it, but remove them from the EXE version. 

      Anyway, it turns out the V1.64N3 was having some dramas dealing with importing the standard bindings and initializing the internal constants.    Was easily fixed once noticed, but the solution made the parser much slower in programs that use lots of constants.  Which occurred due to some lazy keyword searching of the constant tables.     Had a peek at that section again and there's actually some room for improvement in the keyword searching in the general.   For time being i'm trialing a  hash variation.    So far it seem much quicker in the test programs.   There pretty long programs like the Dissassembler which is basically 80% declarations and 20% actual code.   Today's build compiles that around 30 percent quicker than V1.64N3 release,   Which was a nice surprise.

 

     

[kevin]

     Back tinkering Pooyan for a bit,  only new tidbits  would be the some transitions for the hit point and letter collection animations, so they now cross fade out, rather than just vanish.  Took a while to work out how it all set up,  replacing some parts with functions to consolidate them into one place.   Swapped some the batch collision functions with Overlaps, since the routine was only looking for a single impact.  Gets rid some of the collision nesting.      

    Started adding a settings panel (ripped from one of the other apps of course) to it.   The settings will be pretty mundane stuff, like some volume controls, perhaps a mouse scaler,  window /full screen mode toggle..   Bellow is mock of the GUI code running, but only drawing over a picture of the game.   Shouldn't be a drama wedging them together.   Just wanna weed out what code i need and what codes just sitting around doing nothing. .  

     Slowly getting better at playing it though, clocked 545K earlier tonight..   Wouldn't mind dropping in the online score board stuff either.  

[kevin]

 
   The order of tonight has been to add preference and drop in some support for the running the game in different screen modes.   The actual game still 800*600, but in the test bellow, it's running in 1280*800 (window),  the display code stretches the buffer and keeps the 4/3 aspect ratio of the frame buffer.  So in full screen mode on a wide screen monitor, it's not going to be pulling horizontally as badly.   While most if not all new  modern monitors allow the user to adjust the sizes, many don't. 
I generally prefer playing such games in a window though.     

   The current build has some hard coded key controls to change between resolutions,  it's a bit messy atm, since it's not really cleaning up after itself before restarting.  The user input is remapped to the stretched size of the frame buffer. So when in  a wide screen mode the mouse coordinates are mapped back to original 800*600 frame.    The only thing that isn't is some code that clips the mouse when it moves up/down while playing .    When in window mode I think i'll had a 'detach' mouse toggle, probably through pause.     So if you're playing and need to do something else, hit space and it releases the mouse and basically sleeps.   

    Will probably need a Mouse graphic actually (for when in full screen mode), since i'm just sticking a circle on the screen at the moment..   The actual game isn't any different.   
   
 

[micky4fun]

Hi all


looking forward to all the changes you make within the game code , i hope i can learn some things with the adjusted code

mick :)