Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Programming Sprite Velocity on the Sega Master System

Reply to topic
Author Message
  • Joined: 05 Jan 2023
  • Posts: 2
Reply with quote
Programming Sprite Velocity on the Sega Master System
Post Posted: Thu Jan 05, 2023 2:09 am
Hello! I am trying to program a platformer in assembly, but I am have some questions about programming sprite velocity.
I have a basic engine working, but I feel that the sprite moves to fast.

For example, here is my code for the sprite's vertical velocity:

updateYVelocity:            ; Update sprite Y velocity

   ld a,(yVelocity)                  ; Load sprite Y velocity into A
   add a,GRAVITY_ACCELERATION      ; Add gravity acceleration to the y velocity
   jp m,updateYVelocity2            ; If A is negative, skip comparing max fall velocity

   cp MAX_FALL_VELOCITY         ; Check if velocity exceeds maximum falling speed
   jr nc,updateYVelocity3            ; If it does, skip updating velocity

updateYVelocity2:

   ld (yVelocity),a                  ; Store updated velocity in RAM

updateYVelocity3:

   ld hl,sYPOS                  ; Load HL with address for sprite Y position
   ld a,(yVelocity)                  ; Load sprite Y velocity into A
   add a,(hl)                     ; Add sprite Y position
   ld (hl),a                     ; Store updated position in RAM

   ret


Now for the vertical movement, I am always incrementing the sprites y velocity by one every frame so that I can simulate gravity and a jump arc. However, that makes the jump arc really fast at that speed, and games like Alex Kidd in Miracle World have slower jump arcs.

So my question is, how would I be able to program slower movement, without it being too choppy? How do games tend to go about it?
  View user's profile Send private message
  • Joined: 31 Dec 2022
  • Posts: 28
Reply with quote
Post Posted: Thu Jan 05, 2023 2:32 am
The obvious way to do it would be do add a secondary new counter (with
some variable let's call it c) which is unconditionally increased
in the main game loop and that can be read from update velocity part
of the code, where c is 8 bit from 0 to 255, and add in a conditional which
only updates the velocity (otherwise ignore updating velocity part of code block) depending on if c modulo 2 = 1 is true (for slowing down twice as much) or in general slowing down by a factor of I and branching if
(C modulo I)=1 true. Using 16bit instead of 8 bit for c will
give you more fine grained control of slowing down the velocity etc.The counter that controls how fast or slow it moves.
  View user's profile Send private message
  • Joined: 01 Feb 2014
  • Posts: 848
Reply with quote
Post Posted: Thu Jan 05, 2023 7:08 am
The obvious solution here is to use 16-bit values for both the velocity and the sprite position. Do all your calculations with these 16-bit values, then use only the MSB of the position value to get the actual on-screen sprite position.

If you do everything with 8-bit values, it will indeed either be too fast or you’ll have to invent some way to stall movement, which can turn things choppy.

If you don’t have different kinds of gravity in your game, you might also consider ditching the calculations altogether and just predetermine the up and down movement and store the values for each frame in a lookup table.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Thu Jan 05, 2023 7:36 am
16-bit values are the way to go, it is in fact the same as 8.8 fixed point maths. This is actually super important because it lets you have velocities like 1.5 pixels per frame - there’s a big jump between 0, 1, 2 pixels per frame.

You may also therefore need to use 24-bit 16.8 fixed point values for the position values.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 596
  • Location: London, UK
Reply with quote
Post Posted: Thu Jan 05, 2023 8:13 am
I did this recently for an upcoming super secret game project 😉 and used 32 bit variables (my projectiles are tracked offscreen), works great. Hint: this is *much* easier in C because it can handle all the larger int sizes automatically for you. It works out as 23.9 fixed point for the constants I'm using.

I even wrote a really basic module to handle multiple projectiles. Happy to share if you're interested in C code.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Jan 2023
  • Posts: 2
Reply with quote
Post Posted: Fri Jan 06, 2023 4:55 am
Thank you everyone for the suggestions. I began to implement them and I am getting the results I wanted. I haven't done a whole lot of assembly programming and this had me stumped, so I appreciate the advice.
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!