help understanding collisions

Raftronaut

Member
Hello!

I have a specific problem in my shooter module game design where the solid tiles at the top and bottom of the playfield, we'll call them "rails" actually halt the player momentum when touched. I believe this would only be a problem for people using solid tiles in an Auto scrolling environment like all scrolling shooter (or perhaps auto scroll-runnners).

Here is an example of the player momentum stopping:
https://youtu.be/qx9gUjPAnBU

The solution I had dreamed up is a sort of "roller" tile where the top and bottom of the tile collision would not allow the player to pass through but would also NOT halt the player momentum, allowing the player to slide along the edges without stopping... in fact, this type of solid collision could almost replace all solid tiles involved in shmups.

now that I am understanding a little 6502 ASM I decided to go looking for the code that dictates collisions of objects and I immediately hit a dead end.

My first instinct was to look in project settings->script settings -> Tile collision 01 - Routines\Basic\ModuleScripts\TileScripts\SolidBehavior.asm :
Code:
;;; SOLID
;;;This is how to inform a solid collision.
;;; You can also add this to the end of
;;; any tile type if you want it to have an effect AND
;;; be treated like solid.
;;; You could also check to see if it is a non-player object,
;;; and only return solid if it's a not player.  This would
;;; cause monsters to treat things like spikes or ladder or fire
;;; as solid while the player is able to interract with it.

	LDA #TILE_SOLID
	STA tile_solidity
	
	;; if you want it solid, declare it at the end

This is seeming to load a bit of code from a macro that I cannot find, or perhaps this is pointing to an address in memory.

in GameEngineDate\Routines\Basic\System\TileTypes\TileType01.asm I find:
Code:
;;; SOLID
;;;This is how to inform a solid collision.
;;; You can also add this to the end of
;;; any tile type if you want it to have an effect AND
;;; be treated like solid.
;;; You could also check to see if it is a non-player object,
;;; and only return solid if it's a not player.  This would
;;; cause monsters to treat things like spikes or ladder or fire
;;; as solid while the player is able to interract with it.
	;; for a PLATFORMER, solidity is handled a little bit different.
	
	
;;; RIGHT NOW, you can also use this tile as a MONSTER LOCK or a COLLECTABLE LOCK
;;; tile type 5, by default, simply uses this code, but changes to walkable when monsters are destroyed.
;;; tile type 6, by default, simply uses this code, but changes to walkable and flips screen state when collectables are collected


	
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ALL THAT IS NEEDED FOR TOP DOWN
	;LDA #TILE_SOLID
	;STA tile_solidity
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	
	;; if you want it solid, declare it at the end

	.include Tile_01

I guess I am failing to understand where these labels are kept in the architecture of Nesmaker. I'd really like to breakdown the collision code happening in #TILE_SOLID so I can start picking it apart. If I could just understand where the collision points are checked and figure out how to modify those points with comparisons to either collide head on and stop momentum or collide from top/bottom and prevent from passing through but allow player to continue momentum.....that would be the solution I think..
Understanding that would really help me going forward, especially as I soon set out to try and solve my need for a Z-axis.
I just think there is something really basic I am failing to understand about how Nesmaker organizes the code.

If anyone could offer any guidance or insight here it would be greatly appreciated.
 

Raftronaut

Member
Actually it seems like all the collision branching is in TileCollisions.asm

The 1st paragraph of comments details the 6 point hit detection of solid tiles.

Code:
HandleTileCollision:
    ;;;;;ASSUMES vulnerability bit 000x0000, if one, skips collision.
    ;;;;;Six collision points. 
    ;;;;;All collision points checked and registered for all objects.
    ;;;; a solid in any of the points will result in negating all others.
    
        ;;; There are 6 ram variables, collisionPoint0 - collisionPoint5.
        ;;; collisionPoint0 = top left
        ;;; collisionPoint1 = top right
        ;;; collisionPoint2 = bottom right
        ;;; collisionPoint3 = bottom left.
        ;;; collisionPoint4 = mid left
        ;;; collisionPoint5 = mid right.
    
    TXA 
    STA currentObject
    TYA
    STA tempy

	LDA npc_collision
	AND #%11111101
	LDA #$00
	STA npc_collision
	LDA navFlag
	AND #%11111110
	STA navFlag
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; EXPLANATION:
;; In this basic module, both non gravity and gravity scripts are loaded.
;; Under most circumstances, a user will likely make use of one or the other,
;; as they each take up a good chunk of data.  But the benefit of including both is that
;; a platforming game with gravity is just a simple bit flip in the screen flags.
    
    
    LDA screenFlags
    AND #%00100000
    BNE useGravity
    JMP dontUseGravity
