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;

Just continuing updates on the game from the devkit thread here.

The switch to code banking failed after trying to refactor for a couple of days, so I've decided to stick with what I've got and switch banks manually if needed.

There seems to be little difference other than having to manage which code bank is active (above banks 0 and 1), unless there are other differences I'm not aware of?

It shouldn't impact the game's design as most of the main systems are complete and it's just a case of adding more data (enemy events, stage events, gfx...) to finish the game.

If you switch banks 'manually' then your code will be paged in slot 2 (that is at address 0x8000) and this means that code can't page any asset (because it would remove itself from the addressable space the moment it does that) so the code you place there has this limitation.

sverx wrote

If you switch banks 'manually' then your code will be paged in slot 2 (that is at address 0x8000) and this means that code can't page any asset (because it would remove itself from the addressable space the moment it does that) so the code you place there has this limitation.

Ah yea this is one limitation I noticed.

As far as I can tell, I either need to include the assets in the banked code file as well, or call the asset loading function from bank 0 or 1 where it can page the assets to bank 2 to load. At the moment I'm choosing to load assets from a function in bank 0 or 1, so I can keep using asset2banks easily and don't need to copy them to my banked code file.

It still has saved me a lot of bytes by banking a whole module, I just need to load assets from 0 or 1.

Worn out from bug fixing but we've got a stable build again and I've been able to add a few more enemy patterns today.

Decided to do a little more gfx work polishing this boss too.

boss_c-export.png (4.63 KB)

Added player dash on double tapping move for a quick escape.

You also spawn score bonuses by dashing through enemy bullets, it's harder than it looks.

It needs more testing but I think with the right settings it won't be spammed to move everwhere (famous last words?)

badcomputer wrote

Added player dash on double tapping move for a quick escape.

You also spawn score bonuses by dashing through enemy bullets, it's harder than it looks.

It needs more testing but I think with the right settings it won't be spammed to move everwhere (famous last words?)

This looks COOL as Heck!!! drooling over these .gifs :D

segasonicfan wrote

This looks COOL as Heck!!! drooling over these .gifs :D

Thanks!

Work continues, mainly doing gfx stuff for now. Here's the title screen so far.

new-titles-export-256.gif (79.69 KB)

badcomputer wrote

segasonicfan wrote

This looks COOL as Heck!!! drooling over these .gifs :D

Thanks!

Work continues, mainly doing gfx stuff for now. Here's the title screen so far.

whoa what an unexpectedly rad intro screen. It was real smart use of space and animation to make that laser shot.

will you release a demo for people to try when it's ready? :D

segasonicfan wrote

whoa what an unexpectedly rad intro screen. It was real smart use of space and animation to make that laser shot.

will you release a demo for people to try when it's ready? :D

I have no plans to release a demo.

badcomputer wrote

segasonicfan wrote

whoa what an unexpectedly rad intro screen. It was real smart use of space and animation to make that laser shot.

will you release a demo for people to try when it's ready? :D

I have no plans to release a demo.

bummer. so it will just be the full game for sale at some point with no way to try it out?

segasonicfan wrote

bummer. so it will just be the full game for sale at some point with no way to try it out?

That's right. It's a pretty simple arcade game, trailers and videos will give you a pretty good idea of what to expect, and the time I would spend making and releasing a demo can be spent on improving the game instead.

badcomputer wrote

segasonicfan wrote

bummer. so it will just be the full game for sale at some point with no way to try it out?

That's right. It's a pretty simple arcade game, trailers and videos will give you a pretty good idea of what to expect, and the time I would spend making and releasing a demo can be spent on improving the game instead.

when will you release the game and how can we buy a copy? cheers.

Dezanuebe wrote

when will you release the game and how can we buy a copy? cheers.

Probably released in 2025. I plan to release the digital version on itch.io, possibly physical release later.

badcomputer wrote

Dezanuebe wrote

when will you release the game and how can we buy a copy? cheers.

Probably released in 2025. I plan to release the digital version on itch.io, possibly physical release later.

Thanks for the reply. Will buy a physical copy for sure.

Back to work, implementing the player bomb.

Initial mockup for the bomb animation (minus collision shapes). I plan to alternate drawing frames with enemy sprites. If it works well then maybe I can add 1 or 2 animation frames to the bomb.

