Forums

Had to take a break from programming today.

Added a guy to the title screen, not sure if I'll do anymore with it yet, I might animate the laser.

alpha-16-newtitles-export.gif (22.58 KB)

Started doing boss stuff.

I had considered vertical scrolling/moving boss but quickly gave up on that idea, plus I think horizontal only is fine for this game.

alpha-17-newboss-export.gif (463.94 KB)

Wow, it looks really great now!

it's so cool !
Can't wait to see the rest.

Thanks!

Another work in progress boss.

alpha-18-newboss_b-export.gif (256.56 KB)

Small bump with the jungle stage preview. This might be the last stage background I show before the game is finished I think.

Lots of enemy sprites and enemy events to do next.

alpha-22-stage2-waterfall-export.gif (458.43 KB)

Freed up some tiles on the volcano stage so added some more lava to give it some movement.

Added 3 new enemy sprites today too, a lot left to do...

Sound and music is complete and in the game though.

new-lava-export.gif (581.7 KB)

Small bump. Starting to design enemy and stage patterns now.

There seems to be plenty of CPU time left for more bullets but this enemy will probably do something more interesting.

spawner-export.gif (367.28 KB)

Great job! I follow your progress via X, and your game seems to me to have nothing to envy compared to commercial games for the SMS in the 90s.

Looks great. Can't wait to play it.
Please go easy with the color purple. It's a dead give away that the game is not designed by graphic designers. Me personally, I really hate the color purple in video games. But if it's just me then ignore the rant. lol.

Aranya wrote

Great job! I follow your progress via X, and your game seems to me to have nothing to envy compared to commercial games for the SMS in the 90s.

Thanks Aranya!

D wrote

Looks great. Can't wait to play it.
Please go easy with the color purple. It's a dead give away that the game is not designed by graphic designers. Me personally, I really hate the color purple in video games. But if it's just me then ignore the rant. lol.

Thanks! I'm sorry you don't like purple but I probably won't change much, particularly on the backgrounds. It's a good compliment to yellow, which I'm sure you understand if you're a graphic designer.

I recently added a darker red to the sprite palette so that will replace purple in a lot of places though.

Speaking of graphic designers, I am one and I have no problems whatsoever with the color purple. I think your graphics are excellent and your choice of color in particular is outstanding.

What I’m not too sure about is that the origin of the player's shots is off-center of the player sprite. I understand it from a graphical point of view, but I think it might feel weird and require much getting used to in regards to the gameplay.

[quote="Kagesan"]Speaking of graphic designers, I am one and I have no problems whatsoever with the color purple. I think your graphics are excellent and your choice of color in particular is outstanding.[quote]

Thanks!

Quote

What I’m not too sure about is that the origin of the player's shots is off-center of the player sprite. I understand it from a graphical point of view, but I think it might feel weird and require much getting used to in regards to the gameplay.

That's a good point, the player is more visible than the player gun so it makes sense. I'll try it centred for a while and see how it feels.

Hello and first of all congratulations for the development made so far, it looks stellar!

badcomputer wrote

Kagesan wrote

What I’m not too sure about is that the origin of the player's shots is off-center of the player sprite. I understand it from a graphical point of view, but I think it might feel weird and require much getting used to in regards to the gameplay.

That's a good point, the player is more visible than the player gun so it makes sense. I'll try it centred for a while and see how it feels.

This reminds me of some games which happened to have the shots off-centered: Time Soldiers and Rambo-first-blood-part-2 (although technically they might not qualify as "fixed screen shoot-em-up" though).

Just wanted to throw in this :)

22772--time-soldiers.png (3.31 KB)

rambo-first-blood-part-2-03.big.jpg (173.39 KB)

umbe1987 wrote

Hello and first of all congratulations for the development made so far, it looks stellar!

Thanks!

umbe1987 wrote

badcomputer wrote

Kagesan wrote