useGravity:
	LDA Object_vulnerability,x
	AND #%00100000
	BEQ useGravity2
	LDA Object_physics_byte,x
	AND #%00000010
	BNE useGravity2
	JMP dontUseGravity
useGravity2:

;;;;;;===================================================
;;;;;;***************************************************
;;;;;; TILE COLLISION FOR SCROLLING PLATFORMERS:
;;;;;; For scrolling platformers we will use three types of collision detection:
;;;;;;          1. A routine to check under our feet to determine
;;;;;;              whether or not you are standing on a solid object.

                    ;;; This function will check under neath the object's feet
                    ;;; by arg0 pixels.
                    ;;; it will update bit 0 of the Object_physics_byte.
                    ;;; If that bit is 0, it means the place is free.
                    ;;; If that bit is 1, it means the place is solid.
    ;**********************
       CheckUnderObject #$01

;;;;;;
;;;;;;          2. A routine that checks to see if the potential position leaves you
;;;;;;              with your 'bottom' or 'top' in a solid object, in which case it ejects pixel perfect
;;;;;;              to that tile.

                    ;;; This function checks the POTENTIAL vertical position.
                    ;;; If it results in a point in a solid object, it appropriately
                    ;;; ejects and places the object directly against the point
                    ;;; of collision.
    ; **********************
     CheckForVerticalEjection 

  
;;;;;;
;;;;;;          3. A routine which checks horizontal motion to see if the potential position
;;;;;;              sees a solid collision, in which case it can not move.
 
                    ;;; This function checks potential horizontal position.
                    ;;; without factoring in vertical motion.  If it sees a solid,
                    ;;; it skips motion.
    ; ***********************
      CheckForHorizontalCollision
    
;;;; This is the end of scrolling platform physics.  It automatically jumps to the proper place.  
;;;; Otherwise, if there was no collision, we jump to updating the position.
    ;; we only need to update horizontal position
    
  

    CheckPlayerCameraPosition
;;;; if it turns out we were outside of the camera bounds, the macro
;;;; has RTSed out of this routine, so the hoziontal position will
;;;; never be updated.
   
     JSR updateHorizontalPosition
   
     JMP DoneWithTileChecksAndUpdatePosition
;;;;;;;;;;;;;==============================================  


dontUseGravity:
;;;;;;===================================================
;;;;;;***************************************************
;;;;;; TILE COLLISION FOR TOP DOWN GAMES: 

;;;; Before we update the position, though, if this is a scrolling game, we need to see if the player
;;;; is at the edge of the camera.  If he is at the edge of the camera, it
;;;; will do a bounds check.
	;CheckPlayerCameraPosition
	   
;;;; if it turns out we were outside of the camera bounds, the macro
;;;; has RTSed out of this routine, so the hoziontal position will
;;;; never be updated.
 
;;;;;   For top down type games, or games that generally have no gravity but have 4 directional movement,
;;;;;   we only need to check potential position and jump to the appropriate label.
  ;  CheckPotentialPosition
   



    
   ; JSR updateHorizontalPosition
   ; JSR updateVerticalPosition
	
;;;; THis is the end of top down scrolling physics.  It automatically jumps to the proper place.
;;;; Otherwise, if there was no collision, we jump to updating the position.

     JMP DoneWithTileChecksAndUpdatePosition
   
   
   

;;; NO POINTS WERE SOLID    
    ;;;; update hold
DoneWithTileChecksAndUpdatePosition:
   ldx currentObject
    RTS
    
HandleSolidCollision:
	LDA screenFlags
	AND #%00000100 ;; is it autoscrolling?
	BEQ + ;; not autoscrolling
	;;; is auto scrolling
	CPX player1_object
	BNE +
	JSR CheckAutoScrollLeftEdge
	RTS 
+ ;; not auto scrolling.

	LDA xPrev
	STA xHold_hi
	LDA yPrev
	STA yHold_hi
    TYA
    STA tempy
    LDA Object_edge_action,x
    LSR
    LSR
    LSR
    LSR
    BEQ doNothingAtSolid
    TAY
    
    LDA AI_ReactionTable_Lo,y
    STA temp16
    LDA AI_ReactionTable_Hi,y
    STA temp16+1
    
    JSR doReactionTrampolineSolid
    JMP pastReactionTrampolineSolid
