Frogz 64 Ongoing development

[WAVE 1 GAMES]

 

 

I wanted to include a similar mode to the PLUS mode in Fast Food 64, so I figured easy enough I can just copy the code I created from there and put the Frogz graphics on top and it should all work out the same. Well that's a big NO. I have to rebuild this type of game from the ground up as the same code does not provide desirable results here. (I tried it doesn't look appealing )

 

So I started making a y tracking system shown in the above video. what happens is as the little boxes move across the screen vertically and the obstacles reach an x position <320 they will reposition to match the middle moving tracker and wrap to the other side.

 

There are 2 issues I have with this way of doing it.

 

1) for some reason even though all obstacles are moving at the same xadd speed they catch up to one another and overlap each other at points.

What could I do to prevent this from happening? I thought of creating collision events between the different obstacles that would basically repeat the y tracker event but with that I'm worried about the obstacles forming a wall.

 

2) there is still this weird thing happening on the left side of the screen where you can see the obstacles re-positioning. I want the object to either be slightly more off to the left or disappear temporarily until it wraps to the other side.

 

 

Ideas? thoughts?

 

 

EDIT-----> I did just figure out that if I use the player object for tracking on half of the obstacles it does create a more randomized look vs the pattern seen in the video

 

 

I apologize for creating a 3rd topic about this project, but I want this one to be about the ongoing development of the current build and the one in the main Jaguar thread to be for the finished product. Also the other topic in the rB+ thread regarding this game is now far too dated.

Edited August 8, 2017 by Jeffrey_Bones

[WAVE 1 GAMES]

 

 

So far with the progress in this mode.

 

I still have the weird effect on the far left side of the screen. The speed is somewhat off on the water and the terrain when hitting level 3 instead of creating a 3d parallax effect it creates something else that makes me dizzy. also the overall speed of the player and everything needs to be toned down a bit. The trick will be to make it gradually increase the speed like the PLUS mode in Fast Food 64.

I haven't set up collisions on the obstacles and the player yet, I want to make sure I have the speed, parallax effect and movement right first.

[ggn]

Ok, I'm going to throw a couple of random thoughts/ideas judging from what I see on the video:

• With regards to your first question: I see you have different sized objects. Let's take two and say they have w1 and w2 widths (w1<>w2 of course) travelling right-to-left. Any given object in order to wrap around the screen has to travel size_of_viewscreen+sprite_width pixels. This is because you initially set the x coordinate to size_of_viewscreen and decrease it. Now, in order for the sprite to completely disappear from the screen it still has to travel sprite_width pixels. So, coming to the assumption above we conclude that the two sprites have to travel different distances in order to wrap around: size_of_viewscreen+w1 and size_of_viewscreen+w2. Which means that the sprite that is longer than the other has to travel an extra abs(size_of_viewscreen+w1-size_of_viewscreen-w2)=abs(w1-w2) pixels. Which of course ties with what you see on screen: sprites get "de-synced" when they start wrapping.
• The above is assuming that your coordinates are relative to the upper left corner of the sprite. If they are relative to center then simply add or subtract sprite_width/2.
• Solving that is very much up to the implementation. One way to do it would be to wrap all sprites using the longest one. So then you need a common width for all (even if the smallest sprites have blank pixels) and it will wrap consistently.
• Another idea would be to add a wait when an object wraps before placing it on screen again
• As for the second question, it really seems that you're wrapping objects too early. Do you do the movement/wrapping manually or does raptor handle that? For the former you probably need to rethink of your maths (the above points will give you a reference). If raptor handles the movement/wrap then there's something set up wrongly about this. I can't help much here because I never used raptor, but the one thing I'm sure is that this is the only feature that was tested to be 100% working as it was one of the first things to go in .

Edited August 8, 2017 by ggn

[+CyranoJ]

[EDIT] Yeah, no

Edited August 9, 2017 by ggn

[WAVE 1 GAMES]

 

Ok, I'm going to throw a couple of random thoughts/ideas judging from what I see on the video:

• With regards to your first question: I see you have different sized objects. Let's take two and say they have w1 and w2 widths (w1<>w2 of course) travelling right-to-left. Any given object in order to wrap around the screen has to travel size_of_viewscreen+sprite_width pixels. This is because you initially set the x coordinate to size_of_viewscreen and decrease it. Now, in order for the sprite to completely disappear from the screen it still has to travel sprite_width pixels. So, coming to the assumption above we conclude that the two sprites have to travel different distances in order to wrap around: size_of_viewscreen+w1 and size_of_viewscreen+w2. Which means that the sprite that is longer than the other has to travel an extra abs(size_of_viewscreen+w1-size_of_viewscreen-w2)=abs(w1-w2) pixels. Which of course ties with what you see on screen: sprites get "de-synced" when they start wrapping.
• The above is assuming that your coordinates are relative to the upper left corner of the sprite. If they are relative to center then simply add or subtract sprite_width/2.
• Solving that is very much up to the implementation. One way to do it would be to wrap all sprites using the longest one. So then you need a common width for all (even if the smallest sprites have blank pixels) and it will wrap consistently.
• Another idea would be to add a wait when an object wraps before placing it on screen again
• As for the second question, it really seems that you're wrapping objects too early. Do you do the movement/wrapping manually or does raptor handle that? For the former you probably need to rethink of your maths (the above points will give you a reference). If raptor handles the movement/wrap then there's something set up wrongly about this. I can't help much here because I never used raptor, but the one thing I'm sure is that this is the only feature that was tested to be 100% working as it was one of the first things to go in .

 

 