What I’m not too sure about is that the origin of the player's shots is off-center of the player sprite. I understand it from a graphical point of view, but I think it might feel weird and require much getting used to in regards to the gameplay.

That's a good point, the player is more visible than the player gun so it makes sense. I'll try it centred for a while and see how it feels.

This reminds me of some games which happened to have the shots off-centered: Time Soldiers and Rambo-first-blood-part-2 (although technically they might not qualify as "fixed screen shoot-em-up" though).

Just wanted to throw in this :)

I like Time Soldiers but wasn't a big fan of the guns to the side, it seems to work less well with 8 directions.

Continuing work on this mid boss.

Starting work on enemies with the mid boss turned out to be a good idea, as a mid boss like this has allowd me to work on simple movement and shooting functions and also branching patterns that big bosses have.

I have a lot of the underlying code in place for small enemies and bosses now, but building good/fun enemy patterns is gonna take a lot of time...

spawner2-export.gif (162.73 KB)

Some WIP screenshots/marketing. These stages will likely be the "back of the box" shots. There are two other stages that won't be revealed until some time after release.

titles-1.png (6.76 KB)

desert-1.png (10.28 KB)

jungle-1.png (12.43 KB)

volcano-1.png (11.68 KB)

Gorgeous looking game, much like your last game. The palette really pops. Very nice job on all your designs.

badcomputer wrote

Some WIP screenshots/marketing. These stages will likely be the "back of the box" shots. There are two other stages that won't be revealed until some time after release.

Have been following you on Twitter!!! Awesome game...crossing my fingers for a physical release. Keep up the good work!!!

Thanks guys!

Dezanuebe wrote

Have been following you on Twitter!!! Awesome game...crossing my fingers for a physical release. Keep up the good work!!!

I'm hoping for a physical release too, but just focussing on finishing the game for now.

I believe your game definitely deserves a physical release.

"There are two other stages that won't be revealed until some time after the release."

I like this kind of secrets/surprises.

Aranya wrote

I believe your game definitely deserves a physical release.

"There are two other stages that won't be revealed until some time after the release."

I like this kind of secrets/surprises.

Thanks, yes plenty of surprises still left to show!

And the soundtrack by Crisps, which takes about half the ROM!

I'm currently adding little animations and bits that might drain the CPU. I decided it might be best to add these before building the stage events (enemy spawning), so I know how many enemies and bullets I can get on screen.

Spawning aimed enemy bullets is probably the biggest single-frame CPU hit, even with a lookup table for atan2, so I'm spacing those out appropriately.

new-en-movementdetails-export.gif (413.1 KB)

badcomputer wrote

Spawning aimed enemy bullets is probably the biggest single-frame CPU hit, even with a lookup table for atan2, so I'm spacing those out appropriately.

Why do you want to actually calculate the trajectory?

For Flight of Pigarus I used four lookup tables with hardcoded x/y speed values for 16 directions. I only had to check the player's position relative to the enemy bullet source to assign the correct values to the bullet entity. The tables didn’t get more granular than 8x8 pixel cells and the accuracy of the aim was still more than sufficient. In your case, things could even be simpler, since your player's y position is fixed. That way you get aimed bullets with a minimum of cpu time wasted.

Kagesan wrote

badcomputer wrote

Spawning aimed enemy bullets is probably the biggest single-frame CPU hit, even with a lookup table for atan2, so I'm spacing those out appropriately.

Why do you want to actually calculate the trajectory?

For Flight of Pigarus I used four lookup tables with hardcoded x/y speed values for 16 directions. I only had to check the player's position relative to the enemy bullet source to assign the correct values to the bullet entity. The tables didn’t get more granular than 8x8 pixel cells and the accuracy of the aim was still more than sufficient. In your case, things could even be simpler, since your player's y position is fixed. That way you get aimed bullets with a minimum of cpu time wasted.

Hmm maths is not my strong point (to put it mildly) so I could be over-engineering the problem.