doReactionTrampolineSolid:
    JMP (temp16) ;;; this now does the action
            ;; and when it hits the RTS in that action,
            ;; it will jump back to the last JSR it saw,
            ;; which was doNewActionTrampoline...which will immediately
            ;; jump to pastDoNewActionTrampoline.
pastReactionTrampolineSolid:
    ;LDA #$00
    ;STA xHold_lo

doNothingAtSolid:
    ;;;;;;;;;;; Do solid reaction type.
    LDY tempy
    LDX currentObject
    RTS
    
    
ejectUp:
    LDA tileY
    and #%00001111;We can only be 0 to 15 pixels in any given wall
    sta temp
 
    lda Object_y_hi,x
    clc;Subtract one plus that so we're a pixel out of the wall rather than one pixel in it.
    SBC temp
    STA Object_y_hi,x
    LDA #$00
    STA yHold_lo
    STA Object_v_speed_hi,x
    STA Object_v_speed_lo,x
    RTS
    
ejectDown:

    lda tileY
    and #%00001111;we can only be 0 to 15 pixels in any given wall
    eor #%00001111;If we're at position 15 in the tile, we only want to eject 0 (+1) so flip the bits
    sec;Will add the extra one to the position so that we're a pixel out of the wall
    adc Object_y_hi,x;rather than one pixel in it.
    sta Object_y_hi,x
    
    LDA #$00
    STA yHold_lo
    STA Object_v_speed_hi,x
    STA Object_v_speed_lo,x
	
	;;; check the top two collision points to see if is it a prize block.
	LDA collisionPoint0
	CMP #COL_INDEX_PRIZE_BLOCK
	BEQ +
	JMP ++ 
+
	LDA Object_x_hi,x
	CLC
	ADC Object_left,x
	STA tileX
	JMP +++
++
	LDA collisionPoint1
	CMP #COL_INDEX_PRIZE_BLOCK
	BEQ +
	JMP ++
+
	LDA Object_x_hi,x
	CLC
	ADC Object_right,x
	STA tileX
+++


	
	LDA gameHandler
	ORA #%00010000
	STA gameHandler
	;;;;; check other head-hit type objects here.
	;; change collision data.
	;; should still have the correct coordinates in tileX and tileY
	ChangeTileAtCollision #COL_INDEX_PRIZE_BLOCK_OFF, #TILE_INDEX_PRIZE_OFF
	
	TXA
	PHA
	LDA Object_x_hi,x
	STA temp
	LDA Object_y_hi,x
	SEC
	SBC #$1A ;; a bit more than the height of it.

	STA temp1
	LDA Object_scroll,x
	STA temp2
	CreateObject temp, temp1, #OBJ_PRIZE, #$00, temp2
	LDA #$00
	SEC
	SBC #$04
	STA Object_v_speed_hi,x
	
	PLA
	TAX
	
++
    RTS
    
    
    

CheckForCollision:

    ;;;; commonly, we won't want to waste cycling 6 times through this for each object when
    ;;;; all points are at no collision.  If by chance we NEED the zero type collision to do something, 
    ;;;; we can comment out the zero type check in this next line.  But most games are going to have
    ;;;; at least one "blank tile" that does nothing, and most games will use zero for this.
	
	;;;; Another conundrum is that a collision could take place in the current or new nametable.
	;;;; if this collision is of type that draws from screen data (for instance, NPC data or warp data), it could
	;;;; be problematic, as all variables handling these things are loaded with the current collision tables data.
	;;;; tempCol ends up being 0 or 1 based on which collision table this should be referencing.
	
    STA temp
    BNE notZeroTypeCollision
    JMP zeroTypeCollision
notZeroTypeCollision:
    LDA #$00
    STA tile_solidity
DoCheckPointsLoop:
    LDA temp
    TAY
    LDA tileTypeBehaviorLo,y
    STA temp16
    LDA tileTypeBehaviorHi,y
    STA temp16+1
    JSR UseTileTypeTrampoline
    JMP pastTileTypeTrampoline
UseTileTypeTrampoline:
    JMP (temp16)
pastTileTypeTrampoline:
DontCheckTileType0:

    
zeroTypeCollision:
    ldx currentObject
    RTS
    
    
    
    