Fortunately I can remove enemy bullets when the bomb triggers (as a gameplay benefit for the player) so I will only need to draw enemies on the bomb-off frame.

I haven't decided yet whether the game will pause for the effect, to make it more dramatic, I need to test it.

I settled on a simpler bomb sprite to keep more explosions, which seems better for now. I might come back to it but for now I'm moving on to the next thing.

I need some second opinions on this.

If the player can only move left and right, how would you want to assign the buttons yourself for the following actions?

- shoot (can be held down for auto-fire, but there is ammo so you may want to stop firing eventually)
- fire one bomb (upwards)
- switch weapon left
- switch weapon right

Shoot: Button 2
Bomb: Button 1
Switch weapon left: D-pad down
Switch weapon right: D-pad up

would be my choices.

Thanks Kagesan.

So far I've gone with Maxim's suggestion on the Discord as the default, only because it feels more natural with left and right switchign on screen:

Shoot: Button 1
Bomb: Button 2
Switch weapon left: D-pad down + Button 1
Switch weapon right: D-pad down + Button 2

There will also be an option to use bombs as laser ammo instead, so when the laser runs out of ammo it will automatically take 1 bomb and refill laser ammo. The laser is unique as it generates more score bonuses, but bombs are obviously useful for survival, so there's a trade off. Beginners would use the bomb, score chasers would use laser ammo.

You can still fire bombs with the "bombs as laser refill" option selected though.

Finally, I also added pause on the pad (console pause still works too):

Pause Toggle: D-pad up + Button 2.

That sounds reasonable to, even though I always prefer simple button presses to button combinations if possible.

Still, I suggest switching around the shot and bomb buttons. The shot button is one that’s going to be held down a lot instead if just tapped, so it makes sense to use the outer button of the pad for that, because your thumb reaches for the buttons from the right and there’s a chance you might accidentally trigger a bomb if you’re forced to reach over the button to hold down the other one.

When developing Pigarus I first had the shot button and speed switch button mapped to 1 and 2 respectively, but found out that it was a lot more comfortable to play with the buttons mapped the other way round.