I have an atan2 LUT (2d array) 32x24 which holds a value for each 8x8 pixel cell. I calculate the enemy-player offset and round to 8x8 pixel coord, and use those coords to get the atan2 value, and then use that to fetch the velocity from the SIN/COS LUT.

This is the function:

(create_next_* are globals for the next "creation" event normally set/used elsewhere)

bool enemy_bullet_aimed_create(void) {
if (num_enemy_shots >= MAX_ENEMY_SHOTS) {
return false;
}

static signed int dx, dy;
static unsigned char atan_two;

dx = (FIXED_TO_INT(player_x) + 8) - (create_next_at_x + 4);
dy = (FIXED_TO_INT(player_y) + 8) - (create_next_at_y + 4);

atan_two = atan2_get((dy + 4) >> 3, (dx + 4) >> 3);

SMS_mapROMBank(CODE_BANK_1_NUM); // SIN_LUT

create_next_vx = SIN_LUT[atan_two + 64] << 2;
create_next_vy = SIN_LUT[atan_two] << 2;

static EnemyShot *s;
s = &enemy_shots[num_enemy_shots++];
enemy_shot_set_new(s);
s->update_func = enemy_bullet_update;

return true;
}

One thing is I still need to be able to adjust velocity of aimed bullets based on 3 difficulty levels, but that's not included in the function yet.

Open to any suggestions for changes/improvements!

As an addition to the above, I'm using only 16 directions for enemy movement events to keep it simple to construct paths, but I felt it didn't offer enough accuracy for aimed bullets. Some shot were missing and the player didn't have to move.

Your method doesn't seem terribly inefficient, actually. It's quite similar to what I do.

Look at the attached picture. (Ignore the black bars at the top and at the left, I handle those directions elsewhere.) Each of the cell colors represents one of 16 directions an enemy bullet can be shot. The table shown is for the case that the player is below and to the right of the enemy. I've got three similar maps for the other three possibilities. I total, there are 64 directions the enemies can shoot.

For determining the direction the enemy has to shoot, I just have to calculate in which cell relative to the enemy the player is.

;=================================================================================
; Set direction for aimed shots
;=================================================================================

; expects enemy xy in de
; destroys a, hl
; returns direction (0-63) in a

.section "aiming" free

AimAtPlayer:

ld a, :AimingTable ; change bank
ld (BankSwitch), a

ld hl, AimingTable ; set base address for aiming table

ld a, (PlayerY+1) ; get player y position
sub e ; subtract enemy y position
jr nc, + ; is player below enemy?
neg ; no? then invert distance
inc h ; change table
+: and %11110000 ; extract higher nibble
ld l, a ; store in index byte

ld a, (PlayerX+1) ; get player x position
sub d ; subtract enemy y position
jr nc, + ; is player right of enemy?
neg ; no? then invert distance
inc h ; change table
inc h
+: rra ; rotate distance into lower nibble
rra
rra
rra
and %00001111 ; extract lower nibble
or l ; combine with higher nibble from earlier
ld l, a ; put result back in index byte

ld a, (hl) ; get direction (0-63) from aiming table

ret

.ends

When it comes to updating the bullet, I just use the direction value to access a table of 64 pairs of 16-bit values representing the x and y speeds in 8.8 fixed point numbers and fetch from there what I have to add to the current bullet position.
If you need different speeds, just prepare different tables to access.

64 possible directions have always been accurate enough for me, but actually you can blow all your 64 directions on two tables instead of four since the player is always below the enemy, thus their aim being potentially even better.

Long story short: I strongly suggest precalculating as much as possible.

aiming_table_16_dr.png (1.18 KB)

Kagesan wrote

Your method doesn't seem terribly inefficient, actually. It's quite similar to what I do.

Look at the attached picture. (Ignore the black bars at the top and at the left, I handle those directions elsewhere.) Each of the cell colors represents one of 16 directions an enemy bullet can be shot. The table shown is for the case that the player is below and to the right of the enemy. I've got three similar maps for the other three possibilities. I total, there are 64 directions the enemies can shoot.