DetermineCollisionTable:
    LDA tempCol
    BNE colPointInDifferentTable
    ;;;; the collision point is in the current collision table.
    LDA Object_scroll,x
    AND #%00000001
    BNE isInOddTable
    JMP isInEvenTable
colPointInDifferentTable:
    ;;; the collision point to be checked is in the NEXT collision table.
    LDA Object_scroll,x
    AND #%00000001
    BNE isInEvenTable
    JMP isInOddTable
	

isInEvenTable:
    LDA collisionTable,y
    RTS
isInOddTable:
    LDA collisionTable2,y

    RTS


    
    
updateHorizontalPosition:
    LDA xHold_lo
    STA Object_x_lo,x
    LDA xHold_hi
    STA Object_x_hi,x
    LDA nt_hold
	CMP Object_scroll,x
	BEQ justUpdateScroll
	LDA #$01
	STA update_screen_data_flag
	LDA nt_hold
justUpdateScroll:
    STA Object_scroll,x
    
    RTS
    
updateVerticalPosition:
    LDA yHold_lo
    STA Object_y_lo,x
    LDA yHold_hi
    STA Object_y_hi,x   
    RTS

Though, I am not understanding where it goes through to check for those 6 points collision. Also, no where do I see anything indicating it would stop the player's momentum.
 

dale_coop

Moderator
Staff member
Hmmm...
A custom tile type, instead of using/modifying the solidity, I'd just block the vertical movement...
For example, using a unused "Tile Collision ??", assigned to a new script, something like:
Code:
	LDA yPrev
	STA Object_y_hi,x
	STA yHold_hi
 

Raftronaut

Member
Hi Dale!

Allowing vertical movement would be a great solution. I will try creating a new tile type tonight and test it.

The "stickiness" of the solid tiles will continue to be a problem for anyone making a Shmup in the future. So having this tile available that will allow the player to press into solid tiles without restricting movement will basically be able to completely REPLACE the default solid tile in the shooter module altogether.

*One more item to add to my list of common shmup design elements. Hoping to eventually compile these items in a community tutorial post for shmups once I understand them better.

thanks for the help as always Dale :)
 

Raftronaut

Member
dale_coop said:
Hmmm...
A custom tile type, instead of using/modifying the solidity, I'd just block the vertical movement...
For example, using a unused "Tile Collision ??", assigned to a new script, something like:
Code:
	LDA yPrev
	STA Object_y_hi,x
	STA yHold_hi

Dale, this did not work quite as expected. As you can see, the tile allows the player to pass through the it, when pressing the input against the solid portion of the tile the same momentum decrease occurs.
You can see it happening here:
https://youtu.be/wddN4Qq9nyk

I don't understand where I can modify the behavior of the character movement halting when pressing input into a solid. I can't describe it other than being "sticky". Maybe this particular characteristic of the solid tile only shows up in the auto scroll module due to the speed at which you pass objects..

Instead of being "sticky" the solid tile should feel "greasy" if that makes any sense.

For example, now that I have 8 direction movement, when pressing forward (right) into a solid tile, the momentum should be stopped completely (as it is currently). However, when pressing forward (right) AND up or down, momentum on the Y axis should be resumed rather than being stuck in place...THEN vice versa for the X axis...(movement should be resumed IF right or left is pressed when holding up/down into solid).

Maybe this is something that can be modified in the movement script? I'm so confused where this collision behavior takes place in code...

Any thoughts?
 

dale_coop

Moderator
Staff member
Strange, it looks like your "rail" tile is null/walkable...
The code I gave you should prevent your player to cross it vertically.
 

Dirk

Member
That's great! I'm glad it worked out.
I'm not planning to make an auto scroller myself atm, but I think I'll have to bookmark this for future reference.
 

dale_coop

Moderator
Staff member
Glad it worked :)

And for your HUD changing colors... don't forget to paint pressing "R", the HUD area of the NEXT screen (the screen at the right of your current screen)
 

Raftronaut

Member
So these tiles seem to be working perfectly as intended as the "rails" here.

However, I keep wondering if this technique can somehow be applied to the Y axis as well. If the tile also had collision on the Y axis it could be used as the default "shooter solid" tile since would allow player to pass by the solid tile unhindered.

I made a short video of head on collisions, the Y axis acts as a null value when hit head on:

https://youtu.be/LoTOdfJGzcg