Author	Message
badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Sun Mar 31, 2024 12:06 am
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 183	Posted: Mon Apr 01, 2024 8:03 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 21	Posted: Tue Apr 02, 2024 7:42 am
baude Joined: 15 Dec 2015 Posts: 21	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: 183	Posted: Tue Apr 02, 2024 11:04 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	Thanks! Another work in progress boss. alpha-18-newboss_b-export.gif (256.56 KB)

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Wed Apr 10, 2024 8:54 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 183	Posted: Wed Apr 17, 2024 6:46 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 183	Posted: Thu Apr 25, 2024 7:04 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 171 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: 253 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: 183	Posted: Fri Apr 26, 2024 8:03 am
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 183	Posted: Fri Apr 26, 2024 8:56 am
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 893	Posted: Fri Apr 26, 2024 9:20 am
Kagesan Joined: 01 Feb 2014 Posts: 893	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: 183	Posted: Fri Apr 26, 2024 10:59 am
badcomputer Joined: 19 Oct 2023 Posts: 183	[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: 183	Posted: Fri Apr 26, 2024 7:57 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 183	Posted: Fri Apr 26, 2024 8:02 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 183	Posted: Sat Apr 27, 2024 8:52 am
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 387	Posted: Sat Apr 27, 2024 10:23 am
xfixium Joined: 18 Jul 2020 Posts: 387	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: 27 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: 183	Posted: Sat Apr 27, 2024 1:09 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 171 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: 183	Posted: Sun Apr 28, 2024 7:12 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 183	Posted: Fri May 03, 2024 12:28 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 893	Posted: Fri May 03, 2024 3:13 pm
Kagesan Joined: 01 Feb 2014 Posts: 893	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: 183	Posted: Fri May 03, 2024 4:39 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 183	Posted: Fri May 03, 2024 5:21 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 893	Posted: Sat May 04, 2024 6:16 am
Kagesan Joined: 01 Feb 2014 Posts: 893	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: 183	Posted: Sat May 04, 2024 8:05 am
badcomputer Joined: 19 Oct 2023 Posts: 183	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: 3912 Location: Stockholm, Sweden	Posted: Sat May 04, 2024 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;

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Mon May 06, 2024 10:58 am
badcomputer Joined: 19 Oct 2023 Posts: 183	Just continuing updates on the game from the devkit thread here. The switch to code banking failed after trying to refactor for a couple of days, so I've decided to stick with what I've got and switch banks manually if needed. There seems to be little difference other than having to manage which code bank is active (above banks 0 and 1), unless there are other differences I'm not aware of? It shouldn't impact the game's design as most of the main systems are complete and it's just a case of adding more data (enemy events, stage events, gfx...) to finish the game.

sverx Joined: 05 Sep 2013 Posts: 3912 Location: Stockholm, Sweden	Posted: Mon May 06, 2024 1:17 pm
	If you switch banks 'manually' then your code will be paged in slot 2 (that is at address 0x8000) and this means that code can't page any asset (because it would remove itself from the addressable space the moment it does that) so the code you place there has this limitation.

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Mon May 06, 2024 1:25 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	sverx wrote If you switch banks 'manually' then your code will be paged in slot 2 (that is at address 0x8000) and this means that code can't page any asset (because it would remove itself from the addressable space the moment it does that) so the code you place there has this limitation. Ah yea this is one limitation I noticed. As far as I can tell, I either need to include the assets in the banked code file as well, or call the asset loading function from bank 0 or 1 where it can page the assets to bank 2 to load. At the moment I'm choosing to load assets from a function in bank 0 or 1, so I can keep using asset2banks easily and don't need to copy them to my banked code file. It still has saved me a lot of bytes by banking a whole module, I just need to load assets from 0 or 1.

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Mon May 06, 2024 8:19 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	Worn out from bug fixing but we've got a stable build again and I've been able to add a few more enemy patterns today. Decided to do a little more gfx work polishing this boss too. boss_c-export.png (4.63 KB)

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Sat May 11, 2024 12:30 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	Added player dash on double tapping move for a quick escape. You also spawn score bonuses by dashing through enemy bullets, it's harder than it looks. It needs more testing but I think with the right settings it won't be spammed to move everwhere (famous last words?)

segasonicfan Joined: 05 Jan 2006 Posts: 407 Location: USA	Posted: Sat Jul 27, 2024 10:00 pm
	badcomputer wrote Added player dash on double tapping move for a quick escape. You also spawn score bonuses by dashing through enemy bullets, it's harder than it looks. It needs more testing but I think with the right settings it won't be spammed to move everwhere (famous last words?) This looks COOL as Heck!!! drooling over these .gifs :D

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Sun Aug 04, 2024 10:58 am
badcomputer Joined: 19 Oct 2023 Posts: 183	segasonicfan wrote This looks COOL as Heck!!! drooling over these .gifs :D Thanks! Work continues, mainly doing gfx stuff for now. Here's the title screen so far. new-titles-export-256.gif (79.69 KB)

segasonicfan Joined: 05 Jan 2006 Posts: 407 Location: USA	Posted: Sun Aug 04, 2024 9:39 pm
	badcomputer wrote segasonicfan wrote This looks COOL as Heck!!! drooling over these .gifs :D Thanks! Work continues, mainly doing gfx stuff for now. Here's the title screen so far. whoa what an unexpectedly rad intro screen. It was real smart use of space and animation to make that laser shot. will you release a demo for people to try when it's ready? :D

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Mon Aug 05, 2024 3:08 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	segasonicfan wrote whoa what an unexpectedly rad intro screen. It was real smart use of space and animation to make that laser shot. will you release a demo for people to try when it's ready? :D I have no plans to release a demo.

segasonicfan Joined: 05 Jan 2006 Posts: 407 Location: USA	Posted: Mon Aug 05, 2024 7:23 pm
	badcomputer wrote segasonicfan wrote whoa what an unexpectedly rad intro screen. It was real smart use of space and animation to make that laser shot. will you release a demo for people to try when it's ready? :D I have no plans to release a demo. bummer. so it will just be the full game for sale at some point with no way to try it out?

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Mon Aug 05, 2024 7:57 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	segasonicfan wrote bummer. so it will just be the full game for sale at some point with no way to try it out? That's right. It's a pretty simple arcade game, trailers and videos will give you a pretty good idea of what to expect, and the time I would spend making and releasing a demo can be spent on improving the game instead.

Dezanuebe Joined: 15 Aug 2005 Posts: 27 Location: Odivelas, Portugal	Posted: Sun Aug 11, 2024 6:20 pm
	badcomputer wrote segasonicfan wrote bummer. so it will just be the full game for sale at some point with no way to try it out? That's right. It's a pretty simple arcade game, trailers and videos will give you a pretty good idea of what to expect, and the time I would spend making and releasing a demo can be spent on improving the game instead. when will you release the game and how can we buy a copy? cheers.

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Mon Aug 12, 2024 6:59 am
badcomputer Joined: 19 Oct 2023 Posts: 183	Dezanuebe wrote when will you release the game and how can we buy a copy? cheers. Probably released in 2025. I plan to release the digital version on itch.io, possibly physical release later.

Dezanuebe Joined: 15 Aug 2005 Posts: 27 Location: Odivelas, Portugal	Posted: Thu Aug 15, 2024 4:14 pm
	badcomputer wrote Dezanuebe wrote when will you release the game and how can we buy a copy? cheers. Probably released in 2025. I plan to release the digital version on itch.io, possibly physical release later. Thanks for the reply. Will buy a physical copy for sure.

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Thu Aug 22, 2024 7:50 am
badcomputer Joined: 19 Oct 2023 Posts: 183	Back to work, implementing the player bomb. Initial mockup for the bomb animation (minus collision shapes). I plan to alternate drawing frames with enemy sprites. If it works well then maybe I can add 1 or 2 animation frames to the bomb. Fortunately I can remove enemy bullets when the bomb triggers (as a gameplay benefit for the player) so I will only need to draw enemies on the bomb-off frame. I haven't decided yet whether the game will pause for the effect, to make it more dramatic, I need to test it.

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Fri Aug 23, 2024 8:01 am
badcomputer Joined: 19 Oct 2023 Posts: 183	I settled on a simpler bomb sprite to keep more explosions, which seems better for now. I might come back to it but for now I'm moving on to the next thing.

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Fri Aug 23, 2024 4:05 pm
badcomputer Joined: 19 Oct 2023 Posts: 183	I need some second opinions on this. If the player can only move left and right, how would you want to assign the buttons yourself for the following actions? - shoot (can be held down for auto-fire, but there is ammo so you may want to stop firing eventually) - fire one bomb (upwards) - switch weapon left - switch weapon right

Kagesan Joined: 01 Feb 2014 Posts: 893	Posted: Sat Aug 24, 2024 6:38 am
Kagesan Joined: 01 Feb 2014 Posts: 893	Shoot: Button 2 Bomb: Button 1 Switch weapon left: D-pad down Switch weapon right: D-pad up would be my choices.

badcomputer Joined: 19 Oct 2023 Posts: 183	Posted: Sat Aug 24, 2024 6:57 am
badcomputer Joined: 19 Oct 2023 Posts: 183	Thanks Kagesan. So far I've gone with Maxim's suggestion on the Discord as the default, only because it feels more natural with left and right switchign on screen: Shoot: Button 1 Bomb: Button 2 Switch weapon left: D-pad down + Button 1 Switch weapon right: D-pad down + Button 2 There will also be an option to use bombs as laser ammo instead, so when the laser runs out of ammo it will automatically take 1 bomb and refill laser ammo. The laser is unique as it generates more score bonuses, but bombs are obviously useful for survival, so there's a trade off. Beginners would use the bomb, score chasers would use laser ammo. You can still fire bombs with the "bombs as laser refill" option selected though. Finally, I also added pause on the pad (console pause still works too): Pause Toggle: D-pad up + Button 2.

Kagesan Joined: 01 Feb 2014 Posts: 893	Posted: Sat Aug 24, 2024 7:55 am
Kagesan Joined: 01 Feb 2014 Posts: 893	That sounds reasonable to, even though I always prefer simple button presses to button combinations if possible. Still, I suggest switching around the shot and bomb buttons. The shot button is one that’s going to be held down a lot instead if just tapped, so it makes sense to use the outer button of the pad for that, because your thumb reaches for the buttons from the right and there’s a chance you might accidentally trigger a bomb if you’re forced to reach over the button to hold down the other one. When developing Pigarus I first had the shot button and speed switch button mapped to 1 and 2 respectively, but found out that it was a lot more comfortable to play with the buttons mapped the other way round.

Forums

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