For determining the direction the enemy has to shoot, I just have to calculate in which cell relative to the enemy the player is.

;=================================================================================
; Set direction for aimed shots
;=================================================================================

; expects enemy xy in de
; destroys a, hl
; returns direction (0-63) in a

.section "aiming" free

AimAtPlayer:

ld a, :AimingTable ; change bank
ld (BankSwitch), a

ld hl, AimingTable ; set base address for aiming table

ld a, (PlayerY+1) ; get player y position
sub e ; subtract enemy y position
jr nc, + ; is player below enemy?
neg ; no? then invert distance
inc h ; change table
+: and %11110000 ; extract higher nibble
ld l, a ; store in index byte

ld a, (PlayerX+1) ; get player x position
sub d ; subtract enemy y position
jr nc, + ; is player right of enemy?
neg ; no? then invert distance
inc h ; change table
inc h
+: rra ; rotate distance into lower nibble
rra
rra
rra
and %00001111 ; extract lower nibble
or l ; combine with higher nibble from earlier
ld l, a ; put result back in index byte

ld a, (hl) ; get direction (0-63) from aiming table

ret

.ends

When it comes to updating the bullet, I just use the direction value to access a table of 64 pairs of 16-bit values representing the x and y speeds in 8.8 fixed point numbers and fetch from there what I have to add to the current bullet position.
If you need different speeds, just prepare different tables to access.

64 possible directions have always been accurate enough for me, but actually you can blow all your 64 directions on two tables instead of four since the player is always below the enemy, thus their aim being potentially even better.

Long story short: I strongly suggest precalculating as much as possible.

Ah sorry I misread your post, you have 16 directions per quadrant.

I suppose a first optimisation is to pre-calculate the 3 difficulty velocity tables instead of multiplying those from SIN/COS at runtime.

I considered cutting down the velocity table too as enemies only fire south on the Y-axis but I might need a homing shot for the player later on.

Thanks for your input.

note that

create_next_vx = SIN_LUT[atan_two + 64] << 2;
create_next_vy = SIN_LUT[atan_two] << 2;

can be troublesome, you better do

create_next_vy = SIN_LUT[atan_two] << 2;
atan_two += 64;
create_next_vx = SIN_LUT[atan_two] << 2;

Author	Message
badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Sun Mar 31, 2024 12:06 am
badcomputer Joined: 19 Oct 2023 Posts: 152	Had to take a break from programming today. Added a guy to the title screen, not sure if I'll do anymore with it yet, I might animate the laser. alpha-16-newtitles-export.gif (22.58 KB)

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Mon Apr 01, 2024 8:03 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	Started doing boss stuff. I had considered vertical scrolling/moving boss but quickly gave up on that idea, plus I think horizontal only is fine for this game. alpha-17-newboss-export.gif (463.94 KB)

baude Joined: 15 Dec 2015 Posts: 17	Posted: Tue Apr 02, 2024 7:42 am
baude Joined: 15 Dec 2015 Posts: 17	Wow, it looks really great now!

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Tue Apr 02, 2024 8:23 am
KingQuack Joined: 15 Jul 2022 Posts: 29	it's so cool ! Can't wait to see the rest.

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Tue Apr 02, 2024 11:04 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	Thanks! Another work in progress boss. alpha-18-newboss_b-export.gif (256.56 KB)

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Wed Apr 10, 2024 8:54 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	Small bump with the jungle stage preview. This might be the last stage background I show before the game is finished I think. Lots of enemy sprites and enemy events to do next. alpha-22-stage2-waterfall-export.gif (458.43 KB)

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Wed Apr 17, 2024 6:46 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	Freed up some tiles on the volcano stage so added some more lava to give it some movement. Added 3 new enemy sprites today too, a lot left to do... Sound and music is complete and in the game though. new-lava-export.gif (581.7 KB)

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Thu Apr 25, 2024 7:04 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	Small bump. Starting to design enemy and stage patterns now. There seems to be plenty of CPU time left for more bullets but this enemy will probably do something more interesting. spawner-export.gif (367.28 KB)