I am asking because the "roadblocks" I use as obstacles in my game are made with solid tiles and possess the same "sticky" qualities. I've watched players get stuck here and dragged into the screen edge which seems to create an unfair Player death..
Here is video of my player getting hung up on the road blocks. When the player is "stuck" it is because I am pressing the input into the obstacle.
https://youtu.be/6JSGJKxJhHI

I am wondering if this is possible?

The collisions seems to take place at 6 different points here:
67634984_436139543776391_6363144140951126016_n.jpg
I wonder if it is possible to write an AND statement that states when the player is touching the points on the Y axis (collision points 4-5) AND a point on the X axis (points 0-3) the tile acts as a solid and does not allow player to pass through... Just thinking out loud here, not sure how you would make that argument in the code..

It would just be great of the player was able to simply "slip or slide" away from these types of collisions.

Any thoughts?
 

Raftronaut

Member
dale_coop said:
Glad it worked :)

And for your HUD changing colors... don't forget to paint pressing "R", the HUD area of the NEXT screen (the screen at the right of your current screen)

Ah yes, the hud colors was just an artifact of me rushing to get the example captured (these screens were built specifically for testing, not too worried about aesthetics here :) I have fixed all of the HUD colors in the game itself already..
 

Raftronaut

Member
Dirk said:
That's great! I'm glad it worked out.
I'm not planning to make an auto scroller myself atm, but I think I'll have to bookmark this for future reference.

I plan on compiling a list of common Autoscroller functions at some point, this will certainly be included ;)
 

dale_coop

Moderator
Staff member
Here a modified one, you could try ;)
Code:
	;; checking center left collision point
	LDA collisionPoint4
	BNE RailsLeftRight	;; there is a collision
	
	;; checking center right collision point
	LDA collisionPoint5
	BNE RailsLeftRight	;; there is a collision

	;; no left/right collision...
	
RailsTopBottom:	
	;; block vertical movement:
	LDA yPrev
	STA Object_y_hi,x
	STA yHold_hi
	JMP endRails
	
RailsLeftRight:
	;; solid from sides:
	LDA #TILE_SOLID
	STA tile_solidity
	
	;; but it sticks !!!!
	;; so...
	;; add here a small sliding down:
	LDA yPrev
	CLC
	ADC #$01
	STA Object_y_hi,x
	STA yHold_hi
	
	
endRails:
(see my comments, in the script)
 

dale_coop

Moderator
Staff member
And here's improved one, your player will slide up or down when colliding from the sides:

Code:
	;; checking center left collision point
	LDA collisionPoint4
	BNE RailsLeftRight		;; there is a left collision
	
	;; checking center right collision point
	LDA collisionPoint5
	BNE RailsLeftRight		;; there is a right collision

	;; checking center right collision point
	LDA collisionPoint0
	CLC
	ADC collisionPoint1
	BNE doRailSlidingDown	;; there is a top collision

	;; checking center right collision point
	LDA collisionPoint2
	CLC
	ADC collisionPoint3
	BNE doRailSlidingUp		;; there is a bottom collision
	
RailsTopBottom:	
	;; block vertical movement:
	LDA yPrev
	STA Object_y_hi,x
	STA yHold_hi
	JMP endRails
	
RailsLeftRight:
	;; solid from sides:
	LDA #TILE_SOLID
	STA tile_solidity
	
	;; now checking the game pad (if pressing Up)
	;; to slide the player vertically
	LDA gamepad
	AND #%00010000
	BNE doRailSlidingDown

doRailSlidingDown:
	;; a small sliding down:
	LDA yPrev
	CLC
	ADC #$01
	STA Object_y_hi,x
	STA yHold_hi
	JMP endRails
	
doRailSlidingUp:
	;; a small sliding up:
	LDA yPrev
	SEC
	SBC #$01
	STA Object_y_hi,x
	STA yHold_hi
	
endRails:
 

Raftronaut

Member
dale_coop said:
And here's improved one, your player will slide up or down when colliding from the sides:

Code:
	;; checking center left collision point
	LDA collisionPoint4
	BNE RailsLeftRight		;; there is a left collision
	
	;; checking center right collision point
	LDA collisionPoint5
	BNE RailsLeftRight		;; there is a right collision

	;; checking center right collision point
	LDA collisionPoint0
	CLC
	ADC collisionPoint1
	BNE doRailSlidingDown	;; there is a top collision

	;; checking center right collision point
	LDA collisionPoint2
	CLC
	ADC collisionPoint3
	BNE doRailSlidingUp		;; there is a bottom collision
	