OK so I tried what you said. I made the wrap point the width of the screen + the width of the sprite for each object. That didn't work. Then I made the wrap point the width of the screen minus the width of the sprite. It did not work. Then I played with the collision box offset of each object to try and trigger the wrap later. This also did not work. (and even if it did, it would effect gameplay.) So I came up with another solution. Another one of my little black boxes. This one will serve as the wrap tacker and be placed just off to the right of the screen (342 pixels to be exact)

IF plusrocka_x<352 THEN

RSETOBJ(plusrocka,R_sprite_active,R_is_inactive)

RSETOBJ(plusrocka,R_sprite_x,trackerd_x)

RSETOBJ(plusrocka,R_sprite_y,tracker_y+5)

RSETOBJ(plusrocka,R_sprite_active,R_is_active)

ENDIF

trackerd is the new object. This code seems to work just fine. I also seem to have gotten the speeds right for the water and terrain as the game progresses. Below are the results .

 

 

Now to set up the collisions with the objects and the player and create a respawn subroutine for the player after a death occurs.

[WAVE 1 GAMES]

frogz2.abs

 

Here is the current build with River Rush Mode 100% complete

[ggn]

OK so I tried what you said. I made the wrap point the width of the screen + the width of the sprite for each object. That didn't work. Then I made the wrap point the width of the screen minus the width of the sprite. It did not work.

"Didn't work" isn't saying much. Just for the sake of clarity could you elaborate a bit? What didn't work? What did did it do instead?

 

So I came up with another solution. Another one of my little black boxes. This one will serve as the wrap tacker and be placed just off to the right of the screen (342 pixels to be exact)

IF plusrocka_x<352 THEN

RSETOBJ(plusrocka,R_sprite_active,R_is_inactive)

RSETOBJ(plusrocka,R_sprite_x,trackerd_x)

RSETOBJ(plusrocka,R_sprite_y,tracker_y+5)

RSETOBJ(plusrocka,R_sprite_active,R_is_active)

ENDIF

trackerd is the new object. This code seems to work just fine. I also seem to have gotten the speeds right for the water and terrain as the game progresses.

Well, to use your terminology, "that doesn't work" for object wrapping (both video and VJ) - stuff disappears while being on screen to the left hand side! If you can tweak the code above so it's not visible then you're good to go.

[omf]

 

RSETOBJ(plusrocka,R_sprite_active,R_is_active)

 

why are you still using obsolete code? move over to RLIST

rlist [plusrocka].active = R_is_active

[WAVE 1 GAMES]

"Didn't work" isn't saying much. Just for the sake of clarity could you elaborate a bit? What didn't work? What did did it do instead?Well, to use your terminology, "that doesn't work" for object wrapping (both video and VJ) - stuff disappears while being on screen to the left hand side! If you can tweak the code above so it's not visible then you're good to go.

Hey what do you mean stuff dissappears?

 

What I meant by it doesn't work is it was the exact same effect as before. It seems that the wrap point is a little off when trying to input the position manually. (Or maybe im off?) The way I did it here its looking for the new object instead, which for some reason it has no issues finding it.

[WAVE 1 GAMES]

why are you still using obsolete code? move over to RLIST

rlist [plusrocka].active = R_is_active

Im still trying to figure out how to use rlist.

[ggn]

Hey what do you mean stuff dissappears?

Here, let me demonstrate. This is a gif captured from vj directly at 60fps:

 

 

Now that might not be too visible, so let's take a few individual frames out of that. Specifically:

 

Frame 5 - that rock on the bottom left looks fine.

 

 

 

 

Frame 6 - hey that rock moved, it's on its way out of the playfield but still needs some time, right?

 

 

 

 

Frame 7 - poof, gone!

 

 

 

 

Now I'm sure you'll agree with me that judging from frame 5 and 6 the rock had at least 2-3 frames more till it disappeared from the screen, but in frame 6 it's gone. Of course that doesn't hurt the gameplay per se but sure looks a bit bad to the eye. I certainly would try to fix that. Also notice that this also happens in the video you uploaded so it's not my capturing program or anything...

 

 

Im still trying to figure out how to use rlist.

Allow me then: At the start of your code insert this line:

rlist=(RAPTOR_LIST *)strptr(RAPTOR_sprite_table)

this initialises rlist. Then if you want to use rsetobj or rgetobj anywhere in your code you do:

 

RSETOBJ(1,R_sprite_y,PY<<16) <-> rlist[1].y=PY

 