Aranya Joined: 02 Mar 2011 Posts: 168 Location: Valencia,Spain.	Posted: Thu Apr 25, 2024 7:56 pm
	Great job! I follow your progress via X, and your game seems to me to have nothing to envy compared to commercial games for the SMS in the 90s.

D Joined: 01 Apr 2005 Posts: 252 Location: Almere, The Netherlands	Posted: Thu Apr 25, 2024 10:10 pm
	Looks great. Can't wait to play it. Please go easy with the color purple. It's a dead give away that the game is not designed by graphic designers. Me personally, I really hate the color purple in video games. But if it's just me then ignore the rant. lol.

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Fri Apr 26, 2024 8:03 am
badcomputer Joined: 19 Oct 2023 Posts: 152	Aranya wrote Great job! I follow your progress via X, and your game seems to me to have nothing to envy compared to commercial games for the SMS in the 90s. Thanks Aranya!

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Fri Apr 26, 2024 8:56 am
badcomputer Joined: 19 Oct 2023 Posts: 152	D wrote Looks great. Can't wait to play it. Please go easy with the color purple. It's a dead give away that the game is not designed by graphic designers. Me personally, I really hate the color purple in video games. But if it's just me then ignore the rant. lol. Thanks! I'm sorry you don't like purple but I probably won't change much, particularly on the backgrounds. It's a good compliment to yellow, which I'm sure you understand if you're a graphic designer. I recently added a darker red to the sprite palette so that will replace purple in a lot of places though.

Kagesan Joined: 01 Feb 2014 Posts: 883	Posted: Fri Apr 26, 2024 9:20 am
Kagesan Joined: 01 Feb 2014 Posts: 883	Speaking of graphic designers, I am one and I have no problems whatsoever with the color purple. I think your graphics are excellent and your choice of color in particular is outstanding. What I’m not too sure about is that the origin of the player's shots is off-center of the player sprite. I understand it from a graphical point of view, but I think it might feel weird and require much getting used to in regards to the gameplay.

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Fri Apr 26, 2024 10:59 am
badcomputer Joined: 19 Oct 2023 Posts: 152	[quote="Kagesan"]Speaking of graphic designers, I am one and I have no problems whatsoever with the color purple. I think your graphics are excellent and your choice of color in particular is outstanding.[quote] Thanks! Quote What I’m not too sure about is that the origin of the player's shots is off-center of the player sprite. I understand it from a graphical point of view, but I think it might feel weird and require much getting used to in regards to the gameplay. That's a good point, the player is more visible than the player gun so it makes sense. I'll try it centred for a while and see how it feels.