RailsTopBottom:	
	;; block vertical movement:
	LDA yPrev
	STA Object_y_hi,x
	STA yHold_hi
	JMP endRails
	
RailsLeftRight:
	;; solid from sides:
	LDA #TILE_SOLID
	STA tile_solidity
	
	;; now checking the game pad (if pressing Up)
	;; to slide the player vertically
	LDA gamepad
	AND #%00010000
	BNE doRailSlidingDown

doRailSlidingDown:
	;; a small sliding down:
	LDA yPrev
	CLC
	ADC #$01
	STA Object_y_hi,x
	STA yHold_hi
	JMP endRails
	
doRailSlidingUp:
	;; a small sliding up:
	LDA yPrev
	SEC
	SBC #$01
	STA Object_y_hi,x
	STA yHold_hi
	
endRails:

DALE! this seems to work perfectly. Here is a quick video of the test I did. It seems to have the added benefit of causing the character to "shake" when you press the input into the solid. Maybe unintended, but it works great as a sort of added friction animation in my game.

https://youtu.be/xT89dfQO4Gc

At the tail end of the demonstration I forced the player up and down into the solid to spotlight the shaking effect. Pretty cool huh???
 

Dirk

Member
Raftronaut said:
At the tail end of the demonstration I forced the player up and down into the solid to spotlight the shaking effect. Pretty cool huh???

Yes, that's a nice and fitting effect.
Do you plan to add sound effects for when the player slides along the guard rails?
 

Raftronaut

Member
Dirk said:
Raftronaut said:
At the tail end of the demonstration I forced the player up and down into the solid to spotlight the shaking effect. Pretty cool huh???

Yes, that's a nice and fitting effect.
Do you plan to add sound effects for when the player slides along the guard rails?

Hmmmm, that is an interesting thought, I hadn’t considered that. My soundtrack is somewhat dense at the moment so causing music to drop out is something of a n issue I have to keep in mind when designing sound fxs.

Though, as I’m typing I realized I was playing the fantastic homebrew “lizard” by Brad Smith over the weekend and that game manages to cut the drums out for a “flame” sound to great effect. That game has the most lovely sound design. It also manages to insert waterfall sounds on the noise channel between snare/kick beats

I’ll play around with this idea and see what I can get to work and maybe post some examples. I’ll need to research how to make a continuous sound loop for a SFX first. Situations like this really make me wish for DPCM drums. That would allow me so much more freedom. I did a mock up of my sound track with the kick and snare sounds from Skate or die 2, and then again with TwinBee 3 I had to force myself to stop playing with it because I was so in love with the sound. Sigh 😔
Anyway, I’ll let you know what I can manage as far as sfx here
 

Raftronaut

Member
Actually yes. Thinking more about it and I like this idea.
Putting a continuous grinding sfx on the noise channel would be a nice touch.
I think I’ll make a dedicated “rail” tile after all that would play this theoretical sound effect. I’ll just duplicate it and add the sound effect and assign it to a new tile type (I have plenty left in my project)

It occurred to me that I’ve got plenty of back beat with the triangle drums I programmed along with chord stabs on the square channel designed to enhance the snare. Dropping out the noise channel won’t completely abandon the rhythm and I think its worth exploring.

So thanks for the suggestion Dirk, I appreciate the feedback :)
 

dale_coop

Moderator
Staff member
Yeah, the shaking effect...
It was more a result (side effect) of the code, unfortunately :(
I was thinking about fixing that, but after testing my demo, I thought it could work for your game ;)

If I find time, I’ll try to fix it, to see how it goes.
 

Dirk

Member
Raftronaut said:
Actually yes. Thinking more about it and I like this idea.
Putting a continuous grinding sfx on the noise channel would be a nice touch.
I think I’ll make a dedicated “rail” tile after all that would play this theoretical sound effect. I’ll just duplicate it and add the sound effect and assign it to a new tile type (I have plenty left in my project)

It occurred to me that I’ve got plenty of back beat with the triangle drums I programmed along with chord stabs on the square channel designed to enhance the snare. Dropping out the noise channel won’t completely abandon the rhythm and I think its worth exploring.

So thanks for the suggestion Dirk, I appreciate the feedback :)

Cool, glad you like it :)
I'm curious how it will sound.
 
Top Bottom