nyanaddy=RGETOBJ(nyan1,R_sprite_gfxbase) <-> nyanaddy=rlist[nyan1].gfxbase)

 

Notice how all those R_sprite_ prefixes are gone so your code is shorter. The full list for variables for both syntaxes is:

 

    RSET/RGETOBJ            RLIST
    ------------            -----
    R_sprite_obj            obj
    R_sprite_active         active  
    R_sprite_x              x
    R_sprite_y              y
    R_sprite_xadd           xadd    
    R_sprite_yadd           yadd    
    R_sprite_flip           flip    
    R_sprite_width          width   
    R_sprite_height         height  
    R_sprite_vbox           vbox    
    R_sprite_hbox           hbox    
    R_sprite_gfxbase        gfxbase 
    R_sprite_framesz        framesz 
    R_sprite_framedel       framedel    
    R_sprite_curframe       curframe
    R_sprite_maxframe       maxframe    
    R_sprite_animloop       animloop
    R_sprite_wrap           wrap
    R_sprite_timer          timer
    R_sprite_track          track
    R_sprite_colchk         colchk
    R_sprite_scaled         scaled
    R_sprite_scale_x        scale_x
    R_sprite_scale_y        scale_y
    R_sprite_CLUT           CLUT
    R_sprite_animspd        animspd
    R_sprite_bytewid        bytewid
    R_sprite_tracktop       tracktop
    R_sprite_was_hit        was_hit
    R_sprite_coffx          coffx
    R_sprite_coffy          coffy
    R_sprite_remhit         remhit
    R_sprite_bboxlink       bboxlink
    R_sprite_hitpoint       hitpoint
    R_sprite_damage         damage
    R_sprite_flash          flash
    R_sprite_gwidth         gwidth
    R_sprite_rmotion        rmotion
    R_sprite_rmcurfrm       rmcurfrm
    R_sprite_rmfrm          rmfrm
    R_sprite_userdat1       userdat1
    R_sprite_userdat2       userdat2
    R_sprite_userdat3       userdat3
    R_sprite_userdat4       userdat4
    R_sprite_userdat5       userdat5
    R_sprite_userdat6       userdat6
    R_sprite_userdat7       userdat7

Edited August 10, 2017 by ggn

[WAVE 1 GAMES]

Ah I see what you mean. I will try and adjust the code so it isn't turning off too soon.

Its also important to point out one of the people I have playtesting it found a bug in this mode last night where if you travel to the left of the screen and down you will go off screen and become invulnerable to the obstacles. I have since created a fix that bounces you back into the playfield when traveling to this edge point of the screen. The death sound was also getting on my nerves so I changed it to a more cartoony sound. I will attempt to fix the dissapearing logs and rocks then upload a new build later today. Hopefully it should be easy enough to trigger the "off" a few seconds later. From the look of your screen grab I think 2 seconds should be good enough. I also want to add a random appearing heart that restores 1 health point if you catch it. It would come accross the screen like the fly does but infrequently

Edited August 10, 2017 by Jeffrey_Bones

[omf]

Ah I see what you mean. I will try and adjust the code so it isn't turning off too soon.

edge_kill

[WAVE 1 GAMES]

edge_kill

While using edge_kill is definitely an option to turn them off appropriately, this would still leave me with the need to reposition and turn the objects back on at the right side of the screen. This is something I could definitely try and play with. I initially skipped doing it this way because I wanted to bring them back on the other side.

[omf]

While using edge_kill is definitely an option to turn them off appropriately, this would still leave me with the need to reposition and turn the objects back on at the right side of the screen. This is something I could definitely try and play with. I initially skipped doing it this way because I wanted to bring them back on the other side.

edge_wrap

[WAVE 1 GAMES]

[WAVE 1 GAMES]

[rayik]

The frog faces up when you move right. That does not look correct

[WAVE 1 GAMES]

The frog faces up when you move right. That does not look correct

 

How does this look?

(he's clearly humping the log at one point, lol)

[rayik]

How does this look?

https://www.youtube.com/watch?v=UuQhjRqTGGQ&feature=youtu.be

(he's clearly humping the log at one point, lol)

Frog faces the direction of his last move. Excellent!

[WAVE 1 GAMES]

Today after fixing the issue about the way the frog was facing when moving I decided to start working out how the frog will interact with the level objects in the space levels. To my surprise, VJ and Fraps were both running at the same time with no issues (this has been rare lately) so I went ahead and grabbed some video of the level in action. The passing asteroids will be the harmful objects within the level and the space shuttles will act as the logs. I am thinking of spacing the shuttles out more and possibly adding a 5th shuttle to make the movement to the top smoother. On a side note I would hate to be outside on this day as I'm sure a large rock falling from the sky would be quite a bummer....

[WAVE 1 GAMES]

2600 mode update!

Collisions on the logs and lilliys not perfect yet, but getting there! (getting VERY close)

Edited August 31, 2017 by Jeffrey_Bones

[WAVE 1 GAMES]

[WAVE 1 GAMES]