umbe1987 Joined: 03 Dec 2021 Posts: 55	Posted: Fri Apr 26, 2024 1:27 pm
umbe1987 Joined: 03 Dec 2021 Posts: 55	Hello and first of all congratulations for the development made so far, it looks stellar! badcomputer wrote Kagesan wrote What I’m not too sure about is that the origin of the player's shots is off-center of the player sprite. I understand it from a graphical point of view, but I think it might feel weird and require much getting used to in regards to the gameplay. That's a good point, the player is more visible than the player gun so it makes sense. I'll try it centred for a while and see how it feels. This reminds me of some games which happened to have the shots off-centered: Time Soldiers and Rambo-first-blood-part-2 (although technically they might not qualify as "fixed screen shoot-em-up" though). Just wanted to throw in this :) 22772--time-soldiers.png (3.31 KB) rambo-first-blood-part-2-03.big.jpg (173.39 KB)

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Fri Apr 26, 2024 7:57 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	umbe1987 wrote Hello and first of all congratulations for the development made so far, it looks stellar! Thanks! umbe1987 wrote badcomputer wrote Kagesan wrote What I’m not too sure about is that the origin of the player's shots is off-center of the player sprite. I understand it from a graphical point of view, but I think it might feel weird and require much getting used to in regards to the gameplay. That's a good point, the player is more visible than the player gun so it makes sense. I'll try it centred for a while and see how it feels. This reminds me of some games which happened to have the shots off-centered: Time Soldiers and Rambo-first-blood-part-2 (although technically they might not qualify as "fixed screen shoot-em-up" though). Just wanted to throw in this :) I like Time Soldiers but wasn't a big fan of the guns to the side, it seems to work less well with 8 directions.

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Fri Apr 26, 2024 8:02 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	Continuing work on this mid boss. Starting work on enemies with the mid boss turned out to be a good idea, as a mid boss like this has allowd me to work on simple movement and shooting functions and also branching patterns that big bosses have. I have a lot of the underlying code in place for small enemies and bosses now, but building good/fun enemy patterns is gonna take a lot of time... spawner2-export.gif (162.73 KB)

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Sat Apr 27, 2024 8:52 am
badcomputer Joined: 19 Oct 2023 Posts: 152	Some WIP screenshots/marketing. These stages will likely be the "back of the box" shots. There are two other stages that won't be revealed until some time after release. titles-1.png (6.76 KB) desert-1.png (10.28 KB) jungle-1.png (12.43 KB) volcano-1.png (11.68 KB)

xfixium Joined: 18 Jul 2020 Posts: 386	Posted: Sat Apr 27, 2024 10:23 am
xfixium Joined: 18 Jul 2020 Posts: 386	Gorgeous looking game, much like your last game. The palette really pops. Very nice job on all your designs.

Dezanuebe Joined: 15 Aug 2005 Posts: 25 Location: Odivelas, Portugal	Posted: Sat Apr 27, 2024 11:46 am
	badcomputer wrote Some WIP screenshots/marketing. These stages will likely be the "back of the box" shots. There are two other stages that won't be revealed until some time after release. Have been following you on Twitter!!! Awesome game...crossing my fingers for a physical release. Keep up the good work!!!

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Sat Apr 27, 2024 1:09 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	Thanks guys! Dezanuebe wrote Have been following you on Twitter!!! Awesome game...crossing my fingers for a physical release. Keep up the good work!!! I'm hoping for a physical release too, but just focussing on finishing the game for now.

Aranya Joined: 02 Mar 2011 Posts: 168 Location: Valencia,Spain.	Posted: Sat Apr 27, 2024 7:53 pm
	I believe your game definitely deserves a physical release. "There are two other stages that won't be revealed until some time after the release." I like this kind of secrets/surprises.

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Sun Apr 28, 2024 7:12 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	Aranya wrote I believe your game definitely deserves a physical release. "There are two other stages that won't be revealed until some time after the release." I like this kind of secrets/surprises. Thanks, yes plenty of surprises still left to show! And the soundtrack by Crisps, which takes about half the ROM!

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Yesterday at 12:28 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	I'm currently adding little animations and bits that might drain the CPU. I decided it might be best to add these before building the stage events (enemy spawning), so I know how many enemies and bullets I can get on screen. Spawning aimed enemy bullets is probably the biggest single-frame CPU hit, even with a lookup table for atan2, so I'm spacing those out appropriately. new-en-movementdetails-export.gif (413.1 KB)

