Writing my first (simple) game in assembly

Página 2/5
1 | | 3 | 4 | 5

Por Pbk71

Expert (101)

Imagen del Pbk71

24-05-2021, 08:00

santiontanon wrote:

Nice and smooth! Are you considering the MSXDev if you finish a game on time? Smile

Once it is finished I will offer it to the contest. But I don't know if it will be MSXDev'21. If I get the the gameplay to work the game also will need quite some effort to create good graphics, sound and an intro. Being just a beginner to assembly, this is gonna take much time I am afraid Wink But maybe 3 months is enough.

Por albs_br

Champion (296)

Imagen del albs_br

24-05-2021, 16:15

The physics of the jump is wonderful. I hope to be able to do something similar in my game, Go Penguin.

Por Pbk71

Expert (101)

Imagen del Pbk71

24-05-2021, 19:37

albs_br wrote:

The physics of the jump is wonderful. I hope to be able to do something similar in my game, Go Penguin.

Thanks. Yeah, it would be nice if you could add a more smooth jump. I personally use gravity and jumpspeed to create jumps. I have been using this often in higher level languages and it was a challenge to implement this in assembly.

In higher level languages I use decimal numbers like 0.3 for gravity. My solution in assembly is to use a word for the y coordinate where the high bite is the actual coordinate on screen. This gives me more flexibility as I can add more than just integers to the coordinate but I don't have to use actual decimal numbers. So for instance if the y coordinate is h3200 and the jumpspeed is h012C then the y coordinate will gradually change:

As a word it is:
h3200 > h332C > h3458 > h3584 > h36B0 > h37DC > h3908 > ...

And than the actual y coordinate, the high byte, is:
h32 > h33 > h34 > h35 > h36 > h37 > h39 > ...

I'm quite happy with the effect this gives. I also use it in my scrolling floor to change the scrollspeed.

Por Grauw

Ascended (9905)

Imagen del Grauw

24-05-2021, 19:28

This is called fixed-point arithmetic, it’s nice and fast to calculate.

Por Pbk71

Expert (101)

Imagen del Pbk71

24-05-2021, 19:36

Grauw wrote:

This is called fixed-point arithmetic, it’s nice and fast to calculate.

Cool, I assumed that I was not the first who came up with this, but I didn't know it actually had a specific name. :)

At the moment I am experimenting with smooth scrolling obstacles created with name and pattern tables. I want this to be the 'basic' obstacles in my game and then add some sprites to it for some extra special obstacles or enemies

Here's my first try: https://msxpen.com/codes/-MaURBQjt7Nqi8MbVTJn

I use a buffer of 40 bytes for just one line of characters in this test. Bytes 1 to 32 are on screen and byte 33 to 40 are off screen but can be used to place an obstacle that scrolls into the screen. The extra byte before the buffer is used when objects disappear on the left side of the screen.

Por ToriHino

Paladin (710)

Imagen del ToriHino

24-05-2021, 22:00

Nice, looking good already. I used a similar technique in this game.

Por Pbk71

Expert (101)

Imagen del Pbk71

25-05-2021, 07:28

ToriHino wrote:

Nice, looking good already. I used a similar technique in this game.

Yeah, I noticed that. Cool game btw!

Por albs_br

Champion (296)

Imagen del albs_br

25-05-2021, 16:55

Pbk71 wrote:

In higher level languages I use decimal numbers like 0.3 for gravity. My solution in assembly is to use a word for the y coordinate where the high byte is the actual coordinate on screen.

Yep. I would do the same way.

One question: why not use screen 2? It makes it possible to achieve far better graphics by using a combination of tiles and sprites. One color per line for tiles (plus black background necessary for scrolling), and one sprite for aditional color.

Por Pbk71

Expert (101)

Imagen del Pbk71

25-05-2021, 21:48

albs_br wrote:

One question: why not use screen 2? It makes it possible to achieve far better graphics by using a combination of tiles and sprites. One color per line for tiles (plus black background necessary for scrolling), and one sprite for aditional color.

Well, I'm a beginner and still learning how these things work and I'm just figuring out how screen 1 works. As soon as I master screen 1 I'm going to dive into screen 2 as well Smile

Have been experimenting again an combined moving obstacles with my jump and moving floor routine. No collision checking yet and it is far from what the game(play) should become. Still, happy I got so far by now:
https://msxpen.com/codes/-Ma_0ZV4tmYJMFi_hqKa

Por Daemos

Paragon (1948)

Imagen del Daemos

26-05-2021, 07:30

Looking awesome. I cannot help but to notice that the jump key is not limited. As soon as you touch the ground you jump back up again. There is a little snippet of code you can use to make that feel very smooth.


ld c,a
 ld (controls), a
 
 ld  hl,Controls
 ld  a,(hl)
 xor  c
 and  c
 ld  (NewPrControls),a
 ld  (hl), c

You basicly take your read controls that are in register a and apply this operation. You will have newprcontols which only triggers again after you release you jump button. Save a into controls before doing thay operation and you can read keypresses and check if keys are pressed.

Página 2/5
1 | | 3 | 4 | 5