Kagesan Joined: 01 Feb 2014 Posts: 883	Posted: Yesterday at 3:13 pm
Kagesan Joined: 01 Feb 2014 Posts: 883	badcomputer wrote Spawning aimed enemy bullets is probably the biggest single-frame CPU hit, even with a lookup table for atan2, so I'm spacing those out appropriately. Why do you want to actually calculate the trajectory? For Flight of Pigarus I used four lookup tables with hardcoded x/y speed values for 16 directions. I only had to check the player's position relative to the enemy bullet source to assign the correct values to the bullet entity. The tables didn’t get more granular than 8x8 pixel cells and the accuracy of the aim was still more than sufficient. In your case, things could even be simpler, since your player's y position is fixed. That way you get aimed bullets with a minimum of cpu time wasted.

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Yesterday at 4:39 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	Kagesan wrote badcomputer wrote Spawning aimed enemy bullets is probably the biggest single-frame CPU hit, even with a lookup table for atan2, so I'm spacing those out appropriately. Why do you want to actually calculate the trajectory? For Flight of Pigarus I used four lookup tables with hardcoded x/y speed values for 16 directions. I only had to check the player's position relative to the enemy bullet source to assign the correct values to the bullet entity. The tables didn’t get more granular than 8x8 pixel cells and the accuracy of the aim was still more than sufficient. In your case, things could even be simpler, since your player's y position is fixed. That way you get aimed bullets with a minimum of cpu time wasted. Hmm maths is not my strong point (to put it mildly) so I could be over-engineering the problem. I have an atan2 LUT (2d array) 32x24 which holds a value for each 8x8 pixel cell. I calculate the enemy-player offset and round to 8x8 pixel coord, and use those coords to get the atan2 value, and then use that to fetch the velocity from the SIN/COS LUT. This is the function: (create_next_* are globals for the next "creation" event normally set/used elsewhere) bool enemy_bullet_aimed_create(void) { if (num_enemy_shots >= MAX_ENEMY_SHOTS) { return false; } static signed int dx, dy; static unsigned char atan_two; dx = (FIXED_TO_INT(player_x) + 8) - (create_next_at_x + 4); dy = (FIXED_TO_INT(player_y) + 8) - (create_next_at_y + 4); atan_two = atan2_get((dy + 4) >> 3, (dx + 4) >> 3); SMS_mapROMBank(CODE_BANK_1_NUM); // SIN_LUT create_next_vx = SIN_LUT[atan_two + 64] << 2; create_next_vy = SIN_LUT[atan_two] << 2; static EnemyShot *s; s = &enemy_shots[num_enemy_shots++]; enemy_shot_set_new(s); s->update_func = enemy_bullet_update; return true; } One thing is I still need to be able to adjust velocity of aimed bullets based on 3 difficulty levels, but that's not included in the function yet. Open to any suggestions for changes/improvements!

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Yesterday at 5:21 pm
badcomputer Joined: 19 Oct 2023 Posts: 152	As an addition to the above, I'm using only 16 directions for enemy movement events to keep it simple to construct paths, but I felt it didn't offer enough accuracy for aimed bullets. Some shot were missing and the player didn't have to move.

Kagesan Joined: 01 Feb 2014 Posts: 883	Posted: Today at 6:16 am
Kagesan Joined: 01 Feb 2014 Posts: 883	Your method doesn't seem terribly inefficient, actually. It's quite similar to what I do. Look at the attached picture. (Ignore the black bars at the top and at the left, I handle those directions elsewhere.) Each of the cell colors represents one of 16 directions an enemy bullet can be shot. The table shown is for the case that the player is below and to the right of the enemy. I've got three similar maps for the other three possibilities. I total, there are 64 directions the enemies can shoot. For determining the direction the enemy has to shoot, I just have to calculate in which cell relative to the enemy the player is. ;================================================================================= ; Set direction for aimed shots ;================================================================================= ; expects enemy xy in de ; destroys a, hl ; returns direction (0-63) in a .section "aiming" free AimAtPlayer: ld a, :AimingTable ; change bank ld (BankSwitch), a ld hl, AimingTable ; set base address for aiming table ld a, (PlayerY+1) ; get player y position sub e ; subtract enemy y position jr nc, + ; is player below enemy? neg ; no? then invert distance inc h ; change table +: and %11110000 ; extract higher nibble ld l, a ; store in index byte ld a, (PlayerX+1) ; get player x position sub d ; subtract enemy y position jr nc, + ; is player right of enemy? neg ; no? then invert distance inc h ; change table inc h +: rra ; rotate distance into lower nibble rra rra rra and %00001111 ; extract lower nibble or l ; combine with higher nibble from earlier ld l, a ; put result back in index byte ld a, (hl) ; get direction (0-63) from aiming table ret .ends When it comes to updating the bullet, I just use the direction value to access a table of 64 pairs of 16-bit values representing the x and y speeds in 8.8 fixed point numbers and fetch from there what I have to add to the current bullet position. If you need different speeds, just prepare different tables to access. 64 possible directions have always been accurate enough for me, but actually you can blow all your 64 directions on two tables instead of four since the player is always below the enemy, thus their aim being potentially even better. Long story short: I strongly suggest precalculating as much as possible. aiming_table_16_dr.png (1.18 KB)

badcomputer Joined: 19 Oct 2023 Posts: 152	Posted: Today at 8:05 am
badcomputer Joined: 19 Oct 2023 Posts: 152	Kagesan wrote Your method doesn't seem terribly inefficient, actually. It's quite similar to what I do. Look at the attached picture. (Ignore the black bars at the top and at the left, I handle those directions elsewhere.) Each of the cell colors represents one of 16 directions an enemy bullet can be shot. The table shown is for the case that the player is below and to the right of the enemy. I've got three similar maps for the other three possibilities. I total, there are 64 directions the enemies can shoot. For determining the direction the enemy has to shoot, I just have to calculate in which cell relative to the enemy the player is. ;================================================================================= ; Set direction for aimed shots ;================================================================================= ; expects enemy xy in de ; destroys a, hl ; returns direction (0-63) in a .section "aiming" free AimAtPlayer: ld a, :AimingTable ; change bank ld (BankSwitch), a ld hl, AimingTable ; set base address for aiming table ld a, (PlayerY+1) ; get player y position sub e ; subtract enemy y position jr nc, + ; is player below enemy? neg ; no? then invert distance inc h ; change table +: and %11110000 ; extract higher nibble ld l, a ; store in index byte ld a, (PlayerX+1) ; get player x position sub d ; subtract enemy y position jr nc, + ; is player right of enemy? neg ; no? then invert distance inc h ; change table inc h +: rra ; rotate distance into lower nibble rra rra rra and %00001111 ; extract lower nibble or l ; combine with higher nibble from earlier ld l, a ; put result back in index byte ld a, (hl) ; get direction (0-63) from aiming table ret .ends When it comes to updating the bullet, I just use the direction value to access a table of 64 pairs of 16-bit values representing the x and y speeds in 8.8 fixed point numbers and fetch from there what I have to add to the current bullet position. If you need different speeds, just prepare different tables to access. 64 possible directions have always been accurate enough for me, but actually you can blow all your 64 directions on two tables instead of four since the player is always below the enemy, thus their aim being potentially even better. Long story short: I strongly suggest precalculating as much as possible. Ah sorry I misread your post, you have 16 directions per quadrant. I suppose a first optimisation is to pre-calculate the 3 difficulty velocity tables instead of multiplying those from SIN/COS at runtime. I considered cutting down the velocity table too as enemies only fire south on the Y-axis but I might need a homing shot for the player later on. Thanks for your input.

sverx Joined: 05 Sep 2013 Posts: 3845 Location: Stockholm, Sweden	Posted: Today at 12:01 pm
	note that create_next_vx = SIN_LUT[atan_two + 64] << 2; create_next_vy = SIN_LUT[atan_two] << 2; can be troublesome, you better do create_next_vy = SIN_LUT[atan_two] << 2; atan_two += 64; create_next_vx = SIN_LUT[atan_two] << 2;

Forums

View topic - Frontier Force (another fixed screen shoot-